Multiprotocol Label Switching (MPLS) enables connection-oriented label switching on connectionless IP networks. It integrates both the flexibility of IP routing and the simplicity of Layer 2 switching.

MPLS has the following advantages:

· MPLS forwards packets according to short- and fixed-length labels, instead of Layer 3 header analysis and complicated routing table lookup, enabling highly-efficient and fast data forwarding on backbone networks.

· MPLS resides between the link layer and the network layer. It can work over various link layer protocols (for example, PPP, ATM, frame relay, and Ethernet), provide connection-oriented services for various network layer protocols (for example, IPv4, IPv6, and IPX), and work with mainstream network technologies.

· MPLS is connection-oriented and supports label stack. It can be used to implement various functions, such as VPN, traffic engineering (TE), and QoS.

For more information about VPN, see "Configuring MPLS L2VPN" and "Configuring MPLS L3VPN."

For more information about MPLS TE, see "Configuring MPLS TE."

Basic concepts

FEC

MPLS groups packets with the same characteristics (such as packets with the same destination or service class) into a class, called a "forwarding equivalence class (FEC)". Packets of the same FEC are handled in the same way on an MPLS network. The switch supports classifying FECs according to the network layer destination addresses.

Label

A label is a short, fixed length identifier for identifying a single FEC. A label is locally significant and must be locally unique.

Figure 1 Format of a label

As shown in Figure 1, a label is encapsulated between the Layer 2 header and Layer 3 header of a packet. A label is four bytes in length and consists of four fields:

· Label—20 bits in length. Label value for identifying a FEC.

· Exp—Three bits in length. Reserved field, usually used for CoS.

· S—One bit in length. MPLS supports multiple levels of labels. This field indicates whether a label is at the bottom of the label stack. 1 indicates that the label is at the bottom of the label stack.

· TTL—Eight bits in length. Like the homonymous IP header field, it is used to prevent loops.

LSR

A label switching router (LSR) is a fundamental component on an MPLS network. LSRs support label distribution and label swapping.

LER

A label edge router (LER) resides at the edge of an MPLS network and is connected with another network.

LSP

A label switched path (LSP) is the path along which packets of a FEC travel through an MPLS network.

An LSP is a unidirectional path from the ingress of an MPLS network to the egress. On an LSP, two neighboring LSRs are called the "upstream LSR" and "downstream LSR." In Figure 2, LSR B is the downstream LSR of LSR A; LSR A is the upstream LSR of LSR B.

Figure 2 Diagram for an LSP

LFIB

Labeled packets are forwarded according to the Label Forwarding Information Base (LFIB).

Control plane and forwarding plane

An MPLS node consists of two planes, control plane and forwarding plane.

· Control plane—Assigns labels, selects routes, creates the LFIB, and establishes and removes LSPs.

· Forwarding plane—Forwards packets according to the LFIB.

MPLS network structure

Figure 3 Diagram for the MPLS network structure

As shown in Figure 3, LSRs in the same routing or administrative domain form an MPLS domain.

An MPLS domain consists of the following LSR types:

· Ingress LSRs receive and label packets coming into the MPLS domain.

· Transit LSRs forward packets along LSPs to their egress LERs according to the labels.

· Egress LSRs remove labels from packets and forward the packets to their destination networks.

LSP establishment and label distribution

LSP establishment

Establishing LSPs is to bind FECs with labels on each LSR involved and notify its adjacent LSRs of the bindings, so as to establish the LFIB on each LSR. LSPs can be manually established through configuration, or dynamically established through label distribution protocols.

· Establishing a static LSP through manual configuration

To establish a static LSP, you must assign a label to the FEC on each LSR along the packet forwarding path. Establishment of static LSPs consumes fewer resources than dynamic LSP establishment. However, static LSPs cannot adapt to network topology changes. Therefore, static LSPs are suitable for small-scale networks with simple, stable topologies.

· Establishing an LSP through a label distribution protocol

Label distribution protocols are MPLS signaling protocols. They can classify FECs, distribute labels, and establish and maintain LSPs. Label distribution protocols include protocols designed specifically for label distribution, such as the Label Distribution Protocol (LDP), and protocols extended to support label distribution, such as BGP and RSVP-TE.

This chapter discusses LDP only. For more information about LDP, see "LDP."

NOTE:

In this chapter, the term label distribution protocols represents all protocols for label distribution, and the term LDP refers to the Label Distribution Protocol defined in RFC 5036.

As shown in Figure 4, a dynamic LSP is established in the following procedure:

A downstream LSR classifies FECs according to destination addresses. It assigns a label to a FEC, and distributes the FEC-label binding to its upstream LSR, which then establishes an LFIB entry for the FEC according to the binding information. After all LSRs along the packet forwarding path establish a LFIB entry for the FEC, an LSP is established for packets of this FEC.

Figure 4 Process of dynamic LSP establishment

Label distribution and management

An LSR informs its upstream LSRs of labels assigned to FECs through label advertisement. The label advertisement modes include downstream unsolicited (DU) and downstream on demand (DoD). The label distribution control modes include independent and ordered.

Label management specifies the mode for processing a received label binding that is not useful at the moment. The processing mode, called "label retention mode," can be either liberal or conservative.

· Label advertisement modes

Figure 5 Label advertisement modes

Figure 5 shows the two label advertisement modes, DU and DoD.

¡ In DU mode, an LSR assigns a label to a FEC and then distributes the FEC-label binding to its upstream LSR unsolicitedly.

¡ In DoD mode, an LSR assigns a label to a FEC and distributes the FEC-label binding to its upstream LSR only when it receives a label request from the upstream LSR.

NOTE:

· The switch supports only the DU mode.

· An upstream LSR and its downstream LSR must use the same label advertisement mode; otherwise, no LSP can be established.

· Label distribution control modes

Label distribution control modes include independent and ordered.

¡ In independent mode, an LSR can distribute label bindings upstream at anytime. This means that an LSR might have distributed a label binding for a FEC to its upstream LSR before it receives a binding for that FEC from its downstream LSR. As shown in Figure 6, in independent label distribution control mode, if the label advertisement mode is DU, an LSR will assign labels to its upstream even if it has not obtained labels from its downstream; if the label advertisement mode is DoD, the LSR distributes a label to its upstream as long as it receives a label request from the upstream.

Figure 6 Independent label distribution control mode

¡ In ordered mode, an LSR distributes its label binding for a FEC upstream only when it receives a label binding for the FEC from its downstream or it is the egress of the FEC. In Figure 5, label distribution control is in ordered mode. In this case, if the label advertisement mode is DU, an LSR will distribute a label upstream only when it receives a label binding for the FEC from its downstream; if the label advertisement mode is DoD, after an LSR (Transit in this example) receives a label request from its upstream (Ingress), the LSR (Transit) sends a label request to its downstream (Egress). Then, after the LSR (Transit) receives the label binding from its downstream (Egress), it distributes a label binding to the upstream (Ingress).

· Label retention modes

Label retention modes include liberal and conservative.

¡ In liberal mode, an LSR keeps any received label binding regardless of whether the binding is from the next hop for the FEC or not. This allows for quicker adaptation to route changes but will waste label resources because LSRs keep extra labels.

¡ In conservative mode, an LSR keeps only label bindings that are from the next hops for the FECs. This allows LSRs to maintain fewer labels but makes LSRs slower in adapting to route changes.

NOTE:

The switch supports only the liberal mode.

MPLS forwarding

LFIB

An LFIB comprises the following table entries:

· Next Hop Label Forwarding Entry (NHLFE)—Describes the label operation to be performed. It is used to forward MPLS packets.

· FEC to NHLFE (FTN) map—FTN maps each FEC to a set of NHLFEs at the ingress LSR. The FTN map is used for forwarding unlabeled packets that need MPLS forwarding. When an LSR receives an unlabeled packet, it looks for the corresponding FIB entry. If the Token value of the FIB entry is not Invalid, the packet needs to be forwarded through MPLS. The LSR then looks for the corresponding NHLFE entry according to the Token value to determine the label operation to be performed.

· Incoming Label Map (ILM)—ILM maps each incoming label to a set of NHLFEs. It is used to forward labeled packets. When an LSR receives a labeled packet, it looks for the corresponding ILM entry. If the Token value of the ILM entry is not null, the LSR looks for the corresponding NHLFE entry to determine the label operation to be performed.

NOTE:

FTN and ILM are associated with NHLFE through Token.

MPLS data forwarding

Figure 7 MPLS forwarding process diagram

As shown in Figure 7, in an MPLS domain, a packet is forwarded in the following procedure:

1. Router B (the ingress LSR) receives a packet carrying no label. It determines the FEC of the packet according to the destination address, and searches the FIB table for the Token value. Because the Token value is not Invalid, Router B looks for the corresponding NHLFE entry that contains the Token value. According to the NHLFE entry, Router B pushes label 40 to the packet, and forwards the labeled packet to the next hop LSR (Router C) through the outgoing interface (GE3/0/2).

2. Upon receiving the labeled packet, Router C looks for the ILM entry that contains the label 40 to get the Token value. Because the Token value is not empty, Router C looks for the corresponding NHLFE entry containing the Token value. According to the NHLFE entry, Router C swaps the original label with label 50, and then forwards the labeled packet to the next hop LSR (Router D) through the outgoing interface (GE3/0/2).

3. Upon receiving the labeled packet, Router D (the egress) looks for the ILM entry according to the label (50) to get the Token value. Because the Token is empty, Router D removes the label from the packet. If the ILM entry records the outgoing interface, Router D forwards the packet through the outgoing interface; if no outgoing interface is recorded, router D forwards the packet according to the IP header of the packet.

PHP

In an MPLS network, when an egress node receives a labeled packet, it looks up the LFIB, pops the label of the packet, and then performs the next level label forwarding or performs IP forwarding. The egress node needs to do two forwarding table lookups to forward a packet: looks up the LFIB twice, or looks up the LFIB once and the FIB once.

The penultimate hop popping (PHP) feature can pop the label at the penultimate node to relieve the egress of the label operation burden.

PHP is configured on the egress node. The label assigned by a PHP-capable egress node to the penultimate hop can be one of the following:

· IPv4 explicit null label 0: The egress assigns an IPv4 explicit null label to a FEC and advertises the FEC-label binding to the upstream LSR. When forwarding an MPLS packet, the upstream LSR replaces the label at the stack top with the explicit null label and then sends the packet to the egress. When the egress receives the packet, which carries a label of 0, it does not look up for the LFIB entry but pops the label stack directly and performs IPv4 forwarding.

· Implicit null label 3: This label never appears in the label stack. The upstream LSR directly performs a pop operation to the labeled packets that match the implicit null label rather than substitutes the implicit null label for the original label at the stack top, and forwards the packet to the downstream egress LSR. The egress directly performs the next level forwarding upon receiving the packet.

LDP

LDP is used to establish LSPs dynamically. Using LDP, LSRs can map network layer routing information to data link layer switching paths.

Basic LDP concepts

· LDP session—LDP sessions are established between LSRs based on TCP connections and used to exchange messages for label binding, label releasing, and error notification.

· LDP peer—Two LSRs using LDP to exchange FEC-label bindings are LDP peers.

LDP message type

LDP messages include the following types:

· Discovery messages—Declare and maintain the presence of LSRs.

· Session messages—Establish, maintain, and terminate sessions between LDP peers.

· Advertisement messages—Create, alter, and remove FEC-label bindings.

· Notification messages—Provide advisory information and notify errors.

LDP session, advertisement, and notification messages use TCP for reliability. Discovery messages use UDP for efficiency.

LDP operation

LDP goes through four phases in operation:

1. Discovery

Each LSR sends hello messages periodically to notify neighboring LSRs of its presence. In this way, LSRs can automatically discover their LDP peers. LDP provides two discovery mechanisms:

¡ Basic discovery mechanism—Discovers directly connected LSRs. An LSR periodically sends LDP link Hello messages to multicast address 224.0.0.2 that identifies all routers on the subnet to advertise its presence.

¡ Extended discovery mechanism—Discovers indirectly connected LDP peers. An LSR periodically sends LDP Hello messages to a given IP address so that the LSR with the IP address can discover the LDP peer.

2. Session establishment and maintenance

After an LSR finds a LDP peer, they start to establish a session through the following two steps:

¡ Establish a TCP connection between them.

¡ Initialize negotiation of session parameters such as the LDP version, label advertisement mode, and Keepalive interval.

After establishing a session between them, the two LDP peers send Hello messages and Keepalive messages to maintain the session.

3. LSP establishment and maintenance

LDP sends label requests and label binding messages between LDP peers to establish LSPs.

For the LSP establishment process, see "LSP establishment and label distribution."

4. Session termination

An LSR terminates its LDP session with an LDP peer in the following cases:

¡ All Hello adjacencies are deleted between the two peers

LDP peers periodically send Hello messages to indicate that they intend to keep the Hello adjacency. If an LSR does not receive any Hello message from a peer before the Hello timer expires, it deletes the Hello adjacency with this peer. An LDP session has one or more Hello adjacencies. When the last Hello adjacency for the session is deleted, the LSR will send a Notification message to terminate the LDP session.

¡ Loss of session connectivity

An LSR determines the integrity of an LDP session according to the LDP PDU (which carries one or more LDP messages) transmitted on the session. Before the Keepalive timer times out, if two LDP peers have no information to exchange, they can send Keepalive messages to each other to maintain the LDP session. If an LSR does not receive any LDP PDU from its peer during a Keepalive interval, it closes the TCP connection and terminates the LDP session.

¡ Receiving a shutdown message from the peer

An LSR can also send a Shutdown message to its LDP peer to terminate the LDP session. Therefore, when receiving the Shutdown message from an LDP peer, an LSR terminates the session with the LDP peer.

Protocols

· RFC 3031, Multiprotocol Label Switching Architecture

· RFC 3032, MPLS Label Stack Encoding

· RFC 5036, LDP Specification

MPLS configuration task list

Task		Remarks
Enabling the MPLS function		Required.
Configuring a static LSP		Required.	Use either the static or dynamic LSP configuration method.
Establishing dynamic LSPs through LDP	Configuring MPLS LDP capability	Required.
	Configuring local LDP session parameters	Optional.
	Configuring remote LDP session parameters	Optional.
	Configuring PHP	Optional.
	Configuring the policy for triggering LSP establishment	Optional.
	Configuring the label distribution control mode	Optional.
	Configuring LDP loop detection	Optional.
	Configuring LDP MD5 authentication	Optional.
	Configuring LDP label filtering	Optional.
Maintaining LDP sessions	Configuring BFD for MPLS LDP	Optional.
Maintaining LDP sessions	Resetting LDP sessions	Optional.
Managing and optimizing MPLS forwarding	Configuring MPLS MTU	Optional.
	Configuring TTL processing mode at ingress	Optional.
	Sending back ICMP TTL exceeded messages for MPLS TTL expired packets	Optional.
	Configuring LDP GR	Optional.
Setting MPLS statistics reading interval		Optional.
Inspecting LSPs	Configuring MPLS LSP ping	Optional.
	Configuring MPLS LSP tracert	Optional.
	Configuring BFD for LSPs	Optional.
	Configuring periodic LSP tracert	Optional.
Enabling MPLS trap		Optional.

NOTE:

Layer 3 interfaces such as Layer 3 Ethernet interfaces and VLAN interfaces support MPLS. Tunnel interfaces and Layer 2 interfaces do not support MPLS.

Enabling the MPLS function

You must enable MPLS on all routers before you can configure other MPLS features.

Before you enable MPLS, complete the following tasks:

· Configure link layer protocols to ensure the connectivity at the link layer.

· Assign IP addresses to interfaces so that all neighboring nodes can reach each other at the network layer.

· Configure static routes or an IGP protocol for the LSRs to communicate with each other.

To enable MPLS:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure the MPLS LSR ID.	mpls lsr-id lsr-id	Not configured by default.
3. Enable MPLS globally and enter MPLS view.	mpls	Not enabled by default.
4. Return to system view.	quit	N/A
5. Enter interface view.	interface interface-type interface-number	N/A
6. Enable MPLS for the interface.	mpls	Not enabled by default.

NOTE:

An MPLS LSR ID is in the format of an IP address and must be unique within an MPLS domain. H3C recommends that you use the IP address of a loopback interface on an LSR as the MPLS LSR ID.

Configuring a static LSP

The principle of establishing a static LSP is that the outgoing label of an upstream LSR is the incoming label of its downstream LSR.

Before you configure a static LSP, complete the following tasks:

· Determine the ingress LSR, transit LSRs, and egress LSR for the static LSP.

· Enable MPLS on all these LSRs.

· Make sure that the ingress LSR has a route to the FEC destination. This is not required on the transit LSRs and egress LSR.

For information about configuring a static IP route, see Layer 3—IP Routing Configuration Guide.

To configure a static LSP:

Step	Command
1. Enter system view.	system-view
2. Configure a static LSP taking the current LSR as the ingress.	static-lsp ingress lsp-name destination dest-addr { mask \| mask-length } { nexthop next-hop-addr \| outgoing-interface interface-type interface-number } out-label out-label
3. Configure a static LSP taking the current LSR as a transit LSR.	static-lsp transit lsp-name incoming-interface interface-type interface-number in-label in-label { nexthop next-hop-addr \| outgoing-interface interface-type interface-number } out-label out-label
4. Configure a static LSP taking the current LSR as the egress.	static-lsp egress lsp-name incoming-interface interface-type interface-number in-label in-label

NOTE:

· When you configure a static LSP on the ingress LSR, the next hop or outgoing interface specified must be consistent with the next hop or outgoing interface of the optimal route in the routing table. If you configure a static IP route for the LSP, be sure to specify the same next hop or outgoing interface for the static route and the static LSP.

· For an ingress or transit LSR, do not specify the public address of an interface on the LSR as the next hop address.

Establishing dynamic LSPs through LDP

Configuring MPLS LDP capability

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable LDP capability globally and enter MPLS LDP view.	mpls ldp	Not enabled by default.
3. Configure the LDP LSR ID.	lsr-id lsr-id	Optional. MPLS LSR ID of the LSR by default.
4. Return to system view.	quit	N/A
5. Enter interface view.	interface interface-type interface-number	N/A
6. Enable LDP capability for the interface.	mpls ldp	Not enabled by default.

NOTE:

· Disabling LDP on an interface terminates all LDP sessions on the interface. As a result, all LSPs using the sessions will be deleted.

· Usually, configuring the LDP LSR ID is not required, as it defaults to the MPLS LSR ID. In some applications that use VPN instances (for example, MPLS L3VPN), however, you must make sure that different LDP instances have different LDP LSR IDs if the address spaces overlap. Otherwise, the TCP connections cannot be established correctly.

Configuring local LDP session parameters

LDP sessions established between local LDP peers are local LDP sessions. To establish a local LDP session:

· Determine the LDP transport addresses of the two peers and make sure that the LDP transport addresses are reachable to each other. This is to establish the TCP connection.

· If many LDP sessions exist between the two LSRs or the CPU is occupied much, adjust timers to ensure the stability of the LDP sessions.

IMPORTANT:

If you configure an LDP transport address by specifying an IP address, the specified IP address must be the IP address of an interface on the switch. Otherwise, the LDP sessions cannot be established.

To configure local LDP session parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Set the link Hello timer.	mpls ldp timer hello-hold value	Optional. 15 seconds by default.
4. Set the link Keepalive timer.	mpls ldp timer keepalive-hold value	Optional. 45 seconds by default.
5. Configure the LDP transport address.	mpls ldp transport-address { ip-address \| interface }	Optional. MPLS LSR ID of the LSR by default.

Configuring remote LDP session parameters

LDP sessions established between remote LDP peers are remote LDP sessions. Remote LDP sessions are mainly used in Martini MPLS L2VPN, Martini VPLS, and MPLS LDP over MPLS TE. For more information about remote session applications, see "Configuring MPLS L2VPN," "Configuring VPLS," and "Configuring MPLS TE."

Configuration restrictions and guidelines

· The IP address specified as the LDP transport address must be the IP address of an interface on the switch.

· The remote peer IP address to be configured must be different from all existing remote peer IP addresses.

· If a local adjacency exists between two peers, no remote adjacency can be established between them. If a remote adjacency exists between two peers, you can configure a local adjacency for them. However, the local adjacency can be established only when the transport address and keepalive settings for the local peer match those for the remote peer, in which case the remote adjacency will be removed. Only one remote session or local session can exist between two LSRs, and the local session takes precedence over the remote session.

Configuration procedure

To establish a remote LDP session:

· Determine the LDP transport addresses of the two peers and make sure that the LDP transport addresses are reachable to each other. This is to establish the TCP connection.

· If many LDP sessions exist between the two LSRs or the CPU is occupied much, adjust timers to ensure the stability of the LDP sessions.

To configure remote LDP session parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a remote peer entity and enter MPLS LDP remote peer view.	mpls ldp remote-peer remote-peer-name	N/A
3. Configure the remote peer IP address.	remote-ip ip-address	N/A
4. Configure LDP to advertise prefix-based labels through a remote session.	prefix-label advertise	Optional. By default, LDP does not advertise prefix-based labels through a remote session.
5. Set the targeted Hello timer.	mpls ldp timer hello-hold value	Optional. 45 seconds by default.
6. Set the targeted Keepalive timer.	mpls ldp timer keepalive-hold value	Optional. 45 seconds by default.
7. Configure the LDP transport address.	mpls ldp transport-address ip-address	Optional. MPLS LSR ID of the LSR by default.

By default, LDP does not advertise any prefix-based label mapping message through a remote session, and remote sessions are used only to transfer messages for L2VPNs. For more information about remote session applications, see the Martini MPLS L2VPN configuration in "Configuring MPLS L2VPN."

Configuring LDP to advertise prefix-based labels through a remote session is for implementing MPLS LDP over MPLS TE. For information about MPLS LDP over MPLS TE, see "Configuring MPLS TE."

Configuring PHP

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS view.	mpls	N/A
3. Specify the type of the label to be distributed by the egress to the penultimate hop.	label advertise { explicit-null \| implicit-null \| non-null }	Optional. By default, an egress distributes to the penultimate hop an implicit null label.

The switch supports PHP when it works as a penultimate hop. It can accept the explicit or implicit null label.

When working as the egress, the switch does not support distributing a normal label to the penultimate hop (that is, it does not support the non-null type). H3C recommends that you use a device that supports PHP as the penultimate hop.

For LDP sessions existing before the label advertise command is configured, you must reset the LDP sessions by using the reset mpls ldp command for the PHP configuration to take effect.

After sessions are established, if you use the label advertise command to change the type of label that the egress should distribute to the penultimate hop, you need to restart the switch for the configuration to take effect.

Configuring the policy for triggering LSP establishment

You can configure an LSP triggering policy on an LSR, so that only routes matching the policy can trigger establishment of LSPs, reducing the number of LSPs to be established on the LSR and avoiding instability of the LSR caused by excessive LSPs.

An LSR supports two types of LSP triggering policies:

· Allowing all routing entries to trigger establishment of LSPs.

· Filtering routing entries by an IP prefix list, so that static and IGP routes denied by the IP prefix list will not trigger LSP establishment. To use this policy, you must create the IP prefix list. For information about IP prefix list configuration, see Layer 3—IP Routing Configuration Guide.

To configure the policy for triggering LSP establishment:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS view.	mpls	N/A
3. Configure the LSP establishment triggering policy.	lsp-trigger [ vpn-instance vpn-instance-name ] { all \| ip-prefix prefix-name }	Optional. By default, only host routes with 32-bit masks can trigger establishment of LSPs. If the vpn-instance vpn-instance-name option is specified, the command configures an LSP establishment triggering policy for the specified VPN; otherwise, the command configures an LSP establishment triggering policy for the public network routes.

NOTE:

For an LSP to be established, an exactly matching routing entry must exist on the LSR. For example, on an LSR, to establish an LSP to a loopback address with a 32-bit mask, there must be an exactly matching host routing entry on the LSR.

Configuring the label distribution control mode

With the label re-advertisement function enabled, an LSR periodically looks for FECs not assigned with labels, assigns labels to them if any, and advertises the label-FEC bindings. You can set the label re-advertisement interval as needed.

To configure the LDP label distribution control mode:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS LDP view.	mpls ldp	N/A
3. Specify the label distribution control mode.	label-distribution { independent \| ordered }	Optional. Ordered by default. For LDP sessions existing before the command is configured, you must reset the LDP sessions for the specified label distribution control mode to take effect.
4. Enable label re-advertisement for DU mode.	du-readvertise	Optional. Enabled by default.
5. Set the interval for label re-advertisement in DU mode.	du-readvertise timer value	Optional. 30 seconds by default.

Configuring LDP loop detection

LSPs established in an MPLS domain might be looping. The LDP loop detection mechanism can detect looping LSPs and prevent LDP messages from looping forever.

LDP loop detection can be in either of two modes:

· Maximum hop count

A label request message or label mapping message carries information about its hop count, which increments by 1 for each hop. When this value reaches the specified limit, LDP considers that a loop is present and terminates the establishment of the LSP.

· Path vector

A label request message or label mapping message carries path information in the form of path vector list. When such a message reaches an LSR, the LSR checks the path vector list of the message for its MPLS LSR ID. If its MPLS LSR ID is not in the list, the LSR will add its LSR ID to the path vector list; if in the list, the LSR considers that a loop appears and terminates the establishment of the LSP.

In the path vector mode, you must also specify the maximum number of hops of an LSP. An LSR will also terminate the establishment of an LSP when the hop count of the path, or the length of the path vector, reaches the specified limit.

Configuration restrictions and guidelines

· The loop detection modes configured on two LDP peers must be the same. Otherwise, the LDP session cannot be established.

· To implement loop detection in an MPLS domain, you must enable loop detection on every LSR in the MPLS domain.

· Configure loop detection before enabling LDP capability on any interface.

Configuration procedure

To configure LDP loop detection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS LDP view.	mpls ldp	N/A
3. Enable loop detection.	loop-detect	Disabled by default.
4. Set the maximum hop count.	hops-count hop-number	Optional. 32 by default.
5. Set the maximum path vector length.	path-vectors pv-number	Optional. 32 by default.

NOTE:

· All loop detection configurations take effect for only the LSPs established after the configurations. Changing the loop detection configurations does not affect existing LSPs. You can execute the reset mpls ldp command in user view, so that the loop detection configurations also take effect for existing LSPs.

· LDP loop detection might result in LSP update, which will generate redundant information and consume many system resources. H3C recommends that you configure the routing protocol's loop detection mechanism.

Configuring LDP MD5 authentication

LDP sessions are established based on TCP connections. To improve the security of LDP sessions, you can configure MD5 authentication for the underlying TCP connections, so that the TCP connections can be established only if the peers have the same authentication password.

To configure LDP MD5 authentication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS LDP view.	mpls ldp	N/A
3. Enable LDP MD5 authentication and set the password.	md5-password { cipher \| plain } peer-lsr-id password	Disabled by default.

NOTE:

To establish an LDP session successfully between two LDP peers, make sure the LDP MD5 authentication configurations on the LDP peers are consistent.

Configuring LDP label filtering

The LDP label filtering feature provides two mechanisms, label acceptance control for controlling which labels will be accepted and label advertisement control for controlling which labels will be advertised. In complicated MPLS network environments, LDP label filtering can be used to control which LSPs are to be established dynamically and prevent devices from accepting and advertising excessive label bindings.

Label acceptance control

Label acceptance control is for filtering received label bindings. An upstream LSR filters the label bindings received from the specified downstream LSR and accepts only those permitted by the specified prefix list. As shown in Figure 8, upstream device LSR A filters the label bindings received from downstream device LSR B. Only if the destination address of an FEC matches the specified prefix list, does LSR A accept the label binding of the FEC from LSR B. LSR A does not filter label bindings received from downstream device LSR C.

Figure 8 Network diagram for label acceptance control

Label advertisement control

Label advertisement control is for filtering label bindings to be advertised. A downstream LSR advertises only the label bindings of the specified FECs to the specified upstream LSR. As shown in Figure 9, downstream device LSR A advertises to upstream device LSR B only label bindings with FEC destinations permitted by prefix list B, and advertises to upstream device LSR C only label bindings with FEC destinations permitted by prefix list C.

Figure 9 Network diagram for label advertisement control

Configuration prerequisites

Before you configure LDP label filtering policies, you must create an IP prefix list. For information about IP prefix list configuration, see Layer 3—IP Routing Configuration Guide.

Configuration procedure

To configure LDP label filtering policies:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS LDP view.	mpls ldp	N/A
3. Configure a label acceptance control policy.	accept-label peer peer-id ip-prefix ip-prefix-name	Optional. By default, no label acceptance policy is configured.
4. Configure a label advertisement control policy.	advertise-label ip-prefix ip-prefix-name [ peer peer-ip-prefix-name ]	By default, no label advertisement policy is configured.

NOTE:

For two neighboring LSRs, configuring a label acceptance control policy on the upstream LSR and configuring a label advertisement control policy on the downstream LSR can achieve the same effect. To reduce the network load, H3C recommends that you configure only label advertisement control policies.

Maintaining LDP sessions

This section describes how to detect communication failures between remote LDP peers and reset LDP sessions.

Configuring BFD for MPLS LDP

MPLS itself cannot detect a neighbor failure or link failure in time. If communication between two remote LDP peers fails, the LDP session will be down, and as a result, MPLS forwarding will fail. By cooperating with bidirectional forwarding detection (BFD), MPLS LDP can be quickly aware of communication failures between remote LDP peers, improving performances of existing MPLS networks.

For more information about BFD, see High Availability Configuration Guide.

For examples of configuring BFD for MPLS LDP, see "Configuring VPLS."

NOTE:

· An LSP can be bound to only one BFD session.

· The BFD for MPLS LDP feature can detect communication failures only between remote LDP peers.

To configure BFD for MPLS LDP:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS LDP remote peer view.	mpls ldp remote-peer remote-peer-name	N/A
3. Enable BFD for MPLS LDP.	remote-ip bfd	Disabled by default.

Resetting LDP sessions

If you change LDP session parameters when some LDP sessions are up, the LDP sessions will not be able to function correctly. In this case, reset LDP sessions so the LDP peers renegotiate parameters and establish new sessions.

To reset LDP sessions, perform the following command in user view:

Task	Command
Reset LDP sessions.	reset mpls ldp [ all \| [ vpn-instance vpn-instance-name ] [ fec mask \| peer peer-id ] ]

Managing and optimizing MPLS forwarding

Configuring MPLS MTU

An MPLS label stack is inserted between the link layer header and network layer header of a packet. During MPLS forwarding, a packet, after encapsulated with an MPLS label, might exceed the allowed length of the link layer and thus cannot be forwarded, although the network layer packet is smaller than the MTU of the interface.

To address the issue, you can configure the MPLS MTU on an interface of an LSR. Then, the LSR will compare the length of an MPLS packet against the configured MPLS MTU on the interface. When the packet is larger than the MPLS MTU:

· If fragmentation is allowed, the LSR removes the label stack from the packet, fragments the IP packet (the length of a fragment is the MPLS MTU minus the length of the label stack), adds the label stack back into each fragment, and then forwards the fragments.

· If fragmentation is not allowed, the LSR drops the packet directly.

To configure the MPLS MTU of an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the MPLS MTU of the interface.	mpls mtu value	By default, the MPLS MTU of an interface is not configured.

The following applies when an interface handles MPLS packets:

· MPLS packets carrying L2VPN or IPv6 packets are always successfully forwarded, even if they are larger than the MPLS MTU.

· If the MPLS MTU of an interface is greater than the MTU of the interface, data forwarding might fail on the interface.

· If you do not configure the MPLS MTU of an interface, fragmentation of packets will be based on the MTU of the interface, and the length of fragments does not take the MPLS labels into account. Thus, after an MPLS label is inserted into a fragment, the length of the MPLS fragment might be larger than the interface MTU.

Configuring TTL processing mode at ingress

At the ingress of an LSP, a label stack encapsulated with a TTL field is added to each packet. Whether the label TTL takes the IP TTL or not depends on whether IP TTL propagation is enabled:

· With IP TTL propagation enabled: When the ingress labels a packet, it copies the TTL value of the original IP packet to the TTL field of the label. When an LSR forwards the labeled packet, it decrements the TTL value of the label at the stack top by 1. When an LSR pops a label, it copies the TTL value of the label at the stack top back to the TTL field of the IP packet. In this case, the TTL value of a packet is decreased hop by hop when forwarded along the LSP. Therefore, the result of tracert will reflect the real path along which the packet has traveled.

Figure 10 Label TTL processing when IP TTL propagation is enabled

· With IP TTL propagation disabled: When the ingress labels a packet, it does not copy the TTL value of the original IP packet to the TTL field of the label, and the label TTL is set to 255. When an LSR forwards the labeled packet, it decrements the TTL value of the label at the stack top by 1. When an LSR pops a label, it compares the IP TTL and the label TTL and uses the smaller value as the TTL of the IP packet. In this case, the result of tracert does not show the hops within the MPLS backbone, as if the ingress and egress were connected directly.

Figure 11 Label TTL processing when IP TTL propagation is disabled

Configuration guidelines

· Within an MPLS domain, TTL is always copied between multiple levels of labels. The ttl propagate command affects only the propagation of the IP TTL to the TTL of an MPLS label. Therefore, this command takes effect only when it is configured on the ingress.

· To enable IP TTL propagation for a VPN, you must enable it on all provider edge (PE) devices in the VPN, so that you can get the same traceroute result (hop count) from those PEs. For more information about PE, see "Configuring MPLS L3VPN."

Configuration procedure

To configure IP TTL propagation of MPLS:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS view.	mpls	N/A
3. Enable MPLS IP TTL propagation.	ttl propagate { public \| vpn }	Optional. Enabled for only public network packets by default.

NOTE:

For locally generated packets, an LSR always copies the IP TTL value of the packet, regardless of whether IP TTL propagation is enabled or not. This makes sure that the local administrator can tracert for network diagnoses.

Sending back ICMP TTL exceeded messages for MPLS TTL expired packets

After you enable an LSR to send back ICMP TTL exceeded messages for MPLS TTL expired packets, when the LSR receives an MPLS packet that carries a label with TTL being 1, it will generate an ICMP TTL exceeded message, and send the message to the packet sender in one of the following ways:

· If the LSR has a route to the packet sender, it sends the ICMP TTL exceeded message to the packet sender directly through the IP route.

· If the LSR has no route to the packet sender, it forwards the ICMP TTL exceeded message along the LSP to the egress, which will send the message to the packet sender.

Usually, for an MPLS packet carrying only one level of label, the first method is used; for an MPLS packet carrying a multi-level label stack, the second method is used. However, because autonomous system boundary routers (ASBRs), superstratum PEs or service provider-end PEs (SPEs) in Hierarchy of VPN (HoVPN) applications, and carrier backbone PEs in nested VPNs might receive MPLS VPN packets that carry only one level of labels but these devices have no IP routes to the packet senders, the first method is not applicable. In this case, you can configure the undo ttl expiration pop command on these devices so that the devices use the second method.

For more information about HoVPN and nested VPN, see "Configuring MPLS L3VPN."

To configure the switch to send back an ICMP TTL exceeded message for a received MPLS TTL expired packet:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS view.	mpls	N/A
3. Enable the switch to send back an ICMP TTL exceeded message when it receives an MPLS TTL expired packet.	ttl expiration enable	Optional. Enabled by default.
4. Specify that ICMP TTL exceeded messages for MPLS packets with only one-level of label travel along the IP routes or along the LSPs.	· Sends back ICMP TTL exceeded messages through IP routing: ttl expiration pop · Sends back ICMP TTL exceeded messages along LSPs: undo ttl expiration pop	Optional. Configure one of them as required. By default, ICMP TTL exceeded messages for MPLS packets with only one-level of label travel along the local IP routes. This configuration does not take effect when the MPLS packets carry multiple levels of labels. ICMP TTL exceeded messages for such MPLS packets always travel along the LSPs.

Configuring LDP GR

Overview

MPLS has two separate planes: the forwarding plane and the control plane. Using this feature, LDP Graceful Restart (GR) preserves the LFIB information when the signaling protocol or control plane fails, so that LSRs can still forward packets according to LFIB, ensuring continuous data transmission.

A switch that participates in a GR process plays either of the following two roles:

· GR restarter, the switch that gracefully restarts due to a manually configured command or a fault. It must be GR-capable.

· GR helper, neighbor of the GR restarter. A GR helper maintains the neighbor relationship with the GR restarter and helps the GR restarter restore its LFIB information. A GR helper must be GR-capable.

Figure 12 LDP GR

As shown in Figure 12, two LDP peers perform GR negotiation when establishing an LDP session. The LDP session established is GR capable only when both peers support LDP GR.

The working procedure of LDP GR is as follows:

1. Whenever restarting, the GR restarter preserves all MPLS forwarding entries, marks them as stale, and starts the MPLS forwarding state holding timer for them.

2. After a GR helper detects that the LDP session with the GR restarter is down, it marks the FEC-label bindings learned from the session as stale and will keep these FEC-label bindings for a period of time defined by the fault tolerant (FT) reconnect time argument. The FT reconnect time is the smaller one between the reconnect time advertised from the peer GR restarter and the neighbor liveness time configured locally.

3. During the FT reconnect time, if the LDP session fails to be re-established, the GR helper will delete the FEC-label bindings marked stale.

4. If the session is re-established successfully, during the LDP recovery time, the GR helper and the GR restarter will use the new LDP session to exchange the label mapping information, update the LFIB, and delete the stale marks of the corresponding forwarding entries. The LDP recovery time is the smaller one between the recovery time configured locally and that configured on the peer GR restarter.

5. After the recovery time elapses, the GR helper deletes the FEC-label bindings that are still marked stale.

6. When the MPLS forwarding state holding timer expires, the GR restarter deletes the label forwarding entries that are still marked stale.

Configuration prerequisites

Configure MPLS LDP capability on each device that will act as the GR restarter or a GR helper.

NOTE:

The switch can act as a GR restarter or a GR helper as needed in the LDP GR process.

Configuration procedure

To configure LDP GR:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS LDP view.	mpls ldp	N/A
3. Enable MPLS LDP GR.	graceful-restart	Disabled by default.
4. Set the FT reconnect time.	graceful-restart timer reconnect timer	Optional. 300 seconds by default.
5. Set the LDP neighbor liveness time.	graceful-restart timer neighbor-liveness timer	Optional. 120 seconds by default.
6. Set the LDP recovery time.	graceful-restart timer recovery timer	Optional. 300 seconds by default.

Verifying LDP GR

To test whether the MPLS LDP GR configuration has taken effect, you can perform graceful restart of MPLS LDP by using the graceful-restart mpls ldp command in use view. During the LDP restart process, you can see whether the packet forwarding path is changed and whether packet forwarding is interrupted.

NOTE:

The graceful-restart mpls ldp command is only used to test MPLS LDP GR function. It does not perform active/standby switchover. Do not perform this operation in other cases.

Setting MPLS statistics reading interval

To use display commands to view LSP statistics, you must first set the statistics reading interval.

To set MPLS statistics reading interval:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MPLS view.	mpls	N/A
3. Set LSP statistics reading interval.	statistics interval interval-time	0 seconds by default, meaning that the system does not read LSP statistics.

Inspecting LSPs

In MPLS, the MPLS control plane is responsible for establishing LSPs. However, when an LSP fails to forward data, the control plane cannot detect the LSP failure or cannot do so in time. This makes network maintenance difficult. To find LSP failures in time and locate the failed node, the switch provides the following mechanisms:

· MPLS LSP ping

· MPLS LSP tracert

· BFD for LSPs

· Periodic LSP tracert

Configuring MPLS LSP ping

MPLS LSP ping is for checking the connectivity of an LSP. At the ingress, it adds the label for the FEC to be inspected into an MPLS echo request, which then is forwarded along the LSP to the egress. The egress processes the request packet and returns an MPLS echo reply to the ingress. An MPLS echo reply carrying a success notification indicates that the lSP is normal, and an MPLS echo reply carrying an error code indicates that the LSP has failed.

To check the connectivity of an LSP:

Task	Command	Remarks
Use MPLS LSP ping to check MPLS LSP connectivity.	ping lsp [ -a source-ip \| -c count \| -exp exp-value \| -h ttl-value \| -m wait-time \| -r reply-mode \| -s packet-size \| -t time-out \| -v ] * ipv4 dest-addr mask-length [ destination-ip-addr-header ]	Available in any view.

Configuring MPLS LSP tracert

MPLS LSP tracert is for locating LSP errors. It consecutively sends the MPLS echo requests along the LSP to be inspected, with the TTL increasing from 1 to a specific value. Then, each hop along the LSP will return an MPLS echo reply to the ingress due to TTL timeout. Thus, the ingress can collect information about each hop along the LSP, so as to locate the failed node. You can also use MPLS LSP tracert to collect the important information about each hop along the LSP, such as the label allocated.

To locate errors of an LSP:

Task	Command	Remarks
Perform MPLS LSP tracert to locate an MPLS LSP error.	tracert lsp [ -a source-ip \| -exp exp-value \| -h ttl-value \| -r reply-mode \|-t time-out ] * ipv4 dest-addr mask-length [ destination-ip-addr-header ]	Available in any view.

Configuring BFD for LSPs

You can configure BFD to detect the connectivity of an LSP. After the configuration, a BFD session will be established between the ingress and egress of the LSP, and the ingress will add the label for the FEC into a BFD control packet, forward the BFD control packet along the LSP to the egress, and determine the status of the LSP according to the reply received. Upon detecting an LSP failure, BFD triggers a traffic switchover.

A BFD session for LSP connectivity detection can be static or dynamic.

· Static—If you specify the local and remote discriminator values by using the discriminator keyword when configuring the bfd enable command, the BFD session will be established with the specified discriminator values. Such a BFD session is used to detect the connectivity of a pair of LSPs in opposite directions (one from local to remote, and the other from remote to local) between two switches.

· Dynamic—If you do not specify the local and remote discriminator values when configuring the bfd enable command, the MPLS LSP ping will be run automatically to negotiate the discriminator values and then the BFD session will be established based on the negotiated discriminator values. Such a BFD session is used for connectivity detection of an LSP from the local switch to the remote switch.

Configuration restrictions and guidelines

· You cannot establish both a static BFD session and a dynamic BFD session for the same LSP.

· After a static BFD session is established, it is not allowed to modify the discriminator values of the BFD session.

Configuration prerequisites

· The BFD session parameters configured on the loopback interface whose IP address is configured as the MPLS LSR ID are used, and the BFD packets use the MPLS LSR ID as the source address. Therefore, before enabling BFD for an LSP, you need to configure an IP address for the loopback interface and configure the IP address as the MPLS LSR ID. You can also configure BFD session parameters for the loopback interface as needed. For more information about BFD, see High Availability Configuration Guide.

· To establish a static BFD session, make sure that there is already an LSP from the local switch to the remote switch and an LSP from the remote switch to the local switch.

Configuration procedure

To configure BFD for LSPs:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable LSP verification and enter the MPLS LSPV view.	mpls lspv	Not enabled by default.
3. Configure BFD to check the connectivity of an LSP to the specified FEC destination.	bfd enable destination-address mask-length [ nexthop nexthop-address [ discriminator local local-id remote remote-id ] ]	Not configured by default.

NOTE:

· In a BFD session for detecting LSP connectivity, the ingress node always operates in active mode and the egress node always operates in passive mode. The bfd session init-mode command does not take effect on the ingress and egress nodes of such a BFD session. Even if you configure the two nodes to both operate in passive mode, the BFD session will still be established successfully.

· BFD for MPLS LDP is for detecting the IP connectivity between two remote LDP peers. BFD for LSP is for detecting the connectivity of LSPs.

Configuring periodic LSP tracert

The periodic LSP tracert function is for locating faults of an LSP periodically. It detects the consistency of the forwarding plane and control plane and records detection results into logs. You can know whether an LSP has failed by checking the logs.

If you configure BFD as well as periodic tracert for an LSP, once the periodic LSP tracert function detects an LSP fault or inconsistency of the forwarding plane and control plane, the BFD session for the LSP will be deleted and a new BFD session will be established according to the control plane.

To configure the periodic LSP tracert function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable LSP verification and enter the MPLS LSPV view.	mpls lspv	Not enabled by default.
3. Configure periodic tracert for an LSP to the specified FEC destination.	periodic-tracert destination-address mask-length [ -a source-ip \| -exp exp-value \| -h ttl-value \| -m wait-time \| -t time-out \| -u retry-attempt ] *	Not configured by default.

Enabling MPLS trap

With the MPLS trap function enabled, trap packets of the notifications level are generated to report critical MPLS events. Such trap packets are sent to the information center of the switch. Whether and where the packets are output depend on the configurations of the information center. For information on how to configure the information center, see Network Management and Monitoring Configuration Guide.

To enable the MPLS trap function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the MPLS trap function.	snmp-agent trap enable mpls	Disabled by default.

For more information about the snmp-agent trap enable mpls command, see the snmp-agent trap enable command in Network Management and Monitoring Command Reference.

Displaying and maintaining MPLS

Displaying MPLS operation

Task	Command	Remarks
Display information about one or all interfaces with MPLS enabled.	display mpls interface [ interface-type interface-number ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about ILM entries on the switch in standalone mode.	display mpls ilm [ label ] [ verbose ] [ slot slot-number ] [ include text \| { \| { begin \| exclude \| include } regular-expression } ]	Available in any view.
Display information about ILM entries on the switch in IRF mode.	display mpls ilm [ label ] [ verbose ] [ chassis chassis-number slot slot-number ] [ include text \| { \| { begin \| exclude \| include } regular-expression } ]	Available in any view.
Display information about specified MPLS labels or all labels.	display mpls label { label-value1 [ to label-value2 ] \| all } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about LSPs.	display mpls lsp [ incoming-interface interface-type interface-number ] [ outgoing-interface interface-type interface-number ] [ in-label in-label-value ] [ out-label out-label-value ] [ asbr \| [ vpn-instance vpn-instance-name ] [ protocol { bgp \| bgp-ipv6 \| crldp \| ldp \| rsvp-te \| static \| static-cr } ] ] [ egress \| ingress \| transit ] [ { exclude \| include } dest-addr mask-length ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display LSP statistics.	display mpls lsp statistics [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display the BFD detection information for an LSP.	display mpls lsp bfd [ ipv4 destination-address mask-length ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about NHLFE entries on the switch in standalone mode.	display mpls nhlfe [ token ] [ verbose ] [ slot slot-number ] [ include text \| { \| { begin \| exclude \| include } regular-expression } ]	Available in any view.
Display information about NHLFE entries on the switch in IRF mode.	display mpls nhlfe [ token ] [ verbose ] [ chassis chassis-number slot slot-number ] [ include text \| { \| { begin \| exclude \| include } regular-expression } ]	Available in any view.
Display usage information for the NHLFE entries on the switch in standalone mode.	display mpls nhlfe reflist token [ slot slot-number ] [ include text \| { \| { begin \| exclude \| include } regular-expression } ]	Available in any view.
Display usage information for the NHLFE entries on the switch in IRF mode.	display mpls nhlfe reflist token [ chassis chassis-number slot slot-number ] [ include text \| { \| { begin \| exclude \| include } regular-expression } ]	Available in any view.
Display information about static LSPs.	display mpls static-lsp [ lsp-name lsp-name ] [ { include \| exclude } dest-addr mask-length ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display LSP-related route information.	display mpls route-state [ vpn-instance vpn-instance-name ] [ dest-addr mask-length ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display statistics for all LSPs or the LSP with a specific index or name.	display mpls statistics lsp { index \| all \| name lsp-name } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display MPLS statistics for one or all interfaces.	display mpls statistics interface { interface-type interface-number \| all } [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.

Displaying MPLS LDP operation

The vpn-instance vpn-instance-name option is used to specify information about an LDP instance. For information about LDP instances, see "Configuring MPLS L3VPN."

Task	Command	Remarks
Display information about LDP.	display mpls ldp [ all [ verbose ] [ \| { begin \| exclude \| include } regular-expression ] ]	Available in any view.
Display the label advertisement information for the specified FEC.	display mpls ldp fec [ vpn-instance vpn-instance-name ] dest-addr mask-length [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about LDP-enabled interfaces.	display mpls ldp interface [ all [ verbose ] \| [ vpn-instance vpn-instance-name ] [ interface-type interface-number \| verbose ] ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about LDP peers.	display mpls ldp peer [ all [ verbose ] \| [ vpn-instance vpn-instance-name ] [ peer-id \| verbose ] ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about remote LDP peers.	display mpls ldp remote-peer [ remote-name remote-peer-name ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about LDP sessions between LDP peers.	display mpls ldp session [ all [ verbose ] \| [ vpn-instance vpn-instance-name ] [ peer-id \| verbose ] ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display statistics information about all LSP sessions.	display mpls ldp session all statistics [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about LSPs established by LDP.	display mpls ldp lsp [ all \| [ vpn-instance vpn-instance-name ] [ dest-addr mask-length ] ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about CR-LSPs established by CR-LDP.	display mpls ldp cr-lsp [ lspid lsr-id lsp-id ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.
Display information about the specified LDP instance.	display mpls ldp vpn-instance vpn-instance-name [ \| { begin \| exclude \| include } regular-expression ]	Available in any view.

Clearing MPLS statistics

Task	Command	Remarks
Clear MPLS statistics for one or all MPLS interfaces.	reset mpls statistics interface { interface-type interface-number \| all }	Available in user view.
Clear MPLS statistics for all LSPs or the LSP with a specific index or name.	reset mpls statistics lsp { index \| all \| name lsp-name }	Available in user view.

MPLS configuration examples

IMPORTANT:

By default, Ethernet, VLAN, and aggregate interfaces are down. To configure such an interface, bring the interface up by executing the undo shutdown command.

Configuring static LSPs

Network requirements

Switch A, Switch B, and Switch C support MPLS.

Establish static LSPs between Switch A and Switch C so that subnets 11.1.1.0/24 and 21.1.1.0/24 can access each other over MPLS. Check the connectivity of the static LSPs.

Figure 13 Network diagram

Configuration considerations

· On an LSP, the out label of an upstream LSR must be identical with the in label of its downstream LSR.

· Configure an LSP for each direction on the forwarding path.

· Configure a static route to the destination address of the LSP on each ingress node. Such a route is not required on the transit and egress nodes. You do not need to configure any routing protocol on the switches.

Configuration procedure

1. Configure IP addresses for the interfaces according to Figure 13. (Details not shown.)

2. Configure a static route to the destination address of the FEC on each ingress node:

# Configure a static route to network 21.1.1.0/24 on Switch A.

<SwitchA> system-view

[SwitchA] ip route-static 21.1.1.0 24 10.1.1.2

# Configure a static route to network 11.1.1.0/24 on Switch C.

<SwitchC> system-view

[SwitchC] ip route-static 11.1.1.0 255.255.255.0 20.1.1.1

3. Enable MPLS:

# Configure MPLS on Switch A.

[SwitchA] mpls lsr-id 1.1.1.9

[SwitchA] mpls

[SwitchA-mpls] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] mpls

[SwitchA-Vlan-interface2] quit

# Configure MPLS on Switch B.

[SwitchB] mpls lsr-id 2.2.2.9

[SwitchB] mpls

[SwitchB-mpls] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] mpls

[SwitchB-Vlan-interface2] quit

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] mpls

[SwitchB-Vlan-interface3] quit

# Configure MPLS on Switch C.

[SwitchC] mpls lsr-id 3.3.3.9

[SwitchC] mpls

[SwitchC-mpls] quit

[SwitchC] interface vlan-interface 3

[SwitchC-Vlan-interface3] mpls

[SwitchC-Vlan-interface3] quit

4. Create a static LSP from Switch A to Switch C:

# Configure the LSP ingress, Switch A.

[SwitchA] static-lsp ingress AtoC destination 21.1.1.0 24 nexthop 10.1.1.2 out-label 30

# Configure the LSP transit node, Switch B.

[SwitchB] static-lsp transit AtoC incoming-interface vlan-interface 2 in-label 30 nexthop 20.1.1.2 out-label 50

# Configure the LSP egress, Switch C.

[SwitchC] static-lsp egress AtoC incoming-interface vlan-interface 3 in-label 50

5. Create a static LSP from Switch C to Switch A:

# Configure the LSP ingress, Switch C.

[SwitchC] static-lsp ingress CtoA destination 11.1.1.0 24 nexthop 20.1.1.1 out-label 40

# Configure the LSP transit node, Switch B.

[SwitchB] static-lsp transit CtoA incoming-interface vlan-interface 3 in-label 40 nexthop 10.1.1.1 out-label 70

# Configure the LSP egress, Switch A.

[SwitchA] static-lsp egress CtoA incoming-interface vlan-interface 2 in-label 70

6. Verify the configuration:

# Execute the display mpls static-lsp command on each switch to view the static LSP information. The following takes Switch A as an example:

[SwitchA] display mpls static-lsp

total statics-lsp : 2

Name FEC I/O Label I/O If State

AtoC 21.1.1.0/24 NULL/30 -/Vlan2 Up

CtoA -/- 70/NULL Vlan2/- Up

# On Switch A, check the connectivity of the LSP from Switch A to Switch C.

[SwitchA] ping lsp -a 11.1.1.1 ipv4 21.1.1.0 24

LSP Ping FEC: IPV4 PREFIX 21.1.1.0/24 : 100 data bytes, press CTRL_C to break

Reply from 20.1.1.2: bytes=100 Sequence=1 time = 2 ms

Reply from 20.1.1.2: bytes=100 Sequence=2 time = 2 ms

Reply from 20.1.1.2: bytes=100 Sequence=3 time = 1 ms

Reply from 20.1.1.2: bytes=100 Sequence=4 time = 2 ms

Reply from 20.1.1.2: bytes=100 Sequence=5 time = 2 ms

--- FEC: IPV4 PREFIX 21.1.1.0/24 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/1/2 ms

# On Switch C, check the connectivity of the LSP from Switch C to Switch A.

[SwitchC] ping lsp -a 21.1.1.1 ipv4 11.1.1.0 24

LSP Ping FEC: IPV4 PREFIX 11.1.1.0/24 : 100 data bytes, press CTRL_C to break

Reply from 10.1.1.1: bytes=100 Sequence=1 time = 3 ms

Reply from 10.1.1.1: bytes=100 Sequence=2 time = 2 ms

Reply from 10.1.1.1: bytes=100 Sequence=3 time = 2 ms

Reply from 10.1.1.1: bytes=100 Sequence=4 time = 2 ms

Reply from 10.1.1.1: bytes=100 Sequence=5 time = 2 ms

--- FEC: IPV4 PREFIX 11.1.1.0/24 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 2/2/3 ms

Configuring LDP to establish LSPs dynamically

Network requirements

Switch A, Switch B, and Switch C support MPLS.

Configure LDP to establish LSPs between Switch A and Switch C so that subnets 11.1.1.0/24 and 21.1.1.0/24 can reach each other over MPLS. Check the LSP connectivity.

Figure 14 Network diagram

Configuration considerations

· Enable LDP on the LSRs. LDP dynamically distributes labels and establishes LSPs and thus there is no need to manually configure labels for LSPs.

· LDP uses routing information for label distribution. Therefore, you must configure a routing protocol to learn routing information. OSPF is used in this example.

Configuration procedure

1. Configure IP addresses for the interfaces according to Figure 14. (Details not shown.)

2. Configure OSPF to ensure IP connectivity between the switches:

# Configure OSPF on Switch A.

<Sysname> system-view

[Sysname] sysname SwitchA

[SwitchA] ospf

[SwitchA-ospf-1] area 0

[SwitchA-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0

[SwitchA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

[SwitchA-ospf-1-area-0.0.0.0] network 11.1.1.0 0.0.0.255

[SwitchA-ospf-1-area-0.0.0.0] quit

[SwitchA-ospf-1] quit

# Configure OSPF on Switch B.

<Sysname> system-view

[Sysname] sysname SwitchB

[SwitchB] ospf

[SwitchB-ospf-1] area 0

[SwitchB-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0

[SwitchB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255

[SwitchB-ospf-1-area-0.0.0.0] quit

[SwitchB-ospf-1] quit

# Configure OSPF on Switch C.

<Sysname> system-view

[Sysname] sysname SwitchC

[SwitchC] ospf

[SwitchC-ospf-1] area 0

[SwitchC-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0

[SwitchC-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] network 21.1.1.0 0.0.0.255

[SwitchC-ospf-1-area-0.0.0.0] quit

[SwitchC-ospf-1] quit

# Execute the display ip routing-table command on each switch. You will see that each switch has learned the routes to other switches. Take Switch A as an example:

[SwitchA] display ip routing-table

Routing Tables: Public

Destinations : 11 Routes : 11

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

2.2.2.9/32 OSPF 10 1 10.1.1.2 Vlan2

3.3.3.9/32 OSPF 10 2 10.1.1.2 Vlan2

10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2

10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

11.1.1.0/24 Direct 0 0 11.1.1.1 Vlan4

11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

20.1.1.0/24 OSPF 10 2 10.1.1.2 Vlan2

21.1.1.0/24 OSPF 10 3 10.1.1.2 Vlan2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

3. Enable MPLS and MPLS LDP:

# Configure Switch A.

[SwitchA] mpls lsr-id 1.1.1.9

[SwitchA] mpls

[SwitchA-mpls] quit

[SwitchA] mpls ldp

[SwitchA-mpls-ldp] quit

[SwitchA] interface vlan-interface 2

[SwitchA-Vlan-interface2] mpls

[SwitchA-Vlan-interface2] mpls ldp

[SwitchA-Vlan-interface2] quit

# Configure Switch B.

[SwitchB] mpls lsr-id 2.2.2.9

[SwitchB] mpls

[SwitchB-mpls] quit

[SwitchB] mpls ldp

[SwitchB-mpls-ldp] quit

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] mpls

[SwitchB-Vlan-interface2] mpls ldp

[SwitchB-Vlan-interface2] quit

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] mpls

[SwitchB-Vlan-interface3] mpls ldp

[SwitchB-Vlan-interface3] quit

# Configure Switch C.

[SwitchC] mpls lsr-id 3.3.3.9

[SwitchC] mpls

[SwitchC-mpls] quit

[SwitchC] mpls ldp

[SwitchC-mpls-ldp] quit

[SwitchC] interface vlan-interface 3

[SwitchC-Vlan-interface3] mpls

[SwitchC-Vlan-interface3] mpls ldp

[SwitchC-Vlan-interface3] quit

# After the configurations, two local LDP sessions are established, one between Switch A and Switch B and the other between Switch B and Switch C. Execute the display mpls ldp session command on each switch to view the LDP session information, and execute the display mpls ldp peer command to view the LDP peer information. Take Switch A as an example:

[SwitchA] display mpls ldp session

LDP Session(s) in Public Network

Total number of sessions: 1

----------------------------------------------------------------

Peer-ID Status LAM SsnRole FT MD5 KA-Sent/Rcv

----------------------------------------------------------------

2.2.2.9:0 Operational DU Passive Off Off 5/5

----------------------------------------------------------------

LAM : Label Advertisement Mode FT : Fault Tolerance

[SwitchA] display mpls ldp peer

LDP Peer Information in Public network

Total number of peers: 1

-----------------------------------------------------------------

Peer-ID Transport-Address Discovery-Source

----------------------------------------------------------------

2.2.2.9:0 2.2.2.9 Vlan-interface2

----------------------------------------------------------------

4. Allow all static routes and IGP routes to trigger LDP to establish LSPs:

# Configure the LSP establishment triggering policy on Switch A.

[SwitchA] mpls

[SwitchA-mpls] lsp-trigger all

[SwitchA-mpls] return

# Configure the LSP establishment triggering policy on Switch B.

[SwitchB] mpls

[SwitchB-mpls] lsp-trigger all

[SwitchB-mpls] quit

# Configure the LSP establishment triggering policy on Switch C.

[SwitchC] mpls

[SwitchC-mpls] lsp-trigger all

[SwitchC-mpls] quit

5. Verify the configuration:

# Execute the display mpls ldp lsp command on each switch to view the LDP LSP information. Take Switch A as an example:

<SwitchA> display mpls ldp lsp

LDP LSP Information

-------------------------------------------------------------------

SN DestAddress/Mask In/OutLabel Next-Hop In/Out-Interface

------------------------------------------------------------------

1 1.1.1.9/32 3/NULL 127.0.0.1 -------/InLoop0

2 2.2.2.9/32 NULL/3 10.1.1.2 -------/Vlan2

3 3.3.3.9/32 NULL/1024 10.1.1.2 -------/Vlan2

4 11.1.1.0/24 3/NULL 0.0.0.0 -------/Vlan4

5 20.1.1.0/24 NULL/3 10.1.1.2 -------/Vlan2

6 21.1.1.0/24 NULL/1027 10.1.1.2 -------/Vlan2

-------------------------------------------------------------------

A '*' before an LSP means the LSP is not established

A '*' before a Label means the USCB or DSCB is stale

# On Switch A, check the connectivity of the LDP LSP from Switch A to Switch C.

[SwitchA] ping lsp ipv4 21.1.1.0 24

LSP Ping FEC: IPV4 PREFIX 21.1.1.0/24 : 100 data bytes, press CTRL_C to break

Reply from 20.1.1.2: bytes=100 Sequence=1 time = 3 ms

Reply from 20.1.1.2: bytes=100 Sequence=2 time = 2 ms

Reply from 20.1.1.2: bytes=100 Sequence=3 time = 1 ms

Reply from 20.1.1.2: bytes=100 Sequence=4 time = 1 ms

Reply from 20.1.1.2: bytes=100 Sequence=5 time = 3 ms

--- FEC: IPV4 PREFIX 21.1.1.0/24 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/2/3 ms

# On Switch C, check the connectivity of the LDP LSP from Switch C to Switch A.

[SwitchC] ping lsp ipv4 11.1.1.0 24

LSP Ping FEC: IPV4 PREFIX 11.1.1.0/24 : 100 data bytes, press CTRL_C to break

Reply from 10.1.1.1: bytes=100 Sequence=1 time = 2 ms

Reply from 10.1.1.1: bytes=100 Sequence=2 time = 2 ms

Reply from 10.1.1.1: bytes=100 Sequence=3 time = 2 ms

Reply from 10.1.1.1: bytes=100 Sequence=4 time = 3 ms

Reply from 10.1.1.1: bytes=100 Sequence=5 time = 2 ms

--- FEC: IPV4 PREFIX 11.1.1.0/24 ping statistics ---

5 packet(s) transmitted

5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 2/2/3 ms

Configuring BFD for LSPs

Network requirements

As shown in Figure 14, use LDP to establish an LSP from 11.1.1.0/24 to 21.1.1.0/24, and an LSP from 21.1.1.0/24 to 11.1.1.0/24. Configure BFD for the LSPs to detect LSP failures.

Configuration procedure

1. Configure LDP sessions (see "Configuring LDP to establish LSPs dynamically").

2. Configure BFD for LSPs:

# Configure Switch A.

<SwitchA> system-view

[SwitchA] mpls lspv

[SwitchA -mpls-lspv] bfd enable 21.1.1.0 24

[SwitchA -mpls-lspv] quit

# Configure Switch C.

<SwitchC> system-view

[SwitchC] mpls lspv

[SwitchC-mpls-lspv] bfd enable 11.1.1.0 24

[SwitchC-mpls-lspv] quit

3. Verify the configuration:

Execute the display mpls lsp bfd command on Switch A and Switch C to view information about the sessions established for the LSPs. Take Switch A as an example:

[SwitchA] display mpls lsp bfd

MPLS BFD Session(s) Information

-----------------------------------------------------------------------------

FEC : 11.1.1.0/24 Type : LSP

Local Discr : 130 Remote Discr : 130

Tunnel ID : --- NextHop : ---

Session State : Up Source IP : 3.3.3.9

Session Role : Passive

FEC : 21.1.1.0/24 Type : LSP

Local Discr : 129 Remote Discr : 129

Tunnel ID : 0x6040000 NextHop : 10.1.1.2

Session State : Up Source IP : 1.1.1.9

Session Role : Active

Total Session Num: 2

The output indicates that two BFD sessions have been established between Switch A and Switch C, one for detecting the connectivity of the LSP Switch A-Switch B-Switch C, and the other for detecting the connectivity of the LSP Switch C-Switch B-Switch A.

You can use the following command to display verbose information about the BFD sessions.

[SwitchA] display bfd session verbose

Total session number: 2 Up session number: 2 Init mode: Active

IPv4 session working under Ctrl mode:

Local Discr: 129 Remote Discr: 129

Source IP: 1.1.1.9 Destination IP: 127.0.0.1

Session State: Up Interface: LoopBack0

Min Trans Inter: 400ms Act Trans Inter: 400ms

Min Recv Inter: 400ms Act Detect Inter: 2000ms

Running Up for: 00:15:52 Auth mode: None

Connect Type: Indirect Board Num: 6

Protocol: MFW/LSPV

Diag Info: No Diagnostic

Local Discr: 130 Remote Discr: 130

Source IP: 1.1.1.9 Destination IP: 3.3.3.9

Session State: Up Interface: LoopBack0

Min Trans Inter: 400ms Act Trans Inter: 400ms

Min Recv Inter: 400ms Act Detect Inter: 2000ms

Running Up for: 00:15:44 Auth mode: None

Connect Type: Indirect Board Num: 7

Protocol: MFW/LSPV

Diag Info: No Diagnostic

09-MPLS Configuration Guide

MPLS overview

Basic concepts

FEC

Label

LSR

LER

LSP

LFIB

Control plane and forwarding plane

MPLS network structure

LSP establishment and label distribution

LSP establishment

Label distribution and management

LFIB

PHP

Basic LDP concepts

LDP message type

LDP operation

Establishing dynamic LSPs through LDP

Configuring MPLS LDP capability

Configuring local LDP session parameters

Configuring remote LDP session parameters

Configuration restrictions and guidelines

Configuration procedure

Configuring PHP

Configuring the label distribution control mode

Configuring LDP loop detection

Configuration restrictions and guidelines

Configuration procedure

Configuring LDP MD5 authentication

Label acceptance control

Label advertisement control

Configuration prerequisites

Configuration procedure

Maintaining LDP sessions

Configuring MPLS MTU

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration procedure

Verifying LDP GR

Setting MPLS statistics reading interval

Configuration prerequisites

Configuration procedure

Configuring periodic LSP tracert

Enabling MPLS trap

Displaying and maintaining MPLS

MPLS configuration examples

Network requirements

Configuration considerations

Configuration procedure

Network requirements

Configuration considerations

Configuration procedure

Network requirements

Configuration procedure

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us