PIM Duplicate Traffic Troubleshooting

Load pim.dup.traffic.tshoot.cfg in the Russo SPv4 lab in EVE-NG.

#IOS-XE
config replace flash:pim.dup.traffic.tshoot.cfg
 
#IOS-XR
configure
load bootflash:pim.dup.traffic.tshoot.cfg
commit replace
y

R5 is connected to a LAN segment, with R10 and R6 as HSRP gateways. R5 has joined (*, 239.1.2.3).

When R3 pings this group, R5 receives duplicate traffic. Explain the issue and find a way to fix it.

Answer

#R6, R10
int gi2.100
 no ip pim passive
 ip pim sparse-mode

Explanation

Currently, R10 and R6 have ip pim passive set on the LAN interface. This can be used to prevent formation of a PIM adjacency on an interface facing receivers/senders, while still enable PIM functionality. However, when two routers connect to the LAN segment, each router will end up electing itself as PIM DR and create a distribution tree rooted at the source/RP.

On R10 and R6 we see that Gi2.100 is enabled in mode “passive” and each believes it is the DR.

Due to this, both routers build a (*, G) rooted at the RP, which is XR4. On XR4 we see there are two outgoing interfaces in the OIL. One leading to R10 and one leading to R6.

Once the traffic is seen, it switches over to a SPT. R6 branches this traffic out onto the LAN and to R10. Also notice above that gi2.100 is operating in sparse-dense mode when using ip pim passive.

Because the interfaces are running in PIM passive mode, no PIM assert is sent on the LAN. This would normally be used in PIM-DM to stop this duplicate traffic. Instead, we should run in normal PIM-SM mode where there are multiple routers on a receiver LAN.

#R6, R10
int gi2.100
 no ip pim passive
 ip pim sparse-mode

The routers now elect a DR. R6 is elected for the highest IP.

Now that R10 is no longer a DR, it prunes itself from the (*, G) and (S, G) tree. R6 is the only router that should send PIM Joins on behalf of clients on the Gi2.100 LAN. The duplicate traffic is no longer seen.

Note that this feature (ip pim passive) does not appear to be available on IOS-XR. This is likely because on IOS-XE, this runs the interface in sparse-dense mode, and sparse-dense mode isn’t supported on IOS-XR. Instead you can use a neighbor filter on IOS-XR and deny any any, but the PIM Assert process appears to still work in this case, so you wouldn’t see duplicate traffic on the LAN.