I'm trying to test pim dense mode over dmvpn and the results i got shocked me. As per classic nbma behaviour, when a spoke sends a prune message, the other spokes cannot hear it and can't send prune overrides. So, the traffic is pruned if at least 1 spoke doesn't want it.
However this is the result i got from the testing it
Summary
- R3 sends prune to R1
- R1 forward the prune back to R2 and R3, it wants to prune the group (172.16.1.6,226.6.6.6) ---- This is where things got interesting!
- R2 replies with a join back to R1 for (172.16.1.6,226.6.6.6) - Prune override (expected)
- R1 doesn't prune the traffic
I noticed that each time R3 sends a prune, R1 forwards the prune out to R2 also. R2 replies with a prune override and the result is that the traffic is not pruned.
Is this an optimization for PIM Dense mode to run well over nbma or am i missing something here.
R3 sends prune
Jan 17 09:44:17.092: PIM(0): Insert (172.16.1.6,226.6.6.6) prune in nbr 172.16.123.1's queue
*Jan 17 09:44:17.092: PIM(0): Building Join/Prune packet for nbr 172.16.123.1
*Jan 17 09:44:17.092: PIM(0): Adding v2 (172.16.1.6/32, 226.6.6.6) Prune
*Jan 17 09:44:17.092: PIM(0): Send v2 join/prune to 172.16.123.1 (Tunnel0)
R1 forwards the prune to both R2 and R3, R3 gets it but ignores it
Jan 17 09:44:17.111: PIM(0): Received v2 Join/Prune on Tunnel0 from 172.16.123.1, not to us
*Jan 17 09:44:17.112: PIM(0): Prune-list: (172.16.1.6/32, 226.6.6.6)
R1 forwards the prune to both R2 and R3, but R2 replies with prune override (join)
Jan 17 09:44:17.115: PIM(0): Received v2 Join/Prune on Tunnel0 from 172.16.123.1, not to us
*Jan 17 09:44:17.115: PIM(0): Prune-list: (172.16.1.6/32, 226.6.6.6)
*Jan 17 09:44:17.115: PIM(0): Set join delay timer to 500 msec for (172.16.1.6/32, 226.6.6.6) on Tunnel0
*Jan 17 09:44:17.534: PIM(0): Insert (172.16.1.6,226.6.6.6) join in nbr 172.16.123.1's queue
*Jan 17 09:44:17.535: PIM(0): Building Join/Prune packet for nbr 172.16.123.1
*Jan 17 09:44:17.535: PIM(0): Adding v2 (172.16.1.6/32, 226.6.6.6) Join
*Jan 17 09:44:17.535: PIM(0): Send v2 join/prune to 172.16.123.1 (Tunnel0)
As a Result, R1 doesn't prune the traffic
*Jan 17 09:44:17.539: PIM(0): Received v2 Join/Prune on Tunnel0 from 172.16.123.2, to us
*Jan 17 09:44:17.540: PIM(0): Join-list: (172.16.1.6/32, 226.6.6.6)
*Jan 17 09:44:17.540: PIM(0): Update Tunnel0/172.16.123.2 to (172.16.1.6, 226.6.6.6), Forward state, by PIM SG Join
See topology below
