Hello my friend,
In this article we’ll talk about the newest technology that can build MPLS data plane. This technology is called Segment Routing, or more formally SPRING (Source Packet Routing In NetworkinG). Let’s take a look how you can configure it in multi-vendor network built with Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR.
Disclaimer
Segment Routing is really new technology. Most of its information is still contained only in IETF drafts, and only one of these drafts has just recently become an RFC. I advise you to spend some time here in order to understand how it works, as I’m not going to explain theory in details. Very good explanation of Segment Routing is provided in book “MPLS in SDN Era” written by Juniper engineers and in presentation of my colleagues. Moreover, I’m very proud of my colleagues, who contributed to development of Segment Routing technology.
Topology
I’m aiming to change the physical architecture a little bit, but it’s still ongoing process. Probably I’ll change it in the next article, but for now the old physical topology is used:
The logical topology is a little bit changed comparing to the previous. The main difference is I’ve reduced the number of links between XR1 and SR1, changed IP addresses and use OSPF as a core IGP:
Frankly speaking, both ISIS and OSPF supports Segment Routing, so you can configure whatever you like. In ISIS it’s even easier to review the structure of new TLVs in the LSP, which contain Segment-Routing-related information. The same information is distributed in OSPF by mean of opaque LSAs (actually, the same LSA type 10 (area scope)) that are used for distributing traffic-engineering information and population of TED. Pay attention also that interface Lo11, Lo22, Lo33 aren’t advertised via OSPF. We’ll advertise them later via BGP in order to show you how MPLS forwarding plane with Segment Routing works.
Any way you can find initial configuration for the lab in the following files:
Building segment routing (SR) MPLS forwarding plane
Before jumping into configuration part, we need to review some specific configurations related. There are two most important components regarding Segment Routing for building MPLS forwarding plane:
- Label block defines possible label values used by certain node (router) in the network.
- SID (site ID) identifies node in the forwarding domain, therefore it must be unique in whole Segment Routing domain.
At the picture below you can find label block / SID per router:
Let’s configure Segment Routing in our lab built with Nokia (Alcatel-Lucent) VSR (SR7750) and Cisco IOS XR (ASR 9000) routers:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
A:SR1>config>router# info |
RP/0/0/CPU0:XR1(config)#show conf |
| SR3 | |
|
A:SR3>config>router# info |
The first point that is important to understand is that in SRPING (Segment Routing) no one signals label itself (at least in interoperable version that implies using indexes). Each router advertises its label block and index via IGP. Then each router calculates label independently from other routers. It may seem to be crazy, but all routers use the same rule:
Egress label equals index of the destination node plus first label from label block of the next hop (to the destination) router.
Later I’ll provide some pictures from Wireshark, so you will understand this rule better.
As the implication of the rule above, each router waits that ingress label for the certain destination will be equal sum of destination’s index and router own’s first label from label block.
Using such common approach to calculation there is no necessity to signal specific labels. Moreover, you don’t need any additional protocol besides your routing protocol (OSPF of ISIS) in order to build MPLS data plane.
Regarding configuration, as you can mention, everything is quite simple. We just enable Segment Routing and configure SID (unique in the OSPF area or ISIS level). In Nokia (Alcatel-Lucent) SR OS you also have to configure label block for Segment-Routing, as it isn’t configure by default. In Cisco IOS XR label block is configured so you don’t have to do it. Let’s check label block in Nokia (Alcatel-Lucent) SR OS:
|
A:SR1# show router mpls-labels label-range |
In principle you can configure any range for Segment Routing (SPRING) labels you like from Dynamic range. You see that amount of available labels in Dynamic range is decreased by total amount of Segment Routing labels. The next point is LFIB. In Cisco it’s quite easy to check it:
|
RP/0/0/CPU0:XR1#show mpls forwarding |
You can see that here are two types of labels. The range of MPLS labels within 16000-23999 relates to Node-SIDs, whereas labels from 24000 relate to Adj and represent particular interfaces towards particular neighbor. The latter labels have only local significance and are used for traffic engineering. They aren’t used in our lab, because you have to have external controller (PCE server) that will provision TE tunnel. Segment routing (SPRING) TE is out of the scope of our lab.
I was think about some similar table for Nokia (Alcatel-Lucent) SR OS. When I’ve asked instructor at one course about LFIB, he said there is no such opportunity to check it and you must to check labels per protocol. Hopefully I’ve found how to see LFIB:
|
A:SR1# show router tunnel-table detail |
Cisco IOS XR implements PHP by default for all types of MPLS LSPs (LDP, RSVP-TE, BGP labeled unicast, SPRING). That’s why the label is 3.
Before testing operation of Segment Routing (SPRING) MPLS data plane, let’s see how this information is distributed via OSPF:
|
A:SR1# show router ospf opaque-database adv-router 10.255.255.11 detail |
For current lab only first two LSAs are relevant, because the last two that starts with “8.” contain local adjacency labels. In the LSA starting with “4.” there is information about label block (the first label and the maximum amount of possible labels) and available algorithm. We must have common algorithm across vendors in our network to get SPRING working. In the LSA that starts with “7.” there is information about router’s SID and related prefix. The same information you can check in Cisco IOS XR with the following commands:
|
RP/0/0/CPU0:XR1#show ospf database opaque-area adv-router 10.255.255.22 |
Again, we are interested only in the first two LSAs. Pay attention that we have only one common algorithm in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR that has numerical value “0”. This algorithm use the rule in terms of MPLS label calculation that is described above. Now it’s time to check how Segment Routing works. We’ll make two tests to show how labels are actually pushed, swapped and popped. Two tests are needed due to PHP behavior of egress PE in Cisco IOS XR.
Case 1 – from SR1 to SR3 to XR1
In the first test we’ll disable direct interface between SR1 and XR1 in order to make all traffic pass SR3. Also we’ll configure iBGP session between SR1 and XR1 and announce Lo11 and Lo22. At Nokia (Alcatel-Lucent) SR OS router SR1 we’ll configure next-hop resolution policy in BGP to use Segment Routing MPLS LSP (in Cisco next-hop resolution is done automatically to best option in routing table including MPLS LSPs). So the resulting topology looks like the following picture:
To accomplish the task above we’ll configure our routers in the following way:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
A:SR1>config>router# info |
RP/0/0/CPU0:XR1(config)#show conf |
Let’s check in our Nokia (Alcatel-Lucent) SR OS PE, how we can reach prefix 22.22.22.22/32:
|
A:SR1# show router fib 1 ipv4 22.22.22.22/32 |
You see that next-hop point to Segment Routing MPLS LSP. Let’s perform ping from IPv4 prefix 11.11.11.11/32 to prefix 22.22.22.22/32:
|
A:SR1# ping 22.22.22.22 source 11.11.11.11 |
And here is the result, what shows us Wireshark:
You see that on the forward path SR1 to XR1 we have the following labels:
- SR1 -> SR3: MPLS label is 500022 (22 is SID of XR1 and 500000 is first available label in SR3’s label block.
- SR3 -> XR1: there is no label, because egress PE XR1 asks SR3 for PHP:
|
A:SR3# show router tunnel-table 10.255.255.22/32 detail |
On the backward path from XR1 to SR1 we see label 500011 at both hops, because SID is persistent in the whole network (11 for SR1) and label block we have configured the same at SR1 and XR1.
Case 2 – from SR1 to XR1 to SR3
In the second test we’ll put XR1. As Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS have different label blocks for Segment Routing (SPRING), we should have different labels in Wireshark’s output. So we bring back connectivity SR1-XR1 and disable direct link SR1-SR3. Then we configure BGP session between SR1 and SR3 using the same guidelines that we’ve used in the first case:
Configuration in this case is done solely at Nokia (Alactel-Lucent) VSRs (SR7750):
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Nokia (Alcatel-Lucent) VSR (SR 7750) |
| SR1 | SR3 |
|
A:SR1>config>router# info |
A:SR3>config>router# info |
Let’s briefly check FIB at our routers:
|
A:SR1# show router fib 1 ipv4 33.33.33.33/32 |
Let’s check how MPLS labels are processed in this case:
|
A:SR1# ping 33.33.33.33 source 11.11.11.11 |
Now the picture from Wireshark is a little bit different:
Here the labels are different at all hops, so let’s discuss it. For the forward path we have the following labels:
- SR1 -> XR1: MPLS label is 16033 (33 is SID of SR3 and 16000 is first available label in XR1’s label block).
- XR1 -> SR3: MPLS label is 500033 (33 is SID of SR3 and 500000 is first available label in SR3’s label block).
The backward path passes XR1 as well, so LSP looks as follows:
- SR3 -> XR1: MPLS label is 16011 (11 is SID of SR1 and 16000 is first available label in XR1’s label block).
- XR1 -> SR1: MPLS label is 500011 (11 is SID of SR1 and 500000 is first available label in SR1’s label block).
Pay attention that you can’t test LSP XR1 to SR3, because there is no direct iBGP peering and we don’t have any BGP RR (Route Reflector) in the network.
The final configs are here:
Lessons learned
Before writing this article I was mistaken about actual label calculation. Previously I’ve used Segment Routing (SPRING) only in Cisco IOS XR environment, where the label block are common for all routers. In current lab I had opportunity to play with different topologies of MPLS data plane:
- SR OS <-> SR OS <-> IOS XR
- SR OS <-> IOS XR <-> SR OS
These two cases clearly show how the labels are calculated and used. Labbing is wonderful!
Conclusion
MPLS/SPRING (Segment Routing) is the 4th option that can be used for establishing MPLS data plane. We can say that it’s last (the most recent developed and the most recent in articles), but not least. Actually there are no other possibilities to establish MPLS data plane:
|
A:SR1>config>router>bgp# next-hop-resolution shortcut-tunnel family ipv4 resolution-filter |
Well, there is one more option that is manual MPLS LSP, where you manually create MPLS labels and their operations at each hop. But this option isn’t scalable and isn’t used in production. Segment Routing (SPRING) is emerging technology and in my opinion it has all possibilities to become the most used technology in the recent future due to wide options for traffic engineering.
The next big topic in my series will be MPLS VPN services (L2 and L3). Take care and good bye!
Support us
BR,
Anton Karneliuk
