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
