Hello my friend,
Up to know we were discussing configuration of routing protocols to establish connectivity between network elements: OSPF for IPv4, OSPFv3 for IPv6, ISIS both for IPv4/IPv6 and BGP both for IPv4/IPv6 are already covered. Now we’ll take a look at the next key point of service provider network, which is MPLS. We’ll start with LDP.
Disclaimer
As you know, LDP is used for numerous application in networks besides pure MPLS/LDP forwarding. It’s used also in MPLS L2 VPNs like VPWS and VPLS. In the latter applications targeted LDP session is used. We won’t cover their configuration in this article, because they must be reviewed together with their applications. In this article we’ll cover only ordinary LDP that is used for establishment of MPLS forwarding plane for all kind of applications.
Topology
The physical topology remains the same, as we have used it previously. We are using only one physical interface, so you can omit VMNet4-eth3-br3:
For the logical topology we’ll use the same topology, as we have used previously in ISIS. The only difference is that all routers will reside in level-2 and each router has its own area, which corresponds to the last digit in IPv4 address of system interface or loopback0:
Usually in the core of the network you will use only one-layer level-2 infrastructure, with level-1 used in aggregation domains. This is the typical architecture for seamless MPLS, what is the most robust topology service providers’ networks now.
Don’t forget to activate ECMP in Nokia (Alcatel-Lucent) SR OS if you don’t use our initial configuration files
Initial configuration is available here: linux SR1_initial SR3_initial XR1_initial
LDP for IPv4
In order to turn on any kind of protocol that will form MPLS forwarding plane, we should get routing protocol converged. We’ have used ISIS as our IGP, so let’s check if we have all routes in routing tables in our Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR routers. SR1 has the following routing table:
|
A:SR1# show router route-table ipv4 |
You can mention that we announce only system interface/loopback 0 and loopback 1/2 in ISIS. For MPLS data plane the interconnect prefixes are usually isn’t interesting, because the MPLS label is needed only for next hop (transport label) and customer services (service label).
More information about concept of labels you can find in this article.
Let’s establish the simplest MPLS forwarding plane by configuring LDP in our multi-vendor core network with Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR and compare their operation:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
*A:SR1>config>router>ldp$ info |
RP/0/0/CPU0:XR1(config)#show conf |
| SR3 | |
|
*A:SR3>config>router>ldp$ info |
The router-id from LDP isn’t explicitly configured in Nokia (Alcatel-Lucent) SR OS, because we have configured it initially in global routing configuration. In Cisco it’s necessary to configure it explicitly per protocol.
Just after applying the configuration above you can see LDP coming up:
|
Cisco IOS XR: |
Even with configured logging I haven’t managed to catch the log message for LDP sessions establishment in Nokia (Alcatel-Lucent) SR OS
As we haven’t seen the logs, we need another way to check if the LDP session is established. Frankly speaking we should do it in all cases. The SR1 has the following picture regarding LDP neighbors:
|
A:SR1# show router ldp session |
In Cisco IOS XR you can check LDP neighbors with the following command:
|
RP/0/0/CPU0:XR1#show mpls ldp neighbor brief |
Remember that regardless of the number of interfaces that is used to interconnect neighboring LDP routers, only one LDP TCP session is established. This session is used for label distribution, whereas LDP hello (over UDP) packets are being sent/received over each interface:
|
A:SR1# show router ldp interface |
In Cisco IOS XR there is a little bit another command is used to display the same information:
|
RP/0/0/CPU0:XR1#show mpls ldp discovery |
As usual there is a lot of possibilities to see the necessary information. I provide the more useful from my point of view.
So far so good. We have checked that LDP peering is established between all our routers and all necessary interfaces are enabled for LDP operation. Let’s check the actual labels that are used for MPLS forwarding. First of all let’s check the LFIB (label forwarding information base) in SR1, which is Nokia (Alcatel-Lucent) SR OS routers:
|
A:SR1# show router ldp bindings active |
Before analyzing it let’s check the XR1’s LFIB, which is Cisco IOS XR router:
|
RP/0/0/CPU0:XR1#show mpls forwarding |
You can spot three major differences in default operation of LDP between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR:
| Parameter | Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| Label allocation | VSR (SR 7750) generates the label only for system interface by default | XRv (ASR 9000) generates label for all known prefixes in routing table |
| IPv4 and IPv6 | VSR (SR 7750) by default implements dual stack label allocation both for IPv4 and IPv6 | In XRv (ASR 9000) LDP operates for IPv4 address family by default only |
| PHP | VSR (SR 7750) doesn’t use PHP by default | XRv (ASR 9000) implements PHP |
The first difference is visible through “Unlabeled” in MPLS LFIB in Cisco. It means that there is no label from next-hop router that is LDP neighbor as well. Alternatively in SR1’s output you see that there is only one prefix with “Pop” operation meaning that only this LSP terminates here.
The second difference is more interesting. Up to the recent version of Cisco IOS XR there were no support for IPv6 LDP. We’ll cover IPv6 LDP later in this article.
The third difference refers to optimization of forwarding lookup. If PHP (Penultimate Hop Popping) is disabled:
- Router signals local prefixes to neighbor with labels of some values.
- When it receives the prefix with labeled packet it performs LFIB lookup first.
- Router determines that operation is “Pop” and it removes the label.
- Router makes another lookup in FIB in order to find route for unlabeled IP packet.
When PHP is enabled:
- Router signals local prefixes to neighbor with special value of 3 (by default).
- This special label value is called “implicit null” and means that router should pop label before sending the packet to neighbor.
- The egress router performs only IP lookup in FIB then.
Both of the cases above have their pros and cons. Enabled PHP increases the efficiency of the router, but it makes the end-to-end QoS in the MPLS backbone more difficult to implement. It’s totally up to you, whether use PHP or not. You can see in output from SR1 that Cisco announces all its connected prefixes with label of value 3.
Let’s align the operation of MPLS in our network. To do it we’ll configure the allocation of labels only for host routes (prefix 32 for IPv4 and 128 for IPv6) both in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR. Also we’ll activate PHP at Nokia (Alcatel-Lucent) routers:
| Nokia (Alcatel-Lucent) VSR (SR 7750) | Cisco IOS XR (ASR 9000) |
| SR1 | XR1 |
|
*A:SR1>config>router>policy-options# info |
RP/0/0/CPU0:XR1(config)#show conf |
| SR3 | |
|
*A:SR3>config>router>ldp# info |
We don’t need such policy at SR3, because we announce there only system interface.
After changes in the configuration, you see that MPLS data plane has changed. Cisco IOS XR shows now that its operation is to pop the label for all egress packets:
|
RP/0/0/CPU0:XR1#show mpls forwarding |
You can see that there is no locally generated prefixes in LFIB, because due to PHP there is no LFIB lookup. In order to see the label for local prefixes in Cisco IOS XR you should issue another command:
|
RP/0/0/CPU0:XR1#show mpls ldp bindings |
This command is more similar to “show router ldp bindings active” in Nokia (Alcatel-Lucent) SR OS
And now we see that there are much more “Pop” operations at SR1:
|
A:SR1# show router ldp bindings active | match expression “Pop|Prefix|Egres|=” |
Now it’s time to make some tests. There is a special MPLS OAM toolset that helps to check MPLS forwarding plane. Both Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR have this functionality. Let’ check from SR3 side first of all:
|
A:SR3# oam lsp-trace prefix 10.0.255.1/32 detail |
And from XR1:
|
RP/0/0/CPU0:XR1#traceroute mpls ipv4 10.0.255.1/32 source 10.0.255.2 |
MPLS OAM is activated by default in Nokia (Alcatel-Lucent) SR OS, but in Cisco IOS XR you have to do it explicitly by issuing “mpls oam” from global configuration.
As all our routers are connected to each other we can’t see the label swap operation. Let’s bring down links between SR3 and XR1 to force all the traffic pass the SR1 and then repeat the tests:
|
A:SR3# oam lsp-trace prefix 10.0.255.1/32 detail |
Cisco IOS XR side:
|
RP/0/0/CPU0:XR1#traceroute mpls ipv4 10.0.255.1/32 source 10.0.255.2 |
You see that there is a difference between Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS:
- Nokia (Alcatel-Lucent) SR OS shows the label that is associated with next hop (label[1]=3 is implicit null label).
- Cisco IOS XR shows the label that is associates with egress interface. You see the Label 262141 (advertised by SR1 to XR1) in trace.
|
RP/0/0/CPU0:XR1#show mpls forwarding |
We’ll bring back disabled link between SR3 and XR1 and go further.
LDP for IPv6
For a long time there was no option to build MPLS forwarding plane over IPv6 addresses, though there were possibility to distribute service labels for IPv6 prefixes in BGP/MPLS VPNs. In the last year (2015) was finally published RFC7552 (https://tools.ietf.org/html/rfc7552) that introduces the operation of LDP for IPv6. So now you can build MPLS forwarding plane over IPv6 core.
In Cisco IOS XR there is support for this technology starting from 5.3.x release. In Nokia (Alcatel-Lucent) it seems to be supported since 13.0.R1, but I might be mistaken.
As you’ve seen before, Nokia (Alcatel-Lucent) SR OS operates both in IPv4/IPv6 mode by default. In the configuration above you might have seen “dual-stack” keyword that says about it. So we need to activate LDP for IPv6 in Cisco IOS XR.
| Cisco IOS XR (ASR 9000) |
| XR1 |
|
RP/0/0/CPU0:XR1(config)#show conf |
So far config seems good, it doesn’t work. You can run LDP IPv6 separately in Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, but not together at least now. We see the following information at SR3 regarding XR1:
|
A:SR3# show router ldp session detail | match expression “IPv6|Session” |
You can see that SR3 considers XR1 to be not IPv6 capable. In the same time you see that SR3 receives prefixes from XR1 for IPv6, but it doesn’t send any single IPv6 prefix over LDP to Cisco IOS XR router. Nevertheless SR3 installs received IPv6 prefixes into LFIB:
|
A:SR3# show router ldp bindings active ipv6 |
Cisco IOS XR routers has solely its own labels:
|
RP/0/0/CPU0:XR1#show mpls ldp ipv6 bindings |
Probably in future releases it will be fixes, but in my lab (Nokia (Alcatel-Lucent) SR OS TiMOS-B-13.0.R1 and Cisco IOS XR 5.3.2 I haven’t managed to force SR1/SR3 to send IPv6 prefixes to Cisco IOS XR.
Also I’ve noticed the following output during session establishment between Nokia (Alctel-Lucent) SR OS and Cisco IOS XR:
|
RP/0/0/CPU0:Jun 18 21:07:11.384 : mpls_ldp[1049]: DBG-MsgRcv[1], VRF(default): Peer(10.0.255.3:0): Peer(10.0.255.3:0): Unsupported/Unknown TLV (type 0x50a, U/F 1/0) rcvd in INIT msg |
As you can see there are 3 TLVs that aren’t negotiated between SR1/SR3 and XR1
LDP security and high availability
As with other protocols, there are several mechanisms that can be used to increase the security and resiliency of LDP. In terms of security there is a possibility to implement authentication based on MD5, like BGP.
For high availability there are two options:
- LDP IGP Sync. This mechanism is used to prevent traffic black holing, when there is a convergence in the network. Routing protocol (OSPF or ISIS) will send maximum metric for link prefix over which both IGP and LDP works, if LDP peer hasn’t sent its labels
- Session protection. In this mechanism in case of link failure the hello adjacency from link based (multicast to 224.0.0.2) is converted to targeted hello (unicast to transport IP address of peer). It saves then session and label bindings, so after the link between routers is restored, LDP has already all labels so the convergence is quicker.
There is no necessity to use both mechanisms of high availability simultaneously. So we’ll configure LDP IGP Sync at all routers, because it’s more widely used and seems to make more sense personally for me.
What we will do is to configure router authentication between our LDP router and LDP IGP Sync:
| 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 |
Before you apply the configuration above, you can see that LDP SYN is disabled at interfaces under IGP interfaces view mode. Here is the output from Nokia (Alcatel-Lucent) SR OS:
|
A:SR3>config>router>if# show router isis interface toXR1 detail | match expression “Interface|Ldp” |
And here the output for the same link from Cisco IOS XR:
|
RP/0/0/CPU0:XR1(config)#do show isis int gig 0/0/0/0.23 | inc LDP |
After the configuration is allied you will see that in the same outputs. SR3 now tells you that it has LDP Sync enabled:
|
A:SR3# show router isis interface “toXR1” detail | match expression “Interface|Ldp” |
XR1 says that it has even achieved Sync state:
|
RP/0/0/CPU0:XR1(config)#do show isis int gig 0/0/0/0.23 | inc LDP |
To check the authentication parameters configured, use the following command in Nokia (Alcatel-Lucent) SR OS:
|
A:SR1# show router ldp tcp-session-parameters |
To get this information in Cisco IOS XR you should just issue the standard command for reviewing peer parameters. In order to reduce output, we have applied the basic filter:
|
RP/0/0/CPU0:XR1#show mpls ldp neighbor | include “Peer|MD5” |
The files with final configuration you can find here: SR1_final SR3_final XR1_final
Cisco IOS XR LDP config simplification
In Cisco IOS XR (as well as in IOS, IOS XE and NX-OS) there is a mechanism that simplifies a little bit configuration of MPLS LDP, which is called auto configuration. Instead of activating LDP at all necessary interfaces, you can activate it just with one command at all interfaces, where your chosen IGP is already activated. It works as follows:
|
RP/0/0/CPU0:XR1(config)#show conf |
With such configuration you don’t need to explicitly configure interfaces in MPLS LDP configuration mode. You can see that interfaces are configured through this feature at XR1:
|
RP/0/0/CPU0:XR1#show mpls ldp interface |
The config for your reference is here: XR1_final_autoconfig
Lessons learned
Until this article I wasn’t aware about LDP IPv6. I knew that there is no possibility to run MPLS forwarding plane over IPv6 core. Now I know that it’s possible, though I haven’t managed to run it in multivendor environment. Probably it will be possible to do get LDP IPv6 working with real devices with the latest SROS/IOS versions, but I don’t have such lab now.
Conclusion
LDP is the first possibility that we use to build MPLS data plane. You can see that basic configuration of it is really straightforward. Even some additional features that improves its operation are easy both for understanding and implementing. That’s why LDP is widely used in the networks, where pure MPLS forwarding without Traffic engineering is enough. For MPLS traffic engineering (MPLS-TE) usually RSVP was used and is being used further. Nowadays to the area comes Segment Routing (SR) that just reinvents the MPLS forwarding plane in terms of labels usage. We’ll cover these and other topics later in the next articles. Take care and good bye.
Support us
BR,
Anton Karneliuk