Hello my friend,
When we speak about MPLS-based services, we should always remember that they are somehow mapped to the MPLS transport. Depending on vendor (Nokia (Alcatel-Lucent) or Cisco) there are different ways how to achieve it. Let’s discover them!
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
Mapping of the service to transport LSP means that ingress PE router must define the egress PE and MPLS LSP to it. In basic case the traffic from all services follows the same path (MPLS LSP), but what if you want more? For example, you would like to have traffic engineering tunnels (RSVP-TE MPLS LSP) for certain services in order to guarantee bandwidth or use certain path that won’t be used by default due IGP route calculation, whereas all other services should follow IGP/LDP path.
The approach how vendors achieve differs a lot. In Nokia (Alcatel-Lucent) SR OS you configure SDP (service distribution point), what is exact mapping between service control plane (signaling) and data plane (forwarding – MPLS LSP). Then you mention each necessary SDP under each service configuration. We were already doing this operation upon configuring VPWS or VPLS.
In Cisco IOS XR you don’t do it, because the mapping of service to MPLS LSP is done based on next hop lookup in forwarding database (FIB) and label forwarding database (LFIB). This is the main difference between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. In Cisco IOS XR you have only one label in FIB/LFIB for particular destination next-hop, which is ultimately used during traffic forwarding based on next-hop lookup. In Nokia (Alcatel-Lucent) SR OS you will have one MPLS label per MPLS technology (RSVP, LDP, BGP-LU, SPRING) and SDP, which is associated with service, defines MPLS transport to use.
What are we going to test?
We are going to configure 2 different L2 VPN services (LDP and BGP signaled) and also 2 L3 VPN services. Each service will be mapped to its own transport MPLS LSP.
Topology
We have 4 routers (2 Nokia (Alcatel-Lucent) SR OS and 2 Cisco IOS XR) that is basis for all my trials:
From architectural point of view for this lab we’ll have two PE routers (SR1 and XR4) and two pure P routers (SR2 and XR3):
IGP for this trial will be OSPF. The cost of interfaces is changed so that default path between SR1 and XR4 (according to SPF) is SR1 – SR2 – XR3 – XR4. Due to this fact all other links aren’t used for pure IP (and default MPLS) forwarding between SR1 and XR4.
Here are initial configuration files for this lab setup: config_initial_sr1 config_initial_sr2 config_initial_xr3 config_initial_xr4 config_initial_linux
Configuration of MPLS data plane (LDP and RSVP-TE) in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR
First of need to configure MPLS data plane. As I’m going to use different transport protocols (LDP and RSVP-TE), so I have to configure both of them. LDP is RSVP-TE are activated at all interfaces in the network and TE tunnels are built as follows:
- SR1 -> SR2 -> XR4 (backup SR1 -> XR3 -> XR4)
- SR1 -> XR3 -> XR4 (backup SR1 -> SR2 -> XR4)
- XR4 -> SR2 -> SR1 (backup XR4 -> XR3 -> SR1)
- XR4 -> XR3 -> SR1 (backup XR4 -> SR2 -> SR1)
The picture below explains this concept in details:
Now we understand, what we need to do, and we come to the next question that is “how to do it”. There is no problem, just configure the network in the following way:
| 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 |
The configuration so far is straightforward:
- We enable LDP on all interfaces
- We enable RSVP and MPLS-TE at all interfaces and configure corresponding colors to links
- We configure TE tunnels (MPLS/RSVP-TE LSP) between SR1 and XR4 with path protection over diverse path
After implementation of the configuration above we have a lot of MPLS LSPs between SR1 and XR4. Let’s take a look at Nokia (Alcatel-Lucent) SR OS router SR1:
|
A:SR1# show router tunnel-table |
To see the actual MPLS labels for these packets, check LFIB:
|
A:SR1# show router fp-tunnel-table 1 |
Now it’s Cisco IOS XR’s turn. Here we need to take look into different tables, because here is no single table that shows the same information in terms of all outgoing labels/interfaces as in Nokia (Alcatel-Lucent) VSR (SR 7750):
|
RP/0/0/CPU0:XR4#show mpls forwarding |
The first table is LFIB and usually you only look into it, but not in case RSVP-TE sessions, when they are originated at this particular router.
In Cisco IOS XR LFIB doesn’t show outgoing labels in case of locally originated RSVP-TE MPLS tunnels.
Field “IPv4-LSP Addr” points to TE router-id of the remote router, that’s why you see here two same session destinations, whereas in routing table different prefixes are mapped two these tunnels:
|
RP/0/0/CPU0:XR4#show route ipv4 | include tunnel |
As I’ve said, only at originating Cisco IOS XR router you have such problems with RSVP-TE LSPs. at core router (XR3) you see these transit sessions in LFIB:
|
RP/0/0/CPU0:XR3#show mpls forwarding |
After establishment of MPLS transport across all routers in the network we can speak about service mapping.
Mapping of the L2 MPLS VPN service to transport – LDP
As I’ve said in the very beginning, in Cisco world the mapping of the service to the particular LSP is done by mapping it to next-hop (BGP update-source, LDP router-id and so on). So our task is to configure corresponding routing policies at ingress and egress PEs. The following table explains, how we’ll map MPLS L2 services to MPLS LSPs:
| Service | PE A | MPLS LSP A -> B | PE B | MPLS LSP B -> A |
| VPLS_LDP | SR1 | LDP | XR4 | LDP |
| VPLS_BGP | SR1 | SR1_to_XR4_RED | XR4 | tunnel-te60401 |
As there is different technics, which we should use for BGP and LDP based L2 services, let’s start with LDP:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR4 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
If you need to refresh the configuration of VPLS services between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, refer to the corresponding article.
The only different from VPLS configuration, what we have done previously, is configuration of “local-lsr-id” at Nokia (Alcatel-Lucent) SR OS side. The idea behind is very straightforward: we map this VPLS to LDP-based MPLS LSP, so we need to have at XR4 (Cisco IOS XR) MPLS label delivered by LDP for SR1 (Nokia (Alcatel-Lucent) SR OS). As we have IPv4 prefix 10.0.255.1/32 associated with RSVP-TE tunnel, then another prefix must be used. In Nokia (Alcatel-Lucent) IPv4 address of system interface is used as transport address for all kind of LDP sessions by default, so we need to change this behavior for this case. Having said that we also need to keep in mind that transport address will be changed for all kind of LDP based services between SR1 and XR4. If we have more VPLS instances signaled by LDP, all of them will use the same next-hop (and MPLS LSP) from XR4 to SR1. Some checks at Nokia VSR side:
|
A:SR1# show router ldp session 10.0.255.4 detail | match expression “Address|StaAdjacency |
Everything looks fine. What’s about Cisco IOS XR?
|
RP/0/0/CPU0:XR4#show mpls ldp neighbor 10.0.255.11 |
Unfortunately, there is no data plane in Cisco IOS XRv, so I can’t simulate the traffic. As indirect evidence of the correct communication, there is constantly increasing counter for MPLS switched traffic to IPv4 prefix 10.0.255.11/32 at XR4.
Mapping of the L2 MPLS VPN service to transport – BGP
Now it’s turn of the BPG service to be mapped to particular MPLS LSP. Just to refresh, what we need to configure:
| Service | PE A | MPLS LSP A -> B | PE B | MPLS LSP B -> A |
| VPLS_LDP | SR1 | LDP | XR4 | LDP |
| VPLS_BGP | SR1 | SR1_to_XR4_RED | XR4 | tunnel-te60401 |
Let’s see, what we need to configure to launch the second (BGP-based service).
|
Nokia (Alcatel-Lucent) SR OS |
Cisco IOS XR |
|
SR1 |
XR4 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
At Cisco IOS XR router XR4 the traffic for this VPLS service must be mapped to TE tunnel 60401, which means that default BGP next-hop of SR1, which is IPv4 address 10.0.255.1, is used. So no modification with outgoing (or export) BGP policy is needed. At Nokia (Alcatel-Lucent) SR OS side we just map VPLS to certain MPLS LSP using spd-group and pw-template.
Some checks at SR1 side:
|
A:SR1# show router bgp routes l2-vpn |
… And at XR4 side:
|
RP/0/0/CPU0:XR4#show bgp l2vpn vpls |
Again we can’t test data plane.
Mapping of the L3 MPLS VPN service to transport
Finally, we have reached the L3 services. Here is the only signalling option possible, so we’ll configure both VPNs simultaneously. I’m gonna to make the following mapping across MPLS LSPs:
| Service | PE A | MPLS LSP A -> B | PE B | MPLS LSP B -> A |
| L3VPN_A | SR1 | LDP | XR4 | LDP |
| L3VPN_B | SR1 | SR1_to_XR4_GREEN | XR4 | Tunnel-te60411 |
Let’s convert this table into language, which Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR understands:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR4 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR4(config)#show conf |
If you need to refresh some knowledge about BGP/MPLS IP VPN configuration and verification in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, read this article.
There are two unusual things in VPRF/VRF configuration caused by our task:
- For vprn 2004 in Nokia (Alcatel-Lucent) SR OS I statically define spoke SDP in order to map it to certain MPLS LSP. Also we have vrf-export policies configured per VRF that defines next-hop, so that XR4 can map it to corresponding MPLS LSP
- In Cisco IOS XR we define route-policy for vpnv4/vpnv6 address families that changes next hop based on the route target (extended community), so SR1 maps it corresponding VPRN.
After all the BGP sessions are established, you will see VPN prefixes at both PEs with corresponding next-hops and its mapping to transport MPLS LSPs. The first thing to review is BGP RIM at Nokia (Alcatel-Lucent) SR OS router SR1:
|
A:SR1# show router bgp routes vpn-ipv4 |
You see here two next-hops and corresponding labels. Then if you check per-VPRN FIB, you will see how these prefixes are mapped to transport LSPs:
|
A:SR1# show router 2003 fib 1 |
And finally LFIB: :
|
A:SR1# show router fp-tunnel-table 1 |
We have all the necessary information at SR1 to forward the traffic from SR1 to XR4. For the sake of comletness, let’s check the same (or similar) tables at Cisco IOS XR router XR4:
|
RP/0/0/CPU0:XR4#show bgp vpnv4 unicast labels |
We know now how the label stacks at both PEs SR1 and XR4 should look like and we can do some tests with packet forwarding:
|
RP/0/0/CPU0:XR4#show route vrf L3VPN_A |
Wireshark shows us the following picture, which fully corresponds provided output:
And another test:
|
RP/0/0/CPU0:XR4#show route vrf L3VPN_B |
And trace from Wireshark:
The key take away is that there are different transport labels for these two traffic flows, what means that they are really mapped to different transport MPLS LSPs.
The final configuration files are here:
Lessons learned
In the beginning I’ve configured TE-tunnels at Cisco IOS XRv (ASR 9000) as follows:
|
RP/0/0/CPU0:XR4#show run interface tunnel-te60401 |
The command marked with bold installs route to this prefix (10.0.255.21/32) into routing table. Though I was able to make MPLS traceroute and ping remote end (SR1) through this tunnel, mapped services was not working. I.E. I saw the following indication at XR4:
|
RP/0/0/CPU0:XR4#show l2vpn bridge-domain bd-name VPLS_BGP detail | include “neighbor 10.0.255.1” PW: neighbor 10.0.255.1, PW ID 10004411, state is down ( provisioned ) (Transport LSP Down) |
I haven’t found in internet solution for this message and make another configuration. Previously in “ordinary” Cisco IOS there was no such “autoroute destination” command and mainly the mapping of prefix to the tunnel was done using static routes:
|
RP/0/0/CPU0:XR4(config)#show conf |
After applying it I become the following message in syslog:
|
RP/0/0/CPU0:Mar 8 08:13:00.419 : l2vpn_mgr[1182]: %L2-L2VPN_PW-3-UPDOWN : Pseudowire with address 10.0.255.1, id 10004411, state is changed to: Up |
And check of the configuration shows pretty nice working neighbor in VPLS:
|
RP/0/0/CPU0:XR4#show l2vpn bridge-domain bd-name VPLS_BGP detail | include “neighbor 10.0.255.1” |
Old good static routes!
Conclusion
Manipulation of next-hop for services (like BGP next-hop addresses or session’s IP addresses for LDP) adds another level of scalability and flexibility to deploy your networks. This toolset is particular important for traffic engineering scenarios, when you want to achieve better network resources utilization or assure certain parameters for certain services. Take care and good bye!
Support us
BR,
Anton Karneliuk
Just a quick heads-up on a show command to see the local label vs outgoing label mapping on a SROS device.
A:sros4# tools dump router segment-routing tunnel
===================================================================================================
Legend: (B) – Backup Next-hop for Fast Re-Route
(D) – Duplicate
===================================================================================================
————————————————————————————————–+
Prefix |
Sid-Type Fwd-Type In-Label Prot-Inst |
Next Hop(s) Out-Label(s) Interface/Tunnel-ID |
————————————————————————————————–+
10.10.48.8
Adjacency Transit 262139 ISIS-0
10.10.48.8 3 ovs-r4-r8
10.10.47.7
Adjacency Transit 262140 ISIS-0
10.10.47.7 3 ovs-r4-r7
10.10.46.6
Adjacency Transit 262141 ISIS-0
10.10.46.6 3 ovs-r4-r6
10.10.45.5
Adjacency Transit 262142 ISIS-0
10.10.45.5 3 ovs-r4-r5
10.10.24.2
Adjacency Transit 262143 ISIS-0
10.10.24.2 3 ovs-r2-r4
10.10.100.1
Node Orig/Transit 500001 ISIS-0
10.10.24.2 500001 ovs-r2-r4
10.10.100.2
Node Orig/Transit 500002 ISIS-0
10.10.24.2 500002 ovs-r2-r4
10.10.100.3
Node Orig/Transit 500003 ISIS-0
10.10.24.2 500003 ovs-r2-r4
10.10.100.4
Node Terminating 500004 ISIS-0
10.10.100.5
Node Orig/Transit 500005 ISIS-0
10.10.45.5 500005 ovs-r4-r5
10.10.100.6
Node Orig/Transit 500006 ISIS-0
10.10.46.6 500006 ovs-r4-r6
10.10.100.7
Node Orig/Transit 500007 ISIS-0
10.10.47.7 500007 ovs-r4-r7
————————————————————————————————–+
No. of Entries: 12
————————————————————————————————–+
A:sros4#
Hi Gunter,
Thanks for the hint! I have never seen such command before.
BR,
Anton