Re: multicast very fundamental

[Bob Sinclair <bob@xxxxxxxxxxxxxxx>]

Bit Gossip wrote:
> Group I am stuck for days on this very fundamental multicast
> mechanics...
> I noticed this strange thing while playing with the multicast task of
> IEWB4-LAB02 and couldn't get to the bottom of it; then I gave up.
> Now I have reproduced it in a very simple scenario, and the pb is still
> there.
>
>         r1
>         |
>         |  
> r2 ----< 
>         |
>         |
>         r3
>
> *) Frame relay hub'n'spoke with r2=hub, only serial physical interfaces
> *) Full reachability via OSPF
> *) PIM-SM with r2=RP; multicast source=132.1.26.8 attached to r2 f1/0
> for group 228.28.28.28; receivers attached to r1 and r3
> *) it works fine, all receivers get the group
>
> And now the funny part !!
> *) there is no layer 2 connectivity between r1 and r3 as you can see
> below; but still r1 HEARS the prune from r3 and OVERRIDES it !!!!!!!!
> How is it possible ??????
>
> When r3 leaves the group this is the pim debug on r1:
>
> PIM(0): Received v2 Join/Prune on Serial0/0 from 132.1.0.3, not to us
> PIM(0): Prune-list: (*, 228.28.28.28) RP 150.1.2.2
> PIM(0): Set join delay timer to 1000 msec for (150.1.2.2/32,
> 228.28.28.28) on Serial0/0
> PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
> 228.28.28.28
> PIM(0): Insert (*,228.28.28.28) join in nbr 132.1.0.2's queue
> PIM(0): Building Join/Prune packet for nbr 132.1.0.2
>   
Bit Gossip,

Given the following, it seems to me that this result SHOULD surprise you!  

1.  PIM prunes are sent to the all PIM routers address:  224.0.0.13.

2.  Each PVC is a separate broadcast domain (traffic to 224.0.0.13 is 
not normally forwarded between PVCs)

3.  You have a hub and spoke topology, where R1 and R3 are spokes.

It seems to me that one of the three statements above must be false.  I 
would bet a diet Pepsi on number 3.  Could you do "show frame PVC" and 
verify that R1 has only 1 Active-Local DLCI? 

--


Bob Sinclair CCIE 10427 CCSI 30427
www.netmasterclass.net