Tags: ,


Notable 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 supported on CSR1k, IOS-XRv and vIOS?

    I tested it with CSR1k nodes

    Also please tell me what does the configuration means: R1(config-subif)#ipv6 pim non-dr-join —> When should i use it?
    In addition, i saw that you used loopback address with /64 and this is reflected in MCAST group with 40.
    But if i will use loopback address with /128, does it mean that i will have to change 40 to 80 in MCAST group IPv6 address i will still use 40 as it’s an RFC format?

    Thanks,

    Regards,
    Vladimir

  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’t work, please post your RP information, MC group info, etc., and we can double check your calculation of the embedded RP address.

  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 suggest you start by creating a simple a network as possible (just three routers) and validate your Embedded RP setup works there. I am probably not telling you anything new in that often problems with multicast networks are RPF failures.

    Some of your other questions:
    FF7X:0 The 0 listed here will always be a zero. That’s just how the address format works.

    As far as /64 = 40, I answered this in my earlier response. 40 represents the prefix length in hex. So if you wanted a /128, use 80.

    I don’t understand what you are asking in your paragraph about the static ipv6 default route.

    ipv6 pim non-dr-join – I had never heard of this command, but I did some research on it. It appears as though this is used when PIM enabled routers are part of a FHRP (first hop redundancy protocol) environment, like VRRP or HSRP. When you enable the non-dr-join command, the router that was NOT elected as the PIM DR still registers itself, but using a “Block” flag. This is block registration allows a quicker transition to the “forward” state than if the non-DR didn’t register at all in the event that the DR router fails.

  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 showing all the time the following mroute output:
    like it’s sending the registering messages all the time but RP is not seeing them at all, it only sees join from R7!

    ****R1*****

    R1#show ipv6 mroute    
    Multicast Routing Table
    Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 
           C - Connected, L - Local, I - Received Source Specific Host Report,
           P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
           J - Join SPT, Y - Joined MDT-data group,
           y - Sending to MDT-data group
           g - BGP signal originated, G - BGP Signal received,
           N - BGP Shared-Tree Prune received, n - BGP C-Mroute suppressed,
           q - BGP Src-Active originated, Q - BGP Src-Active received
           E - Extranet
    Timers: Uptime/Expires
    Interface state: Interface, State
    
    (2001:1:5::5, FF78:240:FC00:2:2:2:0:A), 00:00:04/00:03:25, flags: SFT
      Incoming interface: GigabitEthernet1.15
      RPF nbr: FE80::250:56FF:FE92:5, Registering
      Immediate Outgoing interface list:
        Tunnel0, Forward, 00:00:04/never
    

    ****RP*****

    R2#show ipv6 mroute      
    Multicast Routing Table
    Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, 
           C - Connected, L - Local, I - Received Source Specific Host Report,
           P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
           J - Join SPT, Y - Joined MDT-data group,
           y - Sending to MDT-data group
           g - BGP signal originated, G - BGP Signal received,
           N - BGP Shared-Tree Prune received, n - BGP C-Mroute suppressed,
           q - BGP Src-Active originated, Q - BGP Src-Active received
           E - Extranet
    Timers: Uptime/Expires
    Interface state: Interface, State
    
    (*, FF78:240:FC00:2:2:2:0:A), 00:09:32/00:03:01, RP FC00:2:2:2::2, flags: S
      Incoming interface: Tunnel2
      RPF nbr: FC00:2:2:2::2
      Immediate Outgoing interface list:
        GigabitEthernet1.23, Forward, 00:09:32/00:03:01
    

    And finally i just started to send ping from R1 (DR) towards MCAST group and ping worked properly!

    R1#ping FF78:240:FC00:2:2:2:0:A
    Output Interface: GigabitEthernet1.12
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to FF78:240:FC00:2:2:2:0:A, timeout is 2 seconds:
    Packet sent with a source address of 2001:1:2::1
    
    Reply to request 0 received from 2001:3:7::7, 53 ms
    Reply to request 0 received from 2001:3:7::7, 54 ms
    Reply to request 0 received from 2001:3:7::7, 91 ms
    Reply to request 0 received from 2001:3:7::7, 92 ms
    

    So it means that when i add another router between source and RP then all the stuff stops working! But this doesn’t make sense as it should work as well! what i add is a DR who should register first the mcast in unicast messages towards RP… Or i miss something general in ipv6 mcast?

    Do you have any suggestions regarding this? Did you try to add another node between source and RP?

    Please reply.

    Thanks,
    Vladimir

  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 group (ipv6 mld join-group FF78:A40:FC00:2:2:2:0:1) even if loopback is still configured with /128 then RP was learned properly and even traffic flowed without any problem, so i think that 40 is a fixed value and it doesn’t matter what prefix subnet is actually used for the RP itself.

    (*, FF78:A40:FC00:2:2:2:0:1), 00:02:30/never, RP FC00:2:2:2::A, flags: SCLJ
      Incoming interface: GigabitEthernet1.37
      RPF nbr: FE80::250:56FF:FE92:3
      Outgoing interface list: Null
    

    And in addition, it doesn’t matter what i put in the 4 bits after the scope (0 is not must at all, in my example i put A), just look on the following example:
    ipv6 mld join-group FF78:AA40:FC00:2:2:2:0:1

    (*, FF78:AA40:FC00:2:2:2:0:1), 00:00:03/never, RP FC00:2:2:2::A, flags: SCLJ
      Incoming interface: GigabitEthernet1.37
      RPF nbr: FE80::250:56FF:FE92:3
      Outgoing interface list: Null
    

    And the traffic is flowing properly:

    R1#ping  FF78:AA40:FC00:2:2:2:0:1
    Output Interface: GigabitEthernet1.12           
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to FF78:AA40:FC00:2:2:2:0:1, timeout is 2 seconds:
    Packet sent with a source address of 2001:1:2::1
    
    Reply to request 0 received from 2001:3:7::7, 39 ms
    Reply to request 0 received from 2001:3:7::7, 39 ms
    Reply to request 0 received from 2001:3:7::7, 76 ms
    Reply to request 0 received from 2001:3:7::7, 76 ms
    

    FYI

    Vladimir

Continue the discussion forum.networklessons.com

3 more replies!

Participants