From: Bob Sinclair (bob@bobsinclair.net)
Date: Mon Mar 26 2007 - 19:26:54 ART
Bit Gossip wrote:
> Bob,
> thank you very much for the config; I have uploaded it and I see exactly
> the behavior that I was complaining about:
> - while r1 (hub) continuously ping 231.1.1.1
> - r3 leaves the group sending a prune to 224.0.0.13
> - r2 mysteriously hears the prune and sends a join (*,231.1.1.1) to r1
> to override it
>
> It is important to notice that r3 should leave the group while there is
> traffic for the group because in the cisco pim-sm implementation a
> router sends a prune only after receiving the first undesired packet of
> the group it wants to leave. Did you execute the test in this condition?
>
You were spot on regarding testing my testing procedures. When I follow
your instructions I get exactly your result. With R1 as hub, R2
receives a prune from R3. Here you see debug of ip packet and pim at
the crucial moment on R2;
*Mar 1 00:35:45.651: IP: s=172.16.123.3 (Serial1/0), d=224.0.0.13, len
54, rcvd 0, proto=103
*Mar 1 00:35:45.659: PIM(0): Received v2 Join/Prune on Serial1/0 from
172.16.123.3, not to us
Note that the spoke R2 is getting a PIM packet with a source address of
the other spoke. Even though there is NO direct PVC and the spokes are
not PIM neighbors.
As you probably know, this does not happen when nbma-mode is configured.
I have to believe that the hub, R1, is re-sending this prune out the hub
interface with the original IP address. Looks like Cisco has
implemented a prune override in this circumstance. Can find no
documentation on it, though.
Interesting!!
--Bob Sinclair CCIE 10427 CCSI 30427 www.netmasterclass.net
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART