While preparing the labs for “Audio over IP Networks for Events - An Opinionated Guide, Part 5: Using PIM-SM to distribute Multicast”, I discovered another weird bug in Arista cEOS, this time related to Multicast Routing.
The Bug
The default setting in cEOS is
router multicast
ipv4
software-forwarding kernel
!
ipv6
software-forwarding kernelWith this default setting, Multicast Routing is simply broken.
The topology is simple: A client / Multicast source is connected to VLAN 1 (specifically Ethernet 3) on delay-row2-right. The uplinks ports are Ethernet 1-2 and PIM-SM relationship with the neighbour is established:
delay-row2-right#show ip pim interface
Address Interface Mode Neighbor Hello DR DR Address PktsQed PktsDropped
Count Intvl Pri
10.8.0.1 Ethernet1 sparse 1 30 1 10.8.0.1 0 0
10.8.0.1 Ethernet2 sparse 1 30 1 10.8.0.1 0 0
10.8.10.1 Vlan1 sparse 0 30 1 10.8.10.1 0 0everything else, like router multicast ipv4 routing or rp-address is also configured of course.
We use the mcjoin tool included in the srl-labs/network-multitool to send some Multicast from the client attached to VLAN 1:
mcjoin -f 1000 -t 255 -i eth1 -s
mcjoin :: sending multicast 18m 48s
speaker1 (10.8.10.10@eth1) [Help | Toggle | Quit] Sun Nov 2 23:26:19 2025
Source,Group Plotter Packets
*,225.1.2.3 / [...............................................................................................] 1127
Time Log
Sun Nov 2 23:07:32 2025 Sending IPv4 multicast on eth1 addr, 10.8.10.10 ifindex: 1985, sd: 5Using Wireshark, we can see that the Multicast packets are indeed sent out to the switch: Dissected Test Multicast Packet
But on the switch we see… nothing:
delay-row2-right#show ip mroute
PIM Bidirectional Mode Multicast Routing Table
RPF route: U - From unicast routing table
M - From multicast routing table
PIM Sparse Mode Multicast Routing Table
Flags: E - Entry forwarding on the RPT, J - Joining to the SPT
R - RPT bit is set, S - SPT bit is set, L - Source is attached
W - Wildcard entry, X - External component interest
I - SG Include Join alert rcvd, P - Programmed in hardware
H - Joining SPT due to policy, D - Joining SPT due to protocol
Z - Entry marked for deletion, C - Learned from a DR via a register
A - Learned via Anycast RP Router, M - Learned via MSDP
N - May notify MSDP, K - Keepalive timer not running
T - Switching Incoming Interface, B - Learned via Border Router
V - Source is reachable via Evpn Tenant Domain
F - Learned via MVPN
RPF route: U - From unicast routing table
M - From multicast routing table
delay-row2-right#
delay-row2-right#show multicast fib ipv4
delay-row2-right#We can also see that the switch doesn’t even try to forward the Multicast packets:
delay-row2-right#show ip pim protocol counters
PIM Control Counters
Received Rx Error Rx Filtered Sent Tx Error Tx Filtered
Assert 0 0 0 0 0 0
Bootstrap Router 0 0 0 0 0 0
CRP Advertisement 0 0 0 0 0 0
DF Election 0 0 0 0 0 0
Graft 0 0 0 0 0 0
Graft Ack 0 0 0 0 0 0
Hello 192 0 0 292 0 0
Join/Prune 0 0 0 0 0 0
Register 0 0 0 0 0 0
Register Stop 0 0 0 0 0 0Register Sent stays at 0…
The Partial Workaround
Once again, we need a magic, undocumented command to work around this issue:
router multicast
ipv4
software-forwarding sfe
!
ipv6
software-forwarding sfe(don’t forget the router multicast ipv4 routing command as well)
software-forwarding sfe changes the Multicast forwarding engine / Multicast dataplane from Linux kernel based to Arista’s SFE (presumably “Software Forwarding Engine”). This dataplane is based on the on the open source Berkeley Extensible Software Switch (BESS), acccording to this Arista Community post, this Reddit TAC comment and this Arista TOI.
Once we do this, things magically start working looking better!
software-forwarding sfe, the Multicast forwarding is still broken. Traffic only sometimes starts flowing after a random, longer (5 minutes) amount of time with no topology changes or anything. Also, no changes in the Multicast FIB in this time… But sometimes suddenly traffic starts flowing. But sometimes it doesn’t. Very weird. Maybe this is related to platform tfa personality - According to Arista, arfa should be pretty feature complete, while python is legacy, but the TOI mentions that python should be used if Multicast is needed..delay-row2-right>show ip mroute
PIM Bidirectional Mode Multicast Routing Table
RPF route: U - From unicast routing table
M - From multicast routing table
PIM Sparse Mode Multicast Routing Table
Flags: E - Entry forwarding on the RPT, J - Joining to the SPT
R - RPT bit is set, S - SPT bit is set, L - Source is attached
W - Wildcard entry, X - External component interest
I - SG Include Join alert rcvd, P - Programmed in hardware
H - Joining SPT due to policy, D - Joining SPT due to protocol
Z - Entry marked for deletion, C - Learned from a DR via a register
A - Learned via Anycast RP Router, M - Learned via MSDP
N - May notify MSDP, K - Keepalive timer not running
T - Switching Incoming Interface, B - Learned via Border Router
V - Source is reachable via Evpn Tenant Domain
F - Learned via MVPN
RPF route: U - From unicast routing table
M - From multicast routing table
225.1.2.3
10.8.10.10, 0:22:05, flags: SLP
Incoming interface: Vlan1
RPF route: [U] 10.8.10.0/24 [0/0]
Outgoing interface list:
Ethernet1
delay-row2-right>
delay-row2-right>
delay-row2-right>show multicast fib ipv4
Activity poll time: 60 seconds
225.1.2.3 10.8.10.10
Vlan1 (iif)
Ethernet1
delay-row2-right>Now, we can see the Multicast FIB populated!
delay-row2-right>show ip pim protocol counters
PIM Control Counters
Received Rx Error Rx Filtered Sent Tx Error Tx Filtered
Assert 0 0 0 104 0 0
Bootstrap Router 0 0 0 0 0 0
CRP Advertisement 0 0 0 0 0 0
DF Election 0 0 0 0 0 0
Graft 0 0 0 0 0 0
Graft Ack 0 0 0 0 0 0
Hello 92 1 0 153 0 0
Join/Prune 33 0 0 0 0 0
Register 0 0 0 76 3 0
Register Stop 25 0 0 0 0 0Now, Register Sent is increasing, and we can see Multicast traffic flowing through the switch:
Sadly, traffic still does not flow properly and stops at some intermediate router in this topology, which has the FIB populated correctly as well, receives the packets but simply decides to not forward them.
I am confident that my topology and config is correct (after all, the Multicast FIB is populated correctly), therefore I consider Multicast Routing in Arista cEOS to be broken as of version 4.35.0F using the default platform tfa personality arfa setting.
More investigation is needed to find out whether platform tfa personality python could fix this issue or has other side effects.