Hello my friend,
The next logical step in multicast journey is to enable multicast support in VPN. Whereas there are almost no problems to do it in L2 VPN (like VPWS and VPLS), there are tremendous amount of options, how to do in L3 VPN. Let’s see what we can do.
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. |
Brief overview
MVPN stands for multicast VPN. In a nutshell it’s a set of technologies, which can be grouped in 3 major categories:
- P-MCAST signaling. It’s set of technologies used to setup MDT (multicast distribution tree) within SP core. There are PIM, mLDP, mRSVP-TE coupled by BGP for Auto-discovery (if necessary) available.
- P-MCAST transport. It’s set of technologies how to encapsulate customer multicast traffic in SP core network. There are GRE or MPLS (LDP or RSVP-TE) available.
- C-MCAST signaling. It’s set of technologies used to propagate customer multicast-routes between PE routers within SP-core. There are PIM or BGP (AFI/SAFI: MVPN IPv4/IPv6) available
At the end of the day certain MVPN option will be particular subset of mentioned technologies (one of each category). What you also need to understand is that not all the combinations are possible. Cisco calls such options MVPN profile and they have 27 profiles actually:
There are a lot of theory behind those MVPN flavors, which is impossible to describe in single article. I will share some links in the end part, where you might see some theory, if you need it.
What are we going to test?
We’ll configure 5 different MVPN profiles. Two of them are based on GRE transport (one uses PIM signaling for customer routes and another uses BGP):
- Profile 0 Default MDT – GRE – PIM C-mcast Signaling
- Profile 11 Default MDT – GRE – BGP-AD – BGP C-mcast Signaling
Two profiles are mLDP based (again one uses PIM and another BGP for customer signaling):
- Profile 1 Default MDT – MLDP MP2MP PIM C-mcast Signaling
- Profile 12 Default MDT – MLDP – P2MP – BGP-AD – BGP C-mcast Signaling
The final profile we are going is partitioned MDT. The main it’s reason comparing to default MDT is absence of I-PMSI (inclusive tree). It’s useful if the customer has only SSM routes.
- Profile 14 Partitioned MDT – MLDP P2MP – BGP-AD – BGP C-mast Signaling
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
As I said in the previous article about multicast, there are some problems with multicast in VSR with SR OS version 15.0.R4. The reason for that is absence of multicast support in VSR-I mode, which is basis for 15.0.R4. As I was said, it is going to be supported, but later. We’ll see how VSR will be developed further.
Topology
Physical topology is quite well known, if you have read other articles in my series:
Pay attention to the fact that we use vnet2 and vnet6 interfaces at Nokia (Alcatel-Lucent) SR OS routers VSR1 and VSR2, because we have to create SAP for customer ports.
The logical topology is quite similar to previous one:
Routers SR1, SR2 and XR3 are PE routers that terminate customer connectivity in BGP/MPLS IP VPN instances. Interconnect links are redistributed into MP-BGP (both form IPv4 and IPv6), whereas multicast clients (created as VRFs) have only default routes in direction of the closest PE. As MPLS dataplane we use ordinary LDP.
The initial configuration files are here: 092_config_initial_XR4 092_config_initial_XR3 092_config_initial_SR2 092_config_initial_SR1 092_config_initial_linux
Initial connectivity check
Before we go into MVPN details, let’s make sure that unicast connectivity with L3VPN is working across our multivendor service provider core build on Nokia (Alcatel-Lucent) VSR (SR 7750) and Cisco IOS XRv (ASR 9000) routers:
|
RP/0/0/CPU0:XR4#ping vrf R41 10.255.114.44 |
Looks good, isn’t it? Let’s go further.
Configuration of MVPN profile 0 (GRE transport, PIM signalling for P Core and for Clients, BGP MDT for Auto Discovery) for IPv4/IPv6
To provide the multicast service for the customer we need to do the following steps:
- Configure PIM in SP core on all interfaces
- Configure MP-BGP (IPv4 MDT) between all PE
- Configure VPRN/VRF to support multicast (PIM, IGMP, MLD)
- Configure mapping of customer multicast (VRF) to core trees (in global routing table – GRT)
The configuration will be quite long, but it’s unavoidable, when we speak about introduction of the such complex service:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3#show run |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4#show run |
Both for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR we show only extension to BGP, which is necessary to fulfil the task. Refer to initial configuration for more details.
Configuration of the multicasting in SP core is pretty the same as we did in previous article, so we don’t stop here. The same statement is applicable for enabling multicast support in VPRN/VRF. BGP configuration is very easy as well, as we only add additional address-family to existing sessions.
Remember that BGP session flaps, when you add new address-family to it.
The most important and complex configuration is mapping of customer multicast to SP Core multicast. In Nokia (Alcatel-Lucent) SR OS all the configuration is done within “mvpn” part of VPRN configuration. In Cisco IOS XR we have two major pillars, which are “multicast-routing vrf CUST” and “router pim vrf CUST”. In the first one we define parameters of MDT tree and in the second one we instruct PIM how to perform RPF check (what topology to use) for multicast traffic as well as what protocol we use for customer signalling. Let’s issue some “show” commands in order to verify operation of multicast.
The first one is summary of MVPN configuration at SR1:
|
A:SR1# show router 10 mvpn |
Another useful command for troubleshooting is see the content of BGP MDT table:
|
A:SR1# show router bgp routes mdt-safi |
For Cisco IOX XR we can check BGP table and RPF policy:
|
RP/0/0/CPU0:XR3#show bgp ipv4 mdt |
There are some other check commands, but it’s much better to configure multicast clients and test how multicast traffic flows across our VPN. The topology of the multicast within customer network is the following:
At the customer side we do the following configuration:
| Cisco IOS XR – XR4 |
|
RP/0/0/CPU0:XR4#show run |
Actually Cisco IOS XRv router XR4 emulates all multicast sender and receivers. There are two streams for IPv4:
- R41 is client of SSM group 232.0.0.11 with source R43
- R43 is client of ASM group 239.0.0.33, where R42 is RP and R41 is sender
Let’s test both streams:
|
RP/0/0/CPU0:XR4#ping vrf R41 239.0.0.44 rep 5 |
It’s amazing, isn’t it? Our customer has possibility to send multicast traffic across L3 VPN!
Let’s look at some details more:
|
A:SR1# show router pim group |
You see that we have only three trees in the SP core, in which customer traffic (from VPRN/VRF) is mapped.
It’s time for IPv6 multicast:
|
RP/0/0/CPU0:XR4#ping vrf R43 ff35::232:0:0:11 source fc00::10:255:134:44 rep 5 |
Unfortunately it doesn’t work. I’ve read through configuration guide for SR OS 14 and found the following:
SR OS IPv6 MVPN multicast implementation provides the following functionality:
- IPv6 C-PIM-SM (ASM and SSM)
- MLDv1 and MLDv2
- SSM mapping for MLDv1
- I-PMSI and S-PMSI using IPv4 P2MP mLDP p-tunnels
- I-PMSI and S-PMSI using IPv4 P2MP RSVP p-tunnels
- BGP auto-discovery
- PE-PE transmission of C-multicast routing using BGP mvpn-ipv6 address family
- IPv6 BSR/RP functions on functional par with IPv4 (auto-RP using IPv4 only)
- Embedded RP
Let’s go further, we’ll configure IPv6 with MPLS data plane.
Configuration files for MVPN profile 0: 092_config_final_SR1_profile_0 092_config_final_XR3_profile_0 092_config_final_SR2_profile_0 092_config_final_XR4_profile_0
Configuration of MVPN profile 11 (GRE transport, PIM signalling for P Core, BGP for client’s routes, BGP MVPN for Auto Discovery) for IPv4
In general, we need to perform similar steps as we did previously with some changes, which are replacement of BGP MDT with BGP MVPN AFI/SAMI:
- Configure PIM in SP core on all interfaces
- Configure MP-BGP (IPv4 MVPN) between all PE
- Configure VPRN/VRF to support multicast (PIM, IGMP, MLD)
- Configure mapping of customer multicast (VRF) to core trees (in global routing table – GRT)
We’ll start again from the initial configuration and add here necessary commands to implement necessary profile. From previous subchapter you remember that the main difference lays in part “mvpn” for Nokia (Alcatel-Lucent) SR OS and “multicast-routing vrf CUST” and “router pim vrf CUST” for Cisco IOS XR:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3#show run |
| SR2 | XR4 |
|
A:SR2>edit-cfg# candidate view |
RP/0/0/CPU0:XR4#show run |
As we learned above, we don’t have possibility to provide IPv6 support for MVPN with GRE transport in core.
The main difference here is that we use new address-family for BGP, which is MVPN. It allows us to utilize auto-discovery and to use BGP for C-MCAST signalling. Let’s see what we have in BGP table. But to make review meaningful, we’ll take two our traffic flows as an example. We start with SSM, because it’s easier from the signalling point of view. Our SSM group looks like the following:
- R41 is client of SSM group 232.0.0.11 with source R43
On Nokia (Alcatel-Lucent) SR OS router SR1 we check PIM table in VPRN 10 and BGP RIB for MVPN-IPV4:
|
A:SR1# show router 10 pim group |
PIM join (S,G) is translated into BGP MVPN type 7 route (Source-Join), as over SP core only BGP signalling is transferred. As multicast ingress router is XR3, we’ll check it:
|
RP/0/0/CPU0:XR3#show bgp ipv4 mvpn vrf CUST |
We see as BGP type 7 MVPN route is translated again into PIM (S,G) join at Cisco IOS XR router XR3 and send further. Let’s perform brief ping check:
|
RP/0/0/CPU0:XR4#ping vrf R43 232.0.0.11 rep 5 |
So for IPv4 SSM multicasting BGP signalling works fine, and in general solution is OK.
In order to shorten the article, I’ll provide very limited output for ASM multicasting. I’ll recall the scenario:
- R43 is client of ASM group 239.0.0.33, where R42 is RP and R41 is sender
We start with check at Cisco IOS XR router XR3:
|
RP/0/0/CPU0:XR3#show pim vrf CUST ipv4 topology |
BGP route type 6 is a translation of PIM (*,G) join from the multicast receiver towards RP. RP is connected to Nokia (Alcatel-Lucent) SR OS router SR2, so we check it now:
|
A:SR2# show router bgp routes mvpn-ipv4 |
In MVPN we have the same logic for shared trees as normal IP network, so RPT tree is built from R43 towards R42, which is RP. Now we issue ping from R41 to assure that multicasting is working:
|
RP/0/0/CPU0:XR4#ping vrf R41 239.0.0.44 rep 5 |
It works, which is good by default. Now we start our check with multicast ingress router SR1:
|
A:SR1# show router 10 pim group |
As we have full-mesh BGP peering, so it’s easier to check MVPN routes at Cisco IOS XR:
|
RP/0/0/CPU0:XR3#show bgp ipv4 mvpn vrf CUST |
We have mentioned previously PIM join (*,G) is translated into BGP type 6 MVPN route. Route type 7 is already known for us, it’s originated by egress multicast router XR3 when R43 switchover from RPT to SPR towards multicast source R41. BGP MVPN route-type 5 is issued when R41 starts multicast stream towards RP R42.
Long story short, we have configured another MVPN profile, which uses BGP for auto-discovery and for signalling customer routes.
The following configuration files provide details for MVPN profile 11: 092_config_final_XR4_profile_11 092_config_final_XR3_profile_11 092_config_final_SR2_profile_11 092_config_final_SR1_profile_11
Lessons learned
When I was studying for CCIE SP I have mastered almost all MVPN profiles for Cisco IOS XR. It was very interesting for me to check the interoperability with Nokia (Alcatel-Lucent) SR OS and I was quite surprised, because it doesn’t support IPv6 over IPv4 GRE. I like interoperability tests, because it shows the real network stuff uncensored.
Conclusion
MVPN and especially something called NG-MVPN (next generation MVPN), where we use BGP for c-mcast signalling and for auto-discovery, is one of the most important value added services to ordinary BGP/MPLS IP VPN. In reality multicasting is also used for financial trading, so MVPN applicability isn’t limited to big service providers but it’s extended also to big financial corporation or trading platform. In the next article we’ll speak about MVPN with MPLS data plane, so we won’t have PIM in SP core. Take care and good bye!
Support us
BR,
Anton Karneliuk
Useful links
Video from CCIE SP program at Cisco Learning Network
howdy Anton, a quick question – why did you specifically set DR priority higher on the PEs? as in:
router pim
vrf CUST
address-family ipv4
!
interface GigabitEthernet0/0/0/0.134
dr-priority 100
Hello Jonas,
Nice to hear from you, sir.
We do that in order to to have predictable results, as Nokia and Cisco have (had at that time) different default DR values. Setting them explicitly allows you have a clear picture, which will become a DR.
Best,
Anton
ok, makes sense, but not the answer I was hoping to hear as I have had to learn the hard way that a PE under IOS XR won’t forward a PIM-Join towards the RP if it were to come from a DR other than the PE itself, say a CE device. The PE in MVPN has to be a DR as well, else your multicast will be in shambles. In your demo there’s no way to test it as you terminated the tree on the PE itself.