Oh, that's a GREAT point. R2 is joining (S,G) with an input interface of its local FR link. However, if the hub actually sends it traffic, it is sending a prune to the hub for (S,G). While this doesn't make any sense on partial-mesh FR, it makes a LOT of sense if PIM is assuming that the interface is full-mesh multi-access.
The ultimate solution is to not source mcast traffic off of a partial-mesh FR spoke link. Thanks for your insight! Keller Giacomarro [email protected] On Tue, Nov 13, 2012 at 2:07 AM, Antoine Monnier <[email protected] > wrote: > Hi, > > Interesting thread. > > I think the recommendation of adding a loopack on the source router > and use it as the source of the ping will allow you to work around > this issue. > > But to come back on your first setup, my take on this is that it > really is a corner case : > > - I do not believe the receiver (R2) is trying to switch from the RPT > to the SPT : I guess you did see the (S,G) RPT Prune message from R2 > to R1, but you did not see the (S,G) Join ? (even without ip pim > spt-threshold infinity) > > - R2 is sending this prune because the source S for the multicast flow > is on the same IP segment as its connected interface. Therefore, > according to the IP logic of broadcast network, R2 should receive it > directly. So it does not need to receive that specific (S,G) from the > RP and prunes it on the RPT. It does not need to create an SPT either > in this case. > > PIM by default treats all segment as broadcast network. PIM nbma-mode > allows to tweak PIM sparse-mode so that it treats each neighbor as on > a different point-to-point link, however I dont think enabling it on > R2 would solve the problem here as it is not a PIM problem per se. > > If you really wanted to make it work.... maybe bridging over > frame-relay ?! I've never encountered multicast over bridging over > frame ! > > BR > > > > On Tue, Nov 13, 2012 at 2:23 AM, Keller Giacomarro <[email protected]> > wrote: > > Hi all, > > > > Thanks for the information so far, been good to dig deep into this tech. > > > > Someone else recommended something -- add a loopback on your source > router, > > enable it for PIM, create statics from the other two routers to get to > it, > > and ping again. The (S,G) tree on the hub router still gets pruned off > for > > the FR interface's source IP, but the (S,G) for the source's loopback > > interface is left in-tact. > > > > It sounds like what Patrick is saying -- even with spt-threshold set to > > infinity, the SPT switchover is still happening. And R2, thinking that > its > > FR interface is a full-mesh multi-access interface, is sending a prune > for > > R1 to stop sending it RP based traffic. R2's intention is to cut off the > > flow via the RPT and instead use the SPT. Except that in this case, > > there's no way for it to know that the source is only reachable via the > RP. > > > > The solution seems to be to change the interface/IP structure. I am not > > currently seeing a way to ping with a source IP of the FR interface on R3 > > and get a response from any other spoke router on the FR cloud. They > will > > all prune off their only connection to the stream (the hub), believing > that > > they are doing SPT switchover. > > > > I will read the INE blog post and investigate further as well, but can > > anyone confirm or deny my thinking? > > > > Thanks! > > > > -Keller > > > > Keller Giacomarro > > [email protected] > > > > > > On Mon, Nov 12, 2012 at 4:45 PM, Baldwin, Patrick A. (MSFC-EO60)[HOSC > > SERVICES CONTRACT] <[email protected]> wrote: > > > >> > >> Keller, > >> > >> With certain topologies within PIM, it is not possible to prevent SPT > >> switchover, I believe your topology is one of those. > >> The article below covers this case and explains as well as possible that > >> PIM will automatically switchover in this case. > >> > >> > http://blog.ine.com/2011/01/14/understanding-advanced-pim-shared-tree-designs/ > >> > >> Since you have configured the topology such that 2&3 cannot communicate > >> with each other directly, they cannot form a PIM neighbor relationship. > >> > >> Therefore the traffic will drop when PIM cuts over to the SPT. > >> > >> There are many ways to fix this, I suppose it just depends on what your > >> constraints are: > >> > >> P2P sub interfaces > >> add a new PVC and frame-relay map statements between 2&3 > >> use a GRE tunnel between 2&3 > >> Change the L3 assignments such that they are on different subnets > >> > >> Others smarter than me may have more to say on the subject.... > >> > >> > >> Hope that helps > >> > >> Patrick A Baldwin > >> > >> > >> > >> ________________________________________ > >> From: [email protected] [ > >> [email protected]] On Behalf Of Keller Giacomarro [ > >> [email protected]] > >> Sent: Monday, November 12, 2012 1:56 PM > >> To: Bal Birdy > >> Cc: CCIE IPExpert OSL > >> Subject: Re: [OSL | CCIE_RS] Multicast over NBMA makes my brain hurt > >> > >> Great input all, thanks so far! My configs above are from me re-doing > the > >> scenario in 15.1. I've put it back into 12.4 (familiar territory), and > >> implemented your suggested changes. Same effect. > >> > >> * 12.4 Configs* > >> R1: http://pastebin.com/raw.php?i=sMdDzs4j > >> R2: http://pastebin.com/raw.php?i=uUXWippY > >> R3: http://pastebin.com/raw.php?i=HJqCGhgt > >> GNS: http://pastebin.com/raw.php?i=Fc8HpNyv > >> > >> Still seeing the same behavior. SPT-threshold is infinity on all > devices. > >> All loopbacks are in PIM. > >> > >> I believe that R2 is the culprit. It is trying to do SPT-switchover > (even > >> though it's disabled?!?), and is sending a PIM Prune towards the RP. > That > >> just happens to be the same DLCI as the SPT takes. > >> > >> Evidence: > >> > >> ! Before ping > >> R2#show ip mroute 229.0.0.2 > >> (*, 229.0.0.2), 00:00:03/00:02:56, RP 1.1.1.1, flags: SCL > >> Incoming interface: Serial0/0, RPF nbr 10.0.0.1 > >> Outgoing interface list: > >> Loopback0, Forward/Sparse, 00:00:03/00:02:56 > >> > >> ! Ping from R3 happens now > >> R2# > >> *Mar 1 00:03:08.295: PIM(0): Insert (10.0.0.3,229.0.0.2) sgr prune in > nbr > >> 10.0.0.1's queue > >> *Mar 1 00:03:08.303: PIM(0): Building Join/Prune packet for nbr > 10.0.0.1 > >> *Mar 1 00:03:08.303: PIM(0): Adding v2 (10.0.0.3/32, 229.0.0.2), > RPT-bit, > >> S-bit Prune > >> *Mar 1 00:03:08.307: PIM(0): Send v2 join/prune to 10.0.0.1 (Serial0/0) > >> > >> ! After ping from R3 > >> R2#show ip mroute 229.0.0.2 > >> (*, 229.0.0.2), 00:00:11/stopped, RP 1.1.1.1, flags: SCL > >> Incoming interface: Serial0/0, RPF nbr 10.0.0.1 > >> Outgoing interface list: > >> Loopback0, Forward/Sparse, 00:00:11/00:02:48 > >> > >> (10.0.0.3, 229.0.0.2), 00:00:03/00:02:59, flags: LJT > >> Incoming interface: Serial0/0, RPF nbr 0.0.0.0 > >> Outgoing interface list: > >> Loopback0, Forward/Sparse, 00:00:03/00:02:56 > >> > >> R2# > >> > >> While I know that we can use p2p subinterfaces, the lab I'm working > >> specifically uses the physical interfaces for all FR endpoints. Is > there > >> any way to make this work? > >> > >> Thanks for everyone's input! > >> > >> -Keller > >> > >> Keller Giacomarro > >> [email protected] > >> > >> > >> On Mon, Nov 12, 2012 at 5:27 AM, Keller Giacomarro <[email protected] > >> >wrote: > >> > >> > It could...except it's not! > >> > > >> > (config) ip pim spt-threshold infinity > >> > > >> > has no effect. It does ACT like an SPT switchover. R2 seems to be > >> > telling R1, "stop sending me traffic from the RP, I'm using SPT now". > >> But > >> > since SPT is via that same interface and via R1, it is cutting off its > >> own > >> > SPT. > >> > > >> > For your full review, if you like... > >> > R1: http://pastebin.com/raw.php?i=cHFzBDEh > >> > R2: http://pastebin.com/raw.php?i=Dn6ATSPM > >> > R3: http://pastebin.com/raw.php?i=yEwnnc8y > >> > GNS3: http://pastebin.com/raw.php?i=A4MnALTq > >> > > >> > Configs and GNS3 are written for IOS 15.1. I have also tried this in > >> 12.4 > >> > with identical results. > >> > > >> > Note that I did this in GNS3 after I experienced the problem with my > real > >> > equipment, so I do not believe this is a GNS3 problem. > >> > > >> > Thoughts appreciated! > >> > > >> > > >> > > >> > Keller Giacomarro > >> > [email protected] > >> > > >> > > >> > > >> > On Mon, Nov 12, 2012 at 4:56 AM, Bal Birdy <[email protected]> > >> wrote: > >> > > >> >> If the first ping gets through could this be spt switchover? > >> >> On Nov 12, 2012 8:03 PM, "Keller Giacomarro" <[email protected]> > >> wrote: > >> >> > >> >>> Okay, I must be totally missing the boat here, but I can't get > >> Multicast > >> >>> over NBMA to work AT ALL. > >> >>> > >> >>> R2-----\ > >> >>> -------- R1 > >> >>> R3-----/ > >> >>> > >> >>> All interfaces are physical interfaces with static ipv4 mappings. > R1 > >> has > >> >>> DLCIs to both spoke routers, and spoke routers only have DLCIs to > R1. > >> >>> This > >> >>> is as simple as I know how to get it. > >> >>> > >> >>> *** R1 *** > >> >>> interface Serial1/0 > >> >>> ip address 10.0.0.1 255.255.255.0 > >> >>> ip pim dr-priority 1000 > >> >>> ip pim nbma-mode > >> >>> ip pim sparse-mode > >> >>> encapsulation frame-relay > >> >>> frame-relay map ip 10.0.0.3 103 broadcast > >> >>> frame-relay map ip 10.0.0.2 102 broadcast > >> >>> no frame-relay inverse-arp > >> >>> ! > >> >>> interface Loopback0 > >> >>> ip address 1.1.1.1 255.255.255.0 > >> >>> ! > >> >>> ip pim rp-address 1.1.1.1 > >> >>> > >> >>> *** R2 *** > >> >>> interface Serial1/0 > >> >>> ip address 10.0.0.2 255.255.255.0 > >> >>> ip pim sparse-mode > >> >>> encapsulation frame-relay > >> >>> frame-relay map ip 10.0.0.3 201 > >> >>> frame-relay map ip 10.0.0.1 201 broadcast > >> >>> ! > >> >>> interface Loopback0 > >> >>> ip address 2.2.2.2 255.255.255.255 > >> >>> ip pim sparse-mode > >> >>> ip igmp join-group 229.0.0.2 > >> >>> ! > >> >>> ip route 1.1.1.1 255.255.255.255 10.0.0.1 > >> >>> ip pim rp-address 1.1.1.1 > >> >>> > >> >>> *** R3 *** > >> >>> interface Serial1/0 > >> >>> ip address 10.0.0.3 255.255.255.0 > >> >>> ip pim sparse-mode > >> >>> encapsulation frame-relay > >> >>> frame-relay map ip 10.0.0.2 301 > >> >>> frame-relay map ip 10.0.0.1 301 broadcast > >> >>> ! > >> >>> ip route 1.1.1.1 255.255.255.255 10.0.0.1 > >> >>> ip pim rp-address 1.1.1.1 > >> >>> > >> >>> *** Testing *** > >> >>> Ping is from R3 to 229.0.0.2, which is joined on R2. The first ping > >> goes > >> >>> through fine, all others drop until the mroute times out on R1. > >> >>> > >> >>> --- > >> >>> R3(config)#do ping 229.0.0.2 re 10 > >> >>> Type escape sequence to abort. > >> >>> Sending 10, 100-byte ICMP Echos to 229.0.0.2, timeout is 2 seconds: > >> >>> > >> >>> Reply to request 0 from 2.2.2.2, 48 ms......... > >> >>> R3(config)# > >> >>> --- > >> >>> > >> >>> Debugs indicate that R2 (subscriber router) is sending a PIM Prune > to > >> R1 > >> >>> (the hub/RP) as soon as the first packet is received. R2 retains > the > >> >>> (S,G) > >> >>> mapping with an incoming interface of s1/0, but the prune message > >> causes > >> >>> R1 > >> >>> to remove S1/0 from the OIL. Any packets after the first are > dropped > >> on > >> >>> R1 > >> >>> due to the olist being null. > >> >>> > >> >>> I don't understand why the PIM Prune is being generated on R2 for > R1 -- > >> >>> isn't that the router that's sending the stream? Most of all, I > don't > >> >>> understand why something that seems so simple isn't working! > >> >>> > >> >>> In conclusion, I hate multicast! > >> >>> > >> >>> Appreciate any help you might be able to provide. =) > >> >>> > >> >>> Keller Giacomarro > >> >>> [email protected] > >> >>> _______________________________________________ > >> >>> For more information regarding industry leading CCIE Lab training, > >> >>> please visit www.ipexpert.com > >> >>> > >> >>> Are you a CCNP or CCIE and looking for a job? Check out > >> >>> www.PlatinumPlacement.com > >> >>> > >> >>> http://onlinestudylist.com/mailman/listinfo/ccie_rs > >> >>> > >> >> > >> > > >> _______________________________________________ > >> For more information regarding industry leading CCIE Lab training, > please > >> visit www.ipexpert.com > >> > >> Are you a CCNP or CCIE and looking for a job? Check out > >> www.PlatinumPlacement.com > >> > >> http://onlinestudylist.com/mailman/listinfo/ccie_rs > >> > > _______________________________________________ > > For more information regarding industry leading CCIE Lab training, > please visit www.ipexpert.com > > > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
