From: Bit Gossip (bit.gossip@chello.nl)
Date: Sun Mar 25 2007 - 12:37:55 ART
I agree that the only explanation is that r2 somehow forwards multicast
prune from r3 to r1
But this is against all my understanding so far ....:-(
Do you mind to expand on your explanation?
Thanks,
Luca.
----- Original Message -----
From: "Edison Ortiz" <edisonmortiz@gmail.com>
To: "Bit Gossip" <bit.gossip@chello.nl>; "ccielab" <ccielab@groupstudy.com>
Sent: Sunday, March 25, 2007 4:12 PM
Subject: Re: multicast very fundamental
> You need to enable pim nbma mode in R2's serial interface to avoid the
> flooding from spoke to spoke.
>
> ----- Original Message -----
> From: "Bit Gossip" <bit.gossip@chello.nl>
> To: "ccielab" <ccielab@groupstudy.com>
> Sent: Sunday, March 25, 2007 6:54 AM
> Subject: multicast very fundamental
>
>
> > 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
> >
> >
> >
> > This one is a classical example mentioned in Cisco doc, where PIM-SM
> > goes into trouble because one spoke cannot hear the prune from another
> > one and then override it; but in my lab it doesn't seem to happen....
> >
> > Below this line config and show's
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > r1
> >
> > ip multicast-routing
> > interface Loopback0
> > ip address 150.1.1.1 255.255.255.0
> > ip pim sparse-dense-mode
> > ip igmp join-group 228.28.28.28
> > !
> > interface FastEthernet0/0
> > ip address 132.1.17.1 255.255.255.0
> > ip pim sparse-mode
> > speed 100
> > full-duplex
> > !
> > interface Serial0/0
> > ip address 132.1.0.1 255.255.255.0
> > ip pim sparse-mode
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > no fair-queue
> > clock rate 64000
> > frame-relay map ip 132.1.0.2 102 broadcast
> > no frame-relay inverse-arp
> > !
> > router ospf 1
> > router-id 150.1.1.1
> > log-adjacency-changes
> > passive-interface default
> > no passive-interface Serial0/0
> > network 132.1.0.1 0.0.0.0 area 0
> > network 132.1.17.1 0.0.0.0 area 0
> > network 150.1.1.1 0.0.0.0 area 0
> > !
> > ip pim rp-address 150.1.2.2
> > ip pim spt-threshold infinity
> >
> > --------
> >
> > r1#show frame-relay map
> > Serial0/0 (up): ip 132.1.0.2 dlci 102(0x66,0x1860), static,
> > broadcast,
> > CISCO, status defined, active
> > r1#ping 224.0.0.2
> >
> > Type escape sequence to abort.
> > Sending 1, 100-byte ICMP Echos to 224.0.0.2, timeout is 2 seconds:
> >
> > Reply to request 0 from 132.1.17.7, 4 ms
> > Reply to request 0 from 132.1.0.2, 88 ms
> > Reply to request 0 from 150.1.1.1, 4 ms
> >
> > r1#show ip mroute 228.28.28.28
> > IP Multicast Routing Table
> >
> > (*, 228.28.28.28), 00:49:48/00:02:58, RP 150.1.2.2, flags: SCL
> > Incoming interface: Serial0/0, RPF nbr 132.1.0.2
> > Outgoing interface list:
> > Loopback0, Forward/Sparse-Dense, 00:47:47/00:02:39
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > r2
> >
> > ip multicast-routing
> > !
> > interface Loopback0
> > ip address 150.1.2.2 255.255.255.0
> > ip pim sparse-mode
> > !
> > interface FastEthernet1/0
> > ip address 132.1.26.2 255.255.255.0
> > ip pim sparse-mode
> > no ip mroute-cache
> > duplex full
> > !
> > interface Serial4/0
> > ip address 132.1.0.2 255.255.255.0
> > ip pim sparse-mode
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > no ip mroute-cache
> > serial restart-delay 0
> > frame-relay lmi-type cisco
> > !
> > router ospf 1
> > router-id 150.1.2.2
> > log-adjacency-changes
> > passive-interface default
> > no passive-interface Serial4/0
> > network 132.1.0.2 0.0.0.0 area 0
> > network 132.1.26.2 0.0.0.0 area 0
> > network 150.1.2.2 0.0.0.0 area 0
> > !
> > ip pim rp-address 150.1.2.2
> >
> > --------
> >
> > r2#show frame-relay map
> > Serial4/0 (up): ip 132.1.0.1 dlci 201(0xC9,0x3090), dynamic,
> > broadcast,
> > CISCO, status defined, active
> > Serial4/0 (up): ip 132.1.0.3 dlci 203(0xCB,0x30B0), dynamic,
> > broadcast,, status defined, active
> > r2#ping 224.0.0.2
> >
> > Type escape sequence to abort.
> > Sending 1, 100-byte ICMP Echos to 224.0.0.2, timeout is 2 seconds:
> >
> > Reply to request 0 from 150.1.2.2, 1 ms
> > Reply to request 0 from 132.1.0.1, 76 ms
> > Reply to request 0 from 132.1.0.3, 64 ms
> >
> > r2#show ip mroute 228.28.28.28
> > IP Multicast Routing Table
> >
> >
> > (*, 228.28.28.28), 01:01:35/00:03:10, RP 150.1.2.2, flags: S
> > Incoming interface: Null, RPF nbr 0.0.0.0
> > Outgoing interface list:
> > Serial4/0, Forward/Sparse, 00:50:51/00:03:10
> >
> > (132.1.26.8, 228.28.28.28), 00:01:18/00:03:22, flags: T
> > Incoming interface: FastEthernet1/0, RPF nbr 0.0.0.0
> > Outgoing interface list:
> > Serial4/0, Forward/Sparse, 00:01:18/00:03:10
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > r3
> >
> > ip multicast-routing
> > !
> > interface Loopback0
> > ip address 150.1.3.3 255.255.255.0
> > !
> > interface FastEthernet3/0
> > ip address 132.1.33.3 255.255.255.0
> > ip pim sparse-mode
> > ip policy route-map T8.2
> > duplex full
> > !
> > interface Serial4/0
> > bandwidth 512
> > ip address 132.1.0.3 255.255.255.0
> > ip pim sparse-mode
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > serial restart-delay 0
> > frame-relay map ip 132.1.0.2 302 broadcast
> > no frame-relay inverse-arp
> > !
> > router ospf 1
> > router-id 150.1.3.3
> > log-adjacency-changes
> > passive-interface default
> > no passive-interface Serial4/0
> > network 132.1.0.3 0.0.0.0 area 0
> > network 132.1.3.3 0.0.0.0 area 0
> > network 132.1.33.3 0.0.0.0 area 0
> > network 150.1.3.3 0.0.0.0 area 0
> > !
> > ip pim rp-address 150.1.2.2
> > ip pim spt-threshold infinity
> >
> > -----------
> >
> > r3#show frame-relay map
> > Serial4/0 (up): ip 132.1.0.2 dlci 302(0x12E,0x48E0), static,
> > broadcast,
> > CISCO, status defined, active
> > r3#ping 224.0.0.2
> >
> > Type escape sequence to abort.
> > Sending 1, 100-byte ICMP Echos to 224.0.0.2, timeout is 2 seconds:
> >
> > Reply to request 0 from 132.1.0.2, 116 ms
> >
> > r3#show ip mroute 228.28.28.28
> > IP Multicast Routing Table
> >
> > (*, 228.28.28.28), 00:02:13/00:02:59, RP 150.1.2.2, flags: SCL
> > Incoming interface: Serial4/0, RPF nbr 132.1.0.2
> > Outgoing interface list:
> > FastEthernet3/0, Forward/Sparse, 00:02:13/00:02:33
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:52 ART