Arista EOS PIM-SM Multicast Configuration

Multicast on Arista EOS is configured in a handful of commands and diagnosed by an even smaller set of show commands, yet it fails in ways that look like routing problems. The reason is RPF: PIM builds its tree using the unicast routing table, so an mroute that never appears in show ip mroute is almost always a missing route or an asymmetric path rather than a PIM fault. This guide builds a working PIM sparse mode domain on EOS — RP configuration, IGMP on the receiver segment, snooping on the access layer, anycast RP for redundancy — and finishes with the verification sequence that tells you exactly which hop is not forwarding.

Enable multicast and PIM

! 1) IP multicast routing must be on (it is off by default in EOS)
switch(config)# ip multicast-routing
switch(config)# ip routing

! 2) the PIM process (sparse mode)
switch(config)# router pim sparse-mode
switch(config-router-pim-sparse)# rp address 10.10.0.10
switch(config-router-pim-sparse)# ipv4

! 3) enable PIM on the interfaces that face sources and receivers
switch(config)# interface Vlan10
switch(config-if-Vl10)# pim ipv4 sparse-mode
switch(config-if-Vl10)# ip igmp version 2
switch(config-if-Vl10)# exit

switch(config)# interface Vlan20
switch(config-if-Vl20)# pim ipv4 sparse-mode

Enabling PIM on an interface also enables IGMP on that interface, which is why the receiver VLAN needs no separate IGMP command. Verify the RP mapping before adding receivers — a wrong RP address produces an mroute that exists but never receives traffic.

switch# show ip pim rp mapping
switch# show ip pim interface
switch# show ip pim neighbor

RP design: static, anycast, or both

A single static RP is fine in a lab and unacceptable in production, because the RP is a control-plane dependency for every new group. Arista supports anycast RP using MSDP for source discovery between RPs sharing the same address:

! both RPs advertise the same loopback /32 (10.10.0.10) via OSPF
interface Loopback10
   ip address 10.10.0.10/32
!
router msdp
   ipv4
   !
   peer 10.10.0.11
!
! each RP also peers with the other on a unique loopback address for MSDP
interface Loopback0
   ip address 10.10.0.11/32

The RP is also the natural place to filter. Restrict which groups and sources the RP will serve so an accidental source in a lab cannot create state across the whole domain:

router pim sparse-mode
   rp address 10.10.0.10
   ipv4
   !
   ipv4 rp-address-filter PIM-RP-FILTER
!
ip access-list PIM-RP-FILTER
   10 permit ip 10.200.0.0/16 any
   20 deny ip any any

IGMP snooping on the access layer

switch(config)# ip igmp snooping
switch(config)# interface Vlan10
switch(config-if-Vl10)# ip igmp snooping querier
switch(config-if-Vl10)# ip igmp snooping
switch(config-if-Vl10)# ip igmp snooping immediate-leave

Without snooping, an access VLAN floods every multicast frame to every port. Enable it globally and make at least one switch in each VLAN a querier so membership expires correctly when the elected querier is a device that does not send queries. immediate-leave speeds up channel changes for IPTV-style traffic but should be used with care where multiple hosts share a port.

Choosing between PIM-SM, SSM and IGMPv3

If your application can specify sources — most video distribution, market data and replication products can — SSM removes the RP from the data path entirely and is the more robust design. On the receiving hosts it requires IGMPv3, so verify host support before committing to it.

Verification: prove forwarding, not just configuration

switch# show ip mroute
switch# show ip mroute 239.1.1.1 detail
switch# show ip mroute count
switch# show ip pim neighbor
switch# show ip pim rp mapping
switch# show ip igmp groups
switch# show ip igmp snooping groups vlan 10
switch# show ip multicast fib summary

A healthy mroute shows an incoming interface, a populated outgoing interface list and, for a group with an active source, an (S,G) entry alongside the (*,G). Non-zero packet counts on the (S,G) entry are the only true proof that multicast data is flowing — an entry with zero packets and a correct RPF interface means the source is not sending, or the sender is using the wrong group.

Troubleshooting the four classic failures

1. No mroute at all: check show ip mroute after a receiver joins. If the *,G is missing, the receiver's IGMP report is not reaching the first-hop router — look at snooping querier election and VLAN membership.
2. mroute present but no traffic (RPF failure): the source is reachable via a different interface than the one the packet arrives on. Confirm with show ip route <source> and fix the unicast path or use a static mroute during the outage.
3. Traffic flows then stops: the source stopped sending and the (S,G) aged out, or a PIM assert is flapping because two routers share a LAN segment with different metrics. Check show ip pim neighbor for duplicated neighbours on the same subnet.
4. Only some receivers work: snooping on the access switch has not learned the group, or the VLAN on that switch has no querier. show ip igmp snooping groups localises it to one switch.

Patterns that scale

• Keep sources and receivers in different VLANs and enable PIM on the SVI of each; a receiver VLAN with no PIM interface will never join.
• Use the same RP design on every device in the domain, and verify with show ip pim rp mapping on a random sample of switches after any change.
• Monitor group count and mroute count as capacity metrics — a switch with thousands of active groups has different silicon resource needs than one with a handful.
• Reuse the same first-hop redundancy design as your unicast services so a failover does not break multicast in a way unicast hides.
• For a full design view of where multicast sits in the data centre, the PIM-SM RP and RPF verification guide covers the generic model, and the IGMP snooping configuration guide explains the layer-2 side in more depth.

原文链接：https://www.arista.com/en/um-eos/eos-protocol-independent-multicast