This topic is to discuss the following lesson:
Thanks for that interesting lesson.
I have some simple questions :
For fixing the issue by the “sub-interfaces” solution ; I guess, there will create 2 sub-interfaces (one for each PVC) ? I guess also that the 2 sub-interfaces will be configured with 2 different subnets ? According to my understanding of split-horizon ; 1 (only 1) sub-interface on R1 will have the same point-to-multipoint issue as the physical interface ?
I do not understand how the tunnel between R2 and R3 could work, if there’s no PVC between the two routers and there is nothing on R1 for “forwarding” information between R2 and R3.
By the way ; there’s a copy/paste error in first configuration lines. See below :
**R1**(config)#interface serial 0/0 R2(config-if)#ip pim sparse-dense-mode **R1**(config)#interface serial 0/0 R3(config-if)#ip pim sparse-dense-mode
We have a split horizon issue here since with the physical point-to-multipoint interface, there is only one interface. With sub-interfaces, you would have two logical interfaces on the hub router. This does mean that you have a different subnet for each PVC yes. You won’t have any split horizon issues anymore since the hub uses a different logical interface for each spoke router.
I see I didn’t include the unicast routing configuration in this lesson, that’s something I will fix. The tunnel uses the 18.104.22.168 and 22.214.171.124 addresses but those have to be known on both spoke routers. Sorry for the confusion!
Thanks for sharing the typo, just fixed it.
could disabling spit horizon on the tunnel be a solution as well?
I configured this up and I never could get auto-rp information to go to the 2nd spoke even when split horizon was disabled on the hub router. Therefore, it seems the only way that multicast will forward multicast traffic is if the OIL is different than the ingress interface
spoke #1>hub>spoke #2
Note: I configured spoke #1 as both the RP and MA as an experiment and I configured an igmp-join on spoke #2 to see what would happen if I disabled split-horizon on the hub. when sourcing from spoke #1 going to the mcast address traffic never made it.
The split-horizon command only applies to distance vector routing protocols (RIP and EIGRP), not to multicast. You can configure the interface to forward multicast traffic that you received on that interface with the NBMA mode:
However, I don’t think that works for AutoRP traffic. If you have the RP and MA on one spoke, then probably the only way to make it work is either by tunneling or using sub-interfaces.