02-MPLS Basics Configuration PDF

i
Table of Contents
1 MPLS Basics Configuration 1-1
MPLS Overview 1-1
Basic Concepts of MPLS1-2
Architecture of MPLS1-4
MPLS and Routing Protocols 1-6
Applications of MPLS 1-6
MPLS Configuration Basics 1-7
Label Distribution and Management1-7
PHP 1-9
TTL Processing in MPLS1-9
Inspecting an MPLS LSP1-10
LDP Overview1-11
Basic Concepts of LDP1-11
LDP Label Distribution1-12
Fundamental Operation of LDP1-13
LDP Loop Detection 1-14
LDP GR1-15
Configuring MPLS Basic Capability 1-15
Configuration Prerequisites 1-15
Configuration Procedure1-16
Configuring PHP 1-17
Configuring a Static LSP1-17
Configuring MPLS LDP1-18
MPLS LDP Configuration Task List1-19
Configuring MPLS LDP Capability 1-19
Configuring Local LDP Session Parameters1-20
Configuring Remote LDP Session Parameters1-20
Configuring the Policy for Triggering LSP Establishment 1-21
Configuring the Label Distribution Control Mode 1-22
Configuring LDP Loop Detection1-22
Configuring LDP MD5 Authentication1-23
Configuring LDP Instances 1-23
Configuring LDP GR 1-24
Restarting MPLS LDP Gracefully1-25
ii
Configuring MPLS IP TTL Processing 1-25
Configuring MPLS IP TTL Propagation1-25
Specifying the Type of the Paths for ICMP Responses 1-26
Configuring MPLS Statistics 1-26
Setting the Interval for Reporting Statistics 1-26
Inspecting an MPLS LSP1-27
Enabling MPLS Trap1-27
Displaying and Maintaining MPLS1-28
Resetting LDP Sessions1-28
Displaying MPLS Operation 1-28
Displaying MPLS LDP Operation 1-29
Clearing MPLS Statistics1-29
MPLS Configuration Examples1-30
Example for Configuring LDP Sessions 1-30
Example for Configuring LDP to Establish LSPs 1-33

1-1
1 MPLS Basics Configuration
When performing MPLS basics configuration, go to these sections for information you are interested in:
MPLS Overview
MPLS Configuration Basics
LDP Overview
Configuring MPLS Basic Capability
Configuring PHP
Configuring a Static LSP
Configuring MPLS LDP
Configuring LDP Instances
Configuring LDP GR
Configuring MPLS IP TTL Processing
Configuring MPLS Statistics
Inspecting an MPLS LSP
Enabling MPLS Trap
Displaying and Maintaining MPLS
MPLS Configuration Examples

For detailed information about VPN, refer to MPLS L2VPN Configuration and MPLS L3VPN
Configuration in the MPLS Volume.
For detailed information about QoS, refer to the QoS Volume.
At present, to support MPLS or MPLS-based functions, S7500E series Ethernet switches must use
the LSQ1SRP1CB engine or use no other LPUs but the EA series.

MPLS Overview
Multiprotocol Label Switching (MPLS), originating in Internet Protocol version 4 (IPv4), was initially
proposed to improve forwarding speed. However, its core technology can be extended to multiple
network protocols, such as Internet Protocol version 6 (IPv6), Internet Packet Exchange (IPX), and
Connectionless Network Protocol (CLNP). That is what the term multiprotocol means.
MPLS integrates both Layer 2 fast switching and Layer 3 routing and forwarding, satisfying the
networking requirements of various new applications.

1-2

For details about the MPLS architecture, refer to RFC 3031 Multiprotocol Label Switching
Architecture.

Basic Concepts of MPLS
FEC
As a forwarding technology based on classification, MPLS groups packets to be forwarded in the same
manner into a class called a forwarding equivalence class (FEC). That is, packets of the same FEC are
handled in the same way on an MPLS network.
The classification of FECs is very flexible. It can be based on any combination of source address,
destination address, source port, destination port, protocol type and Virtual Private Network (VPN). For
example, in traditional IP forwarding using the longest match algorithm, all packets to the same
destination belong to the same FEC.
Label
A label is a short, fixed length identifier for identifying a FEC. A FEC may correspond to multiple labels in
scenarios where, for example, load sharing is required, while a label can only represent a single FEC.
A label is carried in the header of a packet. It does not contain any topology information and is local
significant.
A label is four octets, or 32 bits, in length. Figure 1-1 illustrates its format.
Figure 1-1 Format of a label

A label consists of four fields:
Label: Label value of 20 bits. Used as the pointer for forwarding.
Exp: For QoS, three bits in length.
S: Flag for indicating whether the label is at the bottom of the label stack, one bit in length. 1
indicates that the label is at the bottom of the label stack. This field is very useful when there are
multiple levels of MPLS labels.
TTL: Time to live (TTL) for the label. Eight bits in length. This field has the same meaning as that for
an IP packet.
Similar to the VPI/VCI in ATM and the DLCI in frame relay, an MPLS label functions as a connection
identifier. If the link layer protocol has a label field like VPI/VCI in ATM or DLCI in frame relay, the MPLS
label is encapsulated in that field. Otherwise, it is inserted between the data link layer header and the
network layer header as a shim. As such, an MPLS label can be supported by any link layer protocol.
Figure 1-2 shows the place of a label in a packet.

1-3
Figure 1-2 Place of a label in a packet

Currently, the device does not support the cell mode.

LSR
A Label switching router (LSR) is a fundamental component on an MPLS network. All LSRs support
MPLS.
LSP
A Label switched path (LSP) is the path along which a FEC travels through an MPLS network. Along an
LSP, two neighboring LSRs are called upstream LSR and downstream LSR respectively. In Figure 1-3,
R2 is the downstream LSR of R1, while R1 is the upstream LSR of R2.
Figure 1-3 Diagram for an LSP
R1
R2
R21 R22
R3
R4

An LSP is a unidirectional path from the ingress of the MPLS network to the egress. It functions like a
virtual circuit in ATM or frame relay. Each node of an LSP is an LSR.
Label distribution protocol
A label distribution protocol is a protocol used by MPLS for control. It has the same functions as a
signaling protocol on a traditional network. It classifies FECs, distributes labels, and establishes and
maintains LSPs.
MPLS supports multiple label distribution protocols of either of the following two types:
Those dedicated for label distribution, such as Label Distribution Protocol (LDP).
Those existing protocols that are extended to support label distribution, such as Border Gateway
Protocol (BGP).
In addition, you can configure static LSPs.

1-4

For information about BGP, refer to BGP Configuration in the IP Routing Volume.

LSP tunneling
MPLS supports LSP tunneling.
An LSR and its downstream LSR on an LSP are not necessarily on a path provided by the routing
protocol. That is, MPLS supports establishing an LSP along a path different from that established by the
routing protocol. Such an LSP is called an LSP tunnel, and the two LSRs are respectively the start point
and end point of the LSP tunnel. For example, the LSP <R2R21R22R3> in Figure 1-3 is a tunnel
between R2 and R3. This tunneling technology does not use the traditional network layer encapsulation
tunneling technology.
If the path that a tunnel traverses is exactly the hop-by-hop route established by the routing protocol, the
tunnel is called a hop-by-hop routed tunnel. Otherwise, the tunnel is called an explicitly routed tunnel.
Multi-level label stack
MPLS allows a packet to carry multiple levels of labels organized as a last-in first-out (LIFO) stack,
which is called a label stack. A packet with multiple levels of labels can travel along more than one level
of LSP tunnel. The ingress and egress of each tunnel perform Push and Pop operations respectively on
the top of a stack.
MPLS has no limit to the depth of a label stack. For a label stack with a depth of m, the label at the
bottom is of level 1, while the label at the top has a level of m. An unlabeled packet can be considered
as a packet with an empty label stack, that is, a label stack whose depth is 0.
Architecture of MPLS
Structure of the MPLS network
As shown in Figure 1-4, the element of an MPLS network is LSR. LSRs in the same routing or
administrative domain form an MPLS domain.
In an MPLS domain, LSRs residing at the domain border and connected with other networks are label
edge routers (LERs), while those within the MPLS domain are core LSRs. All core LSRs, which can be
routers running MPLS or ATM-LSRs upgraded from ATM switches, use MPLS to communicate, while
LERs interact with devices outside the domain that use traditional IP technologies.
Each packet entering an MPLS network is labeled on the ingress LER and then forwarded along an LSP
to the egress LER. All the intermediate LSRs are called transit LSRs.

1-5
Figure 1-4 Structure of the MPLS network
Ingress
LSP
Egress
Transit
IP network
IP network

The following describes how MPLS operates:
1) First, the LDP protocol and the traditional routing protocol (such as OSPF and ISIS) work together
on each LSR to establish the routing table and the label information base (LIB) for intended FECs.
2) Upon receiving a packet, the ingress LER completes the Layer 3 functions, determines the FEC to
which the packet belongs, labels the packet, and forwards the labeled packet to the next hop along
the LSP.
3) After receiving a packet, each transit LSR looks up its Label Forwarding Information Base (LFIB)
for the next hop according to the label of the packet, swaps the label, and then forwards the packet
to the next hop. None of the transit LSRs performs Layer 3 processing.
4) When the egress LER receives the packet, it removes the label of the packet and IP forwards the
packet.
Obviously, MPLS is not a service or application, but actually a tunneling technology and a routing and
switching technology platform that combines label switching with Layer 3 routing. This platform not only
supports multiple upper layer protocols and services, but also secures transmission of information to a
certain degree.

1-6
Structure of an LSR
Figure 1-5 Structure of an LSR

As shown in Figure 1-5, an LSR consists of two planes:
Control plane: Implements label distribution and routing, establishes the LFIB, and builds and tears
LSPs.
Forwarding plane: Forwards packets according to the LFIB.
An LER forwards both labeled packets and IP packets on the forwarding plane and therefore uses both
the LFIB and the FIB. An ordinary LSR only needs to forward labeled packets and therefore uses only
the LFIB.
MPLS and Routing Protocols
When establishing an LSP hop by hop, LDP uses the information in the routing tables of the LSRs along
the path to determine the next hop. The information in the routing tables is provided by routing protocols
such as IGPs and BGP. LDP only uses the routing information indirectly; it has no direct relationship
with routing protocols.
On the other hand, existing protocols such as BGP can be extended to support label distribution.
In MPLS applications, it may be necessary to extend some routing protocols. For example,
MPLS-based VPN applications requires that BGP be extended to propagate VPN routing information.
Applications of MPLS
By integrating both Layer 2 fast switching and Layer 3 routing technologies, MPLS features improved
route lookup speed. However, with the development of the application specific integrated circuit (ASIC)
technology, route lookup speed is no longer the bottleneck hindering network development. This makes
MPLS not so outstanding in improving forwarding speed.
Nonetheless, MPLS can easily implement the seamless integration between IP networks and Layer 2
networks of ATM, frame relay, and the like, and offer better solutions to Quality of Service (QoS), TE,
and VPN applications thanks to the following advantages.

1-7
MPLS-based VPN
Traditional VPNs depend on tunneling protocols such as GRE, L2TP, and PPTP to transport data
between private networks across public networks, while an LSP itself is a tunnel over public networks.
Therefore, implementation of VPN using MPLS holds natural advantages.
An MPLS-based VPN uses LSPs to connect geographically dispersed branches of an organization to
form a united network. MPLS-based VPN also supports the interconnection between VPNs.
Figure 1-6 MPLS-based VPN
CE 1 PE 1
PE 3
CE 3
PE 2 CE 2
VPN 1 VPN 2
VPN 3
MPLS backbone

Figure 1-6 shows the basic structure of an MPLS-based VPN. Two of the fundamental components are
customer edge device (CE) and service provider edge router (PE). A CE can be a router, switch, or host.
All PEs are on the backbone network.
PEs are responsible for establishing LSPs between them, managing VPN users, and advertising routes
among different branches of the same VPN. Route advertisement among PEs is usually implemented
by LDP or extended BGP.
MPLS-based VPN supports IP address multiplexing between branches and interconnection between
VPNs. Compared with a traditional route, a VPN route requires the branch and VPN identification
information. Therefore, it is necessary to extend BGP to carry VPN routing information.
MPLS Configuration Basics
Label Distribution and Management
In MPLS, the label that an LSR uses for an FEC is assigned by the downstream LSR. The downstream
LSR then informs the upstream LSR of the assignment. That is, labels are advertised in the upstream
direction.
Label advertisement mode
Two label advertisement modes are available:
Downstream on demand (DoD): In this mode, an LSR distributes a label binding to another LSR
only when it receives a label request from the LSR.
Downstream unsolicited (DU): In this mode, an LSR does not wait for any label request before
distributing a label binding.

1-8
An upstream LSR and its downstream LSR must use the same label advertisement mode; otherwise,
no LSP can be established normally. For more information, refer to LDP Label Distribution.

Currently, S7500E Series Ethernet Switches supports only the DU mode.

Label distribution control mode
There are two label distribution control modes:
Independent: In this mode, an LSR can advertise label bindings upstream at anytime. A
consequence of this mode is that an LSR may have advertised a label binding to the upstream LSR
when it receives a binding from its downstream LSR.
Ordered: In this mode, an LSR advertises its label binding for a FEC upstream only when it
receives a label binding from the next hop for the FEC or it is the egress of the FEC.
Label retention mode
Label retention mode dictates how to process a received label binding that is not useful at the moment.
There are two label retention modes:
Liberal: In this mode, an LSR keeps any received label binding regardless of whether the binding is
from its next hop for the FEC or not.
Conservative: In this mode, an LSR keeps only label bindings that are from its next hops for the
FECs.
In liberal mode, an LSR can adapt to route changes quickly; while in conservative mode, there are less
label bindings for an LSR to advertise and keep.
The conservative label retention mode is usually used together with the DoD mode on LSRs with limited
label spaces.

Currently, S7500E Series Ethernet Switches supports only the liberal mode.

Basic concepts for label switching
Next hop label forwarding entry (NHLFE): Operation to be performed on the label, which can be
Push or Swap.
FEC to NHLFE mapping (FTN): Mapping of a FEC to an NHLFE at the ingress node.
Incoming label mapping (ILM): Mapping of each incoming label to a set of NHLFEs. The operations
performed for each incoming label can be Null or Pop.

1-9
Label switching process
Each packet is classified into a certain FEC at the ingress LER. Packets of the same FEC travel along
the same path in the MPLS domain, that is, the same LSP. For each incoming packet, an LSR examines
the label, uses the ILM to map the label to an NHLFE, replaces the old label with a new label, and then
forwards the labeled packet to the next hop.
PHP
As described in Architecture of MPLS, each transit LSR on an MPLS network forwards an incoming
packet based on the label of the packet, while the egress removes the label from the packet and
forwards the packet based on the network layer destination address.
In fact, on a relatively simple MPLS application network, the label of a packet is useless for the egress,
which only needs to forward the packet based on the network layer destination address. In this case,
the penultimate hop popping (PHP) feature can pop the label at the penultimate node, relieving the
egress of the label operation burden and improving the packet processing capability of the MPLS
network.
TTL Processing in MPLS
MPLS TTL processing involves two aspects: IP TTL propagation and ICMP response path.
IP TTL propagation
An MPLS label contains an 8-bit long TTL field, which has the same meaning as that of an IP packet.
According to RFC 3031 Multiprotocol Label Switching Architecture, when an LSR labels a packet, it
copies the TTL value of the original IP packet or the lower level label to the TTL field of the newly added
label. When an LSR forwards a 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 or the lower level label.
TTL can be used not only to prevent routing loops, but to implement the tracert function:
With IP TTL propagation enabled at ingress, whenever a packet passes a hop along the LSP, its IP
TTL gets decremented by 1. Therefore, the result of tracert will reflect the path along which the
packet has traveled.
With IP TTL propagation disabled at ingress, the IP TTL of a packet does not decrement when the
packet passes a hop along the LSP, and the result of tracert does not show the hops within the
MPLS backbone, as if the ingress and egress were connected directly.

Within an MPLS domain, TTL propagation always occurs between the multi-level labels.
The TTL value of a transmitted local packet is always copied regardless of whether IP TTL
propagation is enabled or not. This ensures that the local administrator can tracert for network test.

1-10
ICMP response
On an MPLS VPN, P routers cannot route VPN packets carried by MPLS. When the TTL of an MPLS
packet expires, an ICMP response will be generated and transported along the LSP until it reaches the
destination router of the LSP, where it is forwarded by IP routing. Such processing increases the
network traffic and the packet forwarding delay.

For description and configuration of P routers, refer to MPLS L3VPN Configuration and MPLS L2VPN
Configuration in the MPLS Volume.

For an MPLS packet with only one level of label, the ICMP response message travels along the IP route
when the TTL expires.
In MPLS, the MPLS control plane is responsible for establishing an LSP. However, it cannot detect the
error when an LSP fails to forward data. This brings difficulty to network maintenance.
MPLS LSP ping and traceroute can be used to detect errors in LSPs and locate nodes with failures in
time. Similar to IP ping and traceroute, MPLS LSP ping and traceroute use MPLS echo requests and
MPLS echo replies to check the availability of LSPs. The MPLS echo request message carries the FEC
information of the LSP to be detected, and is sent along the LSP like other data packets of the FEC.
Thus, the LSP can be checked.
MPLS LSP ping is a tool for checking the validity and availability of an LSP. It uses messages
called MPLS echo requests. In a ping operation, MPLS echo requests are forwarded along an LSP
to the egress, where the control plane confirms that the LSR is the egress of the FEC and responds
with MPLS echo replies. If the ping initiator receives the replies, the LSP is considered perfect for
forwarding data.
MPLS LSP traceroute is a tool for locating LSP errors. By sending MPLS echo requests to the
control plane of each transit LSR, it can determine whether the LSR is really a transit node on the
LSP.

The destination address in the IP header of an MPLS echo request is set to an address on 127.0.0.0/8
(a loopback address of the LSR) and the TTL is set to 1, so as to prevent further forwarding of the
request when the request reaches the egress.

1-11
LDP Overview
Basic Concepts of LDP
The LDP protocol dictates the messages to be used in label distribution and the related processes.
Using LDP, LSRs can map network layer routing information to data link layer switching paths directly
and further establish LSPs. LSPs can be established between both neighboring LSRs and LSRs that
are not directly connected, making label switching possible at all transit nodes on the network.

For detailed description about LDP, refer to RFC 3036 LDP Specification.

LDP peer
Two LSRs with an LDP session established between them and using LDP to exchange label bindings
are called LDP peers, each of which obtains the label bindings of its peer over the LDP session between
them.
LDP session
LDP sessions are used to exchange messages for label binding and releasing.
LDP sessions come in two categories:
Local LDP session: Established between two directly connected LSRs.
Remote LDP session: Established between two indirectly connected LSRs.
LDP message type
There are four types of LDP messages:
Discovery message: Used to declare and maintain the presence of LSRs on a network.
Session message: Used to establish, maintain, and terminate sessions between LDP peers.
Advertisement message: Used to create, alter, or remove label bindings.
Notification message: Used to provide advisory information and to notify errors.
For reliable transport of LDP messages, TCP is used for LDP session messages, advertisement
messages, and notification messages, while UDP is used only for discovery messages.
Label space and LDP identifier
A scope of labels that can be assigned to LDP peers is called a label space. A label space can be per
interface or per platform. A per interface label space is interface-specific, while a per platform label
space is for an entire LSR.
An LDP identifier is used to identify an LSR label space. It is a six-byte numerical value in the format of
<LSR ID>:<Label space ID>, where LSR ID is four-byte long. A label space ID of 1 means that the label
space is per interface, a label space ID of 0 means that the label space is per platform.

1-12

Currently, only per platform label space is supported by S7500E Series Ethernet Switches..

LDP Label Distribution
Figure 1-7 illustrates how LDP distributes labels.
Figure 1-7 Label distribution
LER
LSR A LSR B LSR D LSR C
LSR E LSR F LSR G
LSR H
Ingress Egress
Label request
LSP1
LSP2
Label mapping

In Figure 1-7, B is the upstream LSR of C along LSP 1.
As described previously, there are two label advertisement modes. The main difference between them
is whether the downstream advertises the bindings unsolicitedly or on demand.
The following details the advertisement process in each of the two modes.
DoD mode
In DoD mode, an upstream LSR sends a label request message containing the description of a FEC to
its downstream LSR. After receiving the message, the downstream LSR assigns a label to the FEC,
encapsulates the binding information in a label mapping message and sends the message to the
upstream LSR. However, the time when the downstream LSR sends label binding information depends
on the label distribution control mode that it uses:
In ordered mode, a downstream LSR sends label binding information only after it receives that of its
downstream LSR.
In independent mode, a downstream LSR sends label binding information immediately after it
receives a label request message, no matter whether it has received the label binding information
of its downstream LSR or not.
Usually, an upstream LSR selects its downstream LSR based on the information in its routing table. In
Figure 1-7, all LSRs along LSP 1 work in ordered mode, while LSR F along LSP 2 works in independent
mode.

1-13
DU mode
In DU mode, an LSR advertises label binding information to all its neighboring LSRs unsolicitedly after
the LDP sessions are established. An LSR receiving the label binding information determines how to
process the label binding information based on its label retention mode and routing table information.
Fundamental Operation of LDP
LDP goes through four phases in operation: discovery, session establishment and maintenance, LSP
establishment and maintenance, and session termination.
Discovery
In this phase, an LSR wanting to establish a session sends Hello messages to its neighboring LSRs
periodically, announcing its presence. This way, LSRs can automatically find their peers without manual
configuration.
LDP provides two discovery mechanisms:
Basic discovery mechanism
The basic discovery mechanism is used to discover local LDP peers, that is, LSRs directly connected at
link layer, and to further establish local LDP sessions.
Using this mechanism, an LSR periodically sends LDP link Hello messages in the form of UDP packets
out its interfaces to the multicast address known as all routers on this subnet. An LDP link Hello
message carries information about the LDP identifier of a given interface and some other information.
Receipt of an LDP link Hello message on an interface indicates that a potential LDP peer is connected
to the interface at link layer.
Extended discovery mechanism
The extended discovery mechanism is used to discover remote LDP peers, that is, LSRs that are not
directly connected at link layer, and to further establish remote LDP sessions.
Using this mechanism, an LSR periodically sends LDP targeted Hello messages in the form of UDP
packets to a given IP address.
An LDP targeted Hello message carries information about the LDP identifier of a given LSR and some
other information. Receipt of an LDP targeted Hello message on an LSR indicates that a potential LDP
peer is connected to the LSR at network layer.
At the end of the discovery phase, Hello adjacency is established between LSRs, and LDP is ready to
initiate session establishment.
Session establishment and maintenance
In this phase, LSRs pass through two steps to establish sessions between them:
1) Establishing transport layer connections (that is, TCP connections) between them.
2) Initializing sessions and negotiating session parameters such as the LDP version, label distribution
mode, timers, and label spaces.
After establishing sessions between them, LSRs send Hello messages and Keepalive messages to
maintain those sessions.

1-14
LSP establishment and maintenance
Establishing an LSP is to bind FECs with labels and notify adjacent LSRs of the bindings. This is
implemented by LDP. The following gives the primary steps when LDP works in DU mode and ordered
mode:
1) When the network topology changes and an LER finds in its routing table a new destination
address that does not correspond to any existing FEC, the LER creates a new FEC for the
destination address.
2) If the LER has upstream LSRs and has at least one free label, it assigns a label to the FEC and
sends the label binding information to the upstream LSRs.
3) Upon receiving the label binding information, an upstream LSR records the binding. Then, if the
LSR which sent the binding information is the next hop of the FEC, it adds an entry in its LFIB,
assigns a label to the FEC, and sends the new label binding information to its own upstream LSRs.
4) When the ingress LER receives the label binding message, it adds an entry in its LFIB. Thus, an
LSP is established for the FEC, and packets of the FEC can be label switched along the LSP.
Session termination
LDP checks Hello messages to determine adjacency and checks Keepalive messages to determine the
integrity of sessions.
LDP uses different timers for adjacency and session maintenance:
Hello timer: 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 its peer in a Hello interval, it
removes the Hello adjacency.
Keepalive timer: LDP peers keep LDP sessions by periodically sending Keepalive messages over
LDP session connections. If an LSR does not receive any Keepalive message from its peer during
a Keepalive interval, it closes the connection and terminates the LDP session.
LDP Loop Detection
LSPs established in an MPLS domain may be looping. The LDP loop detection mechanism can detect
looping LSPs and prevent LDP messages from looping forever.
For the LDP loop detection mechanism to work, all LSRs must have the same LDP loop detection
configuration. However, establishing an LDP session does not require that the LDP loop detection
configuration on the LDP peers be the same.
LDP loop detection can be in either of the following two modes:
Maximum hop count
A label request message or label mapping message may contain 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 the attempt to establish an LSP fails.
Path vector
A label request message or label mapping message may contain 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
to see whether its MPLS LSR ID is in the list. If either of the following cases occurs, the attempt to
establish an LSP fails:
The MPLS LSR ID of the LSR is already in the path vector list.

1-15
The hop count of the path reaches the specified limit.
If the LSR does not find its MPLS LSR ID in the path vector list, it adds the ID into the list.
LDP GR

For details about Graceful Restart (GR), refer to GR Configuration in the System Volume.

During MPLS LDP session establishment, the LDP peers need to perform Fault Tolerance (FT) and GR
capability negotiation. Only when both devices support GR, can the established session be FT/GR
capable. To support GR, a GR device must backup the FECs and label information.
When an LDP session is GR capable:
1) Whenever the GR restarter restarts, a GR helper will detect that the related LDP session is down
and will keep its neighborship with the GR restarter and retain information about the session until
the reconnect timer times out.
2) If the GR helper receives a session request from the GR restarter before the reconnect timer times
out, it retains the LSP and label information of the session and restores the session with the GR
restarter. Otherwise, it deletes all LSP and label information associated with the session.
3) After the session recovers, the GR restarter and helper activate the neighbor liveness timers and
recovery timers, restore all LSP information related to the session, and send to each other label
mapping and label request messages.
4) Upon receipt of the mapping messages from each other, the GR restarter and helper delete the
LSP stale flag. After the neighbor liveness timer and recovery timer time out, the GR restarter and
helper will delete all LSP information of the session.
To summarize, during a GR recover, the LSP information is preserved for the forwarding plane and
therefore MPLS packets can be forwarded without interruption.
Configuring MPLS Basic Capability
You need to configure MPLS basic capability on all routers for MPLS forwarding within an MPLS domain,
and to configure MPLS basic capability before configuring any other MPLS features.

Currently, only VLAN-interface supports MPLS capability.

Configuration Prerequisites
Before configuring MPLS basic capability, be sure to complete these tasks:
Configuring physical parameters on relevant interfaces,
Configuring link layer attributes on relevant interfaces,

1-16
Assigning IP addresses to relevant interfaces,
Configuring static routes or an IGP protocol, ensuring that LSRs can reach each other at Layer 3.

MPLS basic capability can be configured on LSRs even when LSRs cannot reach each other. However,
you need to configure the mpls ldp transport-address command in this case.

Configuration Procedure
Follow these steps to configure MPLS basic capability:
To do Use the command Remarks
Enter system view system-view
Configure the MPLS LSR ID mpls lsr-id lsr-id
Required
Not configured by default
Enable MPLS globally and
enter MPLS view
mpls
Required
Not enabled by default
Exit to system view quit
Enter interface view
interface interface-type
interface-number

Enable MPLS for the interface mpls
Required

An MPLS LSR ID is in the format of an IP address and must be unique within an MPLS domain.
You are recommended to use the IP address of a loopback interface on an LSR as the MPLS LSR
ID.
At present, the S7500E series switches support enabling MPLS on only VLAN interfaces.
As MPLS will encapsulate original packets with single layer or multiple layers of labels, after
enabling MPLS on the VLAN interface of a VLAN, you are recommended to enable the jumboframe
function on the ports of the VLAN and configure a proper jumbo frame length to prevent packets
from being dropped due to size limit. For example, if two layers of MPLS labels are required for
encapsulating FTP packets, you need to configure the jumbo frame length on related ports to 1544
bytes: 1518 bytes for the FTP packet + 4 bytes 2 for the MPLS labels + 4 bytes for the VLAN tag
+ 14 bytes for the Ethernet frame header. For descriptions of the jumboframe function, refer to
Ethernet Interface Configuration in the Access Volume.

1-17
Configuring PHP
Configure PHP on an egress and select the type of labels for the egress to distribute based on whether
the penultimate hop supports PHP.
Before configuring PHP, be sure to complete the following task: Configuring MPLS basic capability on
all LSRs.
According to RFC 3032 MPLS Label Stack Encoding:
A label value of 0 represents an IPv4 explicit null label and is valid only when it appears at the
bottom of a label stack.
A label value of 3 represents an implicit null label and never appears in the label stack. When an
LSR finds that it is assigned an implicit null label, it directly performs a pop operation, rather than
substitutes the implicit null label for the original label at the stack top.
Follow these steps to configure PHP:
Enter MPLS view mpls
Configure the egress to
support PHP and specify
the type of the label to be
distributed to the
penultimate hop
label advertise
{ explicit-null |
implicit-null | non-null }
Optional
By default, an egress supports PHP
and distributes to the penultimate hop
an implicit null label.
Note that you must reset LDP sessions
for the configuration to take effect.

For the S7500E series Ethernet switches, a label with a value of 0 can be at the top of a label stack.
After receiving a packet with such a label, the switch will pop the label directly and check whether there
is any inner layer label. If finding an inner layer label, the switch will forward the packet based on the
inner layer label; otherwise, the switch will forward the packet based on the IP address.

Configuring a Static LSP
An LSP can be static or dynamic. A static LSP is manually configured, while a dynamic LSP is
established by MPLS LDP.
For a static LSP to work, all LSRs along the LSP must be configured properly.
Static LSPs can be used in MPLS L2VPN.

1-18

For configuration of MPLS L2VPN, refer to MPLS L2VPN Configuration in the MPLS Volume.

Before configuring a static LSP, be sure to complete these tasks:
Determining the ingress, transit LSRs, and egress for the static LSP,
Configuring MPLS basic capability on all the LSRs.
Follow these steps to configure a static LSP:
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 out-label out-label
Optional
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 out-label out-label
Optional
the current LSR as the egress
static-lsp egress lsp-name
incoming-interface interface-type
interface-number in-label in-label
Optional

The value of the next-hop-addr argument cannot be any local public network IP address.
If you specify the next hop when configuring a static LSP, and the address of the next hop is
present in the routing table, you also need to specify the next hop when configuring the static IP
route.
For information about configuring a static IP route, refer to Static Routing Configuration in the IP
Routing Volume.

Configuring MPLS LDP
Before configuring LDP, be sure to complete the following task:
Configuring MPLS basic capability.

1-19
MPLS LDP Configuration Task List
Complete the following tasks to configure LDP:
Task Remarks
Configuring MPLS LDP Capability Required
Configuring Local LDP Session Parameters Optional
Configuring Remote LDP Session Parameters 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 MPLS LDP Capability
Follow these steps to configure MPLS LDP capability:
Enable LDP capability globally
and enter MPLS LDP view
mpls ldp
Required
Configure the LDP LSR ID lsr-id lsr-id
Optional
MPLS LSR ID of the LSR by default
Exit to system view quit
interface-number

Enable LDP capability for the
interface
mpls ldp
Required

Currently, only VLAN-interface supports LDP capability.
Disabling LDP on an interface terminates all LDP sessions on the interface. As a result, all LSPs
using the sessions will be deleted.
Usually, you do not need to configure the LDP LSR ID, which defaults to the MPLS LSR ID. In
some VPN applications (for example, MPLS L3VPN applications), however, you need to ensure
that different LDP instances have different LDP LSR IDs if the address spaces overlap. Otherwise,
the TCP connections cannot be established normally.

1-20
Configuring Local LDP Session Parameters
You can configure a local session transport address to be the IP address of an interface or a specified IP
address.
Follow these steps to configure local LDP session parameters:
interface-number

Set the link Hello timer
mpls ldp timer hello-hold
value
Optional
15 seconds by default
Set the link Keepalive timer
mpls ldp timer
keepalive-hold value
Optional
Configure the LDP transport
address
mpls ldp transport-address
{ ip-address | interface }
Optional
MPLS LSR ID of the LSR by
default

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 device. Otherwise, the LDP sessions cannot be established.

Configuring Remote LDP Session Parameters
Configure a remote session transport address by specifying an IP address.
Follow these steps to configure remote LDP session parameters:
Create a remote peer entity and
enter MPLS LDP remote peer
view
mpls ldp remote-peer
remote-peer-name
Required
Configure the remote peer IP
address
remote-ip ip-address Required
Set the targeted Hello timer
mpls ldp timer hello-hold
value
Optional
Set the targeted Keepalive
timer
mpls ldp timer
keepalive-hold value
Optional
Configure the transport
address
mpls ldp transport-address
ip-address
Optional
default

1-21

In the current implementation, LDP itself does not send any label information through remote sessions,
and remote sessions are used only to transfer messages for L2VPNs. For applications of remote
sessions, refer to information about Martini MPLS L2VPN configuration in MPLS L2VPN Configuration
of the MPLS Volume.

If Hello adjacency exists between two peers, no remote adjacency can be established between
them. If remote adjacency exists between two peers, you can configure local adjacency for them.
However, the local adjacency can be established only when the transport address and keepalive
settings of the two peers match respectively, in which case the remote adjacency will be removed.
That is, only one remote session or local session can exist between two LSRs, and the local
session takes precedence over the remote session.
The remote peer IP address to be configured must be different from all existing remote peer IP
addresses. Otherwise, the configuration fails.
The IP address specified as the LDP transport address must be the IP address of an interface on
the device.

Configuring the Policy for Triggering LSP Establishment
You can specify the routes that are allowed to trigger the establishment of LSPs:
All static and IGP routes.
Static and IGP routes permitted by an IP address prefix list.
Follow these steps to configure the policy for triggering LSP establishment:
Configure the LSP
establishment triggering policy
lsp-trigger { all | ip-prefix
prefix-name }
Optional
By default, only local loopback
addresses with 32-bit masks can
trigger LDP to establish LSPs.

1-22

For an LSP to be established, an exactly matching routing entry must exist on the LSR. With
loopback addresses using 32-bit masks, only exactly matching host routing entries can trigger LDP
to establish LSPs.
For information about IP address prefix list, refer to Routing Policy Configuration in the IP Routing
Volume.

Configuring the Label Distribution Control Mode
Follow these steps to configure the LDP label distribution control mode:
mpls ldp Required
Specify the label distribution
control mode
label-distribution
{ independent | ordered }
Optional
Ordered by default
Note that you need to reset
LDP sessions for this command
to take effect.
Enable label readvertisement
for DU mode
du-readvertise
Optional
Enabled by default
Set the interval for label
readvertisement in DU mode
du-readvertise timer value
Optional

Configuring LDP Loop Detection
Follow these steps to configure LDP loop detection:
mpls ldp Required
Enable loop detection loop-detect
Required
Disabled by default
Set the maximum hop count hops-count hop-number
Optional
32 by default
Set the maximum path vector
length
path-vectors pv-number
Optional
32 by default

1-23

Changing the loop detection configurations does not affect existing LSPs.

You need to configure loop detection before enabling LDP capability on any interface.

Configuring LDP MD5 Authentication
To improve the security of LDP sessions, you can configure MD5 authentication for the underlying TCP
connections.
Follow these steps to configure LDP MD5 authentication:
mpls ldp Required
Enable LDP MD5
authentication and set the
password
md5-password { cipher |
plain } peer-lsr-id password
Required
Disabled by default

Configuring LDP Instances
LDP instances are for carriers carrier networking applications of MPLS L3VPN. You need to configure
LDP capability for existing VPN instances.
Except for the command for the LDP GR feature, all commands available in MPLS LDP view can be
configured in MPLS LDP VPN instance view.
Before configuring LDP instances, be sure to complete these tasks:
Configuring VPN instances,
Configuring MPLS basic capability,
Configuring MPLS LDP capability.
Usually, you do not need to configure the LDP LSR ID, which defaults to the MPLS LSR ID. In some
VPN applications (for example, MPLS L3VPN applications), however, you need to ensure that different
LDP instances have different LDP LSR IDs if the address spaces overlap. Otherwise, the TCP
connections cannot be established normally.
Follow these steps to configure LDP instances:

1-24
Enable LDP capability for a
VPN instance and enter MPLS
LDP VPN instance view
mpls ldp vpn-instance
vpn-instance-name
Required
Configure the LDP LSR ID for
the VPN instance
lsr-id lsr-id
Optional
default

Configurations in MPLS LDP VPN instance view affect only LDP-enabled interfaces bound to the
VPN instances, while configurations in MPLS LDP view do not affect interfaces bound to VPN
instances. When configuring the transport address of an LDP instance, you need to use the IP
address of the interface bound to the VPN instance.
By default, LDP adjacencies on a private network are established using addresses of the
LDP-enabled interfaces, while those on the public network are established using the LDP LSR ID.

Configuring LDP GR
Before configuring LDP GR, be sure to complete this task:
Configuring MPLS LDP capability on each device to be the GR restarter or a GR helper.

The S7500E Series Ethernet Switches can act as both a GR restarter and a GR helper.

Follow these steps to configure LDP GR:
Enter MPLS LDP view mpls ldp
Enable MPLS LDP GR graceful-restart
Required
Disabled by default
Set the FT reconnect timer
graceful-restart timer
reconnect timer
Optional

1-25
Set the LDP neighbor liveness
timer
neighbor-liveness timer
Optional
Set the LDP recovery timer
recovery timer
Optional

During MPLS LDP GR, a GR helper takes the lesser one between its LDP neighbor liveness time and
the GR restarters FT reconnect time as its FT reconnect interval, and takes the lesser one between its
LDP recovery time and that of the GR restarter as its LDP recovery interval.

Restarting MPLS LDP Gracefully
To test MPLS LDP GR without main/backup switchover, you can restart MPLS LDP gracefully. You are
not recommended to perform this operation in normal cases.
Follow these steps to restart MPLS LDP gracefully:
Restart MPLS LDP gracefully graceful-restart mpls ldp
Required
Available in user view

Configuring MPLS IP TTL Processing
Before configuring MPLS IP TTL propagation, be sure to complete this task:
Configuring MPLS basic capability.
Configuring MPLS IP TTL Propagation
Follow these steps to configure IP TTL propagation of MPLS:
Enter MPLS view mpls Required
Enable MPLS IP TTL
propagation
ttl propagate { public | vpn }
Optional
Enabled for only public
network packets by default

1-26

The ttl propagate command affects only the propagation of the IP TTL to the TTL in an MPLS label.
At egress, the system uses the smaller one between the IP TTL and MPLS TTL as the TTL of the IP
packet and decrements the value by 1.
If you enable MPLS IP TTL propagation for VPN packets on one LSR, you are recommended to do
so on all related PEs as well, guaranteeing that you can get the same result when tracerting from
those PEs.

Specifying the Type of the Paths for ICMP Responses
ICMP responses can use two kinds of paths: IP route and LSP.
For MPLS packets with one-level of labels, you can configure MPLS to send back ICMP responses
along IP routes instead of LSPs when the TTL expires.
In MPLS, an IP router generally maintains public network routes only, and MPLS packets with one-level
of labels carry public network payload. Therefore, you can configure this function.
In MPLS VPN, for autonomous system border routers (ASBRs), MPLS packets that carry VPN packets
may have only one-level of labels. To tracert the VPN packets on public networks in this case, you need
to:
Configure the ttl propagate vpn command on all relevant PEs to allow IP TTL propagation of VPN
packets.
Configure the undo ttl expiration pop command on the ASBRs to assure that ICMP responses
can travel along the original LSPs.
Follow these steps to specify the type of the paths for ICMP responses:
Specify that ICMP responses
travel along the IP route when
the TTL of an MPLS packet
expires
ttl expiration pop
Specify that ICMP responses
travel along the LSP when the
TTL of an MPLS packet expires
undo ttl expiration pop
Optional
Configure one of them as
required.
By default, ICMP response
messages of an MPLS packet
with a one-level label stack
travel along the IP route.

Configuring MPLS Statistics
Setting the Interval for Reporting Statistics
To view LSP statistics, you need to set the interval for collecting statistics at first.
Follow these steps to set the interval for collecting statistics:

1-27
Set the interval for collecting
statistics
statistics interval
interval-time
Required
0 seconds by default, meaning that
the system does not collect statistics.

Check the validity and
reachability of an MPLS
LSP
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
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 ]

Enabling MPLS Trap
With the MPLS trap function enabled, trap packets of the notifications level will be generated to report
critical MPLS events. Such trap packets will be sent to the information center of the device. Whether
and where the packets will then be output depend on the configurations of the information center. For
information on how to configure the information center, refer to Information Center Configuration in the
System Volume.
Follow these steps to enable the MPLS trap function:
Enable the MPLS trap function snmp-agent trap enable mpls
Required
Disabled by default

For detailed information about the snmp-agent trap enable mpls command, refer to the snmp-agent
trap enable command in SNMP Commands of the System Volume.

1-28
Displaying and Maintaining MPLS
Resetting LDP Sessions
If you change any LDP session parameters when the sessions are up, the LDP sessions will not be able
to function normally. In this case, you need to reset LDP sessions so that the LDP peers renegotiate
parameters and establish new sessions. Use one of the following commands to reset LDP sessions:
Reset LDP sessions
reset mpls ldp [ all | [ vpn-instance
vpn-instance-name ] [ fec mask |
peer peer-id ] ]

Displaying MPLS Operation
Display information about one
or all interfaces with MPLS
enabled
display mpls interface
[ interface-type interface-number ]
[ verbose ]
Display information about ILM
entries
display mpls ilm [ label ] [ slot
slot-number ] [ include text ]
Display information about
specified labels or all labels
display mpls label { label-value1
[ to label-value2 ] | all }
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 | ldp |
static } ] ] [ egress | ingress |
transit ] [ { exclude | include }
dest-addr mask-length ] [ verbose ]
NHLFE entries
display mpls nhlfe [ token ] [ slot
slot-number ] [ include text ]
Display LSP statistics display mpls lsp statistics Available in any view
Display information about static
LSPs
display mpls static-lsp [ lsp-name
lsp-name ] [ { include | exclude }
dest-addr mask-length ] [ verbose ]
Display LSP-related route
information
display mpls route-state
[ dest-addr mask-length ]
Display statistics for all LSPs or
the LSP with a specified index
or name
display mpls statistics lsp { all |
index | name lsp-name }
Display MPLS statistics for one
or all interfaces
display mpls statistics interface
{ interface-type interface-number |
all }

1-29
Displaying MPLS LDP Operation
Display information about LDP
display mpls ldp [ all [ verbose ] [ |
{ begin | exclude | include }
regular-expression ] ]
LDP-enabled interfaces
display mpls ldp interface [ all
[ verbose ] | [ vpn-instance
vpn-instance-name ] [ interface-type
interface-number | verbose ] ] [ |
{ begin | exclude | include }
regular-expression ]
session peers
display mpls ldp peer [ all
vpn-instance-name ] [ peer-id |
verbose ] ] [ | { begin | exclude |
include } regular-expression ]
remote LDP peers
display mpls ldp remote-peer
[ remote-name remote-peer-name ]
[ | { begin | exclude | include }
sessions
display mpls ldp session [ all
vpn-instance-name ] [ peer-id |
verbose ] ] [ | { begin | exclude |
include } regular-expression ]
Display information about LSPs
established by LDP
display mpls ldp lsp [ all |
[ dest-addr mask-length ] ] [ | { begin |
exclude | include }
Display information about a
specified LDP instance
display mpls ldp vpn-instance
vpn-instance-name [ | { begin |
exclude | include }

Clearing MPLS Statistics
Clear MPLS statistics for one or
all MPLS interfaces
reset mpls statistics interface
{ interface-type interface-number |
all }
Clear MPLS statistics for all
LSPs or the LSP with a
specified index or name
reset mpls statistics lsp { index | all
| name lsp-name }

1-30
MPLS Configuration Examples
Example for Configuring LDP Sessions
Network requirements
Switch A, Switch B, and Switch C support MPLS and use OSPF as the IGP for the MPLS
backbone.
Local LDP sessions are established between Switch A and Switch B as well as between Switch B
and Switch C, while a remote LDP session is required between Switch A and Switch C.
Network diagram
Figure 1-8 Network diagram for configuring LDP sessions

Configuration procedure
1) Configure the IP addresses of the interfaces
Configure the IP addresses and masks of the interfaces including the VLAN interfaces and loopback
interfaces as required in Figure 1-8. The detailed configuration procedure is omitted here.
2) Configure the routes for OSPF to advertise
# Configure Switch A.
<Sysname> syst em- vi ew
[ Sysname] sysname Swi t chA
[ Swi t chA] ospf
[ Swi t chA- ospf - 1] ar ea 0
[ Swi t chA- ospf - 1- ar ea- 0. 0. 0. 0] net wor k 1. 1. 1. 9 0. 0. 0. 0
[ Swi t chA- ospf - 1- ar ea- 0. 0. 0. 0] net wor k 10. 1. 1. 0 0. 0. 0. 255
[ Swi t chA- ospf - 1- ar ea- 0. 0. 0. 0] qui t
[ Swi t chA- ospf - 1] qui t
# Configure Switch B.
[ Sysname] sysname Swi t chB
[ Swi t chB] ospf
[ Swi t chB- ospf - 1] ar ea 0
[ Swi t chB- ospf - 1- ar ea- 0. 0. 0. 0] net wor k 2. 2. 2. 9 0. 0. 0. 0
[ Swi t chB- ospf - 1- ar ea- 0. 0. 0. 0] qui t
[ Swi t chB- ospf - 1] qui t
# Configure Switch C.

1-31
[ Sysname] sysname Swi t chC
[ Swi t chC] ospf
[ Swi t chC- ospf - 1] ar ea 0
[ Swi t chC- ospf - 1- ar ea- 0. 0. 0. 0] net wor k 3. 3. 3. 9 0. 0. 0. 0
[ Swi t chC- ospf - 1- ar ea- 0. 0. 0. 0] net wor k 20. 1. 1. 0 0. 0. 0. 255
[ Swi t chC- ospf - 1- ar ea- 0. 0. 0. 0] qui t
[ Swi t chC- ospf - 1] qui t
After completing the above configurations, you will see that every switch has learned the routes to other
switches if you execute the display ip routing-table command. The following takes Switch A as an
example:
[ Swi t chA] di spl ay i p r out i ng- t abl e
Rout i ng Tabl es: Publ i c
Dest i nat i ons : 9 Rout es : 9
Dest i nat i on/ Mask Pr ot o Pr e Cost Next Hop I nt er f ace
1. 1. 1. 9/ 32 Di r ect 0 0 127. 0. 0. 1 I nLoop0
2. 2. 2. 9/ 32 OSPF 10 1563 10. 1. 1. 2 Vl an1
3. 3. 3. 9/ 32 OSPF 10 3125 10. 1. 1. 2 Vl an1
10. 1. 1. 0/ 24 Di r ect 0 0 10. 1. 1. 1 Vl an1
10. 1. 1. 1/ 32 Di r ect 0 0 127. 0. 0. 1 I nLoop0
10. 1. 1. 2/ 32 Di r ect 0 0 10. 1. 1. 2 Vl an1
20. 1. 1. 0/ 24 OSPF 10 3124 10. 1. 1. 2 Vl an1
127. 0. 0. 0/ 8 Di r ect 0 0 127. 0. 0. 1 I nLoop0
127. 0. 0. 1/ 32 Di r ect 0 0 127. 0. 0. 1 I nLoop0
Now, OSPF adjacency should have been established between Switch A and Switch B and between
Switch B and Switch C respectively. If you execute the display ospf peer verbose command, you will
find that the neighbors are in the state of Full. The following takes Switch A as an example:
[ Swi t chA] di spl ay ospf peer ver bose
OSPF Pr ocess 1 wi t h Swi t ch I D 1. 1. 1. 9
Nei ghbor s
Ar ea 0. 0. 0. 0 i nt er f ace 10. 1. 1. 1( Vl an- i nt er f ace1) ' s nei ghbor s
Rout er I D: 2. 2. 2. 9 Addr ess: 10. 1. 1. 2 GR St at e: Nor mal
St at e: Ful l Mode: Nbr i s Mast er Pr i or i t y: 1
DR: None BDR: None MTU: 1500
Dead t i mer due i n 39 sec
Nei ghbor i s up f or 00: 02: 13
Aut hent i cat i on Sequence: [ 0 ]
3) Configure MPLS basic capability and enable LDP
[ Swi t chA] mpl s l sr - i d 1. 1. 1. 9
[ Swi t chA] mpl s
[ Swi t chA- mpl s] qui t
[ Swi t chA] mpl s l dp
[ Swi t chA- mpl s- l dp] qui t
[ Swi t chA] i nt er f ace vl an- i nt er f ace 1
[ Swi t chA- Vl an- i nt er f ace1] mpl s

1-32
[ Swi t chA- Vl an- i nt er f ace1] mpl s l dp
[ Swi t chA- Vl an- i nt er f ace1] qui t
[ Swi t chB] mpl s l sr - i d 2. 2. 2. 9
[ Swi t chB] mpl s
[ Swi t chB- mpl s] qui t
[ Swi t chB] mpl s l dp
[ Swi t chB- mpl s- l dp] qui t
[ Swi t chB] i nt er f ace vl an- i nt er f ace 1
[ Swi t chB- Vl an- i nt er f ace1] mpl s
[ Swi t chB- Vl an- i nt er f ace1] mpl s l dp
[ Swi t chB- Vl an- i nt er f ace1] qui t
[ Swi t chB] i nt er f ace vl an- i nt er f ace 2
[ Swi t chB- Vl an- i nt er f ace2] mpl s
[ Swi t chB- Vl an- i nt er f ace2] mpl s l dp
[ Swi t chB- Vl an- i nt er f ace2] qui t
[ Swi t chC] mpl s l sr - i d 1. 1. 1. 9
[ Swi t chC] mpl s
[ Swi t chC- mpl s] qui t
[ Swi t chC] mpl s l dp
[ Swi t chC- mpl s- l dp] qui t
[ Swi t chC] i nt er f ace vl an- i nt er f ace 1
[ Swi t chC- Vl an- i nt er f ace1] mpl s
[ Swi t chC- Vl an- i nt er f ace1] mpl s l dp
[ Swi t chC- Vl an- i nt er f ace1] qui t
After completing the above configurations, local sessions should have been established between
Switch A and Switch B and between Switch B and Switch C. You can execute the display mpls ldp
session command to check whether the local sessions have been established, or use the display
mpls ldp peer command to check the peers. The following takes Switch A as an example:
[ Swi t chA] di spl ay mpl s l dp sessi on
LDP Sessi on( s) i n Publ i c Net wor k
Tot al number of sessi ons: 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Peer - I D St at us LAM SsnRol e FT MD5 KA- Sent / Rcv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2. 2. 2. 9: 0 Oper at i onal DU Passi ve Of f Of f 5/ 5
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LAM : Label Adver t i sement Mode FT : Faul t Tol er ance
[ Swi t chA] di spl ay mpl s l dp peer
LDP Peer I nf or mat i on i n Publ i c net wor k
Tot al number of peer s: 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Peer - I D Tr anspor t - Addr ess Di scover y- Sour ce
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2. 2. 2. 9: 0 2. 2. 2. 9 Vl an- i nt er f ace1

1-33
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4) Configure the remote LDP session
[ Swi t chA] mpl s l dp r emot e- peer peer c
[ Swi t chA- mpl s- l dp- r emot e- peer c] r emot e- i p 3. 3. 3. 9
[ Swi t chA- mpl s- l dp- r emot e- peer c] qui t
[ Swi t chC] mpl s l dp r emot e- peer peer a
[ Swi t chC- mpl s- l dp- r emot e- peer a] r emot e- i p 1. 1. 1. 9
[ Swi t chC- mpl s- l dp- r emot e- peer a] qui t
After completing the above configurations, you will find by issuing the following commands on Switch A
that the remote LDP session with Switch C is already established:
[ Swi t chA] di spl ay mpl s l dp sessi on
LDP Sessi on( s) i n Publ i c Net wor k
Tot al number of sessi ons: 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Peer - I D St at us LAM SsnRol e FT MD5 KA- Sent / Rcv
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LAM : Label Adver t i sement Mode FT : Faul t Tol er ance
[ Swi t chA] di spl ay mpl s l dp peer
LDP Peer I nf or mat i on i n Publ i c net wor k
Tot al number of peer s: 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Peer - I D Tr anspor t - Addr ess Di scover y- Sour ce
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2. 2. 2. 9: 0 2. 2. 2. 9 Vl an- i nt er f ace1
3. 3. 3. 9: 0 3. 3. 3. 9 Remot e Peer : peer c
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Example for Configuring LDP to Establish LSPs
Network requirements
On the network in Figure 1-8, an LSP is required between Switch A and Switch C. Check the validity and
reachability of the LSP.
Network diagram
See Figure 1-8.
Configuration procedure
1) Configure LDP sessions. Refer to Example for Configuring LDP Sessions .
2) Configure the LSP establishment triggering policy for LDP to establish LSPs.

1-34

For LDP to establish an LSP, LDP sessions are required between neighboring routers along the LSP. In
Figure 1-8, an LDP LSP can be established from Switch A to Switch C provided that local LDP sessions
exist between Switch A and Switch B, and between Switch B and Switch C; no remote LDP session is
required between Switch A and Switch C.

[ Swi t chA] mpl s
[ Swi t chA- mpl s] l sp- t r i gger al l
[ Swi t chA- mpl s] r et ur n
[ Swi t chB] mpl s
[ Swi t chB- mpl s] l sp- t r i gger al l
[ Swi t chB- mpl s] qui t
[ Swi t chC] mpl s
[ Swi t chC- mpl s] l sp- t r i gger al l
[ Swi t chC- mpl s] qui t
After completing the above configurations, you will see that the LSPs have been established if you
execute the display mpls ldp lsp command. The following takes Switch A as an example:
<Swi t chA> di spl ay mpl s l dp l sp
LDP LSP I nf or mat i on
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SN Dest Addr ess/ Mask I n/ Out Label Next - Hop I n/ Out - I nt er f ace
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 1. 1. 1. 9/ 32 3/ NULL 127. 0. 0. 1 Vl an1/ I nLoop0
2 2. 2. 2. 9/ 32 NULL/ 3 10. 1. 1. 2 - - - - / Vl an1
3 3. 3. 3. 9/ 32 NULL/ 1025 10. 1. 1. 2 - - - - / Vl an1
4 20. 1. 1. 0/ 24 NULL/ 3 10. 1. 1. 2 - - - - / Vl an1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A ' *' bef or e an LSP means t he LSP i s not est abl i shed
A ' *' bef or e a Label means t he USCB or DSCB i s st al e
# Check the validity and reachability of the LSP.
<Swi t chA> pi ng l sp i pv4 3. 3. 3. 9 32
LSP PI NG FEC: LDP I PV4 PREFI X 3. 3. 3. 9/ 32 : 100 dat a byt es, pr ess CTRL_C t o br eak
Repl y f r om20. 1. 1. 2: byt es=100 Sequence=1 t i me = 1 ms

- - - FEC: LDP I PV4 PREFI X 3. 3. 3. 9/ 32 pi ng st at i st i cs - - -
5 packet ( s) t r ansmi t t ed

1-35
5 packet ( s) r ecei ved
0. 00%packet l oss
r ound- t r i p mi n/ avg/ max = 1/ 1/ 1 ms

02-MPLS Basics Configuration PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

02-MPLS Basics Configuration PDF

Cargado por

Copyright:

Formatos disponibles

i

También podría gustarte