From: Bit Gossip (bit.gossip@chello.nl)
Date: Tue Mar 27 2007 - 16:09:09 ART
Happy to hear that I am not the only one to experience this 'behind the
curtains' prune override.
As a consequence of this behaviour, the only real benifit of 'ip pim
nbma-mode' is:
- efficiency in sending the group to only PVCs that really want it
- performance in that in can be performed in CEF mode instead of process
switch
Would be interesting to know when this feature was introduced and how it is
called ....
Thanks,
Luca.
----- Original Message -----
From: "Bob Sinclair" <bob@bobsinclair.net>
To: "Bit Gossip" <bit.gossip@chello.nl>
Cc: "ccielab" <ccielab@groupstudy.com>
Sent: Tuesday, March 27, 2007 12:26 AM
Subject: Re: multicast very fundamental
> 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