Does anyone know of the default setting for the PIM DM prune limit timer in Cisco's implementation? This is the timer used to prevent a node from sending an upstream prune in response to every incoming packet (see RFC 3973, sec 4.4.1).
In a lab setting I am seeing results that differ from what is described in the RFC as outlined below.
Consider a three node network R1, R2, R3; each router has a single loopback l0 and a single ethernet interface.
The ethernet interfaces are on the same L2 domain with all three interfaces in the same IP subnet, e.g, 10.0.0.1, 10.0.0.2, and 10.0.0.3.
Assume R3 has a receiver on group G configured with:
interface loopback 0
ip igmp join-group G
and R1 sends icmp pings with:
ping G repeat 100 source l0
From my understanding of the RFC the expected behavior is:
R2 - with no receiver - will send a PRUNE upstream to R1.
R1 will set its prune pending timer and also send a PRUNE ECHO - prune packet with itself as the upstream neighbor
R3 will override with PRUNE with a JOIN
R2 will continue to receive packets for group G on it's RPF interface but will not send another PRUNE until its prune limit timer - per RFC the default value is 210s - has expired.
After the prune limit timer has expired on R2, the next packet received will trigger a new PRUNE.
In short, the pattern of three packets, PRUNE, PRUNE ECHO, JOIN - should be repeated aproximately every 210s.
What is I have observed in the lab using three CSR1000Vs is:
* an initial PRUNE from R2 followed by a PRUNE override from R3.
* after approximately 125 s R2 sends another PRUNE, followed by R1 sending a PRUNE ECHO and then a JOIN from R3.
* this three packet pattern the repeats approximately every 10s.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...