Interesting, but isn't the static-group command similiar to the join-group command. Both effectively force the router to send a IGMP Join to the MCAST Group, but the join-group command results in the router processing mcast traffic, vs the static which though the router has joined the router won't process the traffic.
Correct me if I'm wrong? But, this to me seems a bit of a "fudge"? Surely this should be working without the static joins? I'm liking this thread as I'm currently going over Multicast, haven't quite got to this topic area, but it's a great discussion. B On Thu, Nov 15, 2012 at 8:55 AM, Greg Chisholm <[email protected]> wrote: > On 11/12/2012 01:02 AM, Keller Giacomarro 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<http://onlinestudylist.com/mailman/listinfo/ccie_rs> >> > I found a solution to this scenario of multicast source and destinations > between frame relay spokes problem. > > On the FR hub router R1's serial interface, add: > ip igmp static-group * > > or at least: > ip igmp static-group 229.0.0.2 > > > > This will have the effect of blocking the pruning actions. The > documentation for "ip pim nbma-mode" claims that's exactly what nbma-mode > will do, but in practice that's not what happening. > > > With the static-group in place and some debugs running, the prune is > overridden. > > > with "debug ip mrouting": > *Nov 14 20:17:10.286: MRT(0): Prune of Serial0/0/0 overridden by static * > interface > > > with "debug ip pim": > *Nov 14 21:24:55.961: PIM(0): Prune-list: (10.0.0.3/32, 229.0.0.2) > RPT-bit set > *Nov 14 21:24:55.961: PIM(0): Prune of Serial0/0/0 from (10.0.0.3, > 229.0.0.2) overridden by static-group * > > > > Now R3 can ping continuously: > > R3#ping 229.0.0.2 repeat 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 10.0.0.2, 128 ms > Reply to request 1 from 10.0.0.2, 124 ms > Reply to request 2 from 10.0.0.2, 136 ms > Reply to request 3 from 10.0.0.2, 136 ms > Reply to request 4 from 10.0.0.2, 136 ms > Reply to request 5 from 10.0.0.2, 136 ms > Reply to request 6 from 10.0.0.2, 136 ms > Reply to request 7 from 10.0.0.2, 136 ms > Reply to request 8 from 10.0.0.2, 136 ms > Reply to request 9 from 10.0.0.2, 136 ms > > > > ------------------ > > Greg Chisholm > RS CCIE #29271 > > ______________________________**_________________ > 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<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
