Hello my friend,
A couple of last articles were dedicated to the SDN topic, and though there are still a lot of things to clear, I’ll right about something different now. In this and a couple of next articles we’ll talk about multicast.
1 2 3 4 5 | No part of this blogpost could be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical or photocopying, recording, or otherwise, for commercial purposes without the prior permission of the author. |
Disclaimer
The reason why I step away from SDN now is that further deep dive requires the controller. I’ve started some tests already but it takes much more time to familiarize myself to the controller than I’ve planned.
Brief overview
In modern network it’s difficult to overestimate the use of multicast traffic. Video streaming (including IP TV) and multipoint video-conferences are just two the easiest examples.
Two years ago I’ve written article about configuration of multicast for Cisco IOS and IOS XR, so you might find more examples and theory there.
Nowadays there are different flavors of multicast. The first one is called ASM (Any Source Multicast) and means that any host in the network can send multicast traffic and corresponding distribution tree will be build. Though it was developed historically earlier than other multicast flavors, it’s quite complex from signaling prospective. The next one is SSM (Source Specific Multicast), where the client (receiver) itself defines from which source it wants to receive the traffic. From the signaling it’s quite straightforward as multicast distribution tree is built from the client directly to the source. These two types for IPv4/IPv6 traffic are subject for this article.
Other types as MVPN (multicast VPN) and LSM (label switched multicast) will be covered in separate article later.
What are we going to test?
We’ll configure and test the following scenarios for multicast data plane:
- ASM for IPv4
- SSM for IPv4
- ASM for IPv6
- SSM for IPv6
In ASM case we’ll use BSR for distribution information about RP (rendezvous point).
Software version
For tests in this lab I use the following versions of software for routers:
- Nokia (Alcatel-Lucent) SR OS 14.0.R4
- Cisco IOS XRv 6.1.2
I had to switch Nokia (Alcatel-Lucent) SR OS version from 15.0.R4 back to 14.0.R4, due to some problems with multicast configuration there. As soon as I clear them I’ll update you
Topology
Physical topology is rather small for such lab, but is maximal for my laptop:
So I need to invent way to extend the number of routers in order to be able to test multicasting properly. Here we go:
As you see, all the hosts are VRFs configured in Cisco IOS XR (R31, R32, R34 at XR3 and R43 at XR4) routers. You might remember, I have used this approach during configuration of BGP (link). These hosts have only default static route both for IPv4 and IPv6 pointing to the core router. As core routers we have 2 Nokia (Alcatel-Lucent) VSR (SR7750) and 2 Cisco IOS XRv (ASR 9000) routers. They use ISIS in multi-topology fashion both for IPv4/IPv6 and announce only passive interfaces, which are loopbacks 0 /system interfaces and interfaces towards multicast clients.
The initial configuration files are located here: 090_config_initial_linux 090_config_initial_SR1 090_config_initial_XR4 090_config_initial_XR3 090_config_initial_SR2
Some default values for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR
There are different versions of PIM, MLD and IGMP. Luckily in Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS they are the same:
| Protocol | Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| PIM | version 2 | version 2 |
| IGMP | version 3 | version 3 |
| MLD | version 2 | version 2 |
What does it mean for us? It means that we don’t need to change protocol version somewhere and therefore it’s easier to configure interoperable solution.
Configuration of ASM (Any Source Multicast) for IPv4
In nutshell configuration of ASM flavor of multicast is quite easy. You just need to enable PIM and IGMP on appropriate interfaces and configure information about RP somehow. In this lab we’ll use BSR mechanism to distribute this information. To make things more interesting, we’ll do the following configuration:
- Nokia (Alcatel-Lucent) SR OS router SR1 will be RP for group 238.0.0.0/8
- Cisco IOS XR router XR4 will be RP for group 239.0.0.0/8
- Both these routers also act as BSR having SR1 as active and XR4 as backup BSR
- All routers are using PIM/IGMP
- Multicast clients R31, R32, R34 join groups 238.0.0.124 and 239.0.0.124
And here how we translate these requirements in actual code lines:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
You see, we just enable PIM and IGMP and mainly that’s it. For RP and BSR we do corresponding configuration at SR1 and XR3. I configured on the customer-facing interfaces at core routers dr-priority so that clients can’t take this role.
At emulation of multicast clients, we have to configure both PIM/IGMP as well
Let’s check if routers in the network already learned information about RP:
|
A:SR2# show router pim rp ipv4 |
You have seen, we have configured a 3 multicast clients (R31, R32 and R34) to join groups 238.0.0.124 and 239.0.0.124
Probably it’s not the best group choice due to the fact that both of these IPv4 addresses will be mapped to the same Ethernet multicast address 01:00:5E:10:00:7C. If you have questions to translations, read my big multicast article
Now we check PIM tables both at Nokia (Alcatel-Lucent) SR OS router SR1 and Cisco IOS XR router XR3 to see how the (*, G) groups looks like:
|
A:SR1# show router pim group ipv4 |
This topology command in Cisco IOS XR is something new, what was not available in the ordinary Cisco IOS / IOS XE.
There are 2 more useful commands in Cisco IOS XR: “show mrib ipv4 route” and “show mfib ipv4 route”. I don’t know analogues in Nokia (Alcatel-Lucent) SR OS for them.
We don’t make extensive checks to see PIM groups’ states at each router, but so far everything looks nice. There is only one opportunity to verify whether our multicast transmission works, that is to ping multicast address. Client VRF R43 will be multicast sender:
|
RP/0/0/CPU0:XR4#ping vrf R43 238.0.0.124 count 5 |
Oops, something is going wrong. We have just figure out that for the group 239.0.0.124, where Cisco XR4 is RP, everything is working fine. But for another group 238.0.0.134, where SR1 is RP, only one client responds, which is directly connected to SR1. Let’s make some troubleshooting.
|
RP/0/0/CPU0:XR3#show mrib ipv4 route 238.0.0.124 |
When we check XR3, we see that only link to SR is added to OIL (output interface list). If we compare it to group 239.0.0.124, we see two interfaces in OIL:
|
RP/0/0/CPU0:XR3#show mrib ipv4 route 239.0.0.124 |
So somehow XR4 doesn’t join SPT to XR3. Let’s check XR4 multicast topology:
|
RP/0/0/CPU0:XR4#show mrib ipv4 route 239.0.0.124 |
What is clear that XR4 even doesn’t know about multicast stream from R43. It means that SR1 doesn’t send the appropriate multicast traffic alongside RPT. Or it might send this traffic, but XR4 doesn’t receive it…
After some experiments (actually packet capture on different interfaces) I came to conclusion, that the second was correct. We must understand that out virtual routers aren’t connected directly to each other, but rather through bridges. And these bridges by default perform IGMP snooping function. Here we come to the point that Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS behave differently regarding multicast. Cisco seems to see IGMP reports or PIM join/prune messages so that IGMP snooping functionality on underlying bridges understands how to send multicast traffic and Nokia (Alcatel-Lucent) SR OS doesn’t do it or does in another way.
Long story short, this article explains the details about IGMP/MLD snooping in Linux bridges and how to disable it. For our lab setup we need to update bridges with the following configuration:
|
[root@localhost ~]# |
Let’s perform the similar multicast test to check if everything works proper now:
|
RP/0/0/CPU0:XR4#ping vrf R43 238.0.0.124 count 5 |
Looks good. Let’s go further to SSM IPv4.
Configuration of SSM (Source Specific Multicast) for IPv4
For this technology we’ll configure the following scenario:
- IPv4 range 232.0.0.0/8 is used for multicasting
- Client R32 joins group 232.2.2.2 with the source 10.255.134.44
- Client R43 joins group 232.4.4.4 with the source 10.255.123.33
And here how we translate these requirements in actual code lines:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
You see that we configure only multicast clients without configuring the range. If we check the status into details, we see that SSM range is already predefined both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR:
|
A:SR1# show router pim status | match Def |
IPv4 address range “232.0.0.0/8” is defined in RFC4607 as SSM range, that’s why we don’t need to configure it explicitly. Let’s briefly check PIM topology at SR2 and XR3:
|
:SR2# show router pim group |
You see that the groups are already has form (S,G) and therefore no groups are signalled to RP. Let’s perform a brief ping test:
|
RP/0/0/CPU0:XR3#ping vrf R32 232.4.4.4 count 5 |
After we have solved the problem with IGMP snooping in underlying Linux bridges, multicast configuration is quite easy and its operation is straightforward. Now we can move further to IPv6 multicasting.
Configuration of ASM (Any Source Multicast) for IPv6
We have gathered some experience regarding multicast in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR upon configuring IPv4. Now it’s time to reuse it for IPv6. We’ll configure the following scenario:
- Nokia (Alcatel-Lucent) SR OS router SR1 will be RP for group ff05::238:0:0:124/80
- Cisco IOS XR router XR4 will be RP for group ff05::239:0:0:124/80
- Both these routers also act as BSR having SR1 as active and XR4 as backup BSR
- All routers are using PIM/MLD
- Multicast clients R31, R34, R43 join groups ff05::238:0:0:124 and ff05::239:0:0:124
To accomplish this scenario we do the following actions:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
As you may see, the configuration at Cisco IOS XR for IPv6 multicasting is fully identical to IPv4 multicast besides keyword “ipv6” vs “ipv4”. In Nokia (Alcatel-Lucent) SR OS it’s even easier, because we just configure it to use PIM for ipv6 in addition to ipv4 and enable MLD on corresponding interfaces (you can just copy-paste configuration of igmp).
We start checks of IPv6 multicast infrastructure with RP information, just in the same way we did for IPv4 multicast:
|
A:SR2# show router pim rp ipv6 |
I’ve significantly reduced output from Cisco IOS XR, because by default it includes all SSM groups for IPv6, which is quite long list. What is really important in this case, all information about configured RP and associated ranges are here. Now let’s check the PIM topology information in order to find evidence of IPv6 multicast clients’ registrations to multicast distribution tree:
|
A:SR1# show router pim group ipv6 |
So far PIM topology looks quite promising and we’ll make our verifications by issuing ipv6 ping from multicast client, which this time will be R32:
|
RP/0/0/CPU0:XR3#ping vrf R32 ff05::238:0:0:124 rep 5 source fc00::10:255:123:33 |
As we don’t have any problems with underlying Linux bridges this time, we don’t have any problems with the multicasting itself. The first icmp is always dropped due to building of multicast distribution trees, but all the rest packets are being delivered without problems.
Configuration of SSM (Source Specific Multicast) for IPv6
It’s the final test scenario for the current lab reading Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR interoperability. So far we have tested, how IPv4 multicast (both ASM and SSM) is working and how IPv6 multicast in SSM flavor is working. For this case we the same scenario as used previously for SSM with just modifying the address groups to IPv6 addresses:
- IPv4 range 232.0.0.0/8 is used for multicasting
- Client R32 joins group ff35::232:2:2:2 with the source fc00::10:255:134:44
- Client R43 joins group ff35::232:4:4:4 with the source fc00::10:255:123:33
And here how we translate these requirements in actual code lines:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
In the same way as in IPv4 multicast we have range “232.0.0.0/8” that is used for SSM, in IPv6 multicast we use range “ff30::/12” that is used for the same task.
Let’s check just PIM topology for these newly created groups:
|
A:SR2# show router pim group ipv6 |
We see the presence for these IPv6 SSM multicast groups both on ingress and egress routers in our network. If we issue ping, everything should be working. We check that:
|
RP/0/0/CPU0:XR3#ping vrf R32 ff35::232:4:4:4 source fc00::10:255:123:33 rep 2 |
That’s good that our assumption is correct and everything is up and running.
Here are the final configuration files from our lab: 090_config_final_XR4 090_config_final_linux 090_config_final_SR1 090_config_final_SR2 090_config_final_XR3
Lessons learned
I was talking yesterday to one colleague of mine, Helen Armstrong, and she said the phrase that perfectly explains the situation with underlying Linux bridges: “Planning networks for VNFs and PNFs is much different, though seems similar”. I fully agree on that as you also must take care of underlying infrastructure and all potential caveats that it has.
Conclusion
I’m very happy to start writing about multicasting as this topic is crucial for modern networks. Quite often it’s ignored or treated somehow separately from other network topics, though today its applicability is really high. The most important point we need to know about multicast that it relies on properly working unicast routing. So if you have problems with multicasting, check unicast beforehand. Take care and good bye!
Support us
BR,
Anton Karneliuk
