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.
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. |
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
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
No changes in software versions are done since the previous article.
Topology
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 |
| 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 |
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 |
|
RP/0/0/CPU0:XR4#show run |
As you see, we have the following IPv4 multicast streams:
- 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
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 232.0.0.11 detail |
So far everything looks fine and we issue ping:
|
RP/0/0/CPU0:XR4#ping vrf R43 232.0.0.11 rep 5 |
Very good! Let’s go further and now we try IPv4 ASM group 239.0.0.44. Here we’ll issue ping to build proper SPT and then show some topology outputs:
|
RP/0/0/CPU0:XR4#ping vrf R41 239.0.0.44 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 239.0.0.44 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 239.0.0.44 |
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 239.0.0.44 |
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:
|
RP/0/0/CPU0:XR4(config-mld-R41-if)#show conf |
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:
|
RP/0/0/CPU0:XR4(config)#show conf |
The final configuration files are here: 094_config_final_SR2_profile_12 094_config_final_XR3_profile_12 094_config_final_XR4_profile_12 094_config_final_SR1_profile_12
Lessons learned
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.
Conclusion
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!
P.S.
If you have further questions or you need help with your networks, I’m happy to assist you, just send me message
Support us
BR,
Anton Karneliuk
