02-MPLS_Basics_Configuration.pdf

8/10/2019 02-MPLS_Basics_Configuration.pdf

1/37

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 GR 1-15

Configuring MPLS Basic Capability 1-15

Configuration Prerequisites1-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


2/37

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 MPLS 1-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 Sessions1-30

Example for Configuring LDP to Establish LSPs 1-33


3/37

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

Configurationin 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.


4/37

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-1illustrates 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. 1indicates 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-2shows the place of a label in a packet.


5/37

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 protoco l

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.


6/37

1-4

For information about BGP, refer to BGP Configuration in theIP 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 in Figure 1-3is 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, whileLERs 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.


7/37

1-5

Figure 1-4 Structure of the MPLS network

Ingress

LSPEgress

Transit

IP networkIP 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.


8/37

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.

Appl ications 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.


9/37

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-6shows 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 implementedby 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 downstreamLSR 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.


10/37

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.


11/37

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 inArchitecture 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 topby 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.


12/37

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 Configurationand MPLS L2VPN

Configurationin 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.


13/37

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

:, 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.


14/37

1-12

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

LDP Label Distribut ion

Figure 1-7illustrates how LDP distributes labels.

Figure 1-7 Label distribution

LER

LSR A LSR B LSR DLSR 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.


15/37

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.


16/37

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.


17/37

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 Configurationin 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,


18/37

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-addresscommand 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-idRequired

Not configured by default

Enable MPLS globally andenter MPLS view

mplsRequired

Not enabled by default

Exit to system view quit

Enter interface viewinterface interface-typeinterface-number

Enable MPLS for the interface mplsRequired


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, afterenabling 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 Configurationin theAccess Volume.


19/37

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 tosupport PHP and specifythe type of the label to be

distributed to thepenultimate hop

label advertise{ explicit-null|

implicit-null | non-null}

Optional

By default, an egress supports PHPand distributes to the penultimate hop

an implicit null label.Note that you must reset LDP sessionsfor 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.


20/37

1-18

For configuration of MPLS L2VPN, refer to MPLS L2VPN Configurationin 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 takingthe current LSR as the ingress

static-lspingresslsp-namedestinationdest-addr{ mask| mask-length} nexthopnext-hop-addrout-label out-label

Optional

Configure a static LSP takingthe current LSR as a transitLSR

static-lsptransitlsp-nameincoming-interfaceinterface-typeinterface-numberin-label in-labelnexthopnext-hop-addrout-label out-label

Optional

Configure a static LSP taking

the current LSR as the egress

static-lsp egress lsp-nameincoming-interfaceinterface-typeinterface-numberin-labelin-label

Optional

The value of the next-hop-addrargument 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 Configurationin the IP

Routing Volume.

Configur ing MPLS LDP


Before configuring LDP, be sure to complete the following task:

Configuring MPLS basic capability.


21/37

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 Capabili ty

Follow these steps to configure MPLS LDP capability:



Enable LDP capability globallyand enter MPLS LDP view

mpls ldpRequired


Configure the LDP LSR ID lsr-idlsr-idOptional

MPLS LSR ID of the LSR by default

Exit to system view quit


Enable LDP capability for theinterface

mpls ldpRequired


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.


22/37

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:




Set the link Hello timermpls ldp timerhello-holdvalue

Optional

15 seconds by default

Set the link Keepalive timermpls ldp timerkeepalive-holdvalue

Optional


Configure the LDP transport

address

mpls ldp transport-address

{ ip-address | interface }

Optional

MPLS LSR ID of the LSR bydefault

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 andenter MPLS LDP remote peer

view

mpls ldp remote-peerremote-peer-name

Required

Configure the remote peer IPaddress

remote-ip ip-address Required

Set the targeted Hello timermpls ldp timerhello-holdvalue

Optional


Set the targeted Keepalivetimer

mpls ldp timerkeepalive-holdvalue

Optional


Configure the transportaddress

mpls ldp transport-addressip-address

Optional

MPLS LSR ID of the LSR by

default


23/37

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 localsession 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 LSPestablishment triggering policy

lsp-trigger{ all | ip-prefixprefix-name}

OptionalBy default, only local loopbackaddresses with 32-bit masks cantrigger LDP to establish LSPs.


24/37

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 Configurationin 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 distributioncontrol mode

label-distribution{ independent| ordered }

Optional

Orderedby default

Note that you need to resetLDP sessions for this commandto take effect.

Enable label readvertisementfor DU mode

du-readvertiseOptional

Enabled by default

Set the interval for labelreadvertisement in DU mode

du-readvertisetimer value Optional30 seconds by default

Configuring LDP Loop Detection

Follow these steps to configure LDP loop detection:




mpls ldp Required

Enable loop detection loop-detectRequired

Disabled by default

Set the maximum hop count hops-count hop-numberOptional

32 by default

Set the maximum path vectorlength

path-vectors pv-numberOptional

32 by default


25/37

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 MD5authentication and set thepassword

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 TCPconnections cannot be established normally.

Follow these steps to configure LDP instances:


26/37

1-24



Enable LDP capability for aVPN instance and enter MPLSLDP VPN instance view

mpls ldpvpn-instancevpn-instance-name

Required

Configure the LDP LSR ID forthe VPN instance lsr-idlsr-id

Optional

MPLS LSR ID of the LSR bydefault

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.

Configur ing 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-restartRequired

Disabled by default

Set the FT reconnect timer graceful-restart timerreconnect timer

Optional300 seconds by default


27/37

1-25


Set the LDP neighbor livenesstimer

graceful-restart timerneighbor-livenesstimer

Optional


Set the LDP recovery timergraceful-restart timerrecovery 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 mp ls ldpRequired

Available in user view

Configur ing 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 TTLpropagation

ttl propagate { public |vpn }

Optional

Enabled for only publicnetwork packets by default


28/37

1-26

The ttl propagatecommand 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 p ropagate vpncommand on all relevant PEs to allow IP TTL propagation of VPN

packets.

Configure the undo ttl expiration popcommand 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 responsestravel along the IP route whenthe TTL of an MPLS packetexpires

ttl expiration pop

Specify that ICMP responsestravel along the LSP when theTTL of an MPLS packet expires

undo ttl expiration pop

Optional

Configure one of them asrequired.

By default, ICMP responsemessages of an MPLS packetwith a one-level label stacktravel 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:


29/37

1-27




Set the interval for collectingstatistics

statistics intervalinterval-time

Required

0 seconds by default, meaning thatthe system does not collect statistics.



Check the validity andreachability of an MPLSLSP

ping lsp [-a source-ip|-c count|-exp exp-value| -h ttl-value|-m wait-time|-r reply-mode|-spacket-size| -t time-out|-v ]*ipv4 dest-addrmask-length [ destination-ip-addr-header]

Available in any view

Locate an MPLS LSPerror

tracert lsp [-a source-ip| -exp exp-value| -httl-value| -r reply-mode |-t time-out]* ipv4dest-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. Forinformation on how to configure the information center, refer to Information Center Configurationin the

System Volume.

Follow these steps to enable the MPLS trap function:



Enable the MPLS trap function snmp-agent trap enable mplsRequired

Disabled by default

For detailed information about the snmp-agent trap enable mpls command, refer to the snmp-agent

trap enablecommand in SNMP Commandsof the System Volume.


30/37

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 sessionsreset mpls ldp [ all | [ vpn-instancevpn-instance-name ] [ fecmask|peerpeer-id ] ]


Displaying MPLS Operation


Display information about oneor all interfaces with MPLSenabled

display mpls interface[ interface-typeinterface-number][ verbose]


Display information about ILMentries

display mpls ilm [label ] [ slotslot-number ] [ includetext]


Display information aboutspecified labels or all labels

display mpls label{ label-value1[ to label-value2] | all }


Display information about LSPs

display mpls lsp[ incoming-interfaceinterface-typeinterface-number ]

[ outgoing-interfaceinterface-typeinterface-number ] [ in-labelin-label-value] [ out-labelout-label-value] [ asbr|[ vpn-instancevpn-instance-name][ protocol{ bgp| bgp-ipv6| ldp|static} ] ] [ egress| ingress|transit] [ { exclude| include}dest-addr mask-length] [ verbose]


Display information aboutNHLFE entries

display mpls nhlfe [token] [ slotslot-number ] [ includetext]


Display LSP statistics display mpls lsp statistics Available in any view

Display information about staticLSPs

display mpls static-lsp[ lsp-namelsp-name] [ { include| exclude}dest-addrmask-length ] [ verbose]


Display LSP-related routeinformation

display mpls route-state[ vpn-instancevpn-instance-name][ dest-addr mask-length]


Display statistics for all LSPs orthe LSP with a specified indexor name

display mpls statisticslsp{ all |index| namelsp-name}


Display MPLS statistics for oneor all interfaces

display mpls statisticsinterface{ interface-typeinterface-number|all }



31/37

1-29

Displaying MPLS LDP Operation


Display information about LDPdisplay mpls ldp[ all [ verbose] [ |{ begin| exclude| include}regular-expression ] ]


Display information aboutLDP-enabled interfaces

display mpls ldp interface[ all [ verbose] | [ vpn-instancevpn-instance-name ] [ interface-typeinterface-number | verbose] ] [ |{ begin| exclude| include}regular-expression ]


Display information about LDPsession peers

display mpls ldp peer [ all [ verbose] | [ vpn-instancevpn-instance-name] [ peer-id|verbose] ] [ |{ begin| exclude|include} regular-expression ]


Display information aboutremote LDP peers

display mpls ldp remote-peer

[ remote-nameremote-peer-name ][ |{ begin| exclude| include}regular-expression ]


Display information about LDPsessions

display mpls ldp session[ all [ verbose] | [ vpn-instancevpn-instance-name] [ peer-id|verbose] ] [ |{ begin| exclude|include} regular-expression ]


Display information about LSPsestablished by LDP

display mpls ldp lsp[ all |[ vpn-instancevpn-instance-name][ dest-addrmask-length] ] [ |{ begin|

exclude| include}regular-expression ]


Display information about aspecified LDP instance

display mpls ldp vpn-instancevpn-instance-name [ |{ begin|exclude| include}regular-expression ]


Clearing MPLS Statistics


Clear MPLS statistics for one orall MPLS interfaces

reset mpls statisticsinterface{ interface-type interface-number |all }


Clear MPLS statistics for allLSPs or the LSP with aspecified index or name

reset mpls statisticslsp{ index|all | namelsp-name}



32/37

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.

syst em- vi ew

[ Sysname] sysname Swi t chA

[ Swi t chA] ospf

[ Swi t chA- ospf - 1] area 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 work 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.

syst em- vi ew

[ Sysname] sysname Swi t chB

[ Swi t chB] ospf

[ Swi t chB- ospf - 1] area 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] net work 10. 1. 1. 0 0. 0. 0. 255

[ Swi t chB- ospf - 1- ar ea- 0. 0. 0. 0] net work 20. 1. 1. 0 0. 0. 0. 255

[ Swi t chB- ospf - 1- ar ea- 0. 0. 0. 0] qui t[ Swi t chB- ospf - 1] qui t

# Configure Switch C.


33/37

1-31

syst em- vi ew

[ Sysname] sysname Swi t chC

[ Swi t chC] ospf

[ Swi t chC- ospf - 1] area 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 work 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-tablecommand. The following takes Switch A as an

example:

[ Swi t chA] di spl ay i p rout i ng- t abl e

Rout i ng Tabl es: Publ i c

Desti nati ons : 9 Rout es : 9

Dest i nat i on/ Mask Prot o Pre Cost Next Hop I nter 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 verbosecommand, 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 Stat e: Normal

St at e: Ful l Mode: Nbr i s Mast er Pri 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 erf ace1] mpl s


34/37

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 erf 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 erf 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 erf ace1] mpl s

[ Swi t chC- Vl an- i nt erf 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 peercommand 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

Total number of sessi ons: 1

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

Peer - I D Stat us LAM SsnRol e FT MD5 KA- Sent / Rcv

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

2. 2. 2. 9: 0 Operat i onal DU Passi ve Of f Of f 5/ 5

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

LAM : Label Advert i sement Mode FT : Faul t Tol erance

[ Swi t chA] di spl ay mpl s l dp peer

LDP Peer I nf ormati on i n Publ i c network

Total number of peers: 1

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

Peer- I D Transpor t - Address Di scovery- Sour ce

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

2. 2. 2. 9: 0 2. 2. 2. 9 Vl an- i nt er f ace1


35/37

1-33

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

4) Configure the remote LDP session


[ Swi t chA] mpl s l dp r emote- peer peer c

[ Swi t chA- mpl s- l dp- r emote- peer c] r emot e-i p 3. 3. 3. 9

[ Swi t chA- mpl s- l dp- r emote- peer c] qui t


[ Swi t chC] mpl s l dp r emote- peer peer a

[ Swi t chC- mpl s- l dp- r emote- peer a] r emot e-i p 1. 1. 1. 9

[ Swi t chC- mpl s- l dp- r emote- 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

Total number of sessi ons: 2

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

Peer - I D Stat us LAM SsnRol e FT MD5 KA- Sent / Rcv

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



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

LAM : Label Advert i sement Mode FT : Faul t Tol erance

[ Swi t chA] di spl ay mpl s l dp peer

LDP Peer I nf ormati on i n Publ i c network

Total number of peers: 2

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

Peer- I D Transpor t - Address Di scovery- 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 Remote 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.


36/37

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 lspcommand. The following takes Switch A as an example:

di spl ay mpl s l dp l sp

LDP LSP I nf ormat i on

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

SN Dest Addr ess/ Mask I n/ OutLabel Next - Hop I n/ Out - I nter 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 ore an LSP means t he LSP i s not est abl i shedA ' *' bef ore a Label means t he USCB or DSCB i s st al e

# Check the validity and reachability of the LSP.

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, press CTRL_C t o br eak

Repl y f r om 20. 1. 1. 2: bytes=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


37/37

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

Documents

02-MPLS_Basics_Configuration.pdf