From: Bit Gossip (bit.gossip@chello.nl)
Date: Sun Mar 25 2007 - 13:45:36 ART
Hi Bob,
I am happy someone is helping me because am out of option and want to get to
the bottom of this
I was sure that there is no pvc between r3 and r1, but I relabb it, and here
is the confirmation:
r3#show frame-relay map
Serial4/0 (up): ip 132.1.0.2 dlci 302(0x12E,0x48E0), dynamic,
broadcast,, status defined, active
r3#show fram
r3#show frame-relay pvc
PVC Statistics for interface Serial4/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 302, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0
input pkts 40 output pkts 28 in bytes 2482
out bytes 1990 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 18 out bcast bytes 1118
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:02:30, last time pvc status changed 00:02:30
r3#show ip igmp group
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
Group Accounted
228.28.28.28 Loopback0 00:03:06 00:02:37 150.1.3.3
224.0.1.40 Loopback0 00:03:06 00:02:41 150.1.3.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and here the debug from r1 when r3 lo0 leaves the group
r1#debug ip pim
PIM debugging is on
r1#
*Mar 1 00:42:06.111: PIM(0): Received RP-Reachable on Serial0/0 from
150.1.2.2
*Mar 1 00:42:06.111: for group 228.28.28.28
*Mar 1 00:42:32.227: PIM(0): Received v2 Join/Prune on Serial0/0 from
132.1.0.3, not to us
*Mar 1 00:42:32.231: PIM(0): Prune-list: (*, 228.28.28.28) RP 150.1.2.2
*Mar 1 00:42:32.231: PIM(0): Set join delay timer to 3000 msec for
(150.1.2.2/32, 228.28.28.28) on Serial0/0
*Mar 1 00:42:35.203: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit)
Prune message for 228.28.28.28
*Mar 1 00:42:35.203: PIM(0): Insert (*,228.28.28.28) join in nbr
132.1.0.2's queue
*Mar 1 00:42:35.203: PIM(0): Building Join/Prune packet for nbr 132.1.0.2
Thanks,
Luca.
----- Original Message -----
From: "Bob Sinclair" <bob@bobsinclair.net>
To: "Bit Gossip" <bit.gossip@chello.nl>
Cc: "ccielab" <ccielab@groupstudy.com>
Sent: Sunday, March 25, 2007 3:55 PM
Subject: Re: multicast very fundamental
> 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
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:52 ART