Re: multicast very fundamental posted 03/25/2007
Bit Gossip wrote:
Group I am stuck for days on this very fundamental multicast
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
*) Frame relay hub'n'spoke with r2=hub, only serial physical interfaces
*) Full reachability via OSPF
*) PIM-SM with r2=RP; multicast source=18.104.22.168 attached to r2 f1/0
for group 22.214.171.124; 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 126.96.36.199, not to us
PIM(0): Prune-list: (*, 188.8.131.52) RP 184.108.40.206
PIM(0): Set join delay timer to 1000 msec for (220.127.116.11/32,
18.104.22.168) on Serial0/0
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
PIM(0): Insert (*,22.214.171.124) join in nbr 126.96.36.199's queue
PIM(0): Building Join/Prune packet for nbr 188.8.131.52
Given the following, it seems to me that this result SHOULD surprise you!
1. PIM prunes are sent to the all PIM routers address: 184.108.40.206.
2. Each PVC is a separate broadcast domain (traffic to 220.127.116.11 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