Hello my friend,
We continue discussion about MVPN, which we have started in the previous article. So you should start there in order to get full picture on what’s going on.
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.
We don’t have part “brief overview” here as it’s provided in the previous article.
What are we going to test?
In this article we focus on mLDP based MVPNs (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
At the end will deploy try to deploy only S-PMSI based profile, which is calles partitioned MDT in Cisco terms.
- Profile 14 Partitioned MDT – MLDP P2MP – BGP-AD – BGP C-mast Signaling
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
No changes in software versions are done since the previous article.
There are two Nokia (Alcatel-Lucent) VSR (SR 7750) and two Cisco IOS XRv (ASR 9000) in my sandbox as usual:
On the logical topology configuration there is nothing has changed since the previous lab:
Therefore, you should use the same initial configuration files to get your topology ready for NG-MVPN configuration: 092_config_initial_XR3 092_config_initial_SR2 092_config_initial_SR1 092_config_initial_linux 092_config_initial_XR4
Configuration of MVPN profile 1 (GRE transport, MLDP signalling for P Core and PIM for Clients) for IPv4/IPv6
It won’t work. It isn’t interoperable scenario, unfortunately. When I started writing the article, I haven’t cleared all the details and, as you, I was learning while writing. What is good, because it makes the live more interesting. Actually, I’ll show you later, MLDP in MP2MP flavor isn’t supported by Nokia (Alcatel-Lucent) SR OS, therefore we can’t configure this MVPN profile there.
Configuration of MVPN profile 12 (MLDP transport, BGP-MVPN signalling for P Core, for Clients and for Auto Discovery) for IPv4/IPv6
To provide the multicast service for the customer we need to do the following steps:
- Configure LDP (with mLDP) in SP core on all interfaces
- Configure MP-BGP (IPv4 MVPN and IPv6 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)
To accomplish this task, we need to apply the following configuration:
|Nokia (Alcatel-Lucent) SR OS||Cisco IOS XR|
A:SR1>edit-cfg# candidate view
A:SR2>edit-cfg# candidate view
Interesting point in configuration of Nokia (Alcatel-Lucent) SR OS is that you don’t configure MLDP itself in global routing context, you just point to in VPRN. It means that MLDP capability is negotiated by default in Nokia (Alcatel-Lucent), whereas in Cisco IOS XR you need to turn on it explicitly. As LDP is preconfigured in our lab, please use initial configuration for details from the files above.
Let’s check LDP sessions with the respect of MLDP. Here is the output from Nokia (Alcatel-Lucent) SR OS router SR1:
A:SR1# show router ldp session 10.0.0.33 detail
MVPN 10 configuration data
In my eyes the output from Cisco IOS XR is a bit more informative and interesting:
RP/0/0/CPU0:XR3#show mpls mldp neighbors
You remember, we have said that it’s impossible to configure MVPN profile 1 (based on MP2MP mLDP) between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, because mLDP in MP2MP fashion isn’t supported in SR OS. The output above clearly shows only P2MP capability is negotiated between Nokia (Alcatel-Lucent) VSR (SR7750 and Cisco IOS XRv, whereas between Cisco IOS XR routers we have P2MP, MP2MP and wildcard-FEC negotiated.
The next useful output comes from BGP RIB for MVPN (we take IPv4 for simplicity) at Cisco IOS XR router XR3:
RP/0/0/CPU0:XR3#show bgp ipv4 mvpn vrf CUST
For route-type 1, which is inclusive PMSI (i-PMSI) tree, we can see very long string that contains information how it’s build. There we have encoded type of the tree (PIM, mLDP, mRSVP-TE), address of the host and other information for mLDP it also encoded opaque value (marked with bold font), which is used for signalling mLDP tree in core, which doesn’t speak BGP. For instance, mentioned value in hex 0x2001 is 8193 translated into decimal as, which value we can see in MLDP at the same Cisco IOS XR router XR3:
RP/0/0/CPU0:XR3#show mpls mldp database brief
Point out that each vendor has its default opaque value. Both Nokia (Alcatel-Lucent) SR OS routers SR1 and SR2 has the same opaque value for i-PMSI, so we need to check FEC source as well.
For Cisco IOS XR default opaque values are different for IPv4 and for IPv6: 1 for IPv4 and 262146 for IPv6
At Nokia (Alcatel-Lucent) SR OS router SR1 we can check this mLDP database by the next command:
A:SR1# show router ldp bindings active p2mp
Remember that in NG-MVPN there is no transport/service label split. There is only one label for multicast stream in VPN which is both transport and service together.
The rest of the checks are related to certain VPRN/VRF instance and are the same as we saw in the first part of the article. That’s why I propose to start some data plane verification, what is ping to multicast address in a nutshell, and we’ll see outputs alongside.
IPv4 multicast customers (ASM, SSM) at NG-MVPN
To refresh our customer topology, refer to the following picture, please:
At the customer side we do the following configuration:
|Cisco IOS XR – XR4|
As you see, we have the following IPv4 multicast streams:
- R41 is client of SSM group 22.214.171.124 with source R43
- R43 is client of ASM group 126.96.36.199, where R42 is RP and R41 is sender
Just in the same way we did previously, we start with IPv4 SSM group, as it’s fully signalled. Here is the output from ingress multicast router XR3 (output is reduced to highlight the interesting moments):
RP/0/0/CPU0:XR3#show bgp ipv4 mvpn vrf CUST route-type 7
At the egress multicast router, which is Nokia (Alcatel-Lucent) VSR SR1 we also see this group:
A:SR1# show router 10 pim group ipv4 188.8.131.52 detail
So far everything looks fine and we issue ping:
RP/0/0/CPU0:XR4#ping vrf R43 184.108.40.206 rep 5
Very good! Let’s go further and now we try IPv4 ASM group 220.127.116.11. Here we’ll issue ping to build proper SPT and then show some topology outputs:
RP/0/0/CPU0:XR4#ping vrf R41 18.104.22.168 rep 5
As usual first packet is dropped due to SPT switchover, but all the rest packets are OK. We start with ingress multicast router, which is Nokia (Alcatel-Lucent) SR OS router SR1:
A:SR1# show router 10 pim group ipv4 22.214.171.124 detail
Output of the PIM groups at SR1 shows that multicast traffic comes from client’s interface and is sent to MLDP MDT. The next router to check is SR2, because we have RP connected there:
A:SR2# show router 10 pim group ipv4 126.96.36.199
We don’t show all the details here, but what is important is that we have two groups here. The initial group (*,G) was used in order to register multicast client R43 with RP. The new group (S,G) was built from multicast client R43 to multicast sender R41.
Now it’s turn of egress multicast router XR3, which is Cisco IOS XRv (ASR 9000):
RP/0/0/CPU0:XR3#show mrib vrf CUST ipv4 route 188.8.131.52
Point out that we have two different RPF neighbours for these two groups. For RPT we have SR2 as RPF neighbour, whereas SR1 is RPF neighbour for SPT.
Well, IPv4 is done, let’s go to IPv6 multicast.
IPv6 multicast customers (ASM, SSM) at NG-MVPN
We have configured already, what is necessary for IPv6 multicast, so I’ll just remind the streams:
- R41 is client of SSM group ff35::232:0:0:11 with source R43
- R43 is client of ASM group ff05::239:0:0:33, where R42 is RP and R41 is sender
And here the problems start.
Pay attention that problems might be related to virtual images solely and you might have it working with nodes (like, Nokia/ALU 7750 or Cisco ASR 9000). I personally know a lot of limitations in IOS XRv.
Problem No 1 – What is NOT working?
Cisco IOS XRv router XR3 can’t understand information about BSR-based RP R42 distributed from SR2. Here is the output about IPv6 RP information from all MPLS PE routers:
A:SR1# show router 10 pim rp ipv6
What is worth mentioning, if I build single vendor environment with Cisco IOS XR, then RP information is propagated properly. I don’t say anything about single vendor environment with Nokia (Alcatel-Lucent) SR OS, because we have an RP and multicast client connected to two different PE, which are Nokia (Alcatel-Lucent) VSR, and it works fine.
Problem No 1 – What is working?
As we have proper PIMv6 and BGP MVPN-IPV6 information at SR1 and SR2, we can issue IPv6 multicast stream from RP R42 down to R41, if it were customer. Let’s register R41 to the same group as R43 registered for the group:
So in this flavour IPv6 multicast works.
To show a bit more MPLS data plane, I shutdown links SR1-XR3 and SR1-SR2, so that all the traffic flows through the P router XR4. There is new ping check:
RP/0/0/CPU0:XR4#ping vrf R42 ff05::239:0:0:44 source fc00::10:255:124:44 rep 5
Here is also packet capture created by Wireshark to show how the encapsulation on the wire look like:
Problem No 2 – What is NOT working?
At a glance the signalling looks fine:
A:SR1# show router 10 pim group ipv6 ff35::232:0:0:11
What is not fine that despite the good signalling the data plane is broken:
RP/0/0/CPU0:XR4#ping vrf R43 ff35::232:0:0:11 source fc00::10:255:134:44 rep 5
And here the Wireshark does awesome job by showing us the root cause:
Remember, I was saying that there is a single label in NG-MVPN, which is both transport and service. For some reason Cisco IOS XRv (I guess, the problem is related only to my virtual router) adds another label, which is IPv6 Explicit-Null label. If you compare to the output of Wireshark in the previous problem, you see correct labelling.
Problem No 2 – What is working?
If we add new IPv6 SSM group at SR3 that points to R42, we got it working:
When I was preparing for CCIE SP this year, I’ve worked a lot with MVPNs. I knew that Cisco IOS XRv has problems with NG-MVPN and IPv6, therefore I have never made a packet capture. Now we have done it and I realised, where the problem comes from. In the same time, there is another virtual Cisco router, which is called CSR 1000v and utilize Cisco IOS XE operation system. It has no problems with data plane and there IPv6 NG-MVPN works, as well all other features that don’t work in Cisco IOS XRv like VPWS or VPLS data plane.
Multicast services are equally important to unicast for customers today. If Communication Service Provider (CSP) helps customer to extend its multicast network over IP VPN, it creates additional value for both of them, which can be easily converted into profit. In the same time, use of NG-MVPN relax the load on the network and therefore improve performance and stability. Even in multivendor environment with Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. Take care and good bye!
If you have further questions or you need help with your networks, I’m happy to assist you, just send me message