LDP Features - Tweaking the Protocol

Visibility: Open to anyone

    This document aims to help you understand not only how to enable LDP (Label Distribution Protocol) on both IOS and IOS-XR but also to tweak it so that you can optimise and protect this critical control-plane protocol in MPLS core backbones. This document will be covering topics ranging from authentication to session protection so that you only form adjacencies with whom you expect and to help improve convergence during network flapping events. The main focus on this document is to help optimisation in MPLS service provider networks however could be adapted to enterprise networks wishing to obtain similar optimisations.

     

    Prerequisites

     

    • Basic understanding of MPLS Architectures
    • Basic understanding of Label Switching
    • Basic understanding of IGP interaction with LDP
    • Knowledge of IOS-XR syntaxes is advisory although not mandatory

     

    LDP - What is it?

     

    LDP or Label Distribution Protocol is the main control-plane protocol used to allow the dynamic allocation and advertisements of MPLS labels for IP prefixes in a core network. It is the industry standard protocol that lead to the demise of the Cisco Proprietary, legacy TDP (Tag Distribution Protocol) which completed a similar function. LDP's transport uses a TCP port 646 and UDP port 646 for dynamic neighbour discovery and session establishment. UDP is used to discover local link neighbours by using the destination multicast address of 224.0.0.2 (All Routers) and once discovered; LDP will establish a TCP session to the transport address listed inside the payload to form an adjacency to advertise allocated labels. Once adjancencies are established, routers can then immediately label switch traffic and perform basic MPLS functions within the core network. The main advantage of the dynamic discovery is the relatively easy "plug and play" nature with little configuration options required to obtain a functional MPLS core. This document aims to reveal the various configuration options available to you so you can tweak and tune the protocol to your environments needs.

     

    LDP Basic Configuration

     

    This next section will be using the following topology to demonstrate basic LDP configuration on IOS and IOS XR so label switching can be achieved.

     

    topology.PNG

     

    I have already configured the other portions of the network required in MPLS L3 VPN scenarios. The final part is to configure MPLS in the core.

     

    For IOS and IOS-XE the following configurations were applied under the OSPF interface to enable LDP on all IGP interfaces.

     

    mpls-ldp.png

    For IOS-XR you need to enable the MPLS process and then add the configuration under the routing process. Please note that LDP can be enabled on a per-interface basis or under the routing process if the IGP is link-state.

     

    mpls-ldp-xr.png

     

    With LDP configured we can then verify that the neighbours have formed and that pinging from CE1 to CE2 is established in the data-plane. This can be done with the show mpls ldp neighbor command and with IOS-XR supporting the brief output of this.

     

    mpls-neighbour-verify-initial.PNG

     

    ping-working-initial.PNG

    With connectivity working, we can now move on to tweaking the protocol.

     

    LDP Authentication

     

    LDP uses TCP for the neighbour transport and therefore it utilises TCP option 19 for authentication (Similar to BGP). Since it uses TCP for authentication it is limited to the hashing functions within TCP. This is the reason why MD5 is the only supported authentication hash. As iterated in previous documents, authentication is not encryption and all the control-plane packets will still be sent in clear text.

     

    Configuration

     

    In this case I will be configuration authentication between all LDP peers using the same topology as before. This can be seen again below:

     

    topology.PNG

     

    LDP authentication can be enabled on a per-neighbour basis or on a group fallback. Below shows an example of a per neighbour authentication. Note that the neighbour listed is the TCP transport address and not the UDP source address. This is critical to ensuring the password is configured for the right neighbour.

     

    For IOS and IOS-XE:

     

    mpls-password-neighbour.PNG

     

    For IOS-XR:

     

    mpls-password-neighbour-xr.PNG

     

    An interesting thing to note is that for IOS and IOS-XE, a password change isn't immediately enforced and only during session establishment. This means a manual reset of the neighbour is required OR to issue the mpls ldp password required command to force the use of any updated passwords.

     

    If a new neighbour comes onto the LDP network you can configure a fallback password that the device will need to meet in order to succeed authentication. This is also the method that can be used to tie a key chain with LDP authentication for key rotation.

     

    For IOS and IOS-XE this is the following configuration:

     

    fallback-password.PNG

     

    For IOS-XR:

     

    fallback-password-xr.png

     

    To cover every permutation of LDP authentication would take too long to discuss in one document. I encourage you to review the docmentation at the end of this document for further reading.

     

    LDP IGP Sync

     

    IGP sync is a protection mechanism in LDP that is designed to prevent a traffic blackhole when IGP is working but LDP has failed. In MPLS based service providers this can cause a failure in the data-plane since MPLS labels are used to direct the traffic to the PE router and to tell the PE router what VRF a packet belongs to.

     

    For example, consider the following diagram:

     

    LDP-Failure-Topology.PNG

     

    LDP IGP Sync attempts to resolve this issue by advertising the failed LDP link as a high IGP cost in the effort to avoid routing native IP packets across it. This then allows other backup paths to be used to route around the failure to the destination.

     

    To configure this setting there is only an additional command that needs to be applied under the routing process.

     

    For IOS and IOS-XE and IOS-XR:

     

    igp-sync.png

    Once enabled, you can verify the sync status by issuing show mpls ldp igp sync

     

    igp-sync-verify.PNG

     

    If the sync status is NOT achieved then this is an indication that the transport-address advertised is not equal a router's LDP router-id. To now demonstrate the repair action, I will now block LDP between PE1 and PE2.


    Once LDP has been disabled the peer is then failed the synchronisation check:


    sync-status.png

    As a result of this failure, PE1 then changed it's type 1 LSA to set the link to the maximum metric to avoid routing through it.

     

    OSPF database change.png

     

    Now, if a trace is completed from the customer side, the traffic still passes.

     

    ce-trace.PNG

    LDP Session Protection

     

    Session protection is a feature in LDP designed to optimise convergence operations in LDP. It is often a misconception that session protection is designed to maintain the session between two LDP peers but this is not the case. Session protection allows LDP peers to maintain their neighbours labels in the LIB (Label Information Base) to prevent the same data from being added and removed from the table in a flapping event.

     

    If a peer goes down, the router will save the labels for that neighbour in the LIB and then start the session protection flush timer. Should the peer return within the time limit, the labels are then installed locally down to the FIB (Forwarding Information Base). If the peer does not return then the labels are flushed from the LIB.

     

    As with most LDP features. This is enabled using a single command and can have an access-list applied to allow for a per-neighbour enabling of the feature.

     

    For IOS and IOS-XE:

     

    Session Protection IOS-XE.PNG

     

    For IOS-XR:

     

    Session Protection IOS-XR.png

     

    Once enabled you can verify the session protection status using show mpls ldp neighbor detail command.

     

    session-protection-verify.png

     

    Once enabled, a failure of the peering will invoke session protection with the appropriate logging. This can be seen below after the LDP session between XR1 and XR2 stops.

     

    session-protection-log.PNG

    (Click the image for a larger view)

     

    The peer's session protection timer then starts to countdown with the labels still retained in the LIB.

     

    session-protection-status.png

    Even though the connection has gone down, the LIB still contains the label space received from XR2.

     

    LIB.png

     

    Summary

     

    In summary, we looked at how LDP works and the transport mechanisms it uses. We then looked at the various features that LDP has to help enhance the protection and convergence optimisations that can be used in high security and high availability environments. This document also reviewed the various syntaxes related to IOS, IOS-XE and IOS-XR and how they can differ in enabling each different feature.

     

    For IOS and IOS-XE syntaxes please review the following Cisco Documentation for more information - http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mpls/command/mp-cr-book/mp-m2.html

     

    Respectively the following is an IOS-XR counterpart - http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-2/mpls/command/reference/b-mpls-cr52xasr9k/b_mpls_cr52xasr9k_chapter_00.html

     

    Hope This Helps,

    Josh Kingsbury