We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 637 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

354 New Members signed up the last 30 days!

satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Forum Replies

  1. Thanks for that interesting lesson.

    I have some simple questions :

    **-1-**

    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 ?

    **-2-**

    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 nothi

    ... Continue reading in our forum

  2. 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 2.2.2.2 and 3.3.3.3 addresses but those have to be known on bo

    ... Continue reading in our forum

  3. could disabling spit horizon on the tunnel be a solution as well?

  4. 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

    test topology
    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.

  5. Hi Roland,

    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:

    https://networklessons.com/multicast/multicast-pim-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.

    Rene

Ask a question or join the discussion by visiting our Community Forum