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 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

470 Sign Ups in the last 30 days

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

Tags: ,

Forum Replies

  1. Hi Rene,

    I tried to simulate the Embedded-RP but it didn’t work.
    The only stuff that worked was statically configured ipv6 pim rp-address on all the nodes.

    But i was trying to check that cool feature and what i saw is that on DR (where source is connected) there’s a constant Registering appears there and RP node itself is not seeing (S,G), only (*,G) as a part of connected receiver via MLD join-group.

    I don’t get what i’m missing here…

    I will be very thankful to you if you can reply with your suggestions what could be the problem?

    By the way does this feature s

    ... Continue reading in our forum

  2. Vladimir,
    I am pretty sure that an Embedded RP will work on that platform. One key configuration step that I didn’t see you mention is that you must manually configured the chosen RP to be an RP for itself, via the ipv6 pim rp-address command.

    After the RP has been statically configured to itself, your embedded RP address (assuming it is configured correctly!) should work.

    You are correct in that if you are using a /128 loop back address, you would need to change the “40” to an “80” since those two digits represent the mask in hexadecimal.

    If this still doesn’

    ... Continue reading in our forum

  3. I looked at the formation of your Embedded RP, and it looks correct.

    Your RP = FC00:2:2:2::2/64
    Your Embedded RP Address: FF78:240:FC00:2:2:2:0:1. This address is correctly formatted assuming you want to use the first multicast group (then trailing 0:1) possible on that RP, and the scope of the multicast group is global (8).

    Also, your show commands have the correct output (like on the RP, for example) where it shows the correct (*,G) entry.

    The problem is your lab is extremely complicated, and frankly, I don’t want to spend two hours troubleshooting it. I su

    ... Continue reading in our forum

  4. Hi Andrew,

    I checked with 3 nodes R1—R2—R3 and it worked properly. R1 (source), R2 (RP) and R3 (receiver)
    What i don’t understand is if R1 is sending the MCAST traffic, then who is DR in this scenario? R2? Who actually is sending the unicast register messages towards RP? A little bit confusing this scenario.

    I’m regular to some basic setup where R5—R1—R2—R3—R7 where (R5 is a source), (R1 a DR), (R2 is and RP), (R3 is a last hop router connected to receiver), (R7 is a receiver)

    But what i found out is if i test with 5 devices than it’s not working and DR is show

    ... Continue reading in our forum

  5. Hi Andrew,

    one more update:
    It’s not working when changing the 40 to 80!
    I changed the loopback prefix to /128 (FC00:2:2:2::A/128 instead of FC00:2:2:2::A/64) and joined the following MCAST ipv6 group on receiver (ipv6 mld join-group FF78:A80:FC00:2:2:2:0:1) but RP wasn’t learned on any node and therefore the traffic didn’t flow as well.

    (*, FF78:A80:FC00:2:2:2:0:1), 00:00:03/never, RP ::, flags: SCLJ
      Incoming interface: Null
      RPF nbr: ::
      Immediate Outgoing interface list:
        GigabitEthernet1.37, Forward, 00:00:03/never

    But if i was using the following g

    ... Continue reading in our forum

3 more replies! Ask a question or join the discussion by visiting our Community Forum