Hello my friend,
As I’ve promised in the most recent article, I’m going to cover the most scalable and advanced designs for service provider networks. The first such option is Seamless MPLS, so let’s take a look how to deploy it in network built with Nokia (Alcatel-Lucent) SR OS routers and Cisco IOS XR.
Brief overview
Seamless MPLS it isn’t a technology or protocol. It’s rather a framework, which allows you to build really smooth network for all types of services on top of end-to-end MPLS hierarchical LSPs. From the technology/protocols point of view, it’s a mix of RSVP-TE or LDP-based MPLS LSPs + BGP-LU MPLS LSPs + BGP/LDP for services. There are a lot of vendor-specific documentation regarding this framework. For example, Cisco called it Unified MPLS previously, and now it’s called Evolved Programmable Network (EPN). In Nokia (Alcatel-Lucent) it’s called just Seamless MPLS.
I advise you to refer to this RFC draft to get the overall understanding about seamless MPLS.
What are we going to test?
I’m going to build together with you the hierarchical BGP-based MPLS LSP that uses different MPLS transport technologies in different domains (LDP in access and RSVP-TE in core). On top of that we’ll test BGP/MPLS IP VPN. Between PE routers. We aren’t going to test any L2 VPN, because one of the PEs is Cisco IOS XRv, which doesn’t support forwarding plane for such test.
Topology
Here is the physical topology, if this is the first my article about Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR you read:
Here is the logical topology:
If you have read my articles previously (link) you might spot that this is probably the easiest logical topology I’ve ever used. That’s true, because we don’t need additional complexity here, as the configuration will be long even without it. In comparison to the previous labs, we don’t have any IGP configured so far. We’ll do it in this lab as we have to configure additional filtering
Here you can find initial configuration files: sr2_initial xr3_initial linux_initial sr1_initial
IGP domains
First of all, we need to establish connectivity inside our network. As IGP we’ll use ISIS with two levels:
- Level-1 in area 49.1122 is our access network;
- Level-2 is core network;
We don’t need any level-1 prefixes to be leaked into level-2, so we’ll configure filtering at SR2 to prevent it. Take a look at the image below to understand routing topology better:
The configuration to achieve this goal looks like the following one:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | |
|
A:SR2>edit-cfg# candidate view |
What we are doing in the configuration above is very straightforward. SR1, which is Nokia (Alcatel-Lucent) VSR residing in access PE, is configured in the area 49.1122 as pure level-1 ISIS router. Router SR2 that we can consider as core PE is configured to act as level-1/2 ISIS node, where level-1 interface goes to SR1 and level-2 interface goes to XR3. SR2 also has route policy, which prevents leaking of level-1 routes into level-2, what is the default operation mode of ISIS. Cisco IOS XR3 is pure level-2 ISIS router, which we consider as service PE (or another core PE). You might spot that all routers are configured with option “advertise passive-only”, what implies that only prefixes of interface put to “passive” state will be advertised.
More information about ISIS configuration you can find in the corresponding article.
Let’s check routing tables at our routers. Nokia (Alcatel-Lucent)’s SR1 has the following routes:
|
A:SR1# show router route-table |
You see here two ISIS-learned prefixes: one is address of the system’s interface at SR2 and another is default route generated automatically due to attach (ATT) bit in LSP from SR2. Let’s check SR2 now:
|
A:SR2# show router route-table |
At this router we see both system address of SR1 and loopback 0 of XR3. The last but not least is XR3 that is our Cisco IOS XR PE:
|
RP/0/0/CPU0:XR3#show route ipv4 |
Each router knows IPv4 address of all system/loopback0 interfaces in its area (for level-1) or level (for level-2). This information is sufficient to build intra-area MPLS tunnels. Let’s do it.
Transport layer 1 / Intra-area MPLS LSP
To make things more interesting, we’ll configure different protocols for MPLS forwarding plane in access and core network. In access network we’ll deploy LDP, whereas in core RSVP-TE will be configured. Refer to the image below:
I don’t tune the default parameters, so configuration for the first level of MPLS forwarding plane is quite simple:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | |
|
A:SR2>edit-cfg# candidate view |
At the first Nokia (Alcatel-Lucent) SR OS router that is SR1 we only activate LDP at interface towards SR2 and activate LDP-IGP Sync. It isn’t necessary in this particular topology, but in general it’s a good practice.
For more information about LDP configuration in Nokia(Alcatel-Lucent) SR OS and Cisco IOS XR refer to the corresponding article.
At the second Nokia (Alcatel-Lucent) VSR that is SR2 we configure LDP including LDP-IGP Sync at the interface towards SR1. Another its interface is configured for RSVP-TE operation. MPLS LSP from SR2 to XR3 is really simple as there are no restrictions, only 100 Mbps of bandwidth is reserved.
For more information about RSVP-TE configuration in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR refer to the corresponding article.
At the only Cisco IOS XRv router that is XR3 we configure only RSVP-TE at the interface towards SR2 and interface tunnel-te, which is actually RSVP-TE based MPLS LSP. We reserve 100 Mbps of bandwidth for this LSP as well.
There are a couple of commands that are very convenient for checking MPLS forwarding plane. In Nokia (Alcatel-Lucent) SR OS such command is “show router tunnel-table details”, which shows all built MPLS LSPs (actually, GRE tunnels as well) at the router. For SR1 it looks like:
|
A:SR1# show router tunnel-table detail |
There is only one MPLS LSP to IPv4 address of SR2’s system interface. As you may guess, at SR2 we have two MPLS LSPs:
|
A:SR2# show router tunnel-table detail |
Preference is used if there are LSPs to the same destination from different owners (i.E. RSVP and LDP). The lower value is more preferable than the higher value. In Cisco IOS XR RSVP is also more preferable than LDP. By the way, let’s check XR3. Usually we use “show mpls forwarding” to check LFIB. But in case of the outgoing RSVP-TE MPLS LSP it doesn’t show anything useful:
|
RP/0/0/CPU0:XR3#show mpls forwarding |
That’s why for our case we need another command:
|
RP/0/0/CPU0:XR3#show rsvp session detail | include “SESSION|Label|Nam” |
Intra-area MPLS LSPs are working now both in access and core network and we can go ahead.
Transport layer 2 / Inter-area hierarchical MPLS LSP
The next step in our journey is to span two separate intra-area MPLS LSPs into one hierarchical inter-area LSP using BGP-LU (BGP labeled unicast). The image below provides more information:
In short words, we configure BGP for IPv4 labeled-unicast address family (AFI/SAFI 1/4). SR2 plays a crucial role here, which is called “inline-RR” (inline route reflector). It not only sends prefixes between iBGP neighbors (BGP route reflector function), but it also puts itself into data path and changes MPLS label (inline).
For more information about BGP and BGP route reflector configuration in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR refer to the corresponding article.
We need the following configuration to get it working:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
| SR2 | |
|
A:SR2>edit-cfg# candidate view |
In Nokia (Alcatel-Lucent) SR OS we have to configure route-policies in order to announce any local prefix. So you can see that we have such routing policy both at SR1 and SR2. Moreover, this route-policy controls all routing information passing by from peer to peer as well, so we have corresponding entry there. In Cisco IOS XR we can also configure redistribution policy or (what is easier) we can just inject network by “network” statement. We need to explicitly configure allocation of labels for IPv4 unciast prefixes in Cisco IOS XR.
BGP-LU address family for IPv4 is called “label-ipv4” in Nokia (Alcatel-Lucent) SR OS and “ipv4 labeled-unicast” in Cisco IOS XR, so we are establishing BGP peering in this address family between our routers. Command “cluster x.x.x.x” at SR2 activates BGP route reflector functionality, and next-hop-self rewrites the original next hop, when the prefix is passing SR2. In Nokia (Alcatel-Lucent) we need to configure “advertise-inactive” function that allows to send BGP prefixes to peers, even if these prefixes aren’t installed in routing table of the router itself (by default it’s deactivated).
In Nokia (Alcatel-Lucent) SR OS we also must configure BGP so that it resolves next hop to built MPLS LSPs. In Cisco IOS XR this process is done automatically via next-hop resolution in routing table.
More information about BGP-LU (labeled unicast) you can find in the corresponding article.
Let’s check our hierarchical MPLS LSP. We will start at SR1 by reviewing tunnel table:
|
A:SR1# show router tunnel-table detail |
You see that there is two tunnel now, and one of the is BGP-based and has next hop IPv4 address 10.123.255.22, which is available through LDP tunnel. Label and next-hop is known via BGP:
|
A:SR1# show router bgp routes label-ipv4 |
If we check FIB, we’ll see the same information just in the short form:
|
A:SR1# show router fib 1 ipv4 10.123.255.33/32 |
At SR2 we can check BGP RIB to see, which IPv4 prefixes with labels are being received from both PEs:
|
A:SR2# show router bgp routes label-ipv4 |
You see that Cisco IOS XR PE XR3 announces label 3, what means implicit null. You can’t see any “>” sign, because in the routing table there is better routes learned from ISIS.
What about Cisco IOS XR? Good question, let’s check LFIB and BGP RIB:
|
RP/0/0/CPU0:XR3#show mpls forwarding |
We see at all point in the network necessary routing and label information, so we can test our hierarchical MPLS LSP. Just let’s make a ping from SR1 to XR3:
|
A:SR1# ping 10.123.255.33 source 10.112.255.11 count 1 |
Wireshark show how MPLS labels are being swapped along the path:
We see that both labels are being changed at SR2. If there were more routers between SR1 and SR2 or SR2 and XR2, the second label will be swapped also only at SR2, as it spans two IGP domains into one internetwork. Packet from SR2 to XR3 doesn’t have any labels, because XR3 sginals implicit null label (value “3”) both for RSVP-TE (transport level 1) and BGP (transport level 2) due to PHP operation.
Service layer
The last step is to test, how services works on top of built hierarchical MPLS LSP. We’ll configure quite easy BGP/MPLS IP VPN to check operation. The service topology is as follows:
The following configuration deploys this service:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR3 |
|
A:SR1>edit-cfg# candidate view |
RP/0/0/CPU0:XR3(config)#show conf |
For the explanation of BGP/MPLS IP VPN operation and configuration refer to the previous article.
Just brief overview that we have established BGP peering for vpnv4/vpnv6 unicast address families (AFI/SAFI 1/128 and 2/128) and route tables for IPv4 and IPv6 in corresponding VPRN/VRF. Nokia (Alcatel-Lucent) SR1:
|
A:SR1# show router bgp summary |
Cisco IOS XR3:
|
RP/0/0/CPU0:XR3#show bgp vpnv4 uni summary |
And finally ping for IPv4:
|
A:SR1# ping router 65100 192.168.3.1 source 192.168.1.1 count 1 |
Wireshark trace for it:
Ping for IPv6:
|
A:SR1# ping 10.123.255.33 source 10.112.255.11 count 1 |
Wireshark trace for it:
You see that the last (bottommost) label is the same across both hops, as it’s signaled and processed only by PEs. The first two labels are transport labels.
Final configuration: sr1_final sr2_final xr3_final
Lessons learned
During configuration of each lab I face some issues. Sometimes these issues are related to the different operation of the technologies and protocols at different platforms, whereas in the rest of the cases it’s a bugs caused by HW/SW version. But it might be that there is my configuration failure as well 🙂 This time I’ve configured “local-as 65000” instead of “peer-as 65000” at SR1 (Nokia (Alcatel-Lucent) VSR (SR 7750)), what prevents possibility to establish peering with Cisco IOS XR3. “Local-as” feature is used when we want to change our AS in the BGP Hello packets as well as add it to AS_PATH path attribute in BGP update. It’s an optional feature that is not widely used, whereas “peer-as” is mandatory for configuration BGP neighborship. If you don’t configure “peer-as” (in Cisco IOS XR it is called “remote-as”), the BGP peering won’t be established. In logs of Cisco IOS XR there were information, whereas in the log of SR1 I found something like “peer isn’t configured or activated”. Only comparison of the configuration with the working one in a “line-by-line” fashion allowed me to find my own typo. As Brain McGahan from INE said in his CCIE classes: “Troubleshooting is a half of fun”.
Conclusion
In general, seamless MPLS provides you to achieve the highest level of flexibility and scalability inside your network. Using BGP-LU you can different IGP domains, which have their own MPLS transport domains, span into one manageable hierarchical MPLS transport domain. It’s necessary in order to reduce number of routing information (prefixes and labels) at all devices. On low-end devices (like Nokia SAR 7705 or Cisco ASR 901/903) there might be not enough resources to process all prefixes and labels from the whole network, if this network has one level (or one area) flat topology. So seamless MPLS will make it possible for small routers to work. Another advantage is that flapping of interfaces inside one area (changes of link-state information) will be distributed inside small part of the network, speeding up convergence and lowering administrative overhead for links. So, I advise you to use seamless MPLS in your network. Take care and good bye!
Support us
BR,
Anton Karneliuk
Hi sir Anton. Thank you for your article really helped me in understanding Seamless MPLS. I am a final semester students who are taking final task about seamless mpls. What if I want to replace ISIS with OSPF? Would you please tell me the configuration? I would be very grateful if you would reply to my question. Thank you once again sir 🙂
Hi Nisa,
thanks for your question. Actually the configuration will be just the same. I’d configure ACCESS network as any non-backbone stub area (i.e. area 0.0.0.1 stub) and CORE network as backbone. you should filter at SR2 routes so that only it’s loopback besides default route is injected into area 0.0.0.1. Everything other doesn’t differ.
BR,
Anton
Thanks sir for the answer. But sir I have an issue when trying to make policy-statement RP_NO_ISIS_LEAK with ospf.
1. I cant do “action drop” in my configuration, theres only “action accept” and “reject”, is “action reject” and “action drop” has similar purpose?
2. In IS-IS you use policy-statement RP_NO_ISIS_LEAK>>entry 10>>from>>level 1>>to>>level 2, what should it be in ospf? Because I cant use from>>area 0.0.0.1>>to>>area 0.0.0.0, I cant assign area 0.0.0.0 as destination prefix, theres only neighbor and prefix-list.
Your answer would be really helpful for me sir.
Hi Nisa,
You can’t apply ISIS policies for OSPF.
1) “reject” and “drop” are similar actions.
2) ISIS don’t have that area in the same meaning as OSPF. ISIS has concept of level instead.
BR,
Anton
Hi Man,
I think you should study what is different between the OSPF and ISIS. They have some different.
Hi Morgan,
You are right, there are some differences between them, but there are much more similarities.
BR,
Anton
Hi Sir Anton, Thank you for your article really helped me in understanding Seamless MPLS. I am working on VPLS related stuff. It would be good if you can post some article on VPLS in Seamless MPLS Networks and also protection mechanism for VPLS in Seamless MPLS Networks.
Hi Srikanth,
In general VPLS might work in the seamless MPLS scenario in the much same way as in ordinary scenario, if inter-AS option C is deployed. You need to take care about inter-AS MPLS LSP, which is not related to VPLS.
If you deploy Option-B, then you will have stiching at ASBR. This scenario is much more complex.
BR,
Anton
Hi Sir Anton, Thanks for your reply. I would like to understand how load balancing works for VPLS in seamless MPLS Networks from forwarding plane perspective . It would be good if you can post some article related to this.
Hi Srikanth,
It fully depends on your configuration. And VPLS or VPWS it doesn’t play major role to be honest. What matters, how you provision e2e path. If you have multipe ABR/ASBR routers and therfore multiple options how to reach PE in another part of the network AND you use LDP or SR, then you have possibility for load balancing within VPLS. Don’t forget to enable control-world and entropy label if it’s supported. If you use MPLS-TE with RSVP or SR-TE, typically you won’t have load balancing within your VPLS.
Hope this helps.
BR,
Anton