Table Of Contents
MPLS Label Distribution Protocol
Supported Standards, MIBs, and RFCs
Configuring LDP for all Interfaces
Configuring LDP for a Specific Interface
Saving Configurations: MPLS/Tag Switching Commands
Label Bindings, Label Spaces, and LDP Identifiers
LDP TCP Connections and Session Establishment
Configuring LDP for Packet Interfaces
Configuring LDP for Label-Controlled ATM Interfaces
Configuring LDP for Targeted Sessions
Transitioning a Network from TDP to LDP
debug mpls ldp peer state-machine
debug mpls ldp session state-machine
debug mpls ldp targeted-neighbors
debug mpls ldp transport connections
debug mpls ldp transport events
mpls ip (global configuration)
mpls ip (interface configuration)
mpls label protocol (global configuration)
mpls label protocol (interface configuration)
mpls ldp advertise-labels old-style
mpls ldp discovery transport-address
MPLS Label Distribution Protocol
Feature History
12.0(10)ST
This feature was introduced.
12.0(14)ST
MPLS LDP commands were modified.
12.1(8a)E
This feature was integrated into Cisco IOS Release 12.1(8a)E.
This document describes the use of the MPLS Label Distribution Protocol (LDP) in Cisco IOS Release 12.1(8a)E. MPLS LDP enables peer label switch routers (LSRs) in an MPLS network to exchange label binding information for supporting hop-by-hop forwarding along normally routed paths. This document includes the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
MPLS label distribution protocol (LDP), as standardized by the Internet Engineering Task Force (IETF) and as enabled by Cisco IOS software, allows the construction of highly scalable and flexible IP Virtual Private Networks (VPNs) that support multiple levels of services.
LDP provides a standard methodology for hop-by-hop, or dynamic label, distribution in an MPLS network by assigning labels to routes that have been chosen by the underlying Interior Gateway Protocol (IGP) routing protocols. The resulting labeled paths, called label switch paths or LSPs, forward label traffic across an MPLS backbone to particular destinations. These capabilities enable service providers to implement MPLS-based IP VPNs and IP+ATM services across multivendor MPLS networks.
LDP provides the means for label switching routers (LSRs) to request, distribute, and release label prefix binding information to peer routers in a network. LDP enables LSRs to discover potential peers and to establish LDP sessions with those peers for the purpose of exchanging label binding information.
From an historical and functional standpoint, LDP is a superset of Cisco's prestandard Tag Distribution Protocol (TDP), which also supports MPLS forwarding along normally routed paths. For those features that LDP and TDP share in common, the pattern of protocol exchanges between network routing platforms is identical. The differences between LDP and TDP for those features supported by both protocols are largely embedded in their respective implementation details, such as the encoding of protocol messages, for example.
This release of LDP, which supports both the LDP and TDP protocols, provides the means for transitioning an existing network from a TDP environment to an LDP environment. Thus, you can run LDP and TDP simultaneously on any router platform. The routing protocol that you select can be configured on a per-interface basis for directly connected neighbors and on a per-session basis for nondirectly connected (targeted) neighbors. In addition, a label switch path (LSP) across an MPLS network can be supported by LDP on some hops and by TDP on other hops.
Benefits
LDP is an IETF standards tracking protocol. The primary benefit of LDP over the prestandard TDP protocol is that the former increases the number of platforms on which MPLS interoperability can be achieved.
Related Documents
For additional information about MPLS functionality running on routers or switches in a network, consult the following documentation:
•
Multiprotocol Label Switching on Cisco Routers—This feature, implemented on Cisco routers and ATM switches, combines the performance of Layer 2 (data link layer) switching with the scalability of Layer 3 (network layer) routing. This combination enables service providers to handle the explosive growth now occurring in network utilization and to differentiate services without having to alter the existing network infrastructure. MPLS supports the dynamic creation of different routes between source and destination nodes, thus enabling IP services to be delivered efficiently by means of Internet backbones.
•
MPLS Class of Service—This feature enables network administrators to provide a range of differentiated services across an MPLS network. Such services are implemented by means of an appropriate setting of the IP precedence bit in each transmitted IP packet.
•
MPLS Traffic Engineering and Enhancements—This feature enables an MPLS backbone to replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay networks. In service provider and Internet service provider (ISP) backbones, traffic engineering provides an effective means of managing networks. Such backbones must support high transmission capacities and be resilient to link or node failures.
•
MPLS Egress Netflow Accounting—This feature enables the detection of MPLS and IP flows traveling over links from the provider edge (PE) router to the customer edge (CE) router in a virtual private network (VPN).
•
MPLS Virtual Private Networks (VPNs)—This feature enables users to deploy and administer IPv4 Layer 3, value-added services and business applications across a public network infrastructure. By deploying business applications on a broad scale over wide area networks (WANs), MPLS VPN users can reduce costs, increase revenue, and develop new business opportunities.
Supported Platforms
LDP is supported on the following platforms in Cisco IOS Release 12.1(8a)E:
•
Cisco 7200
•
Cisco 7500 series
Platform Support Through Feature Navigator
Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.
Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.
To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.
Feature Navigator is updated when major Cisco IOS software releases and technology releases occur. As of May 2001, Feature Navigator supports M, T, E, S, and ST releases. You can access Feature Navigator at the following URL:
http://www.cisco.com/go/fn
Supported Standards, MIBs, and RFCs
Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
•
RFC 3036—LDP Applicability
Prerequisites
Label switching on a router requires that Cisco Express Forwarding (CEF) be enabled on that router. Refer to the chapters on CEF in the following documents for configuration information:
•
Cisco IOS Switching Services Configuration Guide, Release 12.1
•
Cisco IOS Switching Services Command Reference, Release 12.1
Configuration Tasks
See the following sections for tasks for configuring LDP to operate in an MPLS network. Each task in the list is identified as either required or optional:
•
Configuring MPLS (required)
•
Configuring LDP for all Interfaces (optional)
•
Configuring LDP for a Specific Interface (optional)
Configuring MPLS
Complete the steps in the table below to configure an MPLS application, such as hop-by-hop forwarding (sometimes called dynamic tag switching or dynamic MPLS), for the desired interfaces:
Note
MPLS requires CEF.
Note
MPLS can be configured globally, as well as for a particular interface.
Note
The mpls ip command is equivalent to the tag-switching ip command. For more information about the mpls ip command, see Table 3.
Note
Targeted sessions are usually not configured explicitly. For example, configuring mpls ip for a traffic engineering tunnel interface initiates establishment of a targeted session with the tunnel tail end.
Configuring LDP for all Interfaces
Complete the steps in the table below to configure LDP for all interfaces:
Command PurposeStep 1
Router# configure terminalEnters configuration mode.
Step 2
Router(config)# mpls label protocol ldpConfigures the use of LDP on all interfaces.
Configuring LDP for a Specific Interface
Complete the steps in the table below to configure LDP for a specific interface:
Verifying LDP Configuration
Step 1
Enter the show mpls interfaces command to verify that the interfaces in question have been configured to use LDP.
Step 2
Enter the show mpls ldp discovery command to verify that the interface is up and sending LDP Discovery Hello messages (as opposed to TDP Hello messages).
Step 3
Enter the show run command to verify the acceptance of the configuration commands.
Note
If you issue the show run command as part of the verification process, be aware that commands you entered by typing mpls . . . may be shown as tag-switching . . . (see the "Saving Configurations: MPLS/Tag Switching Commands" section.)
Saving Configurations: MPLS/Tag Switching Commands
A number of configuration commands with both MPLS and tag switching forms will be supported during the transition from a tag switching environment to a standards-based MPLS environment. For example, the mpls ip command is equivalent to the tag-switching ip command.
Refer to Table 2 and Table 3 in the "CLI Command Summary" section for a complete list of commands related to LDP that have both MPLS and tag switching forms.
For commands that support both MPLS and tag switching forms, the tag switching form will be written to saved configurations during the transition period from TDP to LDP. Suppose, for example, that you configured an LC-ATM interface on a router by means of the following commands:
Router# configure terminalRouter(config)# interface ATM3/0.1 mplsRouter(config-if)# ip unnumbered Loopback0router(config-if)# mpls ipRouter(config-if)# mpls label protocol ldpIn this example, the interface ATM3/0.1 mpls command and the mpls ip command have tag switching forms. After you enter these commands and save this configuration or display the running configuration by means of the show running command, the commands thus saved or displayed would appear as shown below:
interface ATM3/0.1 tag-switchingip unnumbered Loopback0tag-switching ipmpls label protocol ldpWriting the tag switching form of commands with both MPLS and tag switching forms to the saved configuration makes it possible for you to use a router software image that supports LDP to:
•
Modify and write interface configurations
•
At a later time, use interface configurations created by the LDP image with an earlier software version that does not support LDP
For the above example, older software that supports TDP, but not LDP, would be able to interpret all of the interface configuration commands, except for the mpls label protocol command. The older software would generate a warning message about the unrecognized command; nevertheless, the image would bring up the interface configured to run TDP.
Configuration Examples
This section provides the following configuration information:
•
Configuring LDP for Packet Interfaces
•
Configuring LDP for Label-Controlled ATM Interfaces
•
Configuring LDP for Targeted Sessions
LDP Configuration Overview
The next three sections briefly describe aspects of MPLS LDP considered helpful to better understanding the configuration examples that follow later for packet interfaces, LC-ATM interfaces and targeted sessions.
Label Bindings, Label Spaces, and LDP Identifiers
An LDP label binding is an association between a destination prefix and a label. The label used in a label binding is allocated from a set of possible labels called a label space.
LDP supports two types of label spaces:
•
Interface-specific—An interface-specific label space uses interface resources for labels. For example, LC-ATM interfaces use VPIs/VCIs for labels. Depending on its configuration, an LDP platform may support zero, one, or more interface-specific label spaces.
•
Platform-wide—An LDP platform supports a single platform-wide label space for use by interfaces that can share the same labels. For Cisco platforms, all interface types except LC-ATM use the platform-wide label space.
LDP uses a 6-byte quantity called an LDP Identifier (or LDP Id) to name label spaces. The LDP convention is: a) the first four bytes of the LDP Id identify the LSR that owns the label space; and 2) the last two bytes identify the label space within the LSR. For the platform-wide label space, the last two bytes of the LDP Id are always both 0.
The Cisco convention is that the first four bytes of an LDP Id is a platform IP address called the LDP router Id. The last two bytes are called the local label space id. The display representation for an LDP Id takes the following form:
<LDP router Id> : <local label space id>
The following are examples of this form:
133.0.0.33:0, 167.3.0.54:3
The LDP router Id is determined as described below. For purposes of this discussion, "S" represents the set of interfaces that are up and have IP addresses, while "I" represents the interface specified by the mpls ldp router-id command, if any.
a.
If interface I is in S, then the IP address of interface I is the LDP router Id.
b.
Otherwise, if there is a loopback interface in S, the largest IP address of the loopback addresses in S is the LDP router Id.
c.
Otherwise, the largest IP address of the interfaces in S is the LDP router Id.
LDP Discovery
LDP discovery is a mechanism that reduces the amount of per-peer configuration required for LDP by enabling an LSR to discover potential LDP peers.
An LSR engages in discovery by periodically transmitting LDP Hello messages to signal its desire to advertise label bindings. The LSR sends the LDP Hello messages as UDP packets to the well known LDP port (646).
LDP defines two types of discovery which differ slightly from each other:
•
Basic discovery—This type is used to discover directly connected LDP LSRs. For basic discovery, an LSR sends Hellos messages to the "all routers on this subnet" multicast address on interfaces for which LDP has been configured.
•
Extended discovery—This type is used between nondirectly connected LDP LSRs. For extended discovery, an LSR sends targeted Hello messages to a specific IP address.
The Hello messages carry the LDP Id of the label space that the sending LSR wants to advertise, as well as other information.
When an LSR receives an LDP Hello message from another LSR, it considers that LSR and the specified label space to be "discovered." After two LSRs discover each other in this manner, they attempt to establish an LDP session (as described in the next section).
LDP TCP Connections and Session Establishment
LDP label distribution between two LSRs requires establishment of an LDP session. LSRs that have discovered each other establish an LDP session by:
•
Opening a TCP connection to be used to distribute label bindings.
For Cisco platforms, an LSR will use either its LDP router Id or the IP source address of its discovery Hello messages as the IP address for its endpoint of the TCP connection. The address it intends to use is specified to its LSR peer in the Hello messages it sends.
To establish the TCP connection, each LSR must have IP connectivity (that is, a route) to the IP address for the other LSR's endpoint for the connection.
•
Negotiating parameters for the LDP session.
Such parameters include the label distribution method (Downstream Unsolicited or Downstream on Demand) and other parameters.
After successfully opening the session TCP connection and agreeing to parameters for the session, LDP label distribution begins.
Configuring LDP for Packet Interfaces
Figure 1 shows a sample network for configuring the use of LDP for packet interfaces.
Note
ATM point-to-point subinterfaces are considered "packet" interfaces when configuring LDP. ATM MPLS subinterfaces (and tag switching subinterfaces) are considered label-controlled ATM (LC-ATM) interfaces when configuring LDP (see the next section).
The three router configurations that follow accomplish the following:
•
Enable MPLS hop-by-hop forwarding for the POS links between Router 1 and Router 2 and between Router 1 and Router 3.
•
Configure the use of LDP for label distribution between Router 1 and Router 2.
•
Configure the use of TDP (the default) for label distribution between Router 1 and Router 3.
•
Configure a loopback interface and IP address for each LSR that can be used as the LDP router Id component of the LSR LDP Id.
Figure 1 Configuration of LDP for Packet Interfaces
Note
The configuration examples below show only the commands related to configuring LDP for Router 1, Router 2, and Router 3 in the sample network shown in Figure 1.
Router 1 Configuration
ip cef distributed !Assumes R1 supports distributed CEFinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.11 255.255.255.255interface POS3/0/0ip address 34.0.0.44 255.0.0.0mpls ip !Enable hop-by-hop MPLS forwardingmpls label protocol ldp !Use LDP for this interfaceinterface POS3/0/1ip address 45.0.0.44 255.0.0.0mpls ip !Enable hop-by-hop MPLS forwarding!Uses TDP (the default)Router 2 Configuration
ip cef distributed !Assumes R2 supports distributed CEFinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.22 255.255.255.255interface POS2/0/0ip address 34.0.0.33 255.0.0.0mpls ip !Enable hop-by-hop MPLS forwardingmpls label protocol ldp !Use LDP for this interfaceRouter 3 Configuration
ip cef !Assumes R3 does not support!distributed CEFinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.33 255.255.255.255interface POS1/0ip address 45.0.0.55 255.0.0.0mpls ip !Enable hop-by-hop MPLS forwarding!Uses TDP (the default)The LDP configuration for Router 1 uses the interface mpls label protocol ldp command because some of its interfaces use LDP and some use TDP.
Another way to configure Router 1 is to use the global mpls label protocol ldp command to configure LDP as the default protocol for interfaces and use the interface mpls label protocol tdp command to configure TDP for the POS3/0/1 link to Router 3. This alternative way to configure Router 1 is shown below:
Router 1 Configuration
ip cef distributed !Assumes R1 supports distributed CEFmpls label protocol ldp !Use LDP for the default protocolinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.11 255.255.255.255interface POS3/0/0ip address 34.0.0.44 255.0.0.0mpls ip !Enable hop-by-hop MPLS forwarding!Use LDP (configured i/f default)interface POS3/0/1ip address 45.0.0.44 255.0.0.0mpls ip !Enable hop-by-hop MPLS forwardingmpls label protocol tdp !Use TDP for this interfaceThe configuration of Router 2 also uses the interface mpls label protocol ldp command. If all of its interfaces are to use LDP, then the global mpls label protocol ldp could be used without any interface mpls label protocol commands.
Note
Use of the mpls ip command on an interface triggers the transmission of discovery Hello messages for the interface.
Note
When two platforms are directly connected by multiple packet links, the same label distribution protocol (LDP or TDP) must be configured for all of the packet interfaces connecting the platforms.
Note
If a loopback IP address has been configured, it will be selected as the router Id component of the local LDP Id unless the loopback interface has been explicitly shut down or the mpls ldp router-id command has been used to specify that some other interface should be preferred when determining the LDP router Id. Configuring a loopback interface and IP address on each router is not a requirement for LDP; however, doing so helps ensure a stable LDP Id for the router because the state of loopback addresses does not change, except in response to explicit configuration action.
Note
If you use a loopback interface, make sure that the IP address for the loopback interface is configured with a /32 network mask. In addition, make sure that the routing protocol in use is configured to advertise the corresponding /32 network.
Configuring LDP for Label-Controlled ATM Interfaces
The commands required to configure LDP for a label controlled ATM (LC-ATM) interface depend upon the type of interface in use.
There are three different types of LC-ATM interfaces:
•
Interface type 1—LC-ATM interfaces on a router.
•
Interface type 2—LC-ATM interfaces on an ATM switch that runs routing and MPLS control plane software. The Cisco 8540 is an example of such an ATM switch.
•
Interface type 3—LC-ATM interfaces on an ATM switch whose MPLS operation is controlled by a label switch controller (LSC). The BPX and MGX are examples of such ATM switches.
The following example illustrates the configuration of LDP for LC-ATM interfaces of types 1 and 2. The configuration of LDP for interfaces on ATM switch/LSC combinations (that is, LC-ATM interfaces of type 3) is not supported in this release.
The example given here is based on the network topology shown in Figure 2, which incorporates a router and an ATM switch connected by means of an ATM link.
Configuring LDP for a router ATM interface is a two-step process:
a.
Creating an MPLS subinterface for the ATM interface
b.
Configuring LDP for the MPLS subinterface
Configuring LDP for an ATM interface on an ATM switch that is running routing and MPLS control plane software (LC-ATM interface type 2) is similar to configuring LDP for a packet interface.
Figure 2 Configuration of LDP for LC-ATM Interfaces
In the following sample configurations, the use of LDP is configured for the ATM link between Router 1 and Switch 1 (see Figure 2).
Router 1 Configuration:
ip cef distributed !Assumes R1 supports distributed CEFinterface Loopback0ip address 133.0.0.33 255.255.255.255interface ATM3/0.1 mpls !Create the MPLS sub-interfaceip unnumbered Loopback0 !Use IP address of loopback!interface 0 for this interfacempls ip !Enable hop-by-hop MPLS forwardingmpls label protocol ldp !Use LDP for this interfaceSwitch 1 Configuration:
interface Loopback0ip address 121.0.0.21 255.255.255.255interface ATM1/1/1ip unnumbered Loopback0 !Use IP address of loopback!interface 0 for this interfacempls ip !Enable hop-by-hop MPLS forwardingmpls label protocol ldp !Use LDP for this interface
Note
The use of unnumbered interfaces is not required for LDP, but it is recommended.
Configuring LDP for Targeted Sessions
Some situations require a label distribution session between platforms that are not directly connected. For example, when you issue the mpls ip command on an MPLS traffic engineering tunnel interface, a label distribution session must be established between the tunnel head end and the tail end platforms. Such a session is called a targeted session.
Session establishment for targeted sessions is supported by targeted Hello messages sent between the platforms. Normally the transmission of targeted Hello messages is triggered by some configuration action for the application that requires the targeted session. For example, using the mpls ip command on an MPLS traffic engineering tunnel initiates the transmission of targeted Hello messages from the tunnel head end platform to the tunnel tail end platform.
Unlike LDP sessions for directly connected peers, targeted sessions are asymmetrical. One peer initiates the session by transmitting targeted Hello messages that carry a "send targeted Hello messages in response" request. This request causes the target peer to respond with targeted Hello messages if its configuration permits it to do so.
The exchange of targeted Hello messages between two nondirectly connected neighbors, N1 and N2, may occur in the following ways:
•
N1 may initiate the transmission of targeted Hello messages carrying a response request to N2, and N2 may send targeted Hello messages in response if its configuration permits. In this situation, N1 is considered to be active and N2 is considered to be passive.
•
N1 and N2 may both be configured to initiate the transmission of targeted Hello messages to each other. In this situation, both are considered to be active. Both, one, or neither N1 nor N2 can also be passive, depending on whether they have been configured to respond to requests for targeted Hello messages from each other.
The default behavior of an LSR is to ignore requests from other LSRs to send targeted Hello messages. You can configure an LSR to respond to requests for targeted Hello messages by issuing the mpls ldp discovery targeted-hellos accept command.
The protocol used for a targeted session is controlled by the active LSR in the following sense: a passive LSR that is permitted to respond to requests from an active LSR will do so using the protocol of the received targeted Hello messages.
For applications in which targeted sessions are associated with interfaces, you can use the mpls label protocol global and interface configuration commands to specify the protocol for a given interface. For example, the following commands:
interface Tunnel1tunnel destination 133.0.0.33mpls ipmpls label protocol ldpwhere Tunnel1 is an MPLS traffic engineering tunnel interface, cause an LDP targeted session to be established with the tunnel tail end router.
The output of the show mpls ldp discovery command provides the following information for targeted Hello messages:
•
The protocol being used for each targeted LSR.
•
The characteristics of the discovery activity with the targeted LSR. This includes whether the local LSR is active (an initiator of targeted Hello messages that carry a response request), passive (a responder of requests for targeted Hello messages from the other LSR), or both.
Consider the following output from the show mpls ldp discovery command:
Router# show mpls ldp discoveryLocal LDP Identifier:118.1.1.1:0Discovery Sources:Interfaces:POS2/0 (ldp): xmit/recvLDP Id: 155.0.0.55:0Tunnel1 (ldp): Targeted -> 133.0.0.33Targeted Hellos:118.1.1.1 -> 133.0.0.33 (ldp): active, xmit/recvLDP Id: 133.0.0.33:0118.1.1.1 -> 168.7.0.16 (tdp): passive, xmit/recvTDP Id: 168.7.0.16:0Router#This command output indicates that:
•
The local LSR (118.1.1.1) is sending LDP link Hello messages on interface POS2/0 and has discovered neighbor 155.0.0.55.
•
The local LSR is sending LDP targeted Hello messages associated with interface Tunnel1 to target 133.0.0.33. The LSR uses LDP for the target because the LSR was configured to do so by means of the mpls label protocol ldp command.
•
The local LSR is active for targeted discovery activity with 133.0.0.33; this means that the targeted Hello messages it sends to 133.0.0.33 carry a response request. This LSR is active due to the configuration of an application (mpls ip on Tunnel1, for example) that requires an LDP session with the nondirectly connected LSR 133.0.0.33.
•
The local LSR is not passive for the discovery activity with 133.0.0.33 because: a) the targeted Hello messages it receives from 133.0.0.33 do not carry a response request, or b) the Local LSR has not been configured to respond to such requests.
•
The local LSR is sending TDP directed Hello messages to the target LSR 168.7.0.16. This LSR uses TDP because the Hell messages received from the target LSR 168.7.0.16 were TDP directed Hello messages.
•
The local LSR is passive in discovery activity with LSR 168.7.0.16. This means that the directed Hello messages it receives from LSR 168.7.0.16 carry a response request and that the local LSR has been configured by means of the mpls ldp discovery targeted-hello accept command to respond to such requests from LSR 168.7.0.16.
•
The local LSR is not active in discovery activity with LSR 168.7.0.16 because no application that requires an LDP session with LSR 168.7.0.16 has been configured on the local LSR.
The following examples illustrate the configuration of platforms for targeted sessions using the sample network shown in Figure 3. Note that Routers 1, 4, 5, and 6 in this sample network are not directly connected to each other.
Figure 3 Sample Network for Configuring LDP for Targeted Sessions
The configuration examples presented below accomplish the following:
a.
Use of LDP for targeted sessions between Router 1 and Router 4. The configurations below require that Router 1 and Router 4 both be active.
b.
Use of LDP for targeted sessions between Router 1 and Router 6. The configurations below require that Router 1 be active and allow Router 6 to be passive.
c.
Use of TDP (the default) for targeted sessions between Router 1 and platforms other than Routers 4 and 6 (for example, between Router 1 and Router 5). The configuration for Router 5 requires it to be active in such sessions.
These examples assume that the active ends of the targeted sessions are associated with tunnel interfaces, such as MPLS traffic engineering tunnels. They show only the commands related to configuring the use of LDP targeted sessions. The examples do not show configuration of the applications that initiate the targeted sessions.
Router 1 Configuration
ip cef distributed !Assumes Router1 supports distributed CEFinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.11 255.255.255.255interface Tunnel14 !Tunnel to Router 4 requiring label distributiontunnel destination 131.11.0.4 !Tunnel endpoint is Router 4mpls label protocol ldp !Use LDP for session with Router 4... !Other configuration for Tunnel14interface Tunnel15 !Tunnel to Router 5 requiring label distributiontunnel destination 131.11.0.5 !Tunnel endpoint is Router 5... !Other configuration for Tunnel15interface Tunnel16 !Tunnel to Router 6 requiring label distributiontunnel destination 131.11.0.6 !Tunnel endpoint is Router 6mpls label protocol ldp !Use LDP for session with Router 6... !Other configuration for Tunnel16For Router 1, the default label protocol for interfaces is TDP because there is no global mpls label protocol ldp command. This requires that the configuration for tunnel interfaces Tunnel14 and Tunnel16 include mpls label protocol ldp commands to specify use of LDP for targeted sessions associated with these interfaces. Since TDP is desired for the targeted session with Router 5, there is no need to include an mpls label protocol tdp command as part of the Tunnel15 configuration because the default protocol for interfaces on Router 1 is TDP.
Router 4 Configuration
ip cef distributed !Assumes Router 4 supports distributed CEFmpls label protocol ldp !Use LDP as default for all interfacesinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.44 255.255.255.255interface Tunnel41 !Tunnel to Router 1 requiring label distributiontunnel destination 131.11.0.1 !Tunnel endpoint is Router 1... !Other configuration for Tunnel41For Router 4, the global mpls label protocol ldp command makes it unnecessary to explicitly specify LDP as part of the configuration for the Tunnel41 targeted session with Router 1.
Router 5 Configuration
ip cef !Assumes Router 5 doesn't support dist. CEFinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.55 255.255.255.255interface Tunnel51 !Tunnel to Router 1 requiring label distributiontunnel destination 131.11.0.1 !Tunnel endpoint is Router 1... !Other configuration for Tunnel51Router 5 must use TDP for all targeted sessions it participates in as an active router because its configuration contains neither the global mpls label protocol ldp command nor the interface mpls label protocol ldp command.
Router 6 Configuration
ip cef distributed !Assumes Router 6 supports distributed CEFinterface Loopback0 !Loopback interface for LDP Id.ip address 131.25.0.66 255.255.255.255mpls ldp discovery targeted-hellos accept from LDP_SOURCES!Respond to requests for targeted hellos!from sources permitted by acl LDP_SOURCESip access-list standard LDP_SOURCES !Define acl for targeted hello sources.permit 131.11.0.1 !Accept targeted hello request from Router 1.deny any !Deny requests from other sources.By default, a router can not be a passive neighbor in targeted sessions. Therefore, Router 1, Router 4, and Router 5 can only be active neighbors in any targeted sessions they are part of because their configuration does not permit them to be passive. The mpls ldp discovery targeted-hello accept command permits Router 6 to be a passive target in targeted sessions with Router 1. Router 6 can also be an active neighbor in targeted sessions, although the example does not include such a configuration.
Transitioning a Network from TDP to LDP
The software for this release facilitates the orderly transition of a network that uses TDP to one that uses LDP. Key software features supporting this transition to LDP include the following:
•
LDP and TDP are both supported and can operate simultaneously on a given platform.
•
The protocol to be used for directly connected peers is configurable on a per-interface basis.
•
The protocol to be used for nondirectly connected peers is configurable on a per-session basis.
•
A label-switched path (LSP) across an MPLS network can be signaled by LDP on some hops and by TDP on other hops.
These software features enable a staged transition from TDP to LDP on a link-by-link or a targeted session-by-session basis.
In considering the steps involved in configuring the simple network shown in Figure 4 to use LDP, assume that the following conditions apply:
•
TDP is currently used for label distribution throughout the network.
•
Each link has been enabled by means of the tag-switching ip command.
•
Tag/label distribution sessions are required between the following nondirectly connected platforms:
–
Router 1 (active via Tunnel15) and Router 5 (passive via Tunnel51)
–
Router 1 (active via Tunnel16) and Router 6 (passive)
Figure 4 Sample Network for Transitioning from TDP to LDP
To accomplish the transition from TDP to LDP for the network topology shown in Figure 4, perform the following steps:
Step 1
Convert the label distribution for Link 1 from TDP to LDP by invoking the mpls label protocol ldp command on Router 1 and Router 2 for their interfaces to Link 1.
Verify proper MPLS operation.
Step 2
Convert the label distribution between Router 1 and Router 3 for the Ethernet link from TDP to LDP by invoking the mpls label protocol both command on Router 1 and Router 3 for their interfaces to Link 3.
The mpls label protocol both command enables Router 1 and Router 3 to use LDP or TDP for label distribution sessions with neighbors directly connected to Link 3 (with a preference for LDP). The resulting configuration establishes:
•
An LDP session between Router 1 and Router 3
•
A TDP session between Router 1 and Router 4
•
A TDP session between Router 3 and Router 4
Verify proper MPLS operation.
Step 3
Convert the label distribution for Link 2 from TDP to LDP by invoking the mpls label protocol ldp command on Router 2 and Router 3 for their interfaces to Link 2.
Verify proper MPLS operation.
Step 4
Convert the label distribution for Link 4 and Link 5 from TDP to LDP by invoking the mpls label protocol ldp command on Router 3, Router 4, and Router 5 for the interfaces to Link 4 and Link 5.
Verify proper MPLS operation. You can do so in two separate steps, if desired—one for Link 4 and one for Link 5.
Step 5
Convert the label distribution for Link 6 and Link 7 from TDP to LDP by invoking the mpls label protocol ldp command on Router 2, Router 5, and Router 6 for the interfaces to Link 6 and Link 7.
Verify proper MPLS operation. You can do so in two separate steps, if desired—one for Link 6 and one for Link 7.
Step 6
Complete the conversion for Link 3 started in Step 2 by invoking the mpls label protocol ldp command on Router 4 for Link 3, and also on Router 1 and Router 3 for Link 3.
Verify proper MPLS operation.
Note
The mpls label protocol both command in Step 2 enables both LDP and TDP discovery to occur for Router 1 and Router 3 on Link 3. Since TDP is no longer required by any of the routers connected to Link 3, replacing that command with the mpls label protocol ldp command disables TDP discovery on Router 1 and Router 3, leaving only LDP discovery enabled on Router 1, Router 3, and Router 4.
Step 7
Convert the targeted label distribution between Router 1 and Router 5 from TDP to LDP.
To do so, add the mpls label protocol ldp command to the configuration of Tunnel15 on Router 1. This assumes that Router 5, which is passive for targeted sessions between Router 1 and Router 5, has previously been configured to accept targeted Hello messages from Router 1 via the mpls ldp discovery targeted-hello accept command.
Verify proper MPLS operation.
Step 8
Convert the targeted label distribution between Router 1 and Router 6 from TDP to LDP by adding the mpls label protocol ldp command to the configurations of Tunnel16 on Router 1 and Tunnel61 Router 6.
Verify proper MPLS operation.
This step completes the transition of the network from TDP to LDP.
At this point, you could make the following additional changes to "clean up" each of the configurations:
a.
Add the global mpls label protocol ldp command to each configuration;
b.
Remove all interface mpls label protocol ldp commands from each configuration.
CLI Command Summary
The CLI commands described in this document fall into three categories:
•
CLI commands introduced in Cisco IOS 12.0(10)ST and 12.0(14)ST for new LDP functionality (see Table 1)—This set of commands supports new MPLS LDP functionality and do not derive from any existing TDP commands.
•
Functionally equivalent, but syntactically different, LDP commands (see Table 2)—The commands in this category, although derived from existing TDP commands, exhibit a command syntax that differs in some respects from their corresponding TDP commands. For example, some commands in this category incorporate new keywords or parameters that are unique to MPLS LDP functionality.
•
Functionally and syntactically equivalent LDP commands (see Table 3)—The commands in this category not only derive from existing TDP commands, but also preserve the basic syntax of their TDP counterparts in implementing MPLS LDP functionality.
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications.
•
debug mpls ldp advertisements
•
debug mpls ldp peer state-machine
•
debug mpls ldp session state-machine
•
debug mpls ldp targeted-neighbors
•
debug mpls ldp transport connections
•
debug mpls ldp transport events
•
mpls ip (global configuration)
•
mpls ip (interface configuration)
•
mpls label protocol (global configuration)
•
mpls label protocol (interface configuration)
•
mpls ldp advertise-labels old-style
•
mpls ldp discovery transport-address
debug mplsatm-ldp api
To display information about the VCI allocation of label VCs (LVCs), label-free requests, and cross-connect requests, use the debug mpls atm-ldp api command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls atm-ldp api
no debug mpls atm-ldp api
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug mpls atm-ldp api command in conjunction with the debug mpls atm-ldp routes and debug mpls atm-ldp states command to display more complete information about an LVC.
Examples
The following shows sample output from the debug mpls atm-ldp api command:
Router# debug mpls atm-ldp apiTailend Router Free label Req 167.50.0.0 on ATM0/0.2 VPI/VCI 1/674TAGATM_API: received label free requestinterface: ATM0/0.2 dir: in vpi: 1 vci: 674TAGATM_API: completed label freeinterface: ATM0/0.2 vpi: 1 vci: 674result: TAGATM_OKTable 4 describes the significant fields shown in the display above.
Related Commands
debug mpls atm-ldp routes
To display information about the state of the routes for which VCI requests are being made, use the debug mpls atm-ldp routes command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls atm-ldp routes
no debug mpls atm-ldp routes
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When there are many routes and system activities (that is, shutting down of interfaces, learning of new routes, and so forth), the debug mpls atm-ldp routes command displays extensive information that might interfere with system timing. Most commonly, this interference affects normal LDP operation. To avoid this problem, you can increase the LDP hold time by means of the mpls ldp holdtime command.
Examples
The following shows sample output from the debug mpls atm-ldp routes command:
Router# debug mpls atm-ldp routesCleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0tcatmFindRouteTags,153.7.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0AddNewRoute,153.7.0.0/16,idb=ATM0/0.2CleanupRoutes,153.7.0.0/16CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0tcatmFindRouteTags,153.8.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0AddNewRoute,153.8.0.0/16,idb=ATM0/0.2CleanupRoutes,153.8.0.0/16CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0tcatmFindRouteTags,153.9.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0AddNewRoute,153.9.0.0/16,idb=ATM0/0.2CleanupRoutes,153.9.0.0/16CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0tcatmFindRouteTags,153.10.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0AddNewRoute,153.10.0.0/16,idb=ATM0/0.2CleanupRoutes,153.10.0.0/16CleanupRoutes,not deleting route of idb ATM0/0.2,rdbIndex 0tcatmFindRouteTags,153.11.0.0/16,idb=ATM0/0.2,nh=134.111.102.98,index=0AddNewRoute,153.11.0.0/16,idb=ATM0/0.2CleanupRoutes,153.11.0.0/16Table 5 describes the significant fields in the display above.
Related Commands
Command DescriptionChanges the time an LDP session will be maintained in the absence of LDP messages from the session peer.
debug mpls atm-ldp states
To display information about LVC state transitions as they occur, use the debug mpls atm-ldp states command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls atm-ldp states
no debug mpls atm-ldp states
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When there are many routes and system activities (such as shutting down of interfaces, learning of new routes, and so forth), the debug mpls atm-ldp states command outputs extensive information that might interfere with system timing. Most commonly, this interference affects normal LDP operation. To avoid this problem, you should increase the LDP hold time by means of the mpls ldp holdtime command.
Examples
The following shows sample output from the debug mpls atm-ldp states command:
Router# debug mpls atm-ldp statesTransit Output 166.35.0.0 VPI/VCI 1/67 Active -> XmitRelease NoPathTransit Input 166.35.0.0 VPI/VCI 1/466 Active -> ApiWaitParentLoss ParentLossTransit Input 166.35.0.0 VPI/VCI 1/466 ApiWaitParentLoss -> ParentWait ApiSuccessTransit Input 166.35.0.0 VPI/VCI 1/466 ParentWait -> XmitWithdraw NoPathTransit Input 166.35.0.0 VPI/VCI 1/466 XmitWithdraw -> XmitWithdraw TransmitTransit Input 166.35.0.0 VPI/VCI 1/466 XmitWithdraw -> NonExistent ReleaseTransit Input 166.35.0.0 VPI/VCI 1/466 NonExistent -> NonExistent ApiSuccessTable 6 describes the significant fields shown in the sample display above.
Related Commands
Command DescriptionChanges the time an LDP session is maintained in the absence of LDP messages from the session peer.
debug mpls ldp advertisements
To display information about the advertisement of labels and interface addresses to LDP peers, use the debug mpls ldp advertisements command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp advertisements [peer-acl acl] [prefix-acl acl]
no debug mpls ldp advertisements [peer-acl acl] [prefix-acl acl]
Syntax Description
Defaults
Displays information about advertisements to all LDP peers for all prefixes.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to monitor the label and address advertisements to LDP peers.
Use the peer-acl or prefix-acl options separately or together to limit the information display to specific LDP peers and/or specific prefixes.
Note
This command monitors advertisement of non-LC-ATM labels (generic labels) only. Use the debug mpls atm-ldp command to monitor LC-ATM activity.
Examples
The following shows sample output from the debug mpls ldp advertisements command:
Router# debug mpls ldp advertisementstagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 130.77.0.33tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 133.0.0.33tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 34.0.0.33tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 103.0.0.33tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 35.0.0.33tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 38.0.0.33tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 34.0.0.0/8, label 3 (#2)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 203.0.7.7/32, label 24 (#4)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 35.0.0.0/8, label 3 (#8)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 103.0.0.0/8, label 3 (#10)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 138.1.0.0/16, label 26 (#14)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 155.0.0.55/32, label 27 (#16)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 38.0.0.0/8, label 3 (#18)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 212.10.1.0/24, label 30 (#24)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 59.0.0.0/8, label 32 (#28)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 144.0.0.44/32, label 33 (#30)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 106.0.0.0/8, label 34 (#32)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 133.0.0.33/32, label 3 (#34)tagcon: peer 144.0.0.44:0 (pp 0x60E105BC): advertise 45.0.0.0/8, label 39 (#36)Table 7 describes the significant fields shown in the sample display above.
Related Commands
debug mpls ldp bindings
To display information about addresses and label bindings learned from LDP peers by means of LDP downstream unsolicited label distribution, use the debug mpls ldp bindings command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp bindings [peer-acl acl] [prefix-acl acl]
no debug mpls ldp bindings [peer-acl acl] [prefix-acl acl]
Syntax Description
Defaults
Displays information about all bindings learned from all LDP peers.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to monitor label bindings and LSR addresses learned from LDP peers.
Note
This command monitors non-LC-ATM labels (generic labels) only. Use the debug mpls atm-ldp command to monitor LC-ATM activity.
Examples
The following shows sample output from the debug mpls ldp bindings command:
Router# debug mpls ldp bindingstagcon:tibent(34.0.0.0/8):created; find route tags requesttagcon:tibent(34.0.0.0/8):label 3 (#2) assignedtagcon:tibent(203.0.7.7/32):created; find route tags requesttagcon:tibent(203.0.7.7/32):label 24 (#4) assignedtagcon:tibent(144.0.0.44/32):created; find route tags requesttagcon:tibent(144.0.0.44/32):label 33 (#30) assignedtagcon:tibent(106.0.0.0/8):created; find route tags requesttagcon:tibent(106.0.0.0/8):label 34 (#32) assignedtagcon:tibent(133.0.0.33/32):created; find route tags requesttagcon:tibent(133.0.0.33/32):label 3 (#34) assignedtagcon:tibent(45.0.0.0/8):created; find route tags requesttagcon:tibent(45.0.0.0/8):label 39 (#36) assignedtagcon:Assign peer id; 144.0.0.44:0:id 0tagcon:144.0.0.44:0:144.0.0.44 added to addr<->ldp ident maptagcon:144.0.0.44:0:34.0.0.44 added to addr<->ldp ident maptagcon:144.0.0.44:0:45.0.0.44 added to addr<->ldp ident maptagcon:tibent(144.0.0.44/32):rem label 3 from 144.0.0.44:0 addedtagcon:tibent(34.0.0.0/8):label 3 from 144.0.0.44:0 addedtagcon:tibent(45.0.0.0/8):label 3 from 144.0.0.44:0 addedtagcon:tibent(107.0.0.0/8):created; remote label learnedtagcon:tibent(107.0.0.0/8):label 55 from 144.0.0.44:0 addedtagcon:tibent(203.0.7.7/32):label 209 from 144.0.0.44:0 addedtagcon:tibent(133.0.0.33/32):label 207 from 144.0.0.44:0 addedTable 8 describes the significant fields shown in the sample display above.
Related Commands
debug mpls ldp messages
To display information about LDP messages sent to or received from LDP peers, use the debug mpls ldp messages command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp messages {sent | received} [all] [peer-acl acl]
no debug mpls ldp messages {sent | received} [all] [peer-acl acl]
Syntax Description
Defaults
All messages sent (for sent keyword) or received (for received keyword) are displayed except for periodic KeepAlive messages
Command Modes
Privileged EXEC
Command History
Usage Guidelines
LDP requires periodic transmission of KeepAlive messages. If you do not specify the all option, periodic KeepAlive messages are not displayed.
Examples
The following shows sample output from the debug mpls ldp messages received command:
Router# debug mpls ldp messages receivedRouter# debug mpls ldp messages sentldp: Rcvd init msg from 144.0.0.44 (pp 0x0)ldp: Sent init msg to 144.0.0.44:0 (pp 0x0)ldp: Sent keepalive msg to 144.0.0.44:0 (pp 0x0)ldp: Rcvd keepalive msg from 144.0.0.44:0 (pp 0x0)ldp: Sent address msg to 144.0.0.44:0 (pp 0x610F00E0)ldp: Sent label mapping msg to 144.0.0.44:0 (pp 0x610F00E0)ldp: Sent label mapping msg to 144.0.0.44:0 (pp 0x610F00E0)ldp: Sent label mapping msg to 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd address msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)ldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610F00E0)Table 9 describes the significant fields shown in the sample display above.
Related Commands
debug mpls ldp peer state-machine
To display information about state transitions for LDP sessions, use the debug mpls ldp peer state-machine command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp peer state-machine
no debug mpls ldp peer state-machine
Syntax Description
This command has no keywords or arguments.
Defaults
This command has no options.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
LDP manages peer sessions by means of two coupled state machines:
•
A low-level state machine that deals with session establishment and shutdown.
•
A high-level state machine that deals with setting up and shutting down label advertisement
Use the debug mpls ldp session state-machine command to monitor the lower-level session state machine.
Use the debug mpls ldp peer state-machine command to monitor the higher-level session state machine.
Examples
The following shows sample output from the debug mpls ldp peer state-machine command:
Router# debug mpls ldp peer state-machinetagcon: start session TCP timers for 144.0.0.44:0 (pp 0x610EEC84)tagcon: Enqueue peer up work for 144.0.0.44:0 (pp 0x610EEC84)tagcon: peer 144.0.0.44:0 (pp 0x610EEC84): Event unsol openunsol op pdg -> estabtagcon: Send initial advertisements to peer 144.0.0.44:0tagcon: Initial address advertisement to peer 144.0.0.44:0tagcon: Initial label advertisement to peer 144.0.0.44:0...tagcon: peer 144.0.0.44:0 (pp 0x610EEC84): Event downestab -> destroyedtagcon: peer 144.0.0.44:0 (pp 0x610EEC84): Event cleanup donedestroyed -> non-exTable 10 describes the significant fields shown in the sample display above.
Related Commands
Command DescriptionDisplays the status of LDP sessions.
Displays information about state transitions for LDP sessions.
Displays information about LDP messages sent to or received from LDP peers.
debug mpls ldp session io
To display the contents of LDP messages sent to and received from LDP peers, use the debug mpls ldp session io command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp session io [all] [peer-acl acl]
no debug mpls ldp session io [all] [peer-acl acl]
Syntax Description
Defaults
Displays the contents of all messages sent and received except for periodic KeepAlive messages.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Displays the contents of all messages sent and received except for periodic KeepAlive messages.
Examples
The following shows sample output from the debug mpls ldp session io command:
Router# debug mpls ldp session io allldp: Rcvd init msg from 144.0.0.44 (pp 0x0)ldp: LDP init msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:0x00 0x01 0x00 0x20 0x90 0x00 0x00 0x2C 0x00 0x00 0x02 0x00 0x00 0x16 0x00 0x000x10 0x21 0x05 0x00 0x00 0x0E 0x00 0x01 0x00 0xB4 0x00 0x00 0x00 0x00 0x85 0x000x00 0x21 0x00 0x00ldp: Sent init msg to 144.0.0.44:0 (pp 0x0)ldp: LDP init msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:0x00 0x01 0x00 0x20 0x85 0x00 0x00 0x21 0x00 0x00 0x02 0x00 0x00 0x16 0x00 0x000x06 0x32 0x05 0x00 0x00 0x0E 0x00 0x01 0x00 0xB4 0x00 0x00 0x00 0x00 0x90 0x000x00 0x2C 0x00 0x00ldp: Sent keepalive msg to 144.0.0.44:0 (pp 0x0)ldp: LDP keepalive msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:0x00 0x01 0x00 0x0E 0x85 0x00 0x00 0x21 0x00 0x00 0x02 0x01 0x00 0x04 0x00 0x000x06 0x33ldp: Rcvd keepalive msg from 144.0.0.44:0 (pp 0x0)ldp: LDP keepalive msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:0x00 0x01 0x00 0x0E 0x90 0x00 0x00 0x2C 0x00 0x00 0x02 0x01 0x00 0x04 0x00 0x000x10 0x22ldp: Sent address msg to 144.0.0.44:0 (pp 0x610ECDD0)ldp: LDP address msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:0x00 0x01 0x00 0x34 0x85 0x00 0x00 0x21 0x00 0x00 0x03 0x00 0x00 0x2A 0x00 0x000x06 0x34 0x01 0x01 0x00 0x22 0x00 0x01 0x02 0x00 0x00 0xA3 0x82 0x42 0x00 0x210x82 0x4D 0x00 0x21 0x85 0x00 0x00 0x21 0x22 0x00 0x00 0x21 0x67 0x00 0x00 0x210x23 0x00 0x00 0x21 0x26 0x00 0x00 0x21ldp: Sent label mapping msg to 144.0.0.44:0 (pp 0x610ECDD0)ldp: LDP label mapping msg: PDU hdr: LDP Id: 133.0.0.33:0; Msg Contents:0x00 0x01 0x00 0x22 0x85 0x00 0x00 0x21 0x00 0x00 0x04 0x00 0x00 0x18 0x00 0x000x06 0x36 0x01 0x00 0x00 0x08 0x02 0x00 0x01 0x20 0xCB 0x00 0x07 0x07 0x02 0x000x00 0x04 0x00 0x00 0x00 0x18ldp: Rcvd address msg from 144.0.0.44:0 (pp 0x610ECDD0)ldp: LDP address msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:0x00 0x01 0x00 0x24 0x90 0x00 0x00 0x2C 0x00 0x00 0x03 0x00 0x00 0x1A 0x00 0x000x10 0x23 0x01 0x01 0x00 0x12 0x00 0x01 0x90 0x00 0x00 0x2C 0x02 0x00 0x00 0xA40x22 0x00 0x00 0x2C 0x2D 0x00 0x00 0x2Cldp: Rcvd label mapping msg from 144.0.0.44:0 (pp 0x610ECDD0)ldp: LDP label mapping msg: PDU hdr: LDP Id: 144.0.0.44:0; Msg Contents:0x00 0x01 0x00 0x22 0x90 0x00 0x00 0x2C 0x00 0x00 0x04 0x00 0x00 0x18 0x00 0x000x10 0x24 0x01 0x00 0x00 0x08 0x02 0x00 0x01 0x20 0x90 0x00 0x00 0x2C 0x02 0x000x00 0x04 0x00 0x00 0x00 0x03Table 11 describes the significant fields shown in the sample display above.
Related Commands
debug mpls ldp session state-machine
To display information about state transitions for LDP sessions, use the debug mpls ldp session state-machine command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp session state-machine [peer-acl acl]
no debug mpls ldp session state-machine [peer-acl acl]
Syntax Description
peer-acl acl
(Optional.) Limits the displayed information to that for LDP peers permitted by the access control list (acl).
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
LDP manages peer sessions by means of two coupled-state machines:
•
A low-level state machine that deals with session establishment and shutdown
•
A high-level state machine that deals with setting up and shutting down label advertisement
Use the debug mpls ldp session state-machine command to monitor the lower-level session state machine.
Use the debug mpls ldp peer state-machine command to monitor the higher-level session state machine.
Examples
The following shows sample output from the debug mpls ldp session state-machine command:
Router# debug mpls ldp session state-machineldp: ptcl_adj:144.0.0.44(0x610EED30): Non-existent -> Role pasvldp: create ptcl_adj: tp = 0x610EED30, ipaddr = 144.0.0.44ldp: ptcl_adj:144.0.0.44(0x610EED30): Event: Xport opened;Role pasv -> Role pasvldp: ptcl_adj:34.0.0.44(0x610EED30): Event: Rcv Init;Role pasv -> Init rcvd pasvldp: ptcl_adj:34.0.0.44(0x610EED30): Event: Rcv KA;Init rcvd pasv -> Operldp: ptcl_adj:unknown(0x610EED30): Event: Xport closed;Oper -> Non-existentTable 12 describes the significant fields in the sample display shown above.
Related Commands
debug mpls ldp targeted-neighbors
To display information about the target neighbor mechanism, use the debug mpls ldp targeted-neighbors command in privileged EXEC mode. This mechanism establishes LDP adjacencies to peers that are not directly adjacent, such as peers at either end of a tunnel. Use the no form of the command to disable this feature.
debug mpls ldp targeted-neighbors
no debug mpls ldp targeted-neighbors
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Platforms that are not directly connected may engage in LDP label distribution (for example, to support two-level labeling across an LSP tunnel).
An LDP session between nondirectly connected LSRs is called a targeted session and is supported by LDP extended discovery which uses targeted Hello messages sent to specific IP addresses.
An LSR (Router 1) attempting to initiate an LDP targeted session with another LSR (Router 2) sends targeted Hello messages sent to a specific IP address of Router 2. If the configuration of Router 2 permits it to respond to targeted Hello messages from Router 1, it does so, and the LDP session can be established. In this situation, Router 1 is said to be an active LSR for the targeted session because it initiated the targeted Hello messages; Router 2 is said to be a passive LSR for the session because it responded to them.
As with LDP sessions between two directly connected LSRs, it is possible for a targeted session to be the result of multiple discovery activities which are targeted to different IP addresses for the same LSR. In addition, it is possible for both LSRs in a targeted session to be active and for both to be passive.
The debug messages enabled by debug mpls ldp targeted-neighbors report activity relating to targeted sessions.
Examples
The following shows sample output from the debug mpls ldp targeted-neighbors command:
Router# debug mpls ldp targeted-neighborsldp-trgtnbr: 144.0.0.44 Req activeldp-trgtnbr: 144.0.0.44 allocatedldp-trgtnbr: 144.0.0.44 Set peer start; flags 0x0ldp-trgtnbr: 144.0.0.44 Defer peer cleanup; cleancnt 1ldp-trgtnbr: 144.0.0.44 Set peer finished; flags 0xFldp-trgtnbr: 144.0.0.44 ref count incremented to 1ldp-trgtnbr: 144.0.0.44 Release active; ref count decremented to 0ldp-trgtnbr: 144.0.0.44 Clear peer start; flags 0xFldp-trgtnbr: 144.0.0.44 Undefer cleanup start; clearcnt 0, flags 0xCldp-trgtnbr: 144.0.0.44 Undefer cleanup finish; clearcnt 0, flags 0x8ldp-trgtnbr: 144.0.0.44 Clear peer finished; flags 0x8ldp-trgtnbr: 144.0.0.44 freedTable 13 describes the significant fields shown in the sample display above.
Related Commands
debug mpls ldp transport connections
To display information about the TCP connections used to support LDP sessions, use the debug mpls ldp transport connections command in privileged EXEC mode. Use the no form of the command to disable this feature.
debug mpls ldp transport connections [peer-acl acl] [interface interface]
no debug mpls ldp transport connections [peer-acl acl] [interface interface]
Syntax Description
Defaults
Display information about LDP TCP connection activity for all peers and all interfaces.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to monitor LDP activity relating to the establishment of the transport (TCP) connection for LDP sessions.
When two devices establish a TCP connection for an LDP session, the device with the larger transport address plays an active role and the other plays a passive role. The active device attempts to establish a TCP connection to the well-known LDP port at the passive device. The passive device waits for the connection to the well-known port to be established.
Examples
The following shows sample output from the debug mpls ldp transport connections command:
Router# debug mpls ldp transport connectionsDebug output at active peer:ldp: Opening listen port 646 for 144.0.0.44, 34.0.0.44ldp: Open LDP listen TCB 0x60E105BC; lport = 646; fhost = 144.0.0.44ldp: Add listen TCB to list; tcb 0x60E105BC; addr 144.0.0.44ldp: Incoming ldp conn 133.0.0.33:646 <-> 144.0.0.44:11042ldp: create ptcl_adj: tp = 0x610ECD64, ipaddr = 144.0.0.44Debug output at passive peer:ldp: Opening ldp conn; adj 0x60BAC33C, 144.0.0.44 <-> 133.0.0.33ldp: ldp conn is up; adj 0x60BAC33C, 144.0.0.44:11042 <-> 133.0.0.33:646Table 14 describes the significant fields shown in the sample display shown above.
Related Commands
Command DescriptionPrints information about the events related to the LDP peer discovery mechanism.
debug mpls ldp transport events
To display information about events related to the LDP peer discovery mechanism, use the debug mpls ld transport events command in privileged EXEC mode. This mechanism is used to determine the devices with which you wish to establish LDP sessions. Use the no form of the command to disable this feature.
debug mpls ldp transport events [peer-acl acl] [interface]
no debug mpls ldp transport events [peer-acl acl] [interface]
Syntax Description
Defaults
Displays information about LDP discovery activity for all peers and all interfaces.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the command to monitor LDP discovery activity.
This command might generate a great deal of output. Use the peer-acl option or interface option, or both, to limit the output to peers or interfaces of interest.
Note
The command includes all of the output generated by the debug mpls ldp transport connection command.
Examples
The following shows sample output from the debug mpls ldp transport events command:
Router# debug mpls ldp transport eventsldp: enabling ldp on Ethernet1/1/1ldp: Set intf id: intf 0x611D684C, Ethernet1/1/1, not lc-atm, intf_id 0ldp: Set intf id: intf 0x617C5638, ATM0/0.2, not lc-atm, intf_id 0ldp: Send ldp hello; ATM3/0.1, src/dst 8.1.1.1/224.0.0.2, inst_id 1, tcatmldp: Rcvd ldp hello; ATM3/0.1, from 203.0.7.7 (203.0.7.7:2), intf_id 1, opt 0x8, tcatmldp: Send ldp hello; Ethernet1/1/1, src/dst 138.1.0.88/224.0.0.2, inst_id 0ldp: Rcvd ldp hello; Ethernet1/1/1, from 10.105.0.9 (7.1.1.1:0), intf_id 0, opt 0xCldp: ldp Hello from 10.105.0.9 (7.1.1.1:0) to 224.0.0.2, opt 0xCldp: New adj 0x617C5EBC from 10.105.0.9 (7.1.1.1:0), Ethernet1/1/1ldp: Opening ldp conn; adj 0x617C5EBC, 8.1.1.1 <-> 7.1.1.1ldp: ldp conn is up; adj 0x617C5EBC, 8.1.1.1:11013 <-> 7.1.1.1:646ldp: Send ldp hello; ATM3/0.1, src/dst 8.1.1.1/224.0.0.2, inst_id 1, tcatmldp: Rcvd ldp hello; ATM3/0.1, from 203.0.7.7 (203.0.7.7:2), intf_id 1, opt 0x8, tcatmldp: Send ldp hello; Ethernet1/1/1, src/dst 138.1.0.88/224.0.0.2, inst_id 0ldp: Rcvd ldp hello; Ethernet1/1/1, from 10.105.0.9 (7.1.1.1:0), intf_id 0, opt 0xC...ldp: Send ldp hello; Ethernet1/1/1, src/dst 138.1.0.88/224.0.0.2, inst_id 0ldp: Send ldp hello; ATM3/0.1, src/dst 8.1no tag ip.0.2, inst_id 1, tcatmldp: disabling ldp on Ethernet1/1/1ldp: Hold timer expired for adj 0x617C5EBC, will close connldp: Closing ldp conn 8.1.1.1:11013 <-> 7.1.1.1:646, adj 0x617C5EBCldp: Adjacency 0x617C5EBC, 10.105.0.9 timed outldp: Adj 0x617C5EBC; state set to closedldp: Rcvd ldp hello; ATM3/0.1, from 203.0.7.7 (203.0.7.7:2), intf_id 1, opt 0x8, tcatmldp: Ignore Hello from 10.105.0.9, Ethernet1/1/1; no intfTable 15 describes the significant fields in the sample display shown above.
Related Commands
Command DescriptionDisplays the status of the LDP discovery process.
Displays information about the TCP connections used to support LDP sessions.
mpls ip (global configuration)
To enable MPLS forwarding of IPv4 packets along normally routed paths for the platform, use the mpls ip command in global configuration mode. Use the no form of the command to disable this feature.
mpls ip
no mpls ip
Syntax Description
This command has no optional keywords or arguments.
Defaults
Label switching of IPv4 packets along normally routed paths is enabled for the platform.
Command Modes
Global configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
MPLS forwarding of IPv4 packets along normally routed paths (sometimes called dynamic label switching) is enabled by this command. For a given interface to perform dynamic label switching, this switching function must be enabled for the interface as well as for the platform.
The no form of this command stops dynamic label switching for all platform interfaces regardless of the interface configuration; it also stops distribution of labels for dynamic label switching. However, the no form of this command does not affect the sending of labeled packets through label switch path (LSP) tunnels.
For an LC-ATM interface, the no form of this command prevents the establishment of label VCs originating at, terminating at, or passing through the platform.
Examples
In the following example, dynamic label switching is disabled for the platform, and all label distribution is terminated for the platform:
Router(config)# no mpls ipRelated Commands
Command DescriptionEnables label switching of IPv4 packets along normally routed paths for the associated interface.
mpls ip (interface configuration)
To enable MPLS forwarding of IPv4 packets along normally routed paths for a particular interface, use the mpls ip command in interface configuration mode. Use the no form of the command to disable this feature.
mpls ip
no mpls ip
Syntax Description
This command has no optional keywords or arguments.
Defaults
MPLS forwarding of IPv4 packets along normally routed paths for the interface is disabled.
Command Modes
Interface configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
MPLS forwarding of IPv4 packets along normally routed paths is sometimes called dynamic label switching. If dynamic label switching has been enabled for the platform when this command is issued on an interface, label distribution for the interface begins with the periodic transmission of neighbor discovery Hello messages on the interface. When the outgoing label for a destination routed through the interface is known, packets for the destination are labeled with that outgoing label and forwarded through the interface.
The no form of this command causes packets routed out through the interface to be sent unlabeled; this form of the command also terminates label distribution for the interface. However, the no form of the command does not affect the sending of labeled packets through any LSP tunnels that might use the interface.
For an LC-ATM interface, the no form of this command prevents the establishment of label VCs beginning at, terminating at, or passing through the interface.
Examples
In the following example, label switching is enabled on the specified Ethernet interface:
Router(config)# configure terminalRouter(config)# interface e0/2Router(config-if)# mpls ipRelated Commands
mpls label protocol (global configuration)
To specify the default label distribution protocol for a platform, use the global mpls label protocol command in global configuration mode. Use the no form of the command to restore the image default.
mpls label protocol {ldp | tdp}
no mpls label protocol
Syntax Description
ldp
Specifies that LDP is the platform default label distribution protocol.
tdp
Specifies that TDP is the platform default label distribution protocol.
Defaults
If no protocol is explicitly configured by the global mpls label protocol command, TDP is the default label distribution protocol for the platform.
Command Modes
Global configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
If neither the global mpls label protocol ldp command nor the interface mpls label protocol ldp command is used, all label distribution sessions will use TDP.
To force all label distribution sessions to use LDP, use the global mpls label protocol ldp command and no interface mpls label protocol commands.
Examples
The following command establishes LDP as the label distribution protocol for the platform.
Router(config)# mpls label protocol ldpRelated Commands
Command DescriptionDisplays MPLS information about interfaces, including the configured tag and/or label distribution protocol.
mpls label protocol (interface configuration)
To specify the label distribution protocol to be used on a given interface, use the mpls label protocol command in interface configuration mode. Use the no form of the command to disable this feature.
mpls label protocol {ldp | tdp | both}
no mpls label protocol
Syntax Description
Defaults
If no protocol is explicitly configured for an interface, the default label distribution protocol for the platform is used. To set the platform default protocol, use the global mpls label protocol command.
Command Modes
Interface configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
To successfully establish a session for label distribution for a link connecting two LSRs, the link interfaces on the LSRs must be configured to use the same label distribution protocol. If there are multiple links connecting two LSRs, all of the link interfaces connecting the two LSRs must be configured to use the same protocol.
The both option is intended for use with interfaces to multi-access networks, such as Ethernet and FDDI, where some peers might use LDP while others use TDP. When you specify the both option, the LSR sends both LDP and TDP discovery Hello messages and responds to both types of messages.
Examples
The following command establishes LDP as the label distribution protocol for the interface.
Router(config-if)# mpls label protocol ldpRelated Commands
Command DescriptionDisplays MPLS information about interfaces, including the configured tag and/or label distribution protocol.
mpls ldp address-message
To specify advertisement of platform addresses to an LC-ATM LDP peer, use the mpls ldp address-message command in interface configuration mode. Use the no form of the command to disable this feature.
mpls ldp address-message
no mpls ldp address-message
Syntax Description
This command has no optional keywords or arguments.
Defaults
Do not send LDP Address and Address Withdraw messages to LC-ATM LDP peers.
Command Modes
Interface configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
The LDP specification includes Address and Address Withdraw messages used by an LSR to advertise its addresses to its peers.
An LSR uses the addresses it learns from peers when operating in Downstream Unsolicited label advertisement mode to convert between route next hop addresses (found in the LSR routing table) and peer LDP identifiers.
The ability to map between the IP address and the peer LDP identifier is required so that
•
When the MPLS forwarding engine (LFIB) asks for labels for a given destination prefix/next hop address, the LSR can find the label learned (if any) from the next hop. The LSR maintains learned labels in its label information base (LIB) tagged by the LDP Id of the advertising LSR.
•
When the LSR learns a label for destination prefix P from an LDP peer, it can determine if that peer (known to the LSR by its LDP identifier) is currently the next hop for P.
In principle, an LSR operating in Downstream On Demand (DoD) mode for an LC-ATM interface does not need this information for two reasons:
•
The LSR should know from the routing table the next hop interface.
•
There is only one DoD peer per LC-ATM interface.
Consequently, Cisco platforms do no normally send Address/Address Withdraw messages to LC-ATM peers.
Some LDP implementations might require the information learned in Address/Address Withdraw messages for LC-ATM. The mpls ldp address-message command is provided to enable interoperability with implementation vendors that require Address messages for LC-ATM.
Note
Cisco platforms always advertise their addresses in Address and Address Withdraw messages for LDP sessions operating in Downstream Unsolicited label advertisement mode.
Examples
The following is an example use of the mpls ldp address-message command:
Router(config-if)# mpls ldp address-messageRelated Commands
Command DescriptionDisplays MPLS information about interfaces, including the configured label distribution protocol.
mpls ldp advertise-labels
To control the distribution of locally-assigned (incoming) labels by means of LDP, use the mpls ldp advertise-labels command in global configuration mode. This command is used to control which labels are advertised to which LDP neighbors. Use the no form of the command to disable this feature.
mpls ldp advertise-labels [for prefix-access-list [to peer-access-list]]
no mpls ldp advertise-labels [for prefix-access-list [to peer-access-list]]
Syntax Description
Defaults
The labels of all destinations are advertised to all LDP neighbors.
Command Modes
Global configuration
Command History
Usage Guidelines
To prevent the distribution of any locally-assigned labels, use the no mpls ldp advertise-labels command with no optional parameters. To re-enable the distribution of all locally-assigned labels to all LDP neighbors, use the mpls ldp advertise-labels command with no optional parameters.
You can execute multiple mpls ldp advertise-labels commands. In the aggregate, such commands determine how the LSR advertises local labels. The following rules describe the effects of multiple commands:
1.
Every mpls ldp advertise-labels ... command has a (prefix acl, peer acl) pair associated with it. The access list pair associated with the mpls ldp advertise-labels command (in the absence of both the for and to keywords) is (none, none); the access list pair associated with the mpls ldp advertise-labels for prefix acl command (in the absence of the to keyword) is (prefix-acl, none).
2.
A given prefix can have, at most, one (prefix acl, peer acl) pair that "applies" to it, as described below:
a.
A given (prefix acl, peer acl) pair "applies" to a prefix only if the prefix acl "matches" the prefix. A match occurs if the prefix acl permits the prefix.
b.
If more than one (prefix acl, peer acl) pair from multiple mpls ldp advertise-labels commands matches a prefix, the (prefix acl, peer acl) pair in the first such command (as determined by the show running command) "applies" to the prefix.
3.
When an LSR is ready to advertise a label for a prefix, the LSR:
a.
Determines whether a (prefix acl, peer acl) pair applies to the prefix.
b.
If none applies, and if the no mpls ldp advertise-labels command has been configured, the label for the prefix is not advertised to any peer; otherwise, the label is advertised to all peers.
c.
If a (prefix acl, peer acl) pair applies to the prefix, and if the prefix acl "denies" the prefix, the label is not advertised to any peer.
d.
If the prefix acl "permits" the prefix and the peer acl is none (that is, the command that "applies" to the prefix is an mpls ldp advertise-labels for prefix acl command without the to keyword), then the label is advertised to all peers.
e.
If the prefix acl "permits" the prefix and there is a peer acl, then the label is advertised to all peers permitted by the peer acl.
Note
The mpls ldp advertise-labels command has no effect on an LC-ATM interface. Such an interface behaves as though this command had not been executed.
Examples
In the following example, the router is configured to advertise no locally assigned labels to any LDP neighbors.
Router(config)# no mpls ldp advertise-labelsIn the following example, the router is configured to advertise to all LDP neighbors only the labels for networks 10.101.0.0 and 10.221.0.0.
Router(config)# ip access-list standard pfx-filterRouter(config-std-nacl)# permit 10.101.0.0 0.0.255.255Router(config-std-nacl)# permit 10.221.0.0 0.0.255.255Router(config-std-nacl)# exitRouter(config)# mpls ldp advertise-labels for pfx-filterRouter(config)# no mpls ldp advertise-labelsIn the following example, the router is configured to advertise the label for network 59.0.0.0 only to LSR 155.0.0.55, the label for network 35.0.0.0 only to LSR 133.0.0.33, and the labels for all other prefixes to all LSRs.
Router(config)# ip access-list standard pfx-filter1Router(config-std-nacl)# permit 59.0.0.0Router(config-std-nacl)# exitRouter(config)# ip access-list standard lsr-filter1Router(config-std-nacl)# permit 155.0.0.55Router(config-std-nacl)# exitRouter(config)# ip access-list standard pfx-filter2Router(config-std-nacl)# permit 35.0.0.0Router(config-std-nacl)# exitRouter(config)# ip access-list standard lsr-filter2Router(config-std-nacl)# permit 133.0.0.33Router(config-std-nacl)# exitRouter(config)# mpls ldp advertise-labels for pfx-filter1 to lsr-filter1Router(config)# mpls ldp advertise-labels for pfx-filter2 to lsr-filter2The output of the show mpls ip binding detail command includes the (prefix acl, peer acl) pairs that apply to each prefix. For this example, the applicable pairs are as shown below:
Router# show mpls ip binding detailAdvertisement spec:Prefix acl = pfx-filter1; Peer acl = lsr-filter1Prefix acl = pfx-filter2; Peer acl = lsr-filter235.0.0.0/8, rev 109in label: 16Advertised to:133.0.0.33:0out label: imp-null lsr: 155.0.0.55:0 inuseout label: imp-null lsr: 133.0.0.33:0Advert acl(s): Prefix acl pfx-filter2, Peer acl lsr-filter259.0.0.0/8, rev 108in label: imp-nullAdvertised to:155.0.0.55:0out label: 16 lsr: 155.0.0.55:0out label: 19 lsr: 133.0.0.33:0Advert acl(s): Prefix acl pfx-filter1, Peer acl lsr-filter1113.0.0.33/32, rev 98out label: imp-null lsr: 133.0.0.33:0114.0.0.44/32, rev 99in label: imp-nullAdvertised to:155.0.0.55:0 133.0.0.33:0133.0.0.33/32, rev 101in label: 20Advertised to:155.0.0.55:0 133.0.0.33:0out label: 19 lsr: 155.0.0.55:0out label: imp-null lsr: 133.0.0.33:0 inuse144.0.0.44/32, rev 103in label: imp-nullAdvertised to:155.0.0.55:0 133.0.0.33:0out label: 20 lsr: 155.0.0.55:0out label: 18 lsr: 133.0.0.33:0155.0.0.55/32, rev 104in label: 17Advertised to:155.0.0.55:0 133.0.0.33:0out label: imp-null lsr: 155.0.0.55:0 inuseout label: 17 lsr: 133.0.0.33:0Related Commands
Command DescriptionUse method of earlier software releases to interpret the for prefix-access-list parameter for the mpls ldp advertise-labels command.
show mpls ip binding detail (see example above)
Shows detailed information about label bindings, including the access lists, if any, controlling which local labels are advertised to which LDP neighbors.
mpls ldp advertise-labels old-style
To cause the interpretation of the for prefix-access-list parameter for mpls ldp advertise-labels commands to be interpreted according to the method used in earlier Cisco IOS software versions, use the mpls ldp advertise-labels old-style command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp advertise-labels old-style
no mpls ldp advertise-labels old-style
Syntax Description
This command has no keywords or arguments.
Defaults
If this command is not specified, the for prefix-access-list parameter in any mpls ldp advertise-labels command is interpreted according to the rules specified under the "Usage Guidelines" heading for the mpls ldp advertise-labels command described in the preceding section.
Command Modes
Global configuration.
Command History
Usage Guidelines
The method for interpreting the for prefix-access-list parameter in mpls ldp advertise-labels commands is defined by Rule 2.a under the "Usage Guidelines" heading for the mpls ldp advertise-labels command described in the preceding section. This Rule 2.a follows normal access list conventions.
However, earlier Cisco IOS software versions used a different method for interpreting the for prefix-access-list parameter in mpls ldp advertise-labels commands. For those earlier software versions, Rule 2.a read as follows:
2. A given prefix can have, at most, one (prefix acl, peer acl) pair that "applies" to it.
a.
A given (prefix acl, peer acl) pair "applies" to a prefix only if the prefix acl "matches" the prefix. A match occurs if the prefix acl explicitly permits or denies the prefix by means of a permit or deny command. A prefix acl that contains a permit any or deny any command matches any prefix.
This earlier Rule 2.a departed from normal access list conventions in that:
•
An explicit deny (including a deny any) that matches the prefix causes the (prefix acl, peer acl) pair to apply to the prefix.
•
Explicit deny any and implicit deny any (which all access lists have) have different effects, in that the explicit deny any causes the access list pair to apply to all prefixes, but the implicit deny any has no effect.
If a configuration developed for use with earlier software versions depends on this previous method for interpreting the for prefix-access-list parameter in mpls ldp advertise-labels commands, and if it is inconvenient to update the configuration to work with Rule 2.a as it now appears under the "Usage Guidelines" heading described in the previous section for the mpls ldp advertise-labels command, use the mpls ldp advertise-labels old-style command to force the use of the old-style method of interpreting the for prefix-access-list parameter used by earlier software versions.
Examples
The following command causes the old-style method of interpreting the for prefix-access-list parameter to be used in executing mpls ldp advertise-labels commands:
Router# mpls ldp advertise-labels old-styleRelated Commands
mpls ldp atm control-mode
To control the mode used for handling label binding requests on LC-ATM interfaces, use the mpls ldp atm control-mode command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp atm control-mode {ordered | independent}
no mpls ldp atm control-mode {ordered | independent}
Syntax Description
Defaults
The default is ordered control mode.
Command Modes
Global configuration
Command History
Usage Guidelines
Use of ordered control mode by an ATM device acting as a transit LSR in an ATM cloud ensures that the device will receive labeled packets to forward only after it has learned the outgoing labels required by MPLS to forward the packets. Ordered control mode relieves the device of the burden of reassembling cells into packets that must be forwarded by means of the normal (non-MPLS) packet forwarding or discard mechanisms.
Use of independent control mode on ATM transit LSRs might slightly reduce the time an ATM edge router must wait to use an ATM LSP it has initiated. Independent control mode eliminates the need for the edge router to wait for the Label Request/Label Mapping signaling to traverse the ATM cloud from edge router ingress to egress and back before it can send packets into the LSP. However, there is a risk that an ATM transit device might receive labeled packets before it has learned the outgoing labels required for MPLS forwarding, thus forcing the transit device to reassemble the cells into a packet that it is likely to discard.
Examples
In the following example, the mode for handling LDP Label Request messages is set to "independent" for the platform:
Router# mpls ldp atm control-mode independentmpls ldp atm vc-merge
To control whether the vc-merge (multipoint-to-point) capability is supported for unicast label VCs, use the mpls ldp atm vc-merge command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp atm vc-merge
no mpls ldp atm vc-merge
Syntax Description
This command has no optional keywords or arguments.
Defaults
The ATM-VC merge capability is enabled by default if the hardware supports this feature; otherwise, the feature is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
Use of VC merge helps conserve ATM labels by allowing incoming LSPs from different sources for the same destination to be merged onto a single outgoing VC.
Examples
In the following example, the ATM-VC merge capability is disabled:
Router# no mpls ldp atm vc-mergeRelated Commands
Command DescriptionDisplays the ATM MPLS capabilities negotiated with LDP neighbors for LC-ATM interfaces.
mpls ldp backoff
To configure parameters for the LDP backoff mechanism, use the mpls ldp backoff command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp backoff initial-backoff maximum-backoff
no mpls ldp backoff initial-backoff maximum-backoff
Syntax Description
Defaults
The initial backoff value is 15 seconds and grows to a maximum value of 120 seconds.
Command Modes
Global Configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
The LDP backoff mechanism prevents two incompatibly configured LSRs from engaging in an unthrottled sequence of session setup failures. For example, an incompatibility arises when two neighboring routers attempt to perform LC-ATM (label-controlled ATM) but the two are using different ranges of VPI/VCI values for labels.
If a session setup attempt fails due to an incompatibility, each LSR delays its next attempt (that is, backs off), increasing the delay exponentially with each successive failure until the maximum backoff delay is reached.
The default settings correspond to the lowest settings for initial and maximum backoff values defined by the LDP protocol specification. You should change the settings from the default values only if such settings result in undesirable behavior.
Examples
The following command sets the initial backoff delay to 30 seconds and the maximum backoff delay to 240 seconds:
Router(config)# mpls ldp backoff 30 240Related Commands
mpls ldp discovery
To configure the interval between transmission of consecutive LDP discovery Hello messages, or the hold time for a discovered LDP neighbor, or the neighbors from which requests for targeted Hello messages may be honored, use the mpls ldp discovery command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp discovery {hello {holdtime | interval} seconds | targeted-hello
{holdtime | interval} seconds | accept [from acl]}no mpls ldp discovery {hello {holdtime | interval} | targeted-hello
{holdtime | interval} | accept}Syntax Description
Defaults
The default value for the holdtime argument is 15 (seconds) for link Hello messages and 45 (seconds) for targeted Hello messages.
The default value for the interval argument (seconds) is 5.
Requests for targeted Hello messages are not accepted from any neighbor.
Command Modes
Global configuration
Command History
Usage Guidelines
When the discovery hold time elapses for a neighbor discovered on an interface or for a neighbor discovered by means of a targeted Hello message, the record associating the neighbor with that interface or that targeted Hello message source is discarded. If an LDP session exists with a neighbor, but a discovery record no longer exists for that neighbor, the LDP session is terminated.
Setting the hold time too high causes LDP to be slow in detecting link outages; setting the hold time too low might cause LDP to terminate sessions when a Hello message is dropped during traffic bursts on a link.
The exchange of targeted Hello messages between two nondirectly connected neighbors (N1 and N2) may occur in the following ways:
•
N1 may initiate the transmission of targeted Hello messages to N2, and N2 may send targeted Hello messages in response. In this situation, N1 is considered to be active and N2 is considered to be passive.
N1's targeted Hello messages carry a request that N2 send targeted Hello messages in response. To respond, N2's configuration must permit it to respond to N1. The mpls ldp discovery targeted-hello accept command is used to configure whether N1 may respond to requests for targeted Hello messages.
•
N1 and N2 may both be configured to initiate the transmission of targeted Hello messages to each other. In this situation, both are active.
Both, one, or neither of N1 and N2 may be passive, depending on whether they have been configured to respond to requests for targeted Hello messages from the other.
Note
Normally, active transmission of targeted Hello messages by a router is triggered by some configuration action, such as an mpls ip command on a traffic engineering tunnel interface.
Examples
In the following example, the period of time for which a neighbor discovered on an interface is remembered if no Hello messages are received is set to 30 seconds:
Router# configure terminalRouter(config)# mpls ldp discovery hello holdtime 30The following example configures the router to respond to requests for targeted Hello messages from neighbors 157.13.0.23 and 168.73.0.18:
Router(config)# ip access standard TRGT_ACCEPTRouter(config-nacl)# permit 157.13.0.23Router(config-nacl)# permit 1168.73.0.18Router(config-nacl)# exitRouter(config)# mpls ldp discovery targeted-hello accept from TRGT_ACCEPTRelated Commands
mpls ldp discovery transport-address
To specify the transport address advertised in LDP Discovery Hello messages sent on an interface, use the mpls ldp discovery transport-address command in interface configuration mode. Use the no form of the command to disable this feature.
mpls ldp discovery transport-address {interface | IP address}
no mpls ldp discovery transport-address
Syntax Description
Defaults
The default behavior when this command has not been issued for an interface depends on the interface type.
Unless the interface is a label-controlled atm (LC-ATM) interface, LDP advertises its LDP Router Id as the transport address in LDP Discovery Hello messages sent from the interface.
If the interface is an LC-ATM interface, no transport address is explicitly advertised in LDP Discovery Hello messages sent from the interface.
Command Modes
Interface configuration
Command History
Release Modification12.0(14)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
The establishment of an LDP session between two routers requires a session TCP connection by which label advertisements can be exchanged between the routers. To establish the session TCP connection, each router must know the transport address (IP address) of the other router.
The LDP discovery mechanism provides the means for a router to advertise the transport address for its end of a session TCP connection. The transport address advertisement itself may be explicit, in which case it appears as part of the contents of Discovery Hello messages sent to the peer, or implicit, in which case it does not, and the peer uses the source IP address of received Hello messages for the peer's transport address.
The mpls ldp discovery transport-address command provides the means to modify the default behavior described above. When the interface alternative is specified, LDP advertises the IP address of the interface in LDP Discovery Hello messages sent from the interface. When the IP address alternative is specified, LDP advertises the specified IP address in LDP Discovery Hello messages sent from the interface.
Note
When a router has multiple links connecting it to its peer device, the router must advertise the same transport address in the LDP Discovery Hello messages it sends on all such interfaces.
Examples
The following example specifies that the LDP transport address for interface pos2/0 should be the interface IP address; it also specifies that the IP address 145.22.0.56 of interface pos3/1 should be the LDP transport address.
Router(config#) interface pos2/0Router(config-if)# mpls ldp discovery transport-address interfaceRouter(config#) interface pos3/1Router(config-if)# mpls ldp discovery transport-address 145.22.0.56Related Commands
mpls ldp explicit-null
To cause a router to advertise an Explicit Null label in situations where it would normally advertise an Implicit Null label, use the mpls ldp explicit-null command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp explicit-null [for prefix-acl | to peer-acl | for prefix-acl to peer-acl]
no mpls ldp explicit-null
Syntax Description
Defaults
The default behavior is to advertise Implicit Null for directly connected routes unless the command mpls ldp explicit-null has been executed.
Command Modes
Global configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
Normally, LDP advertises an Implicit Null label for directly connected routes. The Implicit Null label causes the previous hop (penultimate) router to do penultimate hop popping. Situations exist where it might be desirable to prevent the penultimate router from performing penultimate hop popping and to force it to replace the incoming label with the Explicit Null label.
When you issue the mpls ldp explicit-null command, Explicit Null is advertised in place of Implicit Null for directly connected prefixes permitted by prefix-acl to peers permitted by peer-acl.
If you do not specify the prefix-acl argument in the command, Explicit Null is advertised in place of Implicit Null for all directly connected prefixes.
If you do not specify the peer-acl argument in the command, Explicit Null is advertised in place of Implicit Null to all peers.
Examples
The following command causes Explicit Null to be advertised for all directly connected routes to all LDP peers:
Router(config)# mpls ldp explicit-nullThe following command sequence causes Explicit Null to be advertised for directly connected route 137.5.0.0 to all LDP peers and Implicit Null to be advertised for all other directly connected routes:
Router(config)# mpls ldp explicit-nullRouter(config)# ip access-list standard adv-exp-nullRouter(config-std-nacl)# permit 137.5.0.0Router(config-std-nacl)# deny anyRelated Commands
mpls ldp holdtime
To change the time for which an LDP session is maintained in the absence of LDP messages from the session peer, use the mpls ldp holdtime command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp holdtime seconds
no mpls ldp holdtime seconds
Syntax Description
seconds
A number between 15 and 2147483, inclusive, that defines the time, in seconds, an LDP session is maintained in the absence of LDP messages from the session peer.
Defaults
The default value for the seconds argument is 180.
Command Modes
Global configuration
Command History
Usage Guidelines
When an LDP session is established between two LSRs, the hold time used for the session is the lower of the values configured on the two LSRs.
Examples
In the following example, the hold time of LDP sessions is configured for 30 seconds:
Router# mpls ldp holdtime 30Related Commands
Command DescriptionDisplays current LDP parameter settings.
Configures parameters for the LDP discovery mechanism.
mpls ldp loop-detection
To enable the LDP optional loop detection mechanism, use the mpls ldp loop-detection command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp loop-detection
no mpls ldp loop-detection
Syntax Description
This command has no optional keywords or arguments.
Defaults
LDP loop detection is off.
Command Modes
Global configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
The LDP loop detection mechanism is intended for use in networks of non-TTL (time-to-live) decrementing devices (for example, ATM switches) that are incapable of fairly allocating device resources among traffic flows.
When configured, the LDP loop detection mechanism is used with the Downstream on Demand (DoD) method of label distribution, supplementing the DoD hop count mechanism to detect looping LSPs that might occur during routing transients. When looping LSPs are detected, the loop is not set up.
Examples
The following command sets the LDP loop detection mechanism on:
Router(config)# mpls ldp loop-detectionRelated Commands
Command DescriptionLimits the number of hops permitted for LSPs to a specified value. An LSP with more hops than the specified value is treated as one with a loop that will not be established.
mpls ldp maxhops
To limit the number of hops permitted in an LSP established by the Downstream on Demand method of label distribution, use the mpls ldp maxhops command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp maxhops number
no mpls ldp maxhops
Syntax Description
Defaults
The default value for the maximum hop count argument (number) is 254.
Command Modes
Global configuration
Command History
Usage Guidelines
When an ATM LSR initiates a request for a label binding, it sets the hop count value in the Label Request message to 1. Subsequent ATM-LSRs along the path to the edge of the ATM label switching region increment the hop count before forwarding the Label Request message to the next hop.
When an ATM LSR receives a Label Request message, it does not send a Label Mapping message in response, nor does it propagate the request to the destination next hop if the hop count value in the request equals or exceeds the maxhops value. Instead, the ATM LSR returns an error message that specifies that the maximum allowable hop count has been reached. This threshold is used to prevent forwarding loops in the setting up of label switch paths across an ATM region.
Examples
In the following example, the hop count limit is set to 10.
Router(config)# mpls ldp maxhops 10Related Commands
mpls ldp neighbor
To configure a password key for use with the TCP Message Digest 5 (MD5) Signature Option for the session TCP connection with the specified neighbor, use the mpls ldp neighbor command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp neighbor ip addr password [0-7] pswd-string
no mpls ldp neighbor ip addr password [0-7] pswd-string
Syntax Description
Defaults
Unless the TCP MD5 Signature Option is explicitly configured for session TCP connections, the option is not used.
Command Modes
Global configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
You can invoke authentication between two LDP peers, verifying each segment sent on the TCP connection between the peers. To do so, you must configure authentication on both LDP peers using the same password; otherwise, the peer session is not established.
The authentication capability uses the MD5 (Message Digest 5) algorithm. MD5, an algorithm used in conjunction with SNMP, verifies the integrity of the communication, authenticates the origin of the message, and checks for timeliness.
Invoking the mpls ldp neighbor command causes the generation and checking of the MD5 digest for every segment sent on the TCP connection.
Configuring a password for an LDP neighbor causes an existing LDP session to be torn down and a new session to be established.
If a router has a password configured for a neighbor, but the neighbor router does not have a password configured, a message such as the following appears on the console while the two routers attempt to establish an LDP session:
%TCP-6-BADAUTH: No MD5 digest from [peer's IP address]:11003 to [local router's IP address]:179Similarly, if the two routers have different passwords configured, a message such as the following appears on the console:
%TCP-6-BADAUTH: Invalid MD5 digest from [peer's IP address]:11004 to [local router's IP address]:179Examples
In the following example, the string "onethirty9" is configured as the password key for use with MD5 for the neighbor whose router ID is 139.27.0.15:
Router(config)# mpls ldp neighbor 139.27.0.15 password onethirty9mpls ldp router-id
To specify a preferred interface for determining the LDP router ID, use the mpls ldp router-id command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp router-id interface [force]
no mpls ldp router-id
Syntax Description
Defaults
If the mpls ldp router-id command is not executed, the LDP router ID is determined as follows:
a.
The IP addresses of all operational interfaces are examined.
b.
If these IP addresses include loopback interface addresses, the largest such loopback address is selected as the LDP router ID.
c.
Otherwise, the largest IP address pertaining to an operational interface is selected as the LDP router ID.
Command Modes
Global configuration
Command History
Usage Guidelines
The normal (default) method for determining the LDP router ID may result in a router ID that is not usable in certain situations. For example, an IP address selected as the LDP router ID might not be advertisable by the routing protocol to a neighboring router. The mpls ldp router-id command provides a means for specifying an interface whose IP address is to be used as the LDP router ID. Note, however, that the specified interface must be operational in order for its IP address to be used as the LDP router ID.
When executed without the force option, the mpls ldp router-id command modifies the method for determining the LDP router ID by causing selection of the IP address of the specified interface (provided that the interface is operational) the next time it is necessary to select an LDP router ID. The effect of the command is delayed until the next time it is necessary to select an LDP router ID, which is typically the next time the interface whose address is the current LDP router ID is shut down or the address itself is deconfigured.
When executed with the force option, the effect of the mpls ldp router-id command depends on the current state of the specified interface:
a.
If the interface is up (operational) when the mpls ldp router-id force command is issued and if its IP address is not currently the LDP router ID, the LDP router ID is forcibly changed to the IP address of the interface. This forced change in the LDP router ID tears down any existing LDP sessions, releases label bindings learned via the LDP sessions, and interrupts MPLS forwarding activity associated with the bindings.
b.
If the interface is down when the mpls ldp router-id force command is issued, when the interface transitions to up, the LDP router ID is forcibly changed to the IP address of the interface. This forced change in the LDP router ID tears down any existing LDP sessions, releases label bindings learned via the LDP sessions, and interrupts MPLS forwarding activity associated with the bindings.
Examples
The example below shows that the pos2/0/0 interface has been specified as the preferred interface for use in determining the LDP router ID. The IP address of such a specified interface is used as the LDP router ID.
Router(config)# mpls ldp router-id pos2/0/0Related Commands
Command DescriptionDisplays the status of the LDP discovery process, including the local LDP router Id and the LDP router Ids of discovered LSRs.
mpls ldp targeted-sessions
To configure the use of LDP for "targeted" sessions, use the mpls ldp targeted-sessions command in global configuration mode. Use the no form of the command to disable this feature.
mpls ldp targeted-sessions [with access-list]
no mpls ldp targeted-sessions [with access-list]
Syntax Description
Defaults
Use LDP for targeted sessions.
Command Modes
Global configuration
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
A "targeted" label distribution session is one between two platforms that are not directly connected by a link. (Such a session is called a targeted session because the discovery Hello messages that support it are sent directly to the peer platform instead of to the "all routers on this subnet" multicast address.)
The mpls ldp targeted-sessions command specifies that LDP should be used for all targeted sessions or specific targeted sessions defined by an IP access list.
Examples
The following command sequence causes targeted sessions to 155.0.0.55 and 144.0.0.44 to use LDP and all other targeted sessions to use TDP.
Router(config)# access-list 1 permit 155.0.0.55Router(config)# access-list 1 permit 144.0.0.44Router(config)# mpls ldp targeted-sessions with 1Related Commands
Command DescriptionDisplays current LDP parameter settings.
Displays the status of the LDP discovery process.
Displays the status of LDP sessions.
show mpls atm-ldp bindings
To display specified entries from the ATM label binding database, use the show mpls atm-ldp bindings command in privileged EXEC mode. To display summary information about all the entries in the ATM label binding database, use the show mpls atm-ldp-bindings summary command in privileged EXEC mode.
The ATM label binding database contains entries for label VCs on LC-ATM interfaces.
show mpls atm-ldp bindings [network {mask | length}] [local-label vpi vci] [remote-label vpi vci] [neighbor interface]
show mpls atm-ldp-bindings summary
Syntax Description
Defaults
The entire ATM label binding database is displayed if no optional parameters or keywords are specified.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Command output can show a summary of entries from the entire database, or the output can be limited to a subset of entries based on the following:
•
Specific prefix
•
Specific VC label value
•
Specific assigning interface
Note
This command displays ATM label bindings learned by LDP or TDP.
Note
The command show mpls ip binding includes the output generated by show mpls atm-ldp bindings as well as information about label bindings for packet interfaces.
Examples
The following shows sample output from the show mpls atm-ldp bindings command:
Router# show mpls atm-ldp bindingsDestination: 10.24.0.0/24Tailend Router ATM1/0.1 1/39 Active, VCD=3Destination: 10.15.0.15/32Tailend Router ATM1/0.1 1/33 Active, VCD=4Destination: 203.0.7.7/32Headend Router ATM1/0.1 (2 hops) 1/34 Active, VCD=810The following is sample output from the show mpls atm-ldp bindings command on an ATM switch:
Router# show mpls atm-ldp bindingsDestination: 150.0.0.0/16Tailend Switch ATM0/0/3 1/35 Active -> Terminating ActiveDestination: 4.4.4.4/32Transit ATM0/0/3 1/33 Active -> ATM0/1/1 1/33 ActiveTable 16 describes the significant fields in the sample display shown above.
The following is sample output from the show mpls atm-ldp bindings summary command:
Router# show mpls atm-ldp bindings summaryTotal number of destinations: 406ATM label bindings summaryinterface total active local remote Bwait Rwait IFwaitATM0/0/0 406 406 404 2 0 0 0ATM0/0/1 406 406 3 403 0 0 0Table 17 describes the significant fields in the sample display shown above.
show mpls atm-ldp capability
To display the ATM MPLS capabilities negotiated with LDP neighbors for LC-ATM interfaces, use the show mpls atm-ldp capability command in privileged EXEC mode.
show mpls atm-ldp capability
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command always displays all of the ATM MPLS capabilities negotiated with all of the LDP neighbors.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When two LSRs establish an LDP session, they negotiate parameters for the session, such as the range of VPIs and VCIs that will be used as labels.
This command displays the ATM MPLS capabilities negotiated by LDP or TDP.
Examples
The following shows sample output from the show mpls atm-ldp capability command.
Router# show mpls atm-ldp capabilityVPI VCI Alloc Odd/Even VC MergeATM0/1/0 Range Range Scheme Scheme IN OUTNegotiated [100 - 101] [33 - 1023] UNIDIR - -Local [100 - 101] [33 - 16383] UNIDIR EN ENPeer [100 - 101] [33 - 1023] UNIDIR - -VPI VCI Alloc Odd/Even VC MergeATM0/1/1 Range Range Scheme Scheme IN OUTNegotiated [201 - 202] [33 - 1023] BIDIR - -Local [201 - 202] [33 - 16383] UNIDIR ODD NO NOPeer [201 - 202] [33 - 1023] BIDIR EVEN - -Table 18 describes the significant fields shown in the sample display above.
Related Commands
Command DescriptionControls whether vc-merge (multipoint-to-point) is supported for unicast label VCs.
show mpls interfaces
To display information about one or more or all interfaces that have been configured for label switching, use the show mpls interfaces command in privileged EXEC mode.
show mpls interfaces [interface] [detail]
Syntax Description
interface
(Optional.) Defines the interface about which to display label switching information.
detail
(Optional.) Displays detailed label switching information for the specified interface.
Defaults
If no optional keyword or parameter is specified in this command, summary information is displayed for each interface that has been configured for label switching.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command shows MPLS information about the specified interface, or about all of the interfaces for which MPLS has been configured.
Examples
The following shows sample output generated by the show mpls interfaces command:
Router# show mpls interfacesInterface IP Tunnel OperationalEthernet1/1/1 Yes (tdp) No NoEthernet1/1/2 Yes (tdp) Yes NoEthernet1/1/3 Yes (tdp) Yes YesPOS2/0/0 Yes (tdp) No NoATM0/0.1 Yes (tdp) No No (ATM labels)ATM3/0.1 Yes (ldp) No Yes (ATM labels)ATM0/0.2 Yes (tdp) No Yes
Note
If an interface uses LC-ATM procedures, the associated line in the display is flagged with the notation (ATM labels).
Table 19 describes the significant fields in the sample display shown above.
The following is sample output from the show mpls interfaces command when you specify the detail keyword:
Router# show mpls interfaces detailInterface Ethernet1/1/1:IP labeling enabled (tdp)LSP Tunnel labeling not enabledMPLS operationalMPLS turbo vectorMTU = 1500Interface POS2/0/0:IP labeling enabled (ldp)LSP Tunnel labeling not enabledMPLS not operationalMPLS turbo vectorMTU = 4470Interface ATM3/0.1:IP labeling enabled (ldp)LSP Tunnel labeling not enabledMPLS operationalMPLS turbo vectorMTU = 4470ATM labels: Label VPI = 1Label VCI range = 33 - 65535Control VC = 0/32Related Commands
show mpls ip binding
To display specified information about label bindings learned by LDP, use the show mpls ip binding command in privileged EXEC mode. To summarize information about label bindings learned by LDP, use the show mpls ip binding summary command in privileged EXEC mode.
show mpls ip binding [network {mask | length} [longer-prefixes]]
[local-label {atm vpi vci | label [- label]}]
[remote-label {atm vpi vci | label [- label]}]
[neighbor address] [local]
[interface interface] [generic | atm]show mpls ip binding summary
Syntax Description
Defaults
All label bindings are displayed when no optional parameters are specified.
Command Modes
Privileged EXEC
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Usage Guidelines
The show mpls ip binding command displays label bindings learned by LDP or TDP.
A request can specify that the entire database be displayed, that a summary of entries from the database be displayed, or that the display be limited to a subset of entries. The subset can be limited according to any of the following:
•
Prefix
•
Input or output label values or ranges
•
Neighbor advertising the label
•
Interface for label bindings of interest (LC-ATM only)
•
Generic (non-LC-ATM) label bindings
•
LC-ATM label bindings
Examples
The following shows sample output from the show mpls ip binding command. The output shows all of the label bindings in the database.
Router# show mpls ip binding34.0.0.0/8in label: 20out label: 26 lsr: 155.0.0.55:0out vc label: 1/80 lsr: 203.0.7.7:2 ATM1/0.8Active ingress 3 hops (vcd 49)45.0.0.0/8in label: 25in vc label: 1/36 lsr: 203.0.7.7:2 ATM1/0.8Active egress (vcd 55)out label: imp-null lsr: 155.0.0.55:0 inuse66.66.0.66/32in label: 26in vc label: 1/39 lsr: 203.0.7.7:2 ATM1/0.8Active egress (vcd 58)out label: 16 lsr: 155.0.0.55:0 inuse133.0.0.33/32in label: 23out label: 22 lsr: 155.0.0.55:0out vc label: 1/83 lsr: 203.0.7.7:2 ATM1/0.8Active ingress 3 hops (vcd 52)144.0.0.44/32in label: 61out label: 27 lsr: 155.0.0.55:0 inuse150.88.0.0/16in label: 28in vc label: 1/40 lsr: 203.0.7.7:2 ATM1/0.8Active egress (vcd 59)out label: imp-null lsr: 155.0.0.55:0 inuse166.47.0.0/16in label: 33in vc label: 1/46 lsr: 203.0.7.7:2 ATM1/0.8Active egress (vcd 65)out label: imp-null lsr: 155.0.0.55:0 inuse194.44.44.0/24in label: 24in vc label: 1/37 lsr: 203.0.7.7:2 ATM1/0.8Active egress (vcd 56)out label: imp-null lsr: 155.0.0.55:0 inuseIn the following example, a request is made for the display of the label binding information for prefix 194.44.44.0/24:
Router# show mpls ip binding 194.44.44.0 24194.44.44.0/24in label: 24in vc label: 1/37 lsr: 203.0.7.7:2 ATM1/0.8Active egress (vcd 56)out label: imp-null lsr: 155.0.0.55:0 inuseIn the following example, the local-label keyword is used to request that label binding information be displayed for the prefix(es) with local label 58:
Router# show mpls ip binding local-label 58166.253.0.0/16in label: 58out label: imp-null lsr: 155.0.0.55:0 inuseTable 20 describes the significant fields in the sample display shown above.
In the following example, summary information about the label bindings learned by LDP is shown:
Router# show mpls ip binding summaryTotal number of prefixes: 53Generic label bindingsassigned learnedprefixes in labels out labels53 53 51ATM label bindings summaryinterface total active local remote Bwait Rwait IFwaitATM1/0.8 47 47 40 7 0 0 0Table 21 describes the significant fields in the sample display shown above.
Related Commands
Command DescriptionDisplays the contents of the label information base (LIB).
Displays specified entries from the ATM label binding database.
show mpls ldp backoff
To display information about the configured session setup backoff parameters and any potential LDP peers with which session setup attempts are being throttled, use the show mpls ldp backoff command in privileged EXEC mode.
show mpls ldp backoff
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Release Modification12.0(10)ST
This command was introduced.
12.1(8a)E
This command was integrated into Cisco IOS Release 12.1(8a)E.
Examples
The following shows sample output from the show mpls ldp backoff command.
Router# show mpls ldp backoffLDP initial/maximum backoff: 30/240 secBackoff table: 2 entriesLDP Id Backoff(sec) Waiting(sec)144.0.0.44:0 60 30155.0.0.55:0 120 90Table 22 describes the significant fields in the sample display shown above.
Related Commands
show mpls ldp bindings
To display the contents of the label information base (LIB), use the show mpls ldp bindings command in privileged EXEC mode:
show mpls ldp bindings [network {mask | length} [longer-prefixes]]
[local-label label [- label]} [remote-label label [- label] [neighbor address] [local]Syntax Description
Defaults
If no optional keyword or parameter is supplied, the command displays the entire label information base (LIB).
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The show mpls ldp bindings command displays label bindings learned by LDP or TDP.
A request can specify that the entire database be displayed, or that the display be limited to a subset of entries according to the following:
•
Prefix
•
Input or output label values or ranges
•
Neighbor advertising the label
Note
The command show mpls ip binding includes the output generated by the show mpls ldp bindings command, as well as information about label bindings for LC-ATM interfaces.
Examples
The following shows sample output from the show mpls ldp bindings command. This form of the command causes the contents of the entire FIB to be displayed.
Router# show mpls ldp bindings34.0.0.0/8, rev 9local binding: label: imp-nullremote binding: lsr: 155.0.0.55:0, label: 17remote binding: lsr: 66.66.0.66:0, label: 18remote binding: lsr: 144.0.0.44:0, label: imp-null45.0.0.0/8, rev 17local binding: label: 19remote binding: lsr: 155.0.0.55:0, label: imp-nullremote binding: lsr: 66.66.0.66:0, label: 16remote binding: lsr: 144.0.0.44:0, label: imp-null66.66.0.66/32, rev 19local binding: label: 20remote binding: lsr: 155.0.0.55:0, label: 19remote binding: lsr: 66.66.0.66:0, label: imp-nullremote binding: lsr: 144.0.0.44:0, label: 18103.0.0.0/8, rev 11local binding: label: imp-null130.77.0.0/16, rev 23local binding: label: 22remote binding: lsr: 155.0.0.55:0, label: 22remote binding: lsr: 144.0.0.44:0, label: 21remote binding: lsr: 66.66.0.66:0, label: 20140.66.0.0/16, rev 96remote binding: lsr: 66.66.0.66:0, label: imp-null155.0.0.55/32, rev 29local binding: label: 25remote binding: lsr: 155.0.0.55:0, label: imp-nullremote binding: lsr: 144.0.0.44:0, label: 24remote binding: lsr: 66.66.0.66:0, label: 24166.45.0.0/16, rev 33local binding: label: 27remote binding: lsr: 155.0.0.55:0, label: imp-nullremote binding: lsr: 66.66.0.66:0, label: 26remote binding: lsr: 144.0.0.44:0, label: 26166.46.0.0/16, rev 35local binding: label: 28remote binding: lsr: 155.0.0.55:0, label: imp-nullremote binding: lsr: 66.66.0.66:0, label: 27remote binding: lsr: 144.0.0.44:0, label: 27. . .The following is sample output from the show mpls ldp bindings 166.0.0.0 8 longer-prefixes neighbor 144.0.0.44 variant of the command; it displays labels learned from LSR 144.0.0.44 for network 166.0.0.0 and any of its subnets. The use of the neighbor option suppresses the output of local labels and labels learned from other neighbors.
Router# show mpls ldp bindings 166.0.0.0 8 longer-prefixes neighbor 144.0.0.44166.44.0.0/16, rev 31remote binding: lsr: 144.0.0.44:0, label: 25166.45.0.0/16, rev 33remote binding: lsr: 144.0.0.44:0, label: 26166.245.0.0/16, rev 71remote binding: lsr: 144.0.0.44:0, label: 45166.246.0.0/16, rev 73remote binding: lsr: 144.0.0.44:0, label: 46. . .Table 23 describes the significant fields in the sample display shown above.
Related Commands
show mpls ldp discovery
To display the status of the LDP discovery process, use the show mpls ldp discovery command in privileged EXEC mode. This command generates a list of interfaces over which the LDP discovery process is running.
show mpls ldp discovery
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command displays neighbor discovery information for LDP or TDP.
Examples
The following shows sample output from the show mpls ldp discovery command.
Router# show mpls ldp discoveryLocal LDP Identifier:8.1.1.1:0Discovery Sources:Interfaces:Ethernet1/1/3 (ldp): xmit/recvLDP Id: 177.73.0.77:0LDP Id: 144.0.0.44:0LDP Id: 155.0.0.55:0ATM3/0.1 (ldp): xmit/recvLDP Id: 203.0.7.7:2ATM0/0.2 (tdp): xmit/recvTDP Id: 119.1.0.1:1Targeted Hellos:8.1.1.1 -> 133.0.0.33 (ldp): active, xmit/recvLDP Id: 133.0.0.33:08.1.1.1 -> 168.7.0.16 (tdp): passive, xmit/recvTDP Id: 133.0.0.33:0Table 24 describes the significant fields in the sample display shown above.
Related Commands
show mpls ldp neighbor
To display the status of LDP sessions, issue the show mpls ldp neighbor command in privileged EXEC mode:
show mpls ldp neighbor [address | interface] [detail]
Syntax Description
address
(Optional) Identifies the neighbor with this IP address.
interface
(Optional) Defines the LDP neighbors accessible over this interface.
detail
(Optional) Displays information in long form.
Defaults
This command displays information about all LDP neighbors if no optional keywords or arguments are specified.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The show mpls ldp neighbor command can provide information about all LDP neighbors, or the information can be limited to the following:
•
Neighbor with specific IP address
•
LDP neighbors known to be accessible over a specific interface
Note
This command displays information about LDP and TDP neighbor sessions.
Examples
The following shows sample output from the show mpls ldp neighbor command:
Router# show mpls ldp neighborPeer LDP Ident: 203.0.7.7:2; Local LDP Ident 8.1.1.1:1TCP connection: 203.0.7.7.11032 - 8.1.1.1.646State: Oper; Msgs sent/rcvd: 5855/6371; Downstream on demandUp time: 13:15:09LDP discovery sources:ATM3/0.1Peer LDP Ident: 7.1.1.1:0; Local LDP Ident 8.1.1.1:0TCP connection: 7.1.1.1.646 - 8.1.1.1.11006State: Oper; Msgs sent/rcvd: 4/411; DownstreamUp time: 00:00:52LDP discovery sources:Ethernet1/0/0Addresses bound to peer LDP Ident:2.0.0.29 7.1.1.1 59.0.0.199 212.10.1.110.205.0.9Table 25 describes the significant fields in the sample display shown above.
Related Commands
show mpls ldp parameters
To display current LDP parameters, use the show mpls ldp parameters command in privileged EXEC mode:
show mpls ldp parameters
Syntax Description
This command has no optional keywords or arguments.
Defaults
This command has no default behavior or values.
Command Modes
Privileged EXEC
Command History
Examples
The following shows sample output from the show mpls ldp parameters command:
Router# show mpls ldp parametersProtocol version: 1Downstream label pool: min label 16; max label 100000Session hold time: 180 sec; keep alive interval: 60 secDiscovery hello: holdtime: 15 sec; interval: 5 secDiscovery targeted hello: holdtime: 180 sec; interval: 5 secLDP for targeted sessions; peer acl: 1LDP initial/maximum backoff: 30/240 secTable 26 describes the significant fields in the sample display above.
Table 26 show mpls ldp parameters Command Field Descriptions
Field DescriptionProtocol version
Indicates the version of LDP running on the platform.
Downstream label pool
Describes the range of labels available for the platform to assign for label switching purposes. The available labels range from the smallest label value (min label) to the largest label value (max label), with a modest number of labels at the low end of the range (reserved labels) reserved for diagnostic purposes.
Session hold time
Indicates the time that an LDP session is to be maintained with an LDP peer without receiving LDP traffic or an LDP keepalive message from the peer.
keep alive interval
Indicates the interval of time between consecutive transmissions of LDP keepalive messages to an LDP peer.
Discovery hello
Indicates the amount of time to remember that a neighbor platform wants an LDP session without receiving an LDP Hello message from the neighbor (hold time), and the time interval between the transmission of consecutive LDP Hello messages to neighbors (interval).
Discovery targeted hello
Indicates the amount of time to remember that a neighbor platform wants an LDP session when:
1.
The neighbor platform is not directly connected to the router.
2.
The neighbor platform has not sent an LDP Hello message. This intervening interval is known as hold time.
Also indicates the time interval between the transmission of consecutive Hello messages to a neighbor not directly connected to the router.
LDP for targeted sessions
Reports the parameters that have been set by the mpls ldp targeted-sessions command.
LDP initial/maximum backoff
Reports the parameters that have been set by the mpls ldp backoff command.
Related Commands
Command DescriptionConfigures the interval between transmission of LDP discovery Hello messages.
Configures keepalive message hold time for LDP sessions.
Glossary
ATM-LSR—A label switch router with a number of LC-ATM interfaces. The router forwards the cells among these interfaces using labels carried in the VPI/VCI field of the ATM cell header.
ATM edge LSR—A router that is connected to the ATM-LSR cloud through LC-ATM interfaces. The ATM edge LSR adds labels to unlabeled packets and strips labels from labeled packets.
CoS—Class of service. A feature that provides scalable, differentiated types of service across an MPLS network.
label—A short fixed-length label that tells switching nodes how to forward data (packets or cells).
label-controlled ATM interface (LC-ATM interface)—An interface on a router or switch that uses label distribution procedures to negotiate label VCs.
label edge router (LER)—A router that performs label imposition.
label imposition—The action of putting the first label on a packet.
Label switch—A node that forwards units of data (packets or cells) on the basis of labels.
label-switched path (LSP)—A sequence of hops (Router 0...Router n) in which a packet travels from R0 to Rn by means of label switching mechanisms. A label-switched path can be chosen dynamically, based on normal routing mechanisms, or it can be configured manually.
label-switched path (LSP) tunnel—A configured connection between two routers, in which label switching techniques are used for packet forwarding.
Label switching router (LSR)—A Layer 3 router that forwards a packet based on the value of a label encapsulated in the packet.
Label VC (LVC)—An ATM virtual circuit that is set up through ATM LSR label distribution procedures.
LDP—Label distribution protocol. The protocol used to distribute label bindings to LSRs.
LFIB—Label forwarding information base. The data structure used by switching functions to switch labeled packets.
LIB—Label information base. A database used by an LSR to store labels learned from other LSRs, as well as labels assigned by the local LSR.
MPLS—Multiprotocol label switching. An emerging industry standard that defines support for MPLS forwarding of packets along normally routed paths (sometimes called MPLS hop-by-hop forwarding).
tailend—The downstream, received end of a tunnel.
traffic engineering—The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been applied.
traffic engineering tunnel—A label-switched tunnel that is used for traffic engineering. Such a tunnel is set up through means other than normal Layer 3 routing; it is used to direct traffic over a path different from the one that Layer 3 routing would cause the tunnel to take.




