GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: multicast very fundamental posted 03/25/2007
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


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@xxxxxxxxxxxxxxx>
To: "Bit Gossip" <bit.gossip@xxxxxxxxx>
Cc: "ccielab" <ccielab@xxxxxxxxxxxxxx>
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