MPLS Fundamentals Review (Chapter IV)

MPLS Fundamentals Chapter 4

Label Distribution Protocol.

LDP Overview

To get packets across a label switched path (LSP) through the MPLS network, all LSRs must run a label distribution protocol and exchange label bindings. When all the LSRs have the labels for a particular Forwarding Equivalence Class (FEC), the packets can be forwarded on the LSP by means of label switching the packets at each LSR. Te LFIB which is the table tat forwards labeled packets, is fed by the label bindings found in the LIB. The LIB is fed by the label bindings received by LDP, RSVP, MP-BGP, or statically assigned label bindings. Because RSVP distributes the labels only for MPLS traffic engineering and MP-BGP distributes the labels only for BGP routes, you are left with LDP for distributing all the labels for interior routes. Therefore , all directly connected LSRs must establish an LDP session between them. The LDP peers exchange the label mapping messages across this LDP session.

LDP major functions:

• The discovery of LSRs that are running LDP
• Session establishment and maintenance
• Advertising of label mappings
• Housekeeping by means of notification.

• Two LSR running LDP discover each other by means of hello messages. 
• The second step is for them to establish a session across a TCP connection.
• Across this TCP connection, LDP advertises the label mapping messages between the two LDP peers.
• These label mapping messages are used to advertise, change, or retract label bindings.
• LDP notify the LDP neighbor of some advisory and error messages by sending notification messages.

LDP Operation

• LSRs running LDP send LDP hello messages on all links that are LDP enabled.
• These are all the interfaces configured with the mpls ip command.
• LDP hello messages are UDP messages that are sent on the links to the "all routers on this subnet" multicast IP address 224.0.0.2
• The UDP port used for LDP is 646.
• The hello message contains a Hold Time. If no Hello message is received from that LSR before the Hold time expires, the LSR removes that LSR from the list of discovered LDP neighbors.
• To discover whether the LSR sends and receives LDP hellos, the  hello interval, and the Hold time, use the show mpls ldp discovery [detail] command.
• If LDP hello messages are sent and received on an interface, there is an LDP adjacency across the link between two LSRs that are running LDP.
• the show mpls interfaces command allows you to quickly see which interfaces are running LDP.
• To change the interval between sending hello messages or to change the LDP Hold time, you can use the command mpls ldp discovery {hello {holdtime | interval } seconds.
• The default value for the holdtime is 15 seconds, for the hello is 5 seconds.
• If two LDP peers have different LDP Hold times configured the smaller of the two values is used as the Hold time for that LDP discovery source.
• If the Hold time expires for one link, that link is removed from the LDP discovery sources list. If the last link from the LDP discovery sources is removed for one LDP neighbor, the LDP session is torn down.

LSRs that are running LDP have an LDP Identifier, or LDP ID. This LDP ID is a 6-byte field that consists of 4 bytes identifying the LSR uniquely and 2 bytes identifying the label space that the LSR is using. If the last two bytes are 0, the label space is the platform-wide or per-platform label space. If they are non-zero, a per-interface label space is used. If that is the case, multiple LDP IDs are used, where the first 4 bytes are the same value, but the last two bytes indicate a different label space.

The first 4 bytes of the LDP ID are an IP address taken from an operational interface on the router. If loopback interfaces exist, the highest IP address of the loopback interfaces is taken for the LDP ID or LDP router ID. If no loopback interfaces exist, the highest IP address of an interface is taken. You can change the LDP router ID manually by using the command mpls ldp router-id interface [force]. If you use the force keyword, the LDP router ID is changed immediately. Without this keyword, the LDP router ID is changed only the next time it is necessary to select the router ID. This happens when the interface that determines the current LDP router ID is shut down.

In Cisco IOS, the MPLS LDP router ID needs to be present in the routing table of the LDP neighboring routers. If it is not, the LDP session is not formed. Therefore, the IP address that is the LDP router ID on the router must be included in the routing protocol of the LSR.



LDP Session Establishment and Maintenance

If two LSRs have discovered each other by means of the LDP hellos. One LSR tries to open a TCP connection to TCP port 646 0 to the other LSR. If the TCP connection is set up, both LSRs negotiate LDP session parameters by exchanging LDP initialization messages. This parameters include such things as:

• Timer Values
• Label distribution method
• Virtual Path identifier (VPI)/virtual channel identifer (VCI) ranges for Label Controlled ATM (LC-ATM).
• Data-link connection identifier (DLCI) ranges for LC-Frame Relay.

If the LDP peers agree on the session parameters, they keep the TCP connection between them. If not, they retry to create the LDP session between them, but at a throttled rate.

the command mpls ldp backoff initial-backoff maximum-backoff control this throttling rate.

This command slows down the LDP session setup attempts of two LDP LSRs, when the two neighboring LDP peers are incompatible in terms of the parameters they exchange. If the session setup attempt fails, the next attempts are undertaken at an exponentially increased time, until the maximum backoff time is reached.

The initial-backoff parameter is a value between 5 and 2,147,483, with a default of 15 seconds. The maximum-backoff is a value between 5 and 2,147,483, with a default of 120 seconds.

After the LDP session has been set up, it is maintained by either the receipt of LDP packets or a periodic keepalive message. Each time the LDP peer receives an LDP packet or keepalive message, the keepalive timer is reset for that peer.

The command to change the LDP session keepalive timer is mpls ldp holdtime seconds.

The LDP session is a TCP connection that is established between two IP addresses of the LSRs. Usually these IP addresses are used to created the LDP router Identifier on each router. To change the IP addres, configure the command mpls ldp discovery transport-address {interface | ip-address} on the interface of the router and specify an interface or IP address to be used to create the LDP session.

Number of LDP Sessions

When the per-platform label space is the only label space used between a pair of LSRs, one LDP session suffices. This is so because only one set of label bindings is exchanged between the two LSRs, no matter how many links are between them.

With per-interface label space, each label binding have relevance only to that interface. Therefore, for each interface that has a per-interface label space, one LDP session must exist between the pair of routers.

For all frame-mode links, only one LDP session should exchange the labels in per-platform label space. For each LC-ATM link, an LDP session should exchange the labels in the per-interface label space.

Advertising of Label Mappings

There are three different modes in which the LSRs can behave: advertisement, label retention, and LSP control mode. Each of the three modes has two possibilities, which lead to the following six modes:

• Unsolicited Downstream (UD) Versus Downstream-On-Demand (DoD) advertisement mode.
• Liberal Label retention (LLR) versus Conservative Label Retention (CLR) mode
• Independent LSP control versus Ordered LSP control mode.

In UD advertisement mode, the LDP peer distributes the label bindings unsolicited to its LDP peers. The label bindings are a set of (LDP Identifier, label) per prefix. An LDP router receives multiple label bindings for each prefix namely, one per LDP peer. All these label bindings are stored in the LIB of the router. However , only one LDP peer is the downstream LSR for that particular prefix.

The downstream LSR is found by looking up the next hop for that prefix in the routing table. Only the remote binding associated with that next-hop LSR should be used to populate the LFIB. This means that only one label from all the advertised label bindings from all the LDP neighbors of this LSR should be used as outgoing label in the LFIB for that prefix.

The problem is that the label bindings are advertised as (LDP Identifier, label) without the IP addresses of the interfaces. This means that to find the outgoing label for a particular prefix, you must map to the LDP Identifier the IP address of the interface , pointing back to this LSR on the downstream LSR. You can only do this if each LDP peer advertises all its IP addresses.

These IP addresses are advertised by the LDP peer with Address Messages and withdrawn with Withdraw address messages. You can fin these addresses when you are looking at the LDP peer. They are called the bound addresses for the LDP peer.

Each LSR assigns one local label to each IGP prefix in the routing table. This is the local label binding. These local bindings are stored in the LIB on the router. Each of these labels and the prefixes they are assigned to are advertised via LDP to all the LDP peers. These label bindings are the remote bindings on the LDP peers and are stored in the LIB.

The concept of split horizon does not exist; an LDP peer assigns its own local label to a prefix and advertises that back to the other LDP peer, even though that other LDP peer owns the prefix (it is a connected prefix) or that other LDP peer is the downstream LSR.

Label Withdrawing

When an LDP peer advertises a label binding, the receiving LDP peers keep it until the LDP session goes down or until the label is withdrawn. The label might be withdrawn if the local label changes. The local label might change if, for example, the interface with a certain prefix on it goes down, but another LSR still advertises the prefix. Therefore, the local label for that prefix changes from implicit NULL to a non-reserved label.  If this happens, the implicit NULL label is immediately withdrawn by sending a Label Withdraw message to the LDP peers. The new label is advertised in  a Label Mapping message.

In older Cisco IOS software (pre 12.0(21)ST), the default behavior was not to send a Label Withdraw message to withdraw the label before advertising the new label for the FEC. The new label advertisement was also an implicit label withdraw.

The command mpls ldp neighbor neighbor implicit-withdraw is used to keep the old behavior.

House Keeping by Means of Notification

Notification messages are needed for the housekeeping of LDP sessions.

The following events can be signaled by sending notification messages:

• Malformed protocol data unit (PDU) or message
• Unknown or malformed type-length-value (TLV).
• Session keepalive timer expiration.
• Unilateral session shutdown
• Initialization message events
• Events resulting from other messages
• Internals errors
• Loop detection
• Miscellaneous events.

Targeted LDP Session.

Normally, LDP sessions are set up between directly connected LSRs. However, in som cases a remote or targeted LDP session is needed. This is an LDP session between LSRs that are not directly connected.

Examples in which the targeted LDP session is needed are AToM networks and TE tunnels in an MPLS VPN network. In the case of AToM, an LDP session must exist between each pair of PE routers. In the case of TE tunnels in an MPLS VPN network, with the TE tunnels ending on a P router, the head-end and the tail-end LSR of the TE tunnel need a targeted LDP session between them to get the MPLS VPN traffic correctly label-switched through the MPLS VPN network.

For LDP neighbors that are not directly connected, the LDP neighborship needs to be configured manually on both routers with the mpls ldp neighbor targeted command.

To change the LDP hello interval and the Hold time for targeted LDP sessions, you can use the following command:

mpls ldp discovery {hello {holdtime | interval } seconds | targeted-hello {holdtime | interval} seconds | accept [from acl]}

Another way of achieving the same result (targeted session) is to configure the targeted LDP neighbor on one router only and to configure the other router to accept targeted LDP sessions from specific LDP routers.

The command to configure this is the mpls ldp discovery targeted-hello accept [from acl]. To prevent just any router from setting up an LDP session with this router, you can use the command with an access list so that you can specify which routers are allowed to set up a targeted LDP session.


LDP authentication 

LDP session are TCP sessions. To protect this sessions you can use Message Digest 5 (MD5) authentication. MD5 adds a signature, called the MD5 digest to the TCP segments. The MD5 digest is calculated for the particular TCP segment using the configured password on both ends of the connection. The configured MD5 password is never transmitted.

the command used to configured MD5 for LDP is mpls ldp neighbor [vrf vpn-name] ip-addr password [0-7] pswd-string

If one LSR has MD5 configured for LDP and the other not, the following message is logged:

%TCP-6-BADAUTH: No MD5 digest from 172.16.20.1(11092) to 172.16.20.2(646)

If both LDP peers have a password configured for MD5 but the password do not match, the following message is logged:

%TCP-6-BADAUTH: Invalid MD5 digest from 10.200.254.4(11093) to 10.200.254.3(646)


Controlling the Advertisement of Labels via LDP.

You can configure LDP to advertise or not to advertise certain labels to certain LDP peers. You can use the locally assigned labels that are advertised to the LDP peers as outgoing label on those LSRs. The command syntax is as follows:

mpls ldp advertise-labels [vrf vpn-name] [interface interface | for prefix-access-list [ to peer-access-list] ]

You cannot control the LDP advertisement of labels for LC-ATM networks with LDP deployed with the mpls ldp advertise-labels command.

that is because LC-ATM networks use DoD instead of UD label advertisement mode. DoD has its own command to limit LDP label advertisement. The command mpls ldp request-labels is used instead of mpls ldp advertise-labels for LC-ATM interfaces.

"Do not forget to configure no mpls ldp advertise-labels, too. If you forget this command and only configure the mpls ldp advertise labels for prefix-access-list to peer-access-list command the LSR still sends labels for all prefixes via LDP".

The cisco IOS LDP implementation allows you to specify more than one mpls ldp advertise-labels for prefix-access-list to peer-access-list command.

MPLS LDP Inbound Label Binding Filtering.

You can use the Inbound label binding filtering on the receiving LDP peer if you cannot apply the outbound filtering of label bindings. For instance, you can filter out all received label bindings from the LDP peers, except for the label bindings of the loopback interfaces of PE routers in an MPLS VPN network. Usually these loopbacks interfaces have the BGP next-hop IP addresses, and the LSRs can use the label associated with that prefix to forward the labeled customer VPN traffic.

The command mpls ldp neighbor [vrf vpn-name] nbr-address labels accept acl

LDP Autoconfiguration

Easier than configuring mpls ip on every interface separately is enabling LDP Autoconfiguration for the IGP. Every interface on which the IGP is running then has LDP enabled.

The OSPF router command to enable LDP autoconfiguration is:

mpls ldp autoconfig [are area-id]

You can disable it from specific interfaces if you want to. The interface command to disable LDP autonconfiguration on an interface is a follows:

no mpls ldp igp autoconfig

MPLS LDP-IGP Synchronization.

A problem with MPLS networks is that LDP and the IGP of the network are not synchronized. Synchronization means that the packet forwarding out of an interface happens only if both the IGP and LDP agree that htis is the outgoing link to be used. A common problem with MPLS networks that are running LDP is that when the LDP session is broken on a link , the IGP still has that link as outgoing; thus , packets are still forwarded out of that link. This happens because the IGP installs the best path in the routing table for any prefix. Therefore, traffic for prefixes with a next hop out of a link where LDP is broken becomes unlabeled.

This is a problem for more than just the IPv4-Over-MPLS case. WIth MPLS VPN, AToM, Virtual Private LAN Switching (VPLS), or IPv6 over MPLS, the packets must not become unlabeled in the MPLS network.

One LDP session being down while the IGP adjacency is up between two LSRs can result in major problems because much traffic can be lost.

The same problem can occur when LSRs restart. The IGP can be quicker in establishing the adjacencies than LDP can establish its sessions. This means that the IGP forwarding is already happening before the LFIB has the necessary information to start the correct label forwarding. The packets are incorrectly forwarded (unlabeled) or dropped until the LDP session is established.

The solution is MPLS LDP-IGP Synchronization. This features ensures that the link is not used to forward (unlabeled) traffic when the LDP session across the link is down. Rather the traffic is forwarded out another link where the LDP session is still established.


How MPLS LDP-IGP Synchronization Works

When the MPLS LDP-IGP synchronization is active for an interface, the IGP announces that link with maximum metric until the synchronization is achieved , or until the LDP session is running across that interface.

The Maximum link metric for OSPF is 65536 (hex 0xFFFF). No path through the interface where LDP  is down is used unless it is the only path. After the LDP session is established and label bindings have been exchanged, the igp advertises this link with is normal igp metric.

Basically, OSPG does not form an adjacency across a link if the LDP session is not established first across that link. OSPF does not send out hellos on the link.

Until the LDP session is established or until the sync holddown timer has expired, the OSPF adjacency is not established. Synchronized her means that the local label bindings have been sent over the LDP session to the LDP peer. However, when the syn is turned on at router A and that router has only one link to router B and no other IP connectivity to router B via another path ( tis means via other routers), the OSPF adjacency never comes up. OSPF waits for the LDP session to come up, but the LDP session cannot come up because router A cannot have the router for the LDP router ID of router B in its routing table. The OSPF and LDP adjacency can stay down forever in this situation. If router A has only router B as a neighbor, the LDP router ID of router B is not reachable; this means that no route exist for it in the routing table of router A.

In that case, the LDP-IGP sync detects that the peer is not reachable and lest OSPF bring up the adjacency anyway.

In some cases, the problem with the LDP session might be a persistent one; therefore, it might not be desirable to keep waiting for the IGP adjacency to be established.  The solution for this is to configure a Hold down timer for the sync. If the timer expires before the LDP session is established, the OSPF adjacency is built anyway.

MPLS LDP-IGP Sync configuration.

MPLS LDP-IGP sync is enabled for the IGP process.

The command to enable it for the IGP is mpls ldp sync and it is configured under the router process.

You can disable MPLS LDP-IGP Sync on one particular interface with the command no mpls ldp igp sync.

If Sync is not achieved , the IGP waits indefinitely to bring up the adjacency. You can change this with the global command mpls ldp igp sync holddown msecs. Which instructs the IGP to wait only for the configured time.

When OSPF is waiting for LDP to synchronize, it says "Interface is down and pending LDP."

When the OSPF adjacency is up but the LDP session is not, OSPF says "interface is up and sending maximum metric."

MPLS LDP Session Protection.

A common problem in networks is flapping links. Because the IGP adjacency and the LDP session are running across the link, they go down when the link goes down. The impact is pretty severe though, because the routing protocol and LDP can take time to rebuild the neighborship. LDP has to rebuild the LDP session and must exchange the label bindings again. To avoid having to rebuild the LDP session altogether, you can protect it.

When the LDP session between two directly connected LSRs is protected, a targeted LDP session is built between the two LSRs. When the directly connected link does go down between the two LSRs, the targeted LDP session is kept up as long as an alternative path exists between the two LSRs. The LDP link adjacency is removed whrn the link goes down, but the targeted adjacency keeps the LSP session up.

The global command to enable LDP Session Protection is this:

mpls ldp session protection [vrf vpn-name] [for acl] [duration seconds]

The access list (acl) you can configure lets you specify the LDP peers that should be protected. It should hold the LDP router identifier of the LDP neighbors that need protection. The duration is the time that the protection (the targeted LDP session) should remain in place after the LDP link adjacency has gone down. The default value is infinite.

For the protection to work, you need to enable it on both the LSRs. If this is not possible, you can enable it on one lSR, and the other LSR can accept the targeted LDP hellos by configuring the command mpls ldp discovery targeted-hello accept.

Other Features

A useful feature is LDP Graceful Restart. It specifies a mechanism for LDP peers to preserve the MPLS forwarding state when the LDP session goes down.