This topic is to discuss the following lesson:
https://networklessons.com/multicast/embedded-rp-ipv6-multicast/
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
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.
Hello Andrew,
I already attached the configuration with couple of MCAST outputs for all the devices and topology as well. Attaching it again.
I did configure the ipv6 pim rp-address on the device that is having that ipv6 address configured on the loopback (R2-RR).
I really got confused why this is not working…If required, please post what additional outputs you need from my side
Couple of additional queries:
Regarding the format of MCAST group IPv6 address with embedded RP:
FF7<Scope>:0<RP Interface ID><HEX prefix Lenght>:<64 bit RP Prefix>:<32 bit group ID>
Do i need to put 0 all the time after the <Scope> for the next 4 bits ? Or i can put there something else as well? Will it work?
Also in all the examples i see that they use 40, so it means that the loopback on the RP device is configured with /64, am i right?
I’m asking as i know that usually loopback is configured with /128 but i didn’t find any example where 80 was used as prefix lenth for RP configuration. Do i miss something here?
In addition, i put attention that for the source (R5) i had to advertise the static ipv6 default route from (R1) so R5 can ping that MCAST IPv6 address, despite of the fact that source is participating in PIM neighborship as well, this is expected correct? As i understand, without static ipv6 default route the traffic will not be forwarded towards R1…
Also please tell me what does the configuration means: R1(config-subif)#ipv6 pim non-dr-join —> When should i use it?
I will be very thankful for your assistance.
Thanks in advance
Regards,
Vladimir
RP-Embedded-config.rar (74.2 KB)
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.
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
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
Hi @ReneMolenaar In the configuration of R2 in the article Embedded RP IPv6 Multicast, I can see there is Tunnel2. What is it?
(*, FF78:240:FC00:2:2:2:0:1), 00:05:23/never, RP FC00:2:2:2::2, flags: SCJ
Incoming interface: Tunnel2
RPF nbr: FC00:2:2:2::2
Immediate Outgoing interface list:
FastEthernet0/0, Forward, 00:05:23/neverThese tunnels are automatically created. One is used to send PIM register packets, on the RP a second tunnel interface is created to decapsulate PIM register packets. I think you can see them with the show ipv6 pim tunnel command.