From: Bit Gossip (bit.gossip@chello.nl)
Date: Sun Mar 25 2007 - 17:31:22 ART
No doubt that without 'ip pim nbma-mode', if a router has to forward a mcast
packet to the logical ip subnet behind the serial interface, it will forward
it accross all pvc's.
But if it receives the mcast frame from one pvc of the serial interface, it
should not forward it to the other pvc's of the same physical interface.
And indeed if I ping 224.0.0.13 from a spoke router only the hub reply,
because all other spoke don't receive the mcast pkt.
What is strange is how can one spoke receive the prune from another spoke
which is also mcast to 224.0.0.13 with ttl=1 ??????
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 9:49 PM
Subject: Re: multicast very fundamental
> Without ip pim nbma-mode, R2 forwards mcast traffic out of all PVCs. It
> doesn't know the serial interface is shared by multiple PVCs.
> With ip nbma-mode, pim will acknowledge the PVCs independently.
>
> You can see the differences on the 'show ip mroute' command with and
without
> ip nbma-mode. With ip nbma-mode, it shows each neighbors
> ip address. Without ip nbma-mode, it just shows in the interface.
>
> ----- Original Message -----
> From: "Bit Gossip" <bit.gossip@chello.nl>
> To: "ccielab" <ccielab@groupstudy.com>
> Sent: Sunday, March 25, 2007 11:37 AM
> Subject: Re: multicast very fundamental
>
>
> >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
> >> >
> >> >
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:52 ART