Label Distribution Protocol
This chapter provides information to enable Label Distribution Protocol (LDP).
Label Distribution Protocol
Label Distribution Protocol (LDP) is a protocol used to distribute labels in non-traffic-engineered applications. LDP allows routers to establish label switched paths (LSPs) through a network by mapping network-layer routing information directly to data link layer-switched paths.
An LSP is defined by the set of labels from the ingress Label Switching Router (LSR) to the egress LSR. LDP associates a Forwarding Equivalence Class (FEC) with each LSP it creates. A FEC is a collection of common actions associated with a class of packets. When an LSR assigns a label to a FEC, it must allow other LSRs in the path know about the label. LDP helps to establish the LSP by providing a set of procedures that LSRs can use to distribute labels.
The FEC associated with an LSP specifies which packets are mapped to that LSP. LSPs are extended through a network as each LSR splices incoming labels for a FEC to the outgoing label assigned to the next hop for the specified FEC.
LDP allows an LSR to request a label from a downstream LSR so it can bind the label to a specific FEC. The downstream LSR responds to the request from the upstream LSR by sending the requested label.
LSRs can distribute a FEC label binding in response to an explicit request from another LSR. This is known as Downstream On Demand (DOD) label distribution. LSRs can also distribute label bindings to LSRs that have not explicitly requested them. This is called Downstream Unsolicited (DUS).
LDP and MPLS
LDP performs the label distribution only in MPLS environments. The LDP operation begins with a hello discovery process to find LDP peers in the network. LDP peers are two LSRs that use LDP to exchange label/FEC mapping information. An LDP session is created between LDP peers. A single LDP session allows each peer to learn the other's label mappings (LDP is bidirectional) and to exchange label binding information.
LDP signaling works with the MPLS label manager to manage the relationships between labels and the corresponding FEC. For service-based FECs, LDP works in tandem with the Service Manager to identify the virtual leased lines (VLLs) and Virtual Private LAN Services (VPLSs) to signal.
An MPLS label identifies a set of actions that the forwarding plane performs on an incoming packet before discarding it. The FEC is identified through the signaling protocol (in this case, LDP) and allocated a label. The mapping between the label and the FEC is communicated to the forwarding plane. In order for this processing on the packet to occur at high speeds, optimized tables are maintained in the forwarding plane that enable fast access and packet identification.
When an unlabeled packet ingresses the IP/MPLS router, classification policies associate it with a FEC. The appropriate label is imposed on the packet, and the packet is forwarded. Other actions that can take place before a packet is forwarded are imposing additional labels, other encapsulations, learning actions, and so on. When all actions associated with the packet are completed, the packet is forwarded.
When a labeled packet ingresses the router, the label or stack of labels indicates the set of actions associated with the FEC for that label or label stack. The actions are preformed on the packet and then the packet is forwarded.
The LDP implementation provides DOD, DUS, ordered control, liberal label retention mode support.
LDP architecture
LDP comprises a few processes that handle the protocol PDU transmission, timer-related issues, and protocol state machine. The number of processes is kept to a minimum to simplify the architecture and to allow for scalability. Scheduling within each process prevents starvation of any particular LDP session, while buffering alleviates TCP-related congestion issues.
The LDP subsystems and their relationships to other subsystems are illustrated in Subsystem interrelationships. This illustration shows the interaction of the LDP subsystem with other subsystems, including memory management, label management, service management, SNMP, interface management, and RTM. In addition, debugging capabilities are provided through the logger.
Communication within LDP tasks is typically done by inter-process communication through the event queue, as well as through updates to the various data structures. The primary data structures that LDP maintains are:
FEC/label database — This database contains all the FEC to label mappings that include, both sent and received. It also contains both address FECs (prefixes and host addresses) as well as service FECs (L2 VLLs and VPLS).
Timer database — This database contains all the timers for maintaining sessions and adjacencies.
Session database — This database contains all the session and adjacency records, and serves as a repository for the LDP MIB objects.
Subsystem interrelationships
The following figure shows how LDP and the other subsystems work to provide services.
Memory manager and LDP
LDP does not use any memory until it is instantiated. It preallocates some amount of fixed memory so that initial startup actions can be performed. Memory allocation for LDP comes out of a pool reserved for LDP that can grow dynamically as needed. Fragmentation is minimized by allocating memory in larger chunks and managing the memory internally to LDP. When LDP is shut down, it releases all memory allocated to it.
Label manager
LDP assumes that the label manager is up and running. LDP will abort initialization if the label manager is not running. The label manager is initialized at system boot-up; therefore, anything that causes it to fail will likely imply that the system is not functional. The 7210 devices uses a label range from 28672 (28K) to 131071 (128K-1) to allocate all dynamic labels, including RSVP allocated labels and VC labels.
LDP configuration
The 7210 SAS devices use a single consistent interface to configure all protocols and services. CLI commands are translated to SNMP requests and are handled through an agent-LDP interface. LDP can be instantiated or deleted through SNMP. Also, LDP targeted sessions can be set up to specific endpoints. Targeted-session parameters are configurable.
Logger
LDP uses the logger interface to generate debug information relating to session setup and teardown, LDP events, label exchanges, and packet dumps. Per-session tracing can be performed.
Service manager
All interaction occurs between LDP and the service manager, because LDP is used primarily to exchange labels for Layer 2 services. In this context, the service manager informs LDP when an LDP session is to be set up or torn down, and when labels are to be exchanged or withdrawn. In turn, LDP informs service manager of relevant LDP events, such as connection setups and failures, timeouts, labels signaled/withdrawn.
Execution flow
LDP activity is limited to service-related signaling. Therefore, the configurable parameters are restricted to system-wide parameters, such as hello and keepalive timeouts.
Initialization
MPLS must be enabled when LDP is initialized. LDP makes sure that the various prerequisites, such as ensuring the system IP interface is operational, the label manager is operational, and there is memory available, are met. It then allocates itself a pool of memory and initializes its databases.
Session lifetime
In order for a targeted LDP (T-LDP) session to be established, an adjacency must be created. The LDP extended discovery mechanism requires hello messages to be exchanged between two peers for session establishment. After the adjacency establishment, session setup is attempted.
Session establishment
When the LDP adjacency is established, the session setup follows as per the LDP specification. Initialization and keepalive messages complete the session setup, followed by address messages to exchange all interface IP addresses. Periodic keepalives or other session messages maintain the session liveliness.
Because TCP is back-pressured by the receiver, it is necessary to be able to push that back-pressure all the way into the protocol. Packets that cannot be sent are buffered on the session object and re-attempted as the back-pressure eases.
Label exchange
Label exchange is initiated by the service manager. When an SDP is attached to a service (for example, the service gets a transport tunnel), a message is sent from the service manager to LDP. This causes a label mapping message to be sent. Additionally, when the SDP binding is removed from the service, the VC label is withdrawn. The peer must send a label release to confirm that the label is not in use.
Other reasons for label actions
Other reasons for label actions include:
MTU changes
LDP withdraws the previously assigned label, and re-signals the FEC with the new MTU in the interface parameter.
Clear labels
When a service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are issued.
SDP down
When an SDP goes administratively down, the VC label associated with that SDP for each service is withdrawn.
Memory allocation failure
If there is no memory to store a received label, it is released.
VC type unsupported
When an unsupported VC type is received, the received label is released.
Cleanup
LDP closes all sockets, frees all memory, and shuts down all its tasks when it is deleted, so its memory usage is 0 when it is not running.
Configuring implicit null label
The implicit null label option allows a 7210 SAS egress LER to receive MPLS packets from the previous hop without the outer LSP label. The operation of the previous hop is referred to as penultimate hop popping (PHP). This option is signaled by the egress LER to the previous hop during the FEC signaling by the control protocol.
The user can configure to signal the implicit null option for all RSVP FECs for which this node is the egress LER using the following command:
config>router>rsvp>implicit-null-label
When the user changes the implicit null configuration option, RSVP withdraws all the FECs and re-advertises them using the new label value.
LDP filters
Both inbound and outbound LDP label binding filtering is supported.
Inbound filtering (import policy) allows configuration of a policy to control the label bindings an LSR accepts from its peers. Label bindings can be filtered based on:
Neighbor: Match on bindings received from the specified peer
Prefix-list: Match on bindings with the specified prefix/prefixes
The default import behavior is to accept all FECs received from peers. The LDP export policy can be used to explicitly add FECs (or non-LDP routes) for label propagation and does not filter out or stop propagation of any FEC received from neighbors.
Export policy enables configuration of a policy to advertise label bindings based on:
Direct: All local subnets
Prefix-list: Match on bindings with the specified prefix or prefixes
The LDP export policy will not filter out FECs. It is only used to explicitly add FECs (or non-LDP routes) for label propagation.
The default export behavior originates label bindings for system address and propagate all FECs received.
ECMP support for LDP
LDP LER ECMP is not supported.
LDP LSR ECMP is only supported on 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE.
This feature performs load balancing for LDP-based LSPs by having multiple outgoing next-hops for a specified IP prefix on ingress and transit LSRs.
An LSR that has multiple equal cost paths to a specified IP prefix can receive an LDP label mapping for this prefix from each downstream next-hop peer. As the LDP implementation uses the liberal label retention mode to retain all the labels for an IP prefix received from multiple next-hop peers.
Without ECMP support (only for LDP LSR LSPs on 7210 SAS), only one of these next-hop peers will be selected and installed in the forwarding plane. The next-hop peer selection algorithm looks up the route information obtained from the RTM for this prefix and finds the first valid LDP next-hop peer (for example, the first neighbor in the RTM entry from which a label mapping was received). If, for some reason, the outgoing label to the installed next-hop is no longer valid ( for example, if the session to the peer is lost or the peer withdraws the label) a new valid LDP next-hop peer will be selected out of the existing next-hop peers and LDP will reprogram the forwarding plane to use the label sent by this peer.
With ECMP support, all the valid LDP next-hop peers, those that sent a label mapping for a specified IP prefix, will be installed in the forwarding plane. In transit LSR, an ingress label will be mapped to the next hops that are in the RTM and from which a valid mapping label has been received. The forwarding plane will then use an internal hashing algorithm to determine how the traffic will be distributed amongst these multiple next-hops, assigning each ‟flow” to a particular next-hop.
For more information about the hash algorithms at transit LSR, see ‟LAG and ECMP Hashing” in the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide.
Label operations
If an LSR is the ingress for a specific IP prefix, LDP programs a push operation for the prefix in the forwarding engine. This creates an LSP ID to the Next Hop Label Forwarding Entry (NHLFE) (LTN) mapping and an LDP tunnel entry in the forwarding plane. LDP will also inform the Tunnel Table Manager (TTM) of this tunnel. Both the LTN entry and the tunnel entry will have a NHLFE for the label mapping that the LSR received from each of its next-hop peers.
If the LSR is to behave as a transit for a specified IP prefix, LDP will program a swap operation for the prefix in the forwarding engine. This results in the creation of an Incoming Label Map (ILM) entry in the forwarding plane. The ILM entry will have to map an incoming label to possibly multiple NHLFEs. If the LSR is an egress for a specific IP prefix, LDP programs a POP entry in the forwarding engine. Programming a POP entry results in an ILM entry in the forwarding plane, but with no NHLFEs.
When unlabeled packets arrive at the ingress LER, the forwarding plane will consult the LTN entry and will use a hashing algorithm to map the packet to one of the NHLFEs (push label) and forward the packet to the corresponding next-hop peer. For labeled packets arriving at a transit or egress LSR, the forwarding plane will consult the ILM entry and either use a hashing algorithm to map it to one of the NHLFEs if they exist (swap label) or simply route the packet if there are no NHLFEs (pop label).
Static FEC swap will not be activated unless there is a matching route in system route table that also matches the user configured static FEC next-hop.
LDP LSR ECMP hashing
The following table lists the cases in which LDP LSR ECMP hashing occurs when an MPLS encapsulated packet is received at LSR, and the cases where the MAC or IP packet address fields that are used in hashing vary.
Number and types of labels egressing iLER |
Packet header address fields used in hashing1 |
Hashing scenario2 |
Notes |
||
|---|---|---|---|---|---|
Varying MAC |
Varying IP |
Hashing over LAG at LSR |
Hashing over ECMP paths at LSR |
||
2 (LDP transport label and service label) |
|
|
|
|
— |
✓ |
|
|
|
||
|
|
✓ |
|
|
||
✓ |
✓ |
|
|
||
3 (LDP transport label, service label, and hash label) |
|
|
|
|
The last label egressing the iLER is a hash label, which has a different value from the other two (2) labels because it has different MAC and IP fields in the packet of the service traffic. |
✓ |
|
✓ |
✓ |
||
|
|
✓ |
✓ |
✓ |
||
✓ |
✓ |
✓ |
✓ |
||
3 (LDP/RSVP transport label, BGP3107 label, and service label) |
|
|
|
|
The packet egressess the LSR between the PE and ASBR with three (3) labels. Each label has the same value in every stream for traffic forwarded in a specific service. However, the values are not the same for traffic forwarded in multiple services using the same LDP LSP. |
✓ |
|
|
|
||
|
|
✓ |
|
|
||
✓ |
✓ |
|
|
||
4 (LDP/RSVP transport label, BGP 3107 label, service label, and hash label) |
|
|
|
|
The packet egressess the LSR between the PE and ASBR with three (3) labels and one (1) hash label, which is the fourth label in the packet. Hashing does not occur at the LSR between the PE and ASBR; however, if a LAG is configured on egress of the ASBR, the packets are hashed over the LAG members. |
✓ |
|
|
|
||
|
|
✓ |
|
|
||
✓ |
✓ |
|
|
||
Link LDP
Hello adjacency will be brought up using link Hello packet with source IP address set to the interface borrowed IP address and a destination IP address set to 224.0.0.2.
By default, the LDP session uses the system interface address as the LSR-ID unless explicitly configured using the command config>router>ldp>interface-parameters>interface>local-lsr-id interface. Using this command user is allowed to use the local interface as both the LSR-ID and the transport address for the link-level LDP session. Note that when the interface option is selected, the transport connection (TCP) for the link LDP session will also use the address of the local LDP interface as the transport address. If system is the value configured under the command configure>router>ldp>interface-parameters>interface>transport-address, it will be overridden.
The LSR with the highest transport address, that is, LSR-ID in this case, will bootstrap the TCP connection and LDP session.
Source and destination IP addresses of LDP packets are the transport addresses, that is, LDP LSR-IDs of systems A and B in this case.
Targeted LDP
Source and destination addresses of targeted Hello packets are the LDP LSR-IDs of systems A and B.
The user can configure the local-lsr-id option on the targeted session and change the value of the LSR-ID to either the local interface or to some other interface name, loopback or not. If the local interface is selected the IP address of the local interface will be used as the LSR-ID. In all cases, the transport address for the LDP session and the source IP address of targeted Hello message will be updated to the new LSR-ID value.
The LSR with the highest transport address, that is, LSR-ID in this case, will bootstrap the TCP connection and LDP session.
Source and destination IP addresses of LDP messages are the transport addresses, which, in this case, are the LDP LSR-IDs of systems A and B.
Unnumbered interface support in LDP
This feature is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.
P2MP LSPs are only supported on 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T.
This feature allows LDP to establish a Hello adjacency and to resolve unicast and multicast FECs over unnumbered LDP interfaces.
This feature also extends the support of lsp-ping, p2mp-lsp-ping, and ldp-treetrace to test an LDP unicast or multicast FEC which is resolved over an unnumbered LDP interface.
Feature configuration
This feature does not introduce a new CLI command for adding an unnumbered interface into LDP. Instead, the fec-originate command is extended to specify the interface name, because an unnumbered interface does not have an IP address of its own. The user can, however, specify the interface name for numbered interfaces.
See the CLI section for the changes to the fec-originate command.
Operation of LDP over an unnumbered IP interface
Consider the setup shown in the following figure.
LSR A and LSR B have the following LDP identifiers respectively:
<LSR Id=A> : <label space id=0>
<LSR Id=B> : <label space id=0>
There are two P2P unnumbered interfaces between LSR A and LSR B. These interfaces are identified on each system with their unique local link identifier. In other words, the combination of {Router-ID, Local Link Identifier} uniquely identifies the interface in OSPF or IS-IS throughout the network.
A borrowed IP address is also assigned to the interface to be used as the source address of IP packets which need to be originated from the interface. The borrowed IP address defaults to the system loopback interface address, A and B respectively in this setup. The user can change the borrowed IP interface to any configured IP interface, loopback or not, by applying the following command:
config>router>if>unnumbered [<ip-int-name | ip-address>]
When the unnumbered interface is added into LDP, it will have the behavior described in the following sections.
Link LDP
Hello adjacency will be brought up using link Hello packet with source IP address set to the interface borrowed IP address and a destination IP address set to 224.0.0.2.
As a consequence of 1, Hello packets with the same source IP address should be accepted when received over parallel unnumbered interfaces from the same peer LSR-ID. The corresponding Hello adjacencies would be associated with a single LDP session.
The transport address for the TCP connection, which is encoded in the Hello packet, will always be set to the LSR-ID of the node regardless if the user enabled the interface option under config>router>ldp>if-params>if>ipv4>transport-address.
The user can configure the local-lsr-id option on the interface and change the value of the LSR-ID to either the local interface or to some other interface name, loopback or not, numbered or not. If the local interface is selected or the provided interface name corresponds to an unnumbered IP interface, the unnumbered interface borrowed IP address will be used as the LSR-ID. In all cases, the transport address for the LDP session will be updated to the new LSR-ID value but the link Hello packets will continue to use the interface borrowed IP address as the source IP address.
The LSR with the highest transport address, that is., LSR-ID in this case, will bootstrap the TCP connection and LDP session.
Source and destination IP addresses of LDP packets are the transport addresses, that is, LDP LSR-IDs of systems A and B in this case.
Targeted LDP
Source and destination addresses of targeted Hello packet are the LDP LSR-IDs of systems A and B.
The user can configure the local-lsr-id option on the targeted session and change the value of the LSR-ID to either the local interface or to some other interface name, loopback or not, numbered or not. If the local interface is selected or the provided interface name corresponds to an unnumbered IP interface, the unnumbered interface borrowed IP address will be used as the LSR-ID. In all cases, the transport address for the LDP session and the source IP address of targeted Hello message will be updated to the new LSR-ID value.
The LSR with the highest transport address, That is, LSR-ID in this case, will bootstrap the TCP connection and LDP session.
Source and destination IP addresses of LDP messages are the transport addresses, that is, LDP LSR-IDs of systems A and B in this case.
FEC resolution
LDP will advertise/withdraw unnumbered interfaces using the Address/Address-Withdraw message. The borrowed IP address of the interface is used.
A FEC can be resolved to an unnumbered interface in the same way as it is resolved to a numbered interface. The outgoing interface and next-hop are looked up in RTM cache. The next-hop consists of the router-id and link identifier of the interface at the peer LSR.
LDP FEC ECMP next-hops over a mix of unnumbered and numbered interfaces is supported.
All LDP FEC types are supported.
The fec-originate command is supported when the next-hop is over an unnumbered interface.
All LDP features are supported except for the following:
BFD cannot be enabled on an unnumbered LDP interface. This is a consequence of the fact that BFD is not supported on unnumbered IP interface on the system.
As a consequence of 1, LDP FRR procedures will not be triggered via a BFD session timeout but only by physical failures and local interface down events.
Unnumbered IP interfaces cannot be added into LDP global and peer prefix policies.
LDP over RSVP tunnels
LDP over RSVP-TE provides end-to-end tunnels that have two important properties, fast reroute and traffic engineering which are not available in LDP. LDP over RSVP-TE is focused at large networks (over 100 nodes in the network). Simply using end-to-end RSVP-TE tunnels will not scale. While an LER may not have that many tunnels, any transit node will potentially have thousands of LSPs, and if each transit node also has to deal with detours or bypass tunnels, this number can make the LSR overly burdened.
Use of the implicit NULL MPLS label must be enabled with use of LDPoRSVP. Use the command configure>router>rsvp>implicit-null-label and configure>router>ldp> implicit-null-label to enable use of implicit NULL MPLS labels.
Only FRR one-to-one is supported when LDPoRSVP is used. FRR facility is not supported. This is not blocked in the CLI, but operators need to ensure it when configuring the nodes.
LDP over RSVP-TE allows tunneling of user packets using an LDP LSP inside an RSVP LSP.The main application of this feature is for deployment of MPLS based services, for example, VPRN, VLL, and VPLS services, in large scale networks across multiple IGP areas without requiring full mesh of RSVP LSPs between PE routers.
The network displayed in LDP over RSVP application consists of two metro areas, Area 1 and 2 respectively, and a core area, Area 3. Each area makes use of TE LSPs to provide connectivity between the edge routers. To enable services between PE1 and PE2 across the three areas, LSP1, LSP2, and LSP3 are set up using RSVP-TE. There are in fact 6 LSPs required for bidirectional operation but we will refer to each bidirectional LSP with a single name, for example, LSP1. A targeted LDP (T-LDP) session is associated with each of these bidirectional LSP tunnels. That is, a T-LDP adjacency is created between PE1 and ABR1 and is associated with LSP1 at each end. The same is done for the LSP tunnel between ABR1 and ABR2, and finally between ABR2 and PE2. The loopback address of each of these routers is advertised using T-LDP. Similarly, backup bidirectional LDP over RSVP tunnels, LSP1a and LSP2a, are configured via ABR3.
This setup effectively creates an end-to-end LDP connectivity which can be used by all PEs to provision services. The RSVP LSPs are used as a transport vehicle to carry the LDP packets from one area to another. Note that only the user packets are tunneled over the RSVP LSPs. The T-LDP control messages are still sent unlabeled using the IGP shortest path.
In this application, the bidirectional RSVP LSP tunnels are not treated as IP interfaces and are not advertised back into the IGP. A PE must always rely on the IGP to look up the next hop for a service packet. LDP-over-RSVP introduces a new tunnel type, tunnel-in-tunnel, in addition to the existing LDP tunnel and RSVP tunnel types. If multiple tunnels types match the destination PE FEC lookup, LDP will prefer an LDP tunnel over an LDP-over-RSVP tunnel by default.
The design in LDP over RSVP application allows a service provider to build and expand each area independently without requiring a full mesh of RSVP LSPs between PEs across the three areas.
To participate in a VPRN service, PE1 and PE2 perform the autobind to LDP. The LDP label which represents the target PE loopback address is used below the RSVP LSP label. Therefore a 3 label stack is required.
To provide a VLL service, PE1 and PE2 are still required to set up a targeted LDP session directly between them. Again a 3 label stack is required, the RSVP LSP label, followed by the LDP label for the loopback address of the destination PE, and finally the pseudowire label (VC label).
This implementation supports a variation of the application in LDP over RSVP application, in which area 1 is an LDP area. In that case, PE1 will push a two label stack while ABR1 will swap the LDP label and push the RSVP label as shown in LDP over RSVP application variant.
Signaling and operation
LDP label distribution and FEC resolution
The user creates a targeted LDP (T-LDP) session to an ABR or the destination PE. This results in LDP hellos being sent between the two routers. These messages are sent unlabeled over the IGP path. Next, the user enables LDP tunneling on this T-LDP session and optionally specifies a list of LSP names to associate with this T-LDP session. By default, all RSVP LSPs which terminate on the T-LDP peer are candidates for LDP-over-RSVP tunnels. At this point in time, the LDP FECs resolving to RSVP LSPs are added into the Tunnel Table Manager as tunnel-in-tunnel type.
Note that if LDP is running on regular interfaces also, then the prefixes LDP learns are going to be distributed over both the T-LDP session as well as regular IGP interfaces. The policy controls which prefixes go over the T-LDP session, for example, only /32 prefixes, or a particular prefix range.
LDP-over-RSVP works with both OSPF and IS-IS. These protocols include the advertising router when adding an entry to the RTM. LDP-over-RSVP tunnels can be used as shortcuts for BGP next-hop resolution.
Default FEC resolution procedure
When LDP tries to resolve a prefix received over a T-LDP session, it performs a lookup in the Routing Table Manager (RTM). This lookup returns the next hop to the destination PE and the advertising router (ABR or destination PE itself). If the next-hop router advertised the same FEC over link-level LDP, LDP will prefer the LDP tunnel by default unless the user explicitly changed the default preference using the system wide prefer-tunnel-in-tunnel command. If the LDP tunnel becomes unavailable, LDP will select an LDP-over-RSVP tunnel if available.
When searching for an LDP-over-RSVP tunnel, LDP selects the advertising routers with best route. If the advertising router matches the T-LDP peer, LDP then performs a second lookup for the advertising router in the Tunnel Table Manager (TTM) which returns the user configured RSVP LSP with the best metric. If there are more than one configured LSP with the best metric, LDP selects the first available LSP.
If all user configured RSVP LSPs are down, no more action is taken. If the user did not configure any LSPs under the T-LDP session, the lookup in TTM will return the first available RSVP LSP which terminates on the advertising router with the lowest metric.
FEC resolution procedure when prefer-tunnel-in-tunnel is enabled
When LDP tries to resolve a prefix received over a T-LDP session, it performs a lookup in the Routing Table Manager (RTM). This lookup returns the next hop to the destination PE and the advertising router (ABR or destination PE itself).
When searching for an LDP-over-RSVP tunnel, LDP selects the advertising routers with best route. If the advertising router matches the targeted LDP peer, LDP then performs a second lookup for the advertising router in the Tunnel Table Manager (TTM) which returns the user configured RSVP LSP with the best metric. If there are more than one configured LSP with the best metric, LDP selects the first available LSP.
If all user configured RSVP LSPs are down, then an LDP tunnel will be selected if available.
If the user did not configure any LSPs under the T-LDP session, a lookup in TTM will return the first available RSVP LSP which terminates on the advertising router. If none are available, then an LDP tunnel will be selected if available.
Rerouting around failures
Every failure in the network can be protected against, except for the ingress and egress PEs. All other constructs have protection available. These constructs are LDP-over-RSVP tunnel and ABR.
LDP-over-RSVP tunnel protection
An RSVP LSP can deal with a failure in two ways:
If the LSP is a loosely routed LSP, then RSVP will find a new IGP path around the failure, and traffic will follow this new path. This may involve some churn in the network if the LSP comes down and then gets re-routed. The tunnel damping feature was implemented on the LSP so that all the dependent protocols and applications do not flap unnecessarily.
If the LSP is a CSPF-computed LSP with the fast reroute option enabled, then RSVP will switch to the detour path very quickly. From that point, a new LSP will be attempted from the head-end (global revertive). When the new LSP is in place, the traffic switches over to the new LSP with make-before-break.
Only FRR one-to-one is supported with LDP-over-RSVP with use of implicit NULL label. In other words, implicit NULL label must be enabled to use FRR one-to-one. FRR facility cannot be used. The software does not make any checks to enforce these restrictions. Operators must ensure this by network design and configuration.
ABR protection
If an ABR fails, then routing around the ABR requires that a new next-hop LDP-over-RSVP tunnel be found to a backup ABR. If an ABR fails, then the T-LDP adjacency fails. Eventually, the backup ABR becomes the new next hop (after SPF converges), and LDP learns of the new next-hop and can reprogram the new path.
T-LDP session tracking using BFD
The user enables BFD tracking of a T-LDP session by using the config>router>ldp>targeted-session>bfd-enable command.
When this command is executed, LDP registers the address of the T-LDP session peer with BFD for tracking purposes. In other words, when the BFD session goes down, the T-LDP session is also brought down. However, the BFD session going up does not affect the state of the T-LDP session as T-LDP has to establish correct Hello adjacency and then a TCP connection to the peer which then allows the T-LDP session to come up.
The source and destination addresses of the BFD session depends on whether the T-LDP peer is directly reachable over a local interface or is more than one hop away.
When the peer is on the local subnet, the BFD session used will be the one associated with the local interface on the direct link to the peer. In that case, the source address and destination address in the BFD packets will be that of the local end and the far-end of that interface respectively. If multiple interfaces exist to the peer because of parallel links, then the BFD session must be associated with the interface which is currently used by the common LDP session shared by both the T-LDP and link-level LDP sessions.
The parameters used for the BFD session, transmit-interval, receive-interval, multiplier, and echo-receive are also configured under the local interfaces using the config>router>interface>bfd command.
Note that the local interface BFD session is used regardless if the LDP session, and underlying TCP connection, were bootstrapped by the link-level LDP Hello adjacency or the T-LDP hello adjacency. Furthermore, if the BFD session goes down it will bring down the state of both the T-LDP session and the link-level LDP session sharing the same LDP session.
When the peer is several hops away, the BFD session used will be the one associated with the loopback interface corresponding to LSR-ID of the T-LDP session. The LSR-ID is used to establish the Hello adjacency with the peer. By default the LSR-ID matches the system interface address but the user can change it to any other loopback interface address [ldp-instances]. In that case, the source address and destination address in the BFD packets will match the local end LSR-ID and the far-end address specified for the peer respectively. The parameters used for the BFD session are also those configured under the loopback interface corresponding to the LSR-ID using the bfd command in the config>router>interface context.
Because the BFD session used to track the same T-LDP peer may move from a link interface to a loopback interface depending on route reachability, it is important that the user configures the BFD session parameters consistently on both interfaces.
The link interface BFD session is sourced and maintained on the IOM while the loopback interface BFD session is sourced and maintained on the CPM. As a result, the system level BFD resource count reflects the worst case where each T-LDP session is using two BFD sessions.
LDP Downstream-on-Demand (DoD)
The user enables the use by an LDP session of the Downstream-on-Demand (DoD) label distribution using the command config>router>ldp>peer-parameters>peer> dod-label-distribution.
When this option is enabled, LDP will set the A-bit in the Label Initialization message, when the LDP session to the peer is established. When both peers set the A-bit, both uses the DoD label distribution method over the LDP session [rfc5036].
This feature can only be enabled on a link level LDP session and applies to prefix labels only, and not service labels.
Single-hop LDP DoD procedures
As soon as the link LDP session comes up, the 7210 SAS sends a label request to the DoD peer for the FEC prefix corresponding to the peer’s LSR-id. The DoD peer LSR-id is found in the basic Hello discovery messages the peer used to establish the Hello adjacency with the 7210.
Similarly, if the 7210 SAS and the directly attached DoD peer enter into the extended discovery and establish a targeted LDP session, the 7210 SAS immediately sends a label request for the FEC prefix corresponding to the peer’s LSR-id found in the extended discovery messages.
However, the 7210 SAS node does not advertise any <FEC, label> bindings, including the FEC of its own LSR-id, unless the DoD peer requested it through a Label Request Message.
When the DoD peer sends a label request for any FEC prefix, the 7210 SAS replies with a <FEC, label> binding for that prefix if the FEC was already activated on the 7210 SAS. If not, the 7210 SAS replies with a notification message containing the status code of ‟no route”. The 7210 SAS does not attempt in the latter case to send a label request to the next-hop for the FEC prefix when the LDP session to this next-hop uses the DoD label distribution mode. Thus, the reference to single-hop LDP DoD procedures.
The single-hop LDP DoD procedures makes sure the 7210 SAS has a label for the LDP DoD peer, whenever it is needed.
The 7210 SAS needs a label of directly attached DoD peer in the following cases:
A BGP labeled route for the peer’s prefix from RTM to its BGP neighbors through iBGP.
When it receives a label request message from a directly attached DoD peer for the prefix of another directly attached DoD peer. In this case the DoD peers are trying to establish a SDP among themselves.
Trying to establish a SDP to a directly attached LDP DoD peer.
The 7210 SAS also supports sending and receiving the Label Abort Request Message as described. This message is used to abort an outstanding request for a label in case no response was received from the peer within a finite amount of time.
LDP over RSVP and ECMP
7210 SAS devices does not support ECMP for LDP over RSVP LSPs.
LDP Fast-Reroute for IS-IS and OSPF prefixes
LDP Fast Re-Route (FRR) is a feature which allows the user to provide local protection for an LDP FEC by precomputing and downloading to IOM both a primary and a backup NHLFE for this FEC.
The primary NHLFE corresponds to the label of the FEC received from the primary next-hop as per standard LDP resolution of the FEC prefix in RTM. The backup NHLFE corresponds to the label received for the same FEC from a Loop-Free Alternate (LFA) next-hop.
The LFA next-hop precomputation by IGP is described in RFC 5286 – ‟Basic Specification for IP Fast Reroute: Loop-Free Alternates”. LDP FRR relies on using the label-FEC binding received from the LFA next-hop to forward traffic for a specified prefix as soon as the primary next-hop is not available. This means that a node resumes forwarding LDP packets to a destination prefix without waiting for the routing convergence. The label-FEC binding is received from the loop-free alternate next-hop ahead of time and is stored in the Label Information Base because LDP on the router operates in the liberal retention mode.
This feature requires that IGP performs the Shortest Path First (SPF) computation of an LFA next-hop, in addition to the primary next-hop, for all prefixes used by LDP to resolve FECs. IGP also populates both routes in the Routing Table Manager (RTM).
LDP FRR configuration
The user enables Loop-Free Alternate (LFA) computation by SPF under the IS-IS or OSPF routing protocol level:
config>router>isis>loopfree-alternate
config>router>ospf>loopfree-alternate
The above commands instruct the IGP SPF to attempt to precompute both a primary next-hop and an LFA next-hop for every learned prefix. When found, the LFA next-hop is populated into the RTM along with the primary next-hop for the prefix.
Next the user enables the use by LDP of the LFA next-hop by configuring the following option:
config>router>ldp>fast-reroute
When this command is enabled, LDP will use both the primary next-hop and LFA next-hop, when available, for resolving the next-hop of an LDP FEC against the corresponding prefix in the RTM. This will result in LDP programming a primary NHLFE and a backup NHLFE into the IOMXCM for each next-hop of a FEC prefix for the purpose of forwarding packets over the LDP FEC.
Note that because LDP can detect the loss of a neighbor/next-hop independently, it is possible that it switches to the LFA next-hop while IGP is still using the primary next-hop. To avoid this situation, it is recommended to enable IGP-LDP synchronization on the LDP interface:
config>router>interface>ldp-sync-timer seconds
Reducing the scope of the LFA calculation by SPF
The user can instruct IGP to not include all interfaces participating in a specific IS-IS level or OSPF area in the SPF LFA computation. This provides a way of reducing the LFA SPF calculation where it is not needed.
config>router>isis>level>loopfree-alternate-exclude
config>router>ospf>area>loopfree-alternate-exclude
Note that if IGP shortcut are also enabled in LFA SPF, LSPs with destination address in that IS-IS level or OSPF area are also not included in the LFA SPF calculation.
The user can also exclude a specific IP interface from being included in the LFA SPF computation by IS-IS or OSPF:
config>router>isis>interface>loopfree-alternate-exclude
config>router>ospf>area>interface>loopfree-alternate-exclude
Note that when an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When the user excludes an interface from the LFA SPF in OSPF, it is excluded in all areas. However, the above OSPF command can only be executed under the area in which the specified interface is primary and when enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.
LDP FRR procedures
The LDP FEC resolution when LDP FRR is not enabled operates as follows. When LDP receives a FEC, label binding for a prefix, it will resolve it by checking if the exact prefix, or a longest match prefix when the aggregate-prefix-match option is enabled in LDP, exists in the routing table and is resolved against a next-hop which is an address belonging to the LDP peer which advertised the binding, as identified by its LSR-id. When the next-hop is no longer available, LDP deactivates the FEC and deprograms the NHLFE in the datapath. LDP will also immediately withdraw the labels it advertised for this FEC and deletes the ILM in the datapath unless the user configured the label-withdrawal-delay option to delay this operation. Traffic that is received while the ILM is still in the datapath is dropped. When routing computes and populates the routing table with a new next-hop for the prefix, LDP resolves again the FEC and programs the datapath accordingly.
When LDP FRR is enabled and an LFA backup next-hop exists for the FEC prefix in RTM, or for the longest prefix the FEC prefix matches to when aggregate-prefix-match option is enabled in LDP, LDP will resolve the FEC as above but will program the datapath with both a primary NHLFE and a backup NHLFE for each next-hop of the FEC.
In order perform a switchover to the backup NHLFE in the fast path, LDP follows the uniform FRR failover procedures which are also supported with RSVP FRR.
When any of the following events occurs, LDP instructs in the fast path the IOM to enable the backup NHLFE for each FEC next-hop impacted by this event. The IOM do that by simply flipping a single state bit associated with the failed interface or neighbor/next-hop:
An LDP interface goes operationally down, or is admin shutdown. In this case, LDP sends a neighbor/next-hop down message to the IOM for each LDP peer it has adjacency with over this interface.
An LDP session to a peer went down as the result of the Hello or Keep-Alive timer expiring over a specific interface. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only.
The TCP connection used by a link LDP session to a peer went down, due say to next-hop tracking of the LDP transport address in RTM, which brings down the LDP session. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only.
A BFD session, enabled on a T-LDP session to a peer, times-out and as a result the link LDP session to the same peer and which uses the same TCP connection as the T-LDP session goes also down. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only.
A BFD session enabled on the LDP interface to a directly connected peer, times-out and brings down the link LDP session to this peer. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only. BFD support on LDP interfaces is a new feature introduced for faster tracking of link LDP peers.
The tunnel-down-dump-time option or the label-withdrawal-delay option, when enabled, does not cause the corresponding timer to be activated for a FEC as long as a backup NHLFE is still available.
Link LDP Hello adjacency tracking with BFD
LDP can only track an LDP peer with which it established a link LDP session with using the Hello and Keep-Alive timers. If an IGP protocol registered with BFD on an IP interface to track a neighbor, and the BFD session times out, the next-hop for prefixes advertised by the neighbor are no longer resolved. This however does not bring down the link LDP session to the peer because the LDP peer is not directly tracked by BFD. More importantly the LSR-id of the LDP peer may not coincide with the neighbor’s router-id IGP is tracking by way of BFD.
To properly track the link LDP peer, LDP needs to track the Hello adjacency to its peer by registering with BFD. This way, the peer next-hop is tracked.
The user enables Hello adjacency tracking with BFD by enabling BFD on an LDP interface:
config>router>ldp>interface-parameters>interface>enable-bfd
The parameters used for the BFD session, that is, transmit-interval, recethat isinterval, and multiplier, are those configured under the IP interface in existing implementation:
config>router>interface>bfd
When multiple links exist to the same LDP peer, a Hello adjacency is established over each link but only a single LDP session will exist to the peer and will use a TCP connection over one of the link interfaces. Also, a separate BFD session should be enabled on each LDP interface. If a BFD session times out on a specific link, LDP will immediately bring down the Hello adjacency on that link. In addition, if the there are FECs which have their primary NHLFE over this link, LDP triggers the LDP FRR procedures by sending to IOM the neighbor/next-hop down message. This will result in moving the traffic of the impacted FECs to an LFA next-hop on a different link to the same LDP peer or to an LFA backup next-hop on a different LDP peer depending on the lowest backup cost path selected by the IGP SPF.
As soon as the last Hello adjacency goes down because of BFD timing out, the LDP session goes down and the LDP FRR procedures will be triggered. This will result in moving the traffic to an LFA backup next-hop on a different LDP peer.
ECMP considerations
Whenever the SPF computation determined there is more than one primary next-hop for a prefix, it will not program any LFA next-hop in RTM. Thus, the LDP FEC will resolve to the multiple primary next-hops in this case which provides the required protection.
Also note that when the system ECMP value is set to ecmp=1 or to no ecmp, which translates to the same and is the default value, SPF will be able to use the overflow ECMP links as LFA next hops in these two cases.
LDP P2MP support
This section describes support for LDP P2MP.
LDP P2MP configuration
This feature is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-Sx 1/10GE and 7210 SAS-Sx 10/100GE, and platforms operating in access-uplink mode.
P2MP LSPs signaled using RSVP or mLDP is only supported on 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.
A node running LDP also supports P2MP LSP setup using LDP. By default, it would advertise the capability to a peer node using P2MP capability TLV in LDP initialization message.
This configuration option per interface is provided to restrict/allow the use of interface in LDP multicast traffic forwarding toward a downstream node. The interface configuration option does not restrict/allow exchange of P2MP FEC by way of established session to the peer on an interface, but it would only restrict/allow use of next-hops over the interface. By default, the LDP-P2MP capability is disabled on interface.
LDP P2MP protocol
Only a single generic identifier range is defined for signaling multipoint tree for all client applications. Implementation on 7210 SAS reserves the range (1 to 8292) of generic LSP P2MP-ID on root node for static P2MP LSP.
Configuration guidelines for P2MP LSPs
Before using P2MP LSPs with NG-MVPN, resources must be allocated from the sf-ingress-internal-tcam resource pool using the configure>system>global-res-profile>sf-ingress-internal-tcam>mpls-p2mp command. In addition, if the 7210 SAS-R6 is deployed as a bud router, the configure>system> loopback-no-svc-port p2mpbud p2mpbud-port-id command must be used to configure one of the front-panel ports as a loopback port.
Ingress FC classification is available for packets received on a P2MP LSP on a network port IP interface that needs to be replicated to IP receivers. Ingress FC classification allows users to prioritize multicast traffic to IP receivers in the service. Also available is the capability to mark the packet with IP DSCP values while sending the multicast stream out of the IP interface. To enable ingress FC classification, use the loopback-no-svc-port [p2mpbud p2mpbud-port-id [classification]] command. Before using the command, users must ensure that sufficient resources are available in the network port ingress CAM resource pool and MPLS EXP ingress profile map resource pool. The tools>dump>system-resources command can be used to check resource availability.
IS-IS and OSPF support for Loop-Free Alternate calculation
SPF computation in IS-IS and OSPF is enhanced to compute LFA alternate routes for each learned prefix and populate it in RTM.
The following figure shows a simple network topology with point-to-point (P2P) interfaces and highlights three routes to reach router R5 from router R1.
The primary route is by way of R3. The LFA route by way of R2 has two equal cost paths to reach R5. The path by way of R3 protects against failure of link R1-R3. This route is computed by R1 by checking that the cost for R2 to reach R5 by way of R3 is lower than the cost by way of routes R1 and R3. This condition is referred to as the loop-free criterion. R2 must be loop-free with respect to source node R1.
The path by way of R2 and R4 can be used to protect against the failure of router R3. However, with the link R2-R3 metric set to 5, R2 sees the same cost to forward a packet to R5 by way of R3 and R4. Thus R1 cannot guarantee that enabling the LFA next-hop R2 will protect against R3 node failure. This means that the LFA next-hop R2 provides link-protection only for prefix R5. If the metric of link R2-R3 is changed to 8, then the LFA next-hop R2 provides node protection since a packet to R5 will always go over R4. In other words it is required that R2 becomes loop-free with respect to both the source node R1 and the protected node R3.
Consider the case where the primary next-hop uses a broadcast interface shown in the following figure.
In order for next-hop R2 to be a link-protect LFA for route R5 from R1, it must be loop-free with respect to the R1-R3 link’s Pseudo-Node (PN). However, since R2 has also a link to that PN, its cost to reach R5 by way of the PN or router R4 are the same. Thus R1 cannot guarantee that enabling the LFA next-hop R2 will protect against a failure impacting link R1-PN since this may cause the entire subnet represented by the PN to go down. If the metric of link R2-PN is changed to 8, then R2 next-hop will be an LFA providing link protection.
The following are the detailed rules for this criterion as provided in RFC 5286:
-
Rule 1
Link-protect LFA backup next-hop (primary next-hop R1-R3 is a P2P interface):
Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)and,Distance_opt(R2, R5) >= Distance_opt(R2, R3) + Distance_opt(R3, R5) -
Rule 2
Node-protect LFA backup next-hop (primary next-hop R1-R3 is a P2P interface):
Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)and,Distance_opt(R2, R5) < Distance_opt(R2, R3) + Distance_opt(R3, R5) Rule 3
Link-protect LFA backup next-hop (primary next-hop R1-R3 is a broadcast interface):
Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)and,Distance_opt(R2, R5) < Distance_opt(R2, PN) + Distance_opt(PN, R5)where; PN stands for the R1-R3 link Pseudo-Node.
For the case of P2P interface, if SPF finds multiple LFA next-hops for a specified primary next-hop, it follows the following selection algorithm:
It will pick the node-protect type in favor of the link-protect type.
If there is more than one LFA next-hop within the selected type, then it will pick one based on the least cost.
If more than one LFA next-hop with the same cost results from Step B, then SPF will select the first one. This is not a deterministic selection and will vary following each SPF calculation.
For the case of a broadcast interface, a node-protect LFA is not necessarily a link protect LFA if the path to the LFA next-hop goes over the same PN as the primary next-hop. Similarly, a link protect LFA may not guarantee link protection if it goes over the same PN as the primary next-hop.
The selection algorithm when SPF finds multiple LFA next-hops for a specified primary next-hop is modified as follows:
The algorithm splits the LFA next-hops into two sets:
The first set consists of LFA next-hops which do not go over the PN used by primary next-hop.
The second set consists of LFA next-hops which go over the PN used by the primary next-hop.
If there is more than one LFA next-hop in the first set, it will pick the node-protect type in favor of the link-protect type.
If there is more than one LFA next-hop within the selected type, then it will pick one based on the least cost.
If more than one LFA next-hop with equal cost results from Step C, SPF will select the first one from the remaining set. This is not a deterministic selection and will vary following each SPF calculation.
If no LFA next-hop results from Step D, SPF will rerun Steps B-D using the second set.
This algorithm is more flexible than strictly applying Rule 3 above; the link protect rule in the presence of a PN and specified in RFC 5286. A node-protect LFA which does not avoid the PN; does not guarantee link protection, can still be selected as a last resort. The same thing, a link-protect LFA which does not avoid the PN may still be selected as a last resort. Both the computed primary next-hop and LFA next-hop for a specified prefix are programmed into RTM.
Loop-Free Alternate calculation for inter-area/inter-level prefixes
When SPF resolves OSPF inter-area prefixes or IS-IS inter-level prefixes, it will compute an LFA backup next-hop to the same exit area/border router as used by the primary next-hop.
Loop-Free Alternate Shortest Path First (LFA SPF) policies
An LFA SPF policy allows the user to apply specific criteria, such as admin group and SRLG constraints, to the selection of a LFA backup next-hop for a subset of prefixes that resolve to a specific primary next-hop. See more details in the Loop-Free Alternate Shortest Path First (LFA SPF) Policies section in the 7210 SAS-Mxp, R6, R12, S, Sx, T Routing Protocols Guide.
Multi-area and multi-instance extensions to LDP
To extend LDP across multiple areas of an IGP instance or across multiple IGP instances, the current standard LDP implementation based on RFC 3036 requires that all the /32 prefixes of PEs be leaked between the areas or instances. This is because an exact match of the prefix in the routing table has to install the prefix binding in the LDP Forwarding Information Base (FIB).
Multi-area and multi-instance extensions to LDP provide an optional behavior by which LDP installs a prefix binding in the LDP FIB by simply performing a longest prefix match with an aggregate prefix in the routing table (RIB). The ABR is configured to summarize the /32 prefixes of PE routers. This method is compliant to RFC 5283- LDP Extension for Inter-Area Label Switched Paths (LSPs).
LDP IPv6 control and data planes
LDP IPv6 is supported only on the 7210 SAS-Mxp.
7210 SAS extends the LDP control and data planes to support the LDP IPv6 adjacency and session using 128-bit LSR-ID.
The implementation provides concurrent support of independent LDP IPv4 (32-bit LSR-ID) and IPv6 (128-bit LSR-ID) adjacencies and sessions between peer LSRs and over the same or different set of interfaces.
LDP Operation in an IPv6 Network
LDP IPv6 can be enabled on the 7210 SAS interface. The following figure shows the LDP adjacency and session over an IPv6 interface.
In the preceding example, LSR-A and LSR-B have the following IPv6 LDP identifiers respectively:
<LSR Id=A/128> : <label space id=0>
<LSR Id=B/128> : <label space id=0>
By default, A/128 and B/128 use the system interface IPv6 address.
Although the LDP control plane can operate using only the IPv6 system address, for optimal operation, the user must configure the IPv4-formatted router ID for OSPF, IS-IS, and BGP.
Link LDP
The 7210 SAS LDP IPv6 implementation uses a 128-bit LSR-ID as defined in draft-pdutta-mpls-ldp-v2-00. See LDP process overview for more information about interoperability of this implementation with 32-bit LSR-ID, as defined in RFC 7552.
Hello adjacency is brought up using a link Hello packet with the source IP address set to the interface link-local unicast address and a destination IP address set to the link-local multicast address FF02:0:0:0:0:0:0:2.
The transport address for the TCP connection, which is encoded in the Hello packet, is set to the LSR-ID of the LSR by default. It is set to the interface IPv6 address if the user enables the interface option under one of the following contexts:
config>router>ldp>if-params>ipv6>transport-address
config>router>ldp>if-params>if>ipv6>transport-address
The interface global unicast address, that is, the primary IPv6 unicast address of the interface, is used.
The user can configure the local-lsr-id option on the interface and change the value of the LSR-ID to either the local interface or to another interface name, whether a loopback interface or any other non-loopback interface. The global unicast IPv6 address corresponding to the primary IPv6 address of the interface is used as the LSR-ID. If the user invokes an interface that does not have a global unicast IPv6 address in the configuration of the transport address or the configuration of the local-lsr-id option, the session does not come up and an error message is displayed.
The LSR with the highest transport address bootstraps the IPv6 TCP connection and IPv6 LDP session.
Source and destination addresses of LDP and TCP session packets are the IPv6 transport addresses.
Targeted LDP
Source and destination addresses of the targeted Hello packet are the LDP IPv6 LSR IDs of systems A and B, as shown in LDP adjacency and session over an IPv6 interface.
The user can configure the local-lsr-id option on the targeted session and change the value of the LSR ID to either the local interface or to some other interface name, whether a loopback interface or any other non-loopback interface. The global unicast IPv6 address corresponding to the primary IPv6 address of the interface is used as the LSR ID. If the user invokes an interface that does not have a global unicast IPv6 address in the configuration of the transport address or the configuration of the local-lsr-id option, the session does not come up and an error message is displayed. In all cases, the transport address for the LDP session and the source IP address of the targeted Hello message is updated to the new LSR ID value.
The LSR with the highest transport address (in this case, the LSR ID) bootstraps the IPv6 TCP connection and IPv6 LDP session.
Source and destination IP addresses of LDP and TCP session packets are the IPv6 transport addresses (in this case, LDP LSR IDs of systems A and B).
FEC resolution
LDP advertises and withdraws all interface IPv6 addresses using the Address and Address-Withdraw message. Both the link-local unicast address and the configured global unicast addresses of an interface are advertised.
All LDP FEC types can be exchanged over an LDP IPv6 LDP session, similar to an LDP IPv4 session.
The LSR does not advertise a FEC for a link-local address and, if received, the LSR does not resolve it.
An IPv4 or IPv6 prefix FEC can be resolved to an LDP IPv6 interface in the same way as it is resolved to an LDP IPv4 interface. The outgoing interface and next hop are looked up in the RTM cache. The next hop can be the link-local unicast address of the other side of the link or a global unicast address. The FEC is resolved to the LDP IPv6 interface of the downstream LDP IPv6 LSR that advertised the IPv4 or IPv6 address of the next hop.
An mLDP P2MP IPv4 FEC with an IPv4 root LSR PE, and carrying one or more IPv4 multicast prefixes, can be resolved to an upstream LDP IPv6 LSR by checking if the LSR advertised the next hop for the IPv4 root PE. The upstream LDP IPv6 LSR then resolves the IPv4 P2MP FEC to one of the LDP IPV6 links to this LSR.
- The 7210 SAS does not support IPv6 multicast and the use of P2MP LSPs for IPv6 multicast.
- Manually configured mLDP P2MP LSPs, NG-mVPN, and dynamic mLDP cannot operate in an IPv6-only network.
A PW FEC can be resolved to a targeted LDP IPv6 adjacency with an LDP IPv6 LSR if there is a context for the FEC with local spoke-SDP configuration.
Resources required to trap LDP control packets to the CPU
On the 7210 SAS, by default, resources required to send LDP IPv6 packets for control plane processing are not available. The resources are shared with other control packets, and the total number of resources is configured using the config>system>resource-profile>ingress-internal-tcam>ip-mpls-protocols command. The user must allocate the appropriate number of resources using the ip-mpls-protocols command to ensure that LDP IPv6 can be configured for use.
The LDP IPv6 IFP entry is installed when an interface is enabled for LDP IPv6. The user can configure the config>router>ldp>interface-parameters>interface>ipv6 command to trigger the installation of the IFP entry.
The IFP entry is installed for the first LDP IPv6-enabled interface. It is uninstalled when the last interface is LDP IPv6-disabled.
-
The LDP IPv6 IFP entry is uninstalled only when the user configures the configure>router>ldp>interface-parameters>interface>no ipv6 command for the last interface in the ldp context. Executing the configure>router>ldp>interface-parameters>interface>ipv6>shutdown command on the last interface does not uninstall the IFP entry.
-
The user can issue the config>router>no ldp command only after issuing the config>router>ldp>shutdown command.
LDP session capabilities
LDP supports advertisement of all FEC types over an LDP IPv4 or an LDP IPv6 session. These FEC types are: IPv4 prefix FEC, IPv6 prefix FEC, IPv4 P2MP FEC, PW FEC 128, and PW FEC 129.
In addition, LDP supports signaling the enabling or disabling of the advertisement of the following subset of FEC types, both during the LDP IPv4 or IPv6 session initialization phase, and subsequently when the session is already up.
IPv4 prefix FEC
This is performed using the State Advertisement Control (SAC) capability TLV, as described in RFC 7473. The SAC capability TLV includes the IPv4 SAC element having the Disable-bit (D-bit) set or reset to disable or enable this FEC type, respectively. The LSR can send this TLV in the LDP Initialization message and subsequently in an LDP Capability message.
IPv6 prefix FEC
This is performed using the SAC capability TLV, as described in RFC 7473. The SAC capability TLV includes the IPv6 SAC element having the D-bit set or reset to disable or enable this FEC type, respectively. The LSR can send this TLV in the LDP Initialization message and subsequently in a LDP Capability message to update the state of this FEC type.
P2MP FEC
This is performed using the P2MP capability TLV, as described in RFC 6388. The P2MP capability TLV has the State-bit (S-bit) with a value of set or reset to enable or disable this FEC type, respectively. Unlike the IPv4 SAC and IPv6 SAC capabilities, the P2MP capability does not distinguish between the IPv4 and IPv6 P2MP FEC. The LSR can send this TLV in the LDP Initialization message and, subsequently, in a LDP Capability message to update the state of this FEC type.
During LDP session initialization, each LSR indicates to its peers the FEC type it supports by including the capability TLV for it in the LDP Initialization message. The 7210 SAS implementation enables the preceding FEC types by default and consequently sends the corresponding capability TLVs in the LDP initialization message. If one or both peers advertise the disabling of a capability in the LDP Initialization message, no FECs of the corresponding FEC type are exchanged between the two peers for the lifetime of the LDP session unless a Capability message is sent subsequently to explicitly enable it. The same behavior applies if no capability TLV for a FEC type is advertised in the LDP initialization message, except for the IPv4 prefix FEC, which is assumed to be supported by all implementations by default.
The Dynamic Capability, as defined in RFC 5561, allows all the preceding FEC types to update the enabled or disabled state after the LDP session initialization phase. An LSR informs its peer that it supports the Dynamic Capability by including the Dynamic Capability Announcement TLV in the LDP Initialization message. If both LSRs advertise this capability, the user is allowed to enable or disable any of the preceding FEC types while the session is up and the change takes effect immediately. The LSR then sends a SAC Capability message with the IPv4 or IPv6 SAC element having the D-bit set or reset, or the P2MP capability TLV in a Capability message with the S-bit set or reset. Each LSR then takes the consequent action of withdrawing or advertising the FECs of that type to the peer LSR. If one or both LSRs did not advertise the Dynamic Capability Announcement TLV in the LDP Initialization message, any change to the enabled or disabled FEC types only takes effect the next time the LDP session is restarted.
The user can enable or disable a specific FEC type for an LDP session to a peer using the following CLI commands:
config>router>ldp>session-params>peer>fec-type-capability p2mp
config>router>ldp>session-params>peer>fec-type-capability prefix-ipv4
config>router>ldp>session-params>peer>fec-type-capability prefix-ipv6
LDP adjacency capabilities
Adjacency-level FEC-type capability advertisement is defined in draft-pdutta-mpls-ldp-adj-capability. By default, all FEC types supported by the LSR are advertised in the LDP IPv4 or IPv6 session initialization; see LDP session capabilities for more information. If a specific FEC type is enabled at the session level, it can be disabled over a specific LDP interface at the IPv4 or IPv6 adjacency level for all IPv4 or IPv6 peers over that interface. If a specific FEC type is disabled at the session level, FECs are not advertised and enabling that FEC type at the adjacency level does not have any effect. The LDP adjacency capability can be configured on link Hello adjacency only and does not apply to targeted Hello adjacency.
The LDP adjacency capability TLV is advertised in the Hello message with the D-bit set or reset to disable or enable the resolution of this FEC type over the link of the Hello adjacency. It is used to restrict which FECs can be resolved over a specific interface to a peer. This provides the ability to dedicate links and data path resources to specific FEC types. An mLDP P2MP FEC can exclude specific links to a downstream LSR from being used to resolve this type of FEC.
Like the LDP session-level FEC-type capability, the adjacency FEC-type capability is negotiated for both directions of the adjacency. If one or both peers advertise disabling a capability in the LDP Hello message, no FECs of the corresponding FEC type are resolved by either peer over the link of this adjacency for the lifetime of the LDP Hello adjacency, unless one or both peers send the LDP adjacency capability TLV subsequently to explicitly enable it.
The user can enable or disable a specific FEC type for an LDP interface to a peer using the following CLI commands:
config>router>ldp>if-params>if>ipv4/ipv6>fec-type-capability p2mp-ipv4
config>router>ldp>if-params>if>ipv4/ipv6>fec-type-capability prefix-ipv4
config>router>ldp>if-params>if> ipv4/ipv6>fec-type-capability prefix-ipv6
These commands, when applied for the P2MP FEC, deprecate the existing command multicast-traffic {enable | disable} under the interface. Unlike the session-level capability, these commands can disable multicast FEC for IPv4 and IPv6 separately.
The encoding of the adjacency capability TLV uses a private Vendor TLV. It is used only in a Hello message to negotiate a set of capabilities for a specific LDP IPv4 or IPv6 Hello adjacency.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| ADJ_CAPABILITY_TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VENDOR_OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ +
| Adjacency capability elements |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the U-bit for the TLV is set to 1 so that a receiver must silently ignore if the TLV is deemed unknown.
The value of the F-bit is 0. After being advertised, this capability cannot be withdrawn; therefore, the S-bit is set to 1 in a Hello message.
Adjacency capability elements are encoded as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| CapFlag |
+-+-+-+-+-+-+-+-+
-
D bit: Controls the capability state.
-
1 : Disable capability
-
0 : Enable capability
-
CapFlag: The adjacency capability
-
1 : Prefix IPv4 forwarding
-
2 : Prefix IPv6 forwarding
-
3 : P2MP IPv4 forwarding
-
5 : MP2MP IPv4 forwarding
Each CapFlag appears no more than once in the TLV. If duplicates are found, the D-bit of the first element is used. For forward compatibility, if the CapFlag is unknown, the receiver must silently discard the element and continue processing the rest of the TLV.
Address and FEC distribution
After an LDP LSR initializes the LDP session to the peer LSR and the session comes up, local IPv4 and IPv6 interface addresses are exchanged using the Address and Address Withdraw messages. Similarly, FECs are exchanged using Label Mapping messages.
By default, IPv6 address distribution is determined by whether the Dual-stack capability TLV, which is defined in RFC 7552, is present in the Hello message from the peer. This coupling is introduced to prevent interoperability issues with existing third-party LDP IPv4 implementations.
The following is the detailed behavior for the processing of the Dual-stack capability TLV in conjunction with the IPv6 SAC TLV in the Hello message:
If the peer has sent the dual-stack capability TLV in the Hello message, IPv6 local addresses are sent to the peer. The user can configure a new address export policy to further restrict the local IPv6 interface addresses sent to the peer. If the peer explicitly enabled the LDP IPv6 FEC type by including the IPv6 SAC TLV with the D-bit set to 0 in the initialization message, IPv6 FECs are sent to the peer. The FEC prefix export policies can be used to restrict the LDP IPv6 FEC that can be sent to the peer.
If the peer has sent the dual-stack capability TLV in the Hello message, but explicitly disabled the LDP IPv6 FEC type by including the IPv6 SAC TLV with the D-bit set to 1 in the initialization message, IPv6 FECs are not sent, but IPv6 local addresses are sent to the peer. A CLI is provided to allow the configuration of an address export policy to further restrict the local IPv6 interface addresses that can be sent to the peer. The FEC prefix export policy has no effect because the peer has explicitly requested disabling the IPv6 FEC type advertisement.
If the peer has not sent the dual-stack capability TLV in the Hello message, no IPv6 addresses or IPv6 FECs are sent to that peer, regardless of whether the IPv6 SAC TLV is present in the initialization message. This case is added to prevent interoperability issues with existing third-party LDP IPv4 implementations. The user can override this by explicitly configuring an address export policy and a FEC export policy to select the addresses and FECs to send to the peer.
The preceding behavior applies to LDP IPv4 and IPv6 addresses and FECs. The procedure is summarized in the flowcharts shown in the following figures.
Controlling IPv6 FEC distribution during an upgrade to 7210 SAS SR OS supporting LDP IPv6
A FEC for each IPv4 and IPv6 system interface address is advertised and resolved automatically by the LDP peers when the LDP session comes up, regardless of whether the session is IPv4 or IPv6.
To avoid the automatic advertisement and resolution of an IPv6 system FEC when the LDP session is IPv4, perform this procedure before and after the upgrade to the 7210 SAS SR OS version that introduces support of LDP IPv6.
- Before the upgrade, implement a global prefix policy that rejects prefix [::0/0 longer] to prevent IPv6 FECs from being installed after the upgrade.
-
In the cold upgrade case:
-
If new IPv4 sessions are created on the node, the per-peer FEC capabilities must be configured to filter out IPv6 FECs.
-
On older, pre-existing IPv4 sessions, the per-peer FEC-capabilities must be configured to filter out IPv6 FECs.
-
- When all LDP IPv4 sessions have dynamic capabilities enabled, with per-peer FEC-capabilities for IPv6 FECs disabled, the global import policy can be removed.
Handling of duplicate link-local IPv6 addresses in FEC resolution
Link-local IPv6 addresses are scoped to a link and, consequently, duplicate addresses can be used on different links to the same or different peer LSRs. When the duplicate addresses exist on the same LAN, routing detects them and blocks one of them. In all other cases, duplicate links are valid because they are scoped to the local link.
In this section, LLn refers to Link-Local address (n).
The following figure shows FEC resolution in a LAN.
LSR B resolves an mLDP FEC with the root node being Root LSR. The route lookup indicates that the best route to loopback of Root LSR is {interface if-B and next-hop LL1}.
However, LDP finds that both LSR A and LSR C have advertised address LL1 and that there are Hello adjacencies (IPv4 or IPv6) to both A and C. In this case, a change is made so that an LSR only advertises link-local IPv6 addresses to a peer for the links over which it established a Hello adjacency to that peer. In this case, LSR C advertises LL1 to LSR E, but not to LSRs A, B, and D. This behavior applies with P2P and broadcast interfaces.
The preceding solution also applies if ambiguity exists with prefix FEC (unicast FEC).
FEC Resolution over P2P links
---------(LL1)-[C]------
|
[Root LSR]-------[A]-(LL1)-----[B] ------(LL4)-[D]------
| |
|-(LL2)---------|
| |
|-(LL3)---------|
LSR B resolves an mLDP FEC with the root node being Root LSR. The route lookup indicates that the best route to loopback of Root LSR is {interface if-B and next-hop LL1}. The following describes the FEC resolution use cases:
Case 1: LDP is enabled on all links
This case has no ambiguity. LDP only selects LSR A because the address LL1 from LSR C is discovered over a different interface. This case also applies to prefix FEC (unicast FEC), and consequently there is no ambiguity in the resolution.
Case 2: LDP is disabled on link A-B with next-hop LL1
LSR B can still select one of the other two interfaces to upstream LSR A, as long as LSR A has advertised the LL1 address in the LDP session.
IGP and static route synchronization with LDP
The IGP-LDP synchronization and the static route to LDP synchronization features are modified to operate on a dual-stack IPv4 or IPv6 LDP interface as follows:
-
If the router interface goes down or both LDP IPv4 and LDP IPv6 sessions go down, IGP sets the interface metric to the maximum value and all static routes with the ldp-sync option enabled and resolved on this interface are deactivated.
-
If the router interface is up and only one of the LDP IPv4 or LDP IPv6 interfaces goes down, no action is taken.
-
When the router interface comes up from a down state, and one of either the LDP IPv4 or LDP IPv6 sessions comes up, IGP starts the synchronization timer at the expiry of which the interface metric is restored to its configured value. All static routes with the ldp-sync option enabled are also activated at the expiry of the timer.
Because of the preceding behavior, Nokia recommends that the user should configure the synchronization timer to a value that allows enough time for both the LDP IPv4 and LDP IPv6 sessions to come up.
BFD operation
The operation of BFD over a LDP interface tracks the next hop of prefix IPv4 and prefix IPv6, in addition to tracking of the LDP peer address of the Hello adjacency over that link. This tracking is required as LDP can now resolve both IPv4 and IPv6 prefix FECs over a single IPv4 or IPv6 LDP session and, therefore, the next hop of a prefix does not necessarily match the LDP peer source address of the Hello adjacency. The failure of either or both of the BFD session tracking the FEC next hop and the one tracking the Hello adjacency cause the LFA backup NHLFE for the FEC to be activated, or the FEC to be re-resolved if there is no FRR backup.
The following CLI command provides the option to track only with an IPv4 BFD session, only with an IPv6 BFD session, or both:
config>router>ldp>if-params>if>bfd-enable [ipv4] [ipv6]
This command provides the flexibility required in case the user does not need to track both the Hello adjacency and next hops of FECs. For example, if the user configures bfd-enable ipv6 only to save on the number of BFD sessions, LDP tracks the IPv6 Hello adjacency and the next hops of IPv6 prefix FECs. LDP does not track next hops of IPv4 prefix FECs resolved over the same LDP IPv6 adjacency. If the IPv4 data plane encounters errors but the IPv6 Hello adjacency is unaffected and remains up, traffic for the IPv4 prefix FECs resolved over that IPv6 adjacency is blackholed. If the BFD tracking the IPv6 Hello adjacency times out, all IPv4 and IPv6 prefix FECs are updated.
The following behavior applies to the tracking of an mLDP FEC:
IPv4 and IPv6 mLDP FECs are only tracked with the Hello adjacency because they do not have the concept of downstream next hop.
The upstream LSR peer for an mLDP FEC supports the multicast upstream FRR procedures, and the upstream peer is tracked using the Hello adjacency on each link or the IPv6 transport address if there is a T-LDP session.
The tracking of a targeted LDP peer with BFD does not change with the support of IPv6 peers. BFD tracks the transport address conveyed by the Hello adjacency that bootstrapped the LDP IPv6 session.
Services using SDP with an LDP IPv6 FEC
The SDP of type ldp with the far-end option using IPv6 addresses is supported. The addresses need not be of the same family (IPv6 or IPv4) for the SDP configuration to be allowed. The user can have an SDP with an IPv4 (or IPv6) control plane for the T-LDP session and an IPv6 (or IPv4) LDP FEC as the tunnel.
Because IPv6 LSP is only supported with LDP, the use of a far-end IPv6 address is not allowed with a BGP or RSVP/MPLS LSP. In addition, the CLI does not allow an SDP with a combination of an IPv6 LDP LSP and an IPv4 LSP of a different control plane. As a result, the following commands are blocked in the SDP configuration context when the far end is an IPv6 address:
bgp-tunnel
lsp
mixed-lsp-mode
SDP administrative groups are not supported with an SDP using an LDP IPv6 FEC; the attempt to assign them is blocked in CLI.
Services that use LDP control plane (such as T-LDP VPLS spoke interface) have the spoke-SDP (PW) signaled with an IPv6 T-LDP session when the far-end option is configured to an IPv6 address. The spoke-SDP for these services binds by default to an SDP that uses a LDP IPv6 FEC, which prefix matches the far end address. In addition, the IPv6 PW control word is supported with both data plane packets and VCCV OAM packets. Hash label is also supported with the preceding services, including the signaling and negotiation of hash label support using T-LDP (Flow sub-TLV) with the LDP IPv6 control plane.
OAM Support with LDP IPv6
MPLS OAM tools lsp-ping and lsp-trace are updated to operate with LDP IPv6 and support the following:
use of IPv6 addresses in the echo request and echo reply messages, including in DSMAP TLV, in accordance with RFC 8029
use of LDP IPv6 prefix target FEC stack TLV, in accordance with RFC 8029
use of IPv6 addresses in the DDMAP TLV and FEC stack change sub-TLV, in accordance with RFC 6424
use of 127/8 IPv4 mapped IPv6 address; that is, in the range ::ffff:127/104, as the destination address of the echo request message, in accordance with RFC 8029
use of 127/8 IPv4 mapped IPv6 address; that is, in the range ::ffff:127/104, as the path-destination address when the user wants to exercise a specific LDP ECMP path
The behavior at the sender and receiver nodes is updated to support both LDP IPv4 and IPv6 target FEC stack TLVs. Specifically, the following applies.
-
The IP family (IPv4/IPv6) of the UDP/IP echo request message always matches the family of the LDP target FEC stack TLV the user entered in the prefix option.
-
The src-ip-address option is extended to accept the IPv6 address of the sender node. If the user did not enter a source IP address, the system IPv6 address is used. If the user entered a source IP address of a different family than the LDP target FEC stack TLV, an error is returned and the test command is aborted.
-
The IP family of the UDP/IP echo reply message must match that of the received echo request message.
-
For lsp-trace, the downstream information in DSMAP/DDMAP is encoded as the same family as the LDP control plane of the link LDP or targeted LDP session to the downstream peer.
-
The sender node inserts a value of 69 in the Router Alert Option in the IPv6 header of the echo request packet, in accordance with RFC 5350.
Finally, vccv-ping and vccv-trace for a single-hop PW are updated to support IPv6 PW FEC 128 and FEC 129, in accordance with RFC 6829. In addition, the PW OAM control word is supported with VCCV packets when the control-word option is enabled on the spoke-SDP configuration. The value of the Channel Type field is set to 0x57, which indicates that the Associated Channel carries an IPv6 packet, in accordance with RFC 4385.
Configuration guidelines for LDP IPv6 OAM tools
It is recommended to ping the remote destination so IPv6 ND tables are updated on intermediate routers along the shortest path to the destination before initiating lsp-ping to the destination router.
LDP IPv6 Interoperability Considerations
Interoperability with implementations compliant with RFC 7552
The 7210 SAS implementation uses a 128-bit LSR-ID, as defined in draft-pdutta-mpls-ldp-v2, to establish an LDP IPv6 session with a peer LSR. This allows a routable system IPv6 address to be used by default to bring up the LDP task on the router and establish link LDP and T-LDP sessions to other LSRs, as is the common practice with LDP IPv4 in existing customer deployments. More importantly, this allows for the establishment of control plane-independent LDP IPv4 and LDP IPv6 sessions between two LSRs over the same interface or set of interfaces. The 7210 SAS implementation allows for two separate LDP IPv4 and LDP IPv6 sessions between two LSRs over the same interface or a set of interfaces because each session uses a unique LSR-ID (32-bit for IPv4 and 128-bit for IPv6).
The 7210 SAS LDP implementation does not interoperate with an implementation using a 32-bit LSR-ID, as defined in draft-ietf-mpls-ldp-ipv6, to establish an IPv6 LDP session. The latter specifies an LSR can send both IPv4 and IPv6 Hellos over an interface such that it can establish either an IPv4 or an IPv6 LDP session with LSRs on the same subnet. It does not allow for separate LDP IPv4 and LDP IPv6 LDP sessions between two routers.
The 7210 SAS LDP implementation should interoperate with an implementation using a 32-bit LSR-ID, as defined in draft-ietf-mpls-ldp-ipv6, to establish an IPv4 LDP session and to resolve both IPv4 and IPv6 prefix FECs. The 7210 SAS LDP implementation otherwise complies with all other aspects of draft-ietf-mpls-ldpipv6, including the support of the dual-stack capability TLV in the Hello message. The latter is used by an LSR to inform its peer that it is capable of establishing either an LDP IPv4 or LDP IPv6 session, and to convey the IP family preference for the LDP Hello adjacency and the resulting LDP session. This is required because the implementation described in draft-ietf-mplsldp-ipv6 allows for a single session between LSRs, and both LSRs must agree if the session should be brought up using IPv4 or IPv6 when both IPv4 and IPv6 Hellos are exchanged between the two LSRs. The 7210 SAS implementation has a separate session for each IP family between two LSRs and, as such, this TLV is used to indicate the family preference and also that it supports resolving IPv6 FECs over an IPv4 LDP session.
Interoperability with implementations compliant with RFC 5036 for IPv4 LDP control plane only
The 7210 SAS implementation supports advertising and resolving IPv6 prefix FECs over an LDP IPv4 session using a 32-bit LSR-ID, in compliance with RFC 7552. When introducing an LSR based on the 7210 SAS in a LAN with a broadcast interface, it can peer with third-party LSR implementations that support RFC 7552 and LSRs that do not. When it peers, using an IPv4 LDP control plane, with a third-party LSR implementation that does not support it, the advertisement of IPv6 addresses or IPv6 FECs to that peer may cause it to bring down the IPv4 LDP session.
That is, there are deployed third-party LDP implementations that are compliant with RFC 5036 for LDP IPv4, but that are not compliant with RFC 5036 for handling IPv6 address or IPv6 FECs over an LDP IPv4 session. To resolve this issue, RFC 7552 modifies RFC 5036 by requiring implementations complying with RFC 7552 to check for the dual-stack capability TLV in the IPv4 Hello message from the peer. Without the peer advertising this TLV, an LSR must not send IPv6 addresses and FECs to that peer. The 7210 SAS implementation supports this requirement.
LDP process overview
The following figure shows the basic LDP parameter provisioning process.
The following figure shows the LDP configuration and implementation process.
Configuring LDP with CLI
This section provides information to configure LDP using the command line interface.
LDP configuration overview
When the 7210 SAS implementation of LDP is instantiated, the protocol is in the no shutdown state. In addition, targeted sessions are then enabled. The default parameters for LDP are set to the documented values for targeted sessions in draft-ietf-mpls-ldp-mib-09.txt.
Basic LDP configuration
This chapter provides information to configure LDP and remove configuration examples of common configuration tasks.
The LDP protocol instance is created in the no shutdown (enabled) state.
A:ALU_SIM11>config>router>ldp# info
----------------------------------------------
aggregate-prefix-match
prefix-exclude "sample"
exit
graceful-restart
exit
peer-parameters
peer 1.1.1.1
ttl-security 1
exit
exit
interface-parameters
interface "a"
exit
exit
targeted-session
exit
----------------------------------------------
A:ALU_SIM11>config>router>ldp#
Common configuration tasks
This section provides information about common configuration tasks.
Enabling LDP
LDP must be enabled in order for the protocol to be active. MPLS must also be enabled. MPLS is enabled in the config>router>mpls context.
Use the following syntax to enable LDP.
ldp
config>router# ldp
The following displays the enabled LDP configuration.
A:ALU_SIM11>config>router>ldp# info
----------------------------------------------
aggregate-prefix-match
prefix-exclude "sample"
exit
graceful-restart
exit
peer-parameters
peer 1.1.1.1
ttl-security 1
exit
exit
interface-parameters
interface "a"
exit
exit
targeted-session
exit
----------------------------------------------
A:ALU_SIM11>config>router>ldp#
Configuring FEC originate parameters
A FEC can be added to the LDP IP prefix database with a specific label operation on the node. Permitted operations are pop or swap. For a swap operation, an incoming label can be swapped with a label in the range of 16 to 1048575. If a swap- label is not configured then the default value is 3.
A route table entry is required for a FEC with a pop operation to be advertised. For a FEC with a swap operation, a route-table entry must exist and user configured next-hop for swap operation must match one of the next-hops in route-table entry.
Use the following syntax to configure FEC originate parameters.
config>router>ldp
fec-originate ip-prefix/mask [advertised-label in-label]
next-hop ip-address [swap-label out-label]
fec-originate ip-prefix/mask [advertised-label in-label]
pop
The following displays a FEC originate configuration example.
A:ALA-5>config>router# info
----------------------------------------------
fec-originate 10.1.1.1/32 pop
fec-originate 10.2.1.1/32 advertised-label 1000 next-hop 10.10.1.2
fec-originate 10.3.1.1/32 advertised-label 1001 next-hop 10.10.2.3
swap-label 131071
session-parameters
exit
interface-parameters
exit
targeted-session
exit
exit
----------------------------------------------
A:ALA-5>config>router>ldp#
Configuring graceful-restart helper parameters
Graceful-restart helper advertises to its LDP neighbors by carrying the fault tolerant (FT) session TLV in the LDP initialization message, assisting the LDP in preserving its IP forwarding state across the restart. The 7210 SAS recovery is self-contained and relies on information stored internally to self-heal. This feature is only used to help third-party routers without a self-healing capability to recover.
Maximum recovery time is the time (in seconds) the sender of the TLV would like the receiver to wait, after detecting the failure of LDP communication with the sender.
Neighbor liveness time is the time (in seconds) the LSR is willing to retain its MPLS forwarding state. The time should be long enough to allow the neighboring LSRs to re-sync all the LSPs in a graceful manner, without creating congestion in the LDP control plane.
Use the following syntax to configure graceful-restart parameters.
config>router>ldp
[no] graceful-restart
[no] maximum-recovery-time interval
[no] neighbor-liveness-time interval
Applying export and import policies
Both inbound and outbound label binding filtering are supported. Inbound filtering allows a route policy to control the label bindings an LSR accepts from its peers. An import policy can accept or reject label bindings received from LDP peers.
Label bindings can be filtered based on:
Neighbor — Match on bindings received from the specified peer.
Interface — Match on bindings received from a neighbor or neighbors adjacent over the specified interface.
Prefix-list — Match on bindings with the specified prefix/prefixes.
Outbound filtering allows a route policy to control the set of LDP label bindings advertised by the LSR. An export policy can control the set of LDP label bindings advertised by the router. By default, label bindings for only the system address are advertised and propagate all FECs that are received.
Matches can be based on:
Loopback — loopback interfaces.
All — all local subnets.
Match — match on bindings with the specified prefix/prefixes.
Use the following syntax to apply import and export policies.
config>router>ldp
export policy-name [policy-name...(up to 32 max)]
import policy-name [policy-name...(up to 32 max)]
A:ALU_SIM11>config>router>ldp# info
----------------------------------------------
aggregate-prefix-match
prefix-exclude "sample"
exit
graceful-restart
exit
peer-parameters
peer 1.1.1.1
ttl-security 1
exit
exit
interface-parameters
interface "a"
exit
exit
targeted-session
exit
----------------------------------------------
Targeted session parameters
Use the following syntax to specify targeted-session parameters.
config>router# ldp
targeted-session
disable-targeted-session
hello timeout factor
keepalive timeout factor
peer ip-address
no bfd-enable
hello timeout factor
keepalive timeout factor
no shutdown
The following example displays an LDP configuration example.
A:ALA-1>config>router>ldp# info
----------------------------------------------
...
targeted-session
hello 5000 255
keepalive 5000 255
peer 10.10.10.104
no bfd-enable
hello 2500 104
keepalive 15 3
exit
exit
----------------------------------------------
A:ALA-1>config>router>ldp#
Interface parameters
Use the following syntax to configure interface parameters.
config>router# ldp
interface-parameters
hello timeout factor
keepalive timeout factor
transport-address {system|interface}
interface ip-int-name
hello timeout factor
keepalive timeout factor
transport-address {system|interface}
no shutdown
The following example displays an interface parameter configuration example.
A:ALU_SIM11>config>router>ldp# info
----------------------------------------------
aggregate-prefix-match
prefix-exclude "sample"
exit
graceful-restart
exit
peer-parameters
peer 1.1.1.1
ttl-security 1
exit
exit
interface-parameters
interface "a"
exit
exit
targeted-session
exit
----------------------------------------------
Peer parameters
Use the following syntax to specify interface parameters.
config>router# ldp
peer-parameters
peer ip-address
auth-keychain name
authentication-key [authentication-key|hash-key]
[hash|hash2]
A:ALA-1>config>router>ldp# info
----------------------------------------------
peer-parameters
peer 10.10.10.104
authentication-key "3WErEDozxyQ" hash
exit
exit
targeted-session
hello 5000 255
keepalive 5000 255
peer 10.10.10.104
no bfd-enable
hello 2500 100
keepalive 15 3
exit
exit
----------------------------------------------
A:ALA-1>config>router>ldp#
LDP signaling and services
When LDP is enabled, targeted sessions can be established to create remote adjacencies with nodes that are not directly connected. When service distribution paths (SDPs) are configured, extended discovery mechanisms enable LDP to send periodic targeted hello messages to the SDP’s far-end point. The exchange of LDP hellos trigger session establishment. The SDP’s signaling default enables tldp. The service SDP uses the targeted-session parameters configured in the config>router>ldp>targeted-session context.
The following example displays the command syntax usage to configure enable LDP on an MPLS SDP.
config>service>sdp#
signaling {off|tldp}
The following displays an example of an SDP configuration showing the signaling default tldp enabled.
A:ALA-1>config>service>sdp# info detail
----------------------------------------------
description "MPLS: to-99"
far-end 10.10.10.99
lsp A_D_1
signaling tldp
path-mtu 4462
keep-alive
hello-time 10
hold-down-time 10
max-drop-count 3
timeout 5
no message-length
no shutdown
exit
no shutdown
----------------------------------------------
A:ALA-1>config>service>sdp#
LDP configuration management tasks
This section describes the LDP configuration management tasks.
Disabling LDP
The no ldp command disables the LDP protocol on the router. All parameters revert to the default settings. LDP must be shut down before it can be disabled.
Use the following command syntax to disable LDP:
no ldp
shutdown
Modifying targeted session parameters
The modification of LDP targeted session parameters does not take effect until the next time the
session goes down and is re-establishes. Individual
parameters cannot be deleted. The
no form of a
targeted-session parameter
command reverts modified values back to the
default.
The following example displays the command syntax usage to revert targeted session parameters back to the default values.
config>router# ldp
config>router>ldp# targeted-session
config>router>ldp>targeted# no authentication-key
config>router>ldp>targeted# no disable-targeted-session
config>router>ldp>targeted# no hello
config>router>ldp>targeted# no keepalive
config>router>ldp>targeted# no peer 10.10.10.99The following output displays the default values.
A:ALA-1>config>router>ldp>targeted# info detail
----------------------------------------------
no disable-targeted-session
hello 45 3
keepalive 40 4
----------------------------------------------
A:ALA-1>config>router>ldp>targeted#
Modifying interface parameters
The modification of LDP targeted session parameters does not take effect until the next time the session goes down and is re-establishes. Individual parameters cannot be deleted. The no form of a interface-parameter command resets the modified values back to the defaults.
The following output displays the default values.
A:ALU_SIM11>config>router>ldp>targ-session# info detail
----------------------------------------------
no disable-targeted-session
hello 45 3
keepalive 40 4
----------------------------------------------
A:ALU_SIM11>config>router>ldp>targ-session#
LDP command reference
Command hierarchies
LDP commands
config
- router
- [no] ldp
- [no] aggregate-prefix-match
- prefix-exclude policy-name [policy-name...(up to 5 max)]
- no prefix-exclude
- [no] shutdown
- export policy-name [policy-name...(up to 5 max)]
- no export
- fast-reroute
- no fast-reroute
- fec-originate ip-prefix/mask [advertised-label in-label] [swap-label out-label] interface interface-name
- fec-originate ip-prefix/mask [advertised-label in-label] next-hop ip-address [swap-label out-label]
- fec-originate ip-prefix/mask [advertised-label in-label] next-hop ip-address [swap-label out-label] interface interface-name
- fec-originate ip-prefix/mask [advertised-label in-label] pop
- no fec-originate ip-prefix/mask interface interface-name
- no fec-originate ip-prefix/mask next-hop ip-address
- no fec-originate ip-prefix/mask next-hop ip-address interface interface-name
- no fec-originate ip-prefix/mask pop
- [no] graceful-restart
- maximum-recovery-time interval
- no maximum-recovery-time
- neighbor-liveness-time interval
- no neighbor-liveness-time
- [no] implicit-null-label
- import policy-name [policy-name...(up to 5 max)]
- interface-parameters
- interface ip-int-name [dual-stack]
- no interface ip-int-name
- bfd-enable
- no bfd-enable
- ipv4
- fec-type-capability
- p2mp-ipv4 {enable | disable}
- prefix-ipv4 {enable | disable}
- prefix-ipv6 {enable | disable}
- hello timeout factor
- no hello
- keepalive timeout factor
- no keepalive
- local-lsr-id {system | interface | interface-name interface-name}
- no local-lsr-id
- [no] shutdown
- transport-address {system | interface}
- ipv6
- fec-type-capability
- p2mp-ipv4 {enable | disable}
- prefix-ipv4 {enable | disable}
- prefix-ipv6 {enable | disable}
- hello timeout factor
- no hello
- keepalive timeout factor
- no keepalive
- local-lsr-id {system | interface}
- local-lsr-id interface-name interface-name
- no local-lsr-id
- [no] shutdown
- transport-address {system | interface}
- ipv4
- hello timeout factor
- no hello
- keepalive timeout factor
- no keepalive
- transport-address {system | interface}
- ipv6
- hello timeout factor
- no hello
- keepalive timeout factor
- no keepalive
- transport-address {system | interface}
- label-withdrawal-delay seconds
- [no] prefer-tunnel-in-tunnel
- session-parameters
- [no] peer ip-address
- [no] adv-adj-add-only
- [no] dod-label-distribution
- export-addresses policy-name [policy-name ... (up to 5 max)]
- no export-addresses
- export-prefixes policy-name [policy-name ... (up to 5 max)]
- no export-prefixes
- fec-limit limit [log-only] [threshold percentage]
- no fec-limit
- fec-type-capability
- p2mp {enable | disable}
- prefix-ipv4 {enable | disable}
- prefix-ipv6 {enable | disable}
- [no] fec129-cisco-interop
- import-prefixes policy-name [policy-name ... (up to 5 max)]
- no import-prefixes
- [no] pe-id-mac-flush-interop
- [no] shutdown
- targeted-session
- [no] disable-targeted-session
- ipv4
- hello timeout factor
- no hello
- hello-reduction {enable factor | disable}
- no hello-reduction
- keepalive timeout factor
- no keepalive
- ipv6
- hello timeout factor
- no hello
- hello-reduction {enable factor | disable}
- no hello-reduction
- keepalive timeout factor
- no keepalive
- peer ip-address
- no peer ip-address
- bfd-enable
- no bfd-enable
- hello timeout factor
- no hello
- keepalive timeout factor
- no keepalive
- local-lsr-id interface-name
- no local-lsr-id
- [no] shutdown
- no tunneling
- no lsp lsp-name
- tcp-session-parameters
- peer-transport ip-address
- auth-keychain name
- authentication-key [authentication-key | hash-key] [hash | hash2]
- no authentication-key
- [no] path-mtu-discovery
- [no] ttl-security min-ttl-value
- tunnel-down-damp-time seconds
- no tunnel-down-damp-time
Show commands
show
- router
- ldp
- bindings active [fec-type prefixes] [prefix ip-prefix/mask] [egress-nh ip-address | egress-if port-id | egress-lsp tunnel-id] [summary]
- bindings active active-ecmp
- bindings active [fec-type p2mp] [p2mp-id identifier root ip-address] [egress-nh ip-address | egress-if port-id | egress-lsp tunnel-id] [summary]
- bindings active [fec-type p2mp] [source ip-address] group mcast-address root ip-address]] [egress-nh ip-address] | egress-if port-id | egress-lsp tunnel-id] [summary]
- bindings active prefixes [family] [{summary | detail}] [egress-if port-id]
- bindings active prefixes [family] [{summary | detail}] [egress-lsp tunnel-id]
- bindings active prefixes [egress-nh ip-address] [family] [{summary | detail}]
- bindings active prefixes prefix ip-prefix/ip-prefix-length [{summary | detail}] [egress-if port-id]
- bindings active prefixes prefix ip-prefix/ip-prefix-length [{summary | detail}] [egress-lsp tunnel-id]
- bindings active prefixes prefix ip-prefix/ip-prefix-length [egress-nh ip-address] [{summary | detail}]
- bindings fec-type {prefixes|services} [session ip-addr 4c5]] [summary| detail]
- bindings fec-type p2mp [session ip-addr[:label-space]] [summary | detail]
- bindings fec-type p2mp p2mp-id identifier root ip-address [session ip-addr[:label-space]] [summary|detail]
- bindings fec-type p2mp root ip-address [session ip-addr[:label-space]] [summary|detail] source ip-address group mcast-address
- bindings[fec-type fec-type [detail]] [session ip-addr[:label-space]]
- bindings [label-type] [start-label [end-label]
- bindings {prefix ip-prefix/mask [detail]} [session ip-addr[:label-space]]
- bindings prefixes prefix ip-prefix/ip-prefix-length [{summary | detail}] [session ip-addr[:label-space]]
- bindings prefixes [family] [{summary | detail}] [session ip-addr[:label-space]]
- bindings active [prefix ip-prefix/mask]
- bindings service-id service-id [detail]
- bindings vc-type vc-type [{vc-id vc-id | agi agi} [session ip-addr[:label-space]]]
- active
- ipv4 [summary | detail] [egress-if port-id]
- ipv4 [summary | detail] [egress-lsp tunnel-id]
- ipv4 [summary | detail] [egress-nh ip-address]
- ipv6 [summary | detail] [egress-if port-id]
- ipv6 [summary | detail] [egress-lsp tunnel-id]
- ipv6 [summary | detail] [egress-nh ip-address]
- ipv4 [session ip-addr[label-space]] [summary | detail]
- ipv6 [session ip-addr[label-space]] [summary | detail]
- discovery [{peer [ip-address]} | {interface [ip-int-name]}] [state state] [detail]
- interface [ip-int-name | ip-address] [detail]
- parameters
- session [ip-addr[:label-space]] [detail | statistics [packet-type]]
- session-parameters [family]
- session-parameters [peer-ip-address]
- statistics
- status
- targ-peer [ip-address] [detail]
- targ-peer [detail] family
- targ-peer resource-failures [family]
- tcp-session-parameters [family]
- tcp-session-parameters [keychain keychain]
- tcp-session-parameters [transport-peer-ip-address]
Clear commands
clear
- router
- ldp
- instance
- interface [ip-int-name] [family]
- peer [ip-address] [statistics]
- session [ip-addr[:label-space]] [statistics]
- statistics
Debug commands
[no] debug
- router
- [no] ldp
- [no] interface interface-name family
- [no] event
- [no] messages
- [no] packet [detail]
- hello [detail]
- no hello
- peer ip-address
- [no] event
- [no] bindings
- [no] messages
- [no] packet
- hello [detail]
- no hello
- init [detail]
- no init
- [no] keepalive
- label [detail]
- no label
Command descriptions
LDP configuration commands
Generic commands
shutdown
Syntax
[no] shutdown
Context
config>router>ldp
config>router>ldp>targ-session>peer
config>router>ldp>interface-parameters>interface>ipv4
config>router>ldp>interface-parameters>ipv4
config>router>ldp>interface-parameters>interface>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>interface-parameters>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>aggregate-prefix-match
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.
The operational state of the entity is disabled, as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.
Unlike other commands and parameters for which the default state is not indicated in the configuration file, the shutdown and no shutdown states are always indicated in system-generated configuration files.
The no form of this command places an entity in an administratively enabled state.
Default
no shutdown
Special Cases
- LDP Protocol Handling
On all 7210 SAS platforms, LDP is created in the no shutdown state.
On the 7210 SAS-Mxp, the protocol is handled as follows:
The configure router ldp command instantiates the protocol in the no shutdown state and resources are allocated to enable the node to process the protocol.
To deallocate resources, users must issue the configure router ldp shutdown and configure router no ldp commands to allow the node to boot up correctly after the reboot. It is not sufficient to issue only the configure router ldp shutdown command.
- See Note for more information about uninstalling LDP IPv6 IFP entries using CLI commands.
LDP global commands
ldp
Syntax
[no] ldp
Context
config>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure LDP parameters. LDP is not enabled by default and must be explicitly enabled (no shutdown).
To suspend the LDP protocol, use the shutdown command. Configuration parameters are not affected.
The no form of this command deletes the LDP protocol instance, removing all associated configuration parameters. The LDP instance must first be disabled using the shutdown command before being deleted.
aggregate-prefix-match
Syntax
[no] aggregate-prefix-match
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables LDP to use the aggregate prefix match function instead of requiring an exact prefix match.
When this command is enabled, LDP performs the following procedures for all prefixes. When an LSR receives a FEC-label binding from an LDP neighbor for a specific FEC1 element, it installs the binding in the LDP FIB if:
it is able to perform a successful longest IP match of the FEC prefix with an entry in the routing table
the advertising LDP neighbor is the next hop to reach the FEC prefix
When the FEC-label binding has been installed in the LDP FIB, LDP programs a next-hop label forwarding entry (NHLFE) in the egress datapath to forward packets to FEC1. LDP also advertises a new FEC-label binding for FEC1 to all its LDP neighbors.
When a new prefix appears in the routing table, LDP checks the LDP FIB to determine if this prefix is a closer match for any of the installed FEC elements. If a closer match is found, LDP may have to update the NHLFE for this FEC.
When a prefix is removed from the routing table, LDP checks the LDP FIB for all FEC elements that matched this prefix to determine if another match exists in the routing table. If another match exists, it updates the NHLFE accordingly. If not, it sends a label withdraw message to its LDP neighbors to remove the binding.
If the next hop for a routing prefix changes, LDP updates the LDP FIB entry for the FEC elements that matched this prefix. It also updates the NHLFE for these FEC elements.
The no form of this command disables the use of the aggregate prefix match function and deletes the configuration. LDP then performs only exact prefix matching for FEC elements.
Default
no aggregate-prefix-match
prefix-exclude
Syntax
prefix-exclude policy-name [policy-name...(up to 5 max)]
no prefix-exclude
Context
config>router>ldp>aggregate-prefix-match
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the policy name containing the prefixes to be excluded from the aggregate prefix match function. Against each excluded prefix, LDP performs an exact match of a specific FEC element prefix, instead of a longest prefix match of one or more LDP FEC element prefixes, when it receives a FEC-label binding or when a change to this prefix occurs in the routing table.
The no form of this command removes all policies from the configuration.
Default
no prefix-exclude
Parameters
- policy-name
Specifies the import route policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
export
Syntax
export policy-name [policy-name … up to 5 max]
no export
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the export route policies that determine which routes are exported to LDP. Policies are configured in the config>router>policy-options context.
If no export policy is specified, non-LDP routes are not exported from the routing table manager to LDP, and LDP-learned routes are exported only to LDP neighbors. The current implementation of the export policy (outbound filtering) can be used only to add FECs for label propagation. The export policy does not control propagation of FECs that an LSR receives from its neighbors.
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered overrides the previous command. A maximum of five policy names can be specified. Specified names must already be defined.
The no form of this command removes all policies from the configuration.
Default
no export
Parameters
- policy-name
Specifies the export route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
The specified names must already be defined.
fast-reroute
Syntax
fast-reroute
no fast-reroute
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables LDP Fast-Reroute (FRR). When enabled, LDP uses both the primary next hop and LFA next hop, when available, for resolving the next hop of an LDP FEC against the corresponding prefix in the routing table. This results in LDP programming a primary NHLFE and a backup NHLFE into the forwarding engine for each next hop of a FEC prefix for the purpose of forwarding packets over the LDP FEC.
The backup NHLFE is enabled for each affected FEC next hop when any of the following events occurs.
An LDP interface goes operationally down or is administratively shut down. In this case, LDP sends a neighbor/next-hop down message to the IOM for each LDP peer it has adjacency with over this interface.
An LDP session to a peer goes down because the Hello or keepalive timer has expired over a specific interface. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only.
The TCP connection used by a link LDP session to a peer goes down because, for example, next-hop tracking of the LDP transport address in RTM brings down the LDP session. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only.
A BFD session, enabled on a T-LDP session to a peer, times out and causes the link LDP session to the same peer, which uses the same TCP connection as the T-LDP session, to also go down. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only.
A BFD session enabled on the LDP interface to a directly connected peer times out and brings down the link LDP session to this peer. In this case, LDP sends a neighbor/next-hop down message to the IOM for this LDP peer only. BFD support on LDP interfaces is a recent feature that provides faster tracking of link LDP peers.
The tunnel-down-dump-time option or the label-withdrawal-delay option, when enabled, does not cause the corresponding timer to be activated for a FEC as long as a backup NHLFE is still available.
Because LDP can detect the loss of a neighbor/next-hop independently, it is possible that it will switch to the LFA next hop while IGP is still using the primary next hop. Also, when the interface for the previous primary next hop is restored, IGP may reconverge before LDP completes the FEC exchange with its neighbor over that interface. This may cause LDP to deprogram the LFA next hop from the FEC and blackhole traffic. To avoid this situation, IGP-LDP synchronization should be enabled on the LDP interface.
When the SPF computation determines there is more than one primary next hop for a prefix, it does not program an LFA next hop in RTM. The LDP FEC will resolve to the multiple primary next hops that provide the required protection.
The no form of this command disables LDP FRR.
Default
no fast-reroute
fec-originate
Syntax
fec-originate ip-prefix/mask [advertised-label in-label] [swap-label out-label] interface interface-name
fec-originate ip-prefix/mask [advertised-label in-label] next-hop ip-address [swap-label out-label]
fec-originate ip-prefix/mask [advertised-label in-label] next-hop ip-address [swap-label out-label] interface interface-name
fec-originate ip-prefix/mask [advertised-label in-label] pop
no fec-originate ip-prefix/mask interface interface-name
no fec-originate ip-prefix/mask next-hop ip-address
no fec-originate ip-prefix/mask next-hop ip-address interface interface-name
no fec-originate ip-prefix/mask pop
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures a way to originate a FEC (with a swap action) for which the LSR is not egress, or to originate a FEC (with a pop action) for which the LSR is egress.
Parameters
- ip-prefix/mask
Specifies the information for the specified IP prefix and mask length.
- ip-address
Specifies the IP address of the next hop of the prefix.
- advertised-label
Keyword to specify the label advertised to the upstream peer. If not configured, the label advertised should be from the label pool. If the configured static label is not available, the IP prefix is not advertised.
- out-label
Specifies the LSR to swap the label. If configured, the LSR should swap the label with the configured swap-label. If not configured, the default action is pop if the next-hop parameter is not defined.
The next-hop, advertised-label, and swap-label parameters are optional. If next-hop is configured but no swap-label specified, a swap occurs with label 3, such as, pop and forward to the next-hop. If the next-hop and swap-label are configured, a regular swap is performed. If no parameters are specified, a pop and route is performed.
- in-label
Specifies the number of labels to send to the peer associated with this FEC.
- pop
Keyword to pop the label and transmit without the label.
- interface interface-name
Specifies the name of the interface the label for the originated FEC is swapped to. For an unnumbered interface, this parameter is mandatory since there is no address for the next-hop. For a numbered interface, it is optional.
graceful-restart
Syntax
[no] graceful-restart
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables graceful restart helper.
The no form of this command disables graceful restart.
Default
no graceful-restart
implicit-null-label
Syntax
[no] implicit-null-label
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of the implicit null label. Use this command to signal the implicit null option for all LDP FECs for which this node is the egress LER.
The no form of this command disables the signaling of the implicit null label.
Default
no implicit-null-label
maximum-recovery-time
Syntax
maximum-recovery-time interval
no maximum-recovery-time
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the local maximum recovery time.
The no form of this command reverts to the default value.
Default
maximum-recovery-time 120
Parameters
- interval
Specifies the length of time, in seconds.
neighbor-liveness-time
Syntax
neighbor-liveness-time interval
no neighbor-liveness-time
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the neighbor liveness time.
The no form of this command reverts to the default value.
Default
neighbor-liveness-time 120
Parameters
- interval
Specifies the length of time in seconds.
import
Syntax
import policy-name [policy-name … up to 5 max]
no import
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures import route policies to determine which label bindings (FECs) are accepted from LDP neighbors. Policies are configured in the config>router>policy-options context.
If no import policy is specified, LDP accepts all label bindings from configured LDP neighbors. Import policies can be used to limit or modify the routes accepted and their corresponding parameters and metrics.
If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered overrides the previous command. A maximum of five policy names can be specified.
The no form of this command removes all policies from the configuration.
Default
no import
Parameters
- policy-name
Specifies the import route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
label-withdrawal-delay
Syntax
label-withdrawal-delay seconds
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the time interval, in seconds, that LDP will delay the withdrawal of the FEC-label bindings it distributed to its neighbors when FEC is deactivated. When the timer expires, LDP sends a label withdrawal for the FEC to all its neighbors. This is applicable only to LDP transport tunnels (IPv4 prefix FECs) and is not applicable to pseudowires (service FECs).
Default
no label-withdrawal-delay
Parameters
- seconds
Specifies the time that LDP delays the withdrawal of the FEC-label binding it distributed to its neighbors when FEC is deactivated.
tunnel-down-damp-time
Syntax
tunnel-down-damp-time seconds
no tunnel-down-damp-time
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the time interval, in seconds, that LDP waits before posting a tunnel down event to the Tunnel Table Manager (TTM).
When LDP can no longer resolve a FEC and deactivates it, it deprograms the NHLFE in the datapath. However, it delays deleting the LDP tunnel entry in the TTM until the tunnel-down-damp-time timer expires. This means that users of the LDP tunnel, such as SDPs (for all services) and BGP (for Layer 3 VPNs), are not immediately notified. Traffic is still blackholed because the forwarding engine NHLFE has been deprogrammed.
If the FEC gets resolved before the tunnel-down-damp-time timer expires, LDP programs the forwarding engine with the new NHLFE and performs a tunnel modify event in the TTM, updating the dampened entry in the TTM with the new NHLFE information. If the FEC does not get resolved and the tunnel-down-damp-time timer expires, LDP posts a tunnel down event to the TTM, which deletes the LDP tunnel.
When there is an upper layer (user of LDP) that depends on the LDP control plane for failover detection, the label-withdrawal-delay and tunnel-down-damp-time options must be set to 0; for example, where a primary pseudowire does not have its own fast failover detection mechanism, and the node depends on the LDP tunnel down event to activate the standby PW.
The no form of this command specifies that tunnel-down events are not damped.
Parameters
- seconds
Specifies the time interval, in seconds, that LDP waits before posting a tunnel down event to the TTM.
keepalive
Syntax
keepalive timeout factor
no keepalive
Context
config>router>ldp>interface-parameters>interface>ipv4
config>router>ldp>interface-parameters>ipv4
config>router>ldp>interface-parameters>interface>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>interface-parameters>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>targ-session>ipv4
config>router>ldp>targ-session>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>targ-session>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the time interval, in seconds, that LDP waits before tearing down the session. The value of the keepalive interval is derived from the factor parameter.
If no LDP messages are exchanged for the configured amount of time, the LDP session is torn down. The keepalive timeout is usually three times the value of the keepalive interval. To maintain the session permanently, regardless of the activity, set the timeout value to zero.
When the LDP session is being set up, the keepalive timeout is negotiated to the lower of the two peers. When an operational value is agreed upon, the keepalive factor derives the value of the keepalive interval. The session must be flapped for the new settings to take effect.
The no form of this command at the interface level sets the timeout and factor to the values defined under the interface-parameters level.
The no form of this command at the peer level sets the timeout and factor to the values defined under the targeted-session level.
Default
The keepalive timeout factor default values, which are dependent on the CLI context, are listed in the following table.
Context |
Timeout |
Factor |
|---|---|---|
|
config>router>ldp>if-params |
30 |
3 |
|
config>router>ldp>targ-session |
40 |
4 |
|
config>router>ldp>if-params>if |
Inherits values from interface-parameters context |
|
|
config>router>ldp>targ-session>peer |
Inherits values from targeted-session context |
|
Parameters
- timeout
Specifies the time interval, in seconds, that LDP waits before tearing down the session.
- factor
Specifies the number of keepalive messages, expressed as a decimal integer, that should be sent on an idle LDP session in the keepalive timeout interval.
local-lsr-id
Syntax
local-lsr-id {system | interface | interface-name interface-name}
local-lsr-id interface-name interface-name
no local-lsr-id
Context
config>router>ldp>interface-parameters>interface>ipv4
config>router>ldp>interface-parameters>interface>ipv6 (supported only on 7210 SAS-Mxp)
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the use of the local LDP interface address as the LSR ID to establish a link LDP adjacency and session with a directly connected LDP peer.
By default, the LDP session uses the system interface address as the LSR ID unless it is explicitly configured using this command. Although it is required to always configure the system interface on the router for the LDP protocol to come up on the node, there is no requirement to include the system interface in any routing protocol.
At initial configuration, the LDP session to the peer remains down while the interface is down.
If the user changes the LSR ID on the fly between system and interface values while the LDP session is up, LDP immediately tears down the session and attempts to re-establish it using the new LSR ID.
If the interface used as the LSR ID goes down, the LDP session goes down.
When the interface option is selected, the transport connection (TCP) for the link LDP session will also use the address of the local LDP interface as the transport address. If system is the value configured using the config>router>ldp>interface-parameters>interface>transport-address command, it is overridden.
The no form of this command returns to the default behavior of using the system interface address as the LSR ID.
Default
local-lsr-id system
Parameters
- interface
Keyword to configure the local LDP interface address as the value of the LSR ID of this LDP LSR.
- system
Keyword to configure the system interface address as the value of the LSR ID of this LDP LSR.
- interface-name
-
Specifies the name of the network IP interface, up to 256 characters. An interface name cannot be in the form of an IP address. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
local-lsr-id
Syntax
local-lsr-id interface-name
no local-lsr-id
Context
config>router>ldp>targeted-session>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of the address of a specific interface as the LSR-ID for the hello adjacency of a T-LDP session. The interface can be a regular interface or a loopback interface, including the system interface.
By default, a T-LDP session uses the system interface address as the LSR-ID. The system interface must always be configured on the router or the LDP protocol will not come up on the node. There is no requirement to include the system interface in any routing protocol though.
At initial configuration, the T-LDP session will remain down while the specified interface is down. LDP will not try to bring it up using the system interface.
If the user changes the LSR-ID on the fly while the T-LDP session is up, LDP immediately tears down the session and attempts to establish one using the new LSR-ID, regardless of operational state of the newly specified interface.
If the interface used as the LSR-ID goes down, the T-LDP session goes down.
The user-configured LSR-ID is used exclusively for extended peer discovery to establish the T-LDP hello adjacency. It is also used as the transport address for the TCP session of the LDP session when it is bootstrapped by the T-LDP hello adjacency. The user-configured LSR-ID is not used in basic peer discovery to establish a link-level LDP hello adjacency.
The no form of this command returns to the default behavior where the system interface address is used as the LSR-ID.
Default
no local-lsr-id
Parameters
- interface-name
Specifies the name of the network IP interface, up to 32 characters. An interface name cannot be in the form of an IP address. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
interface-parameters
Syntax
interface-parameters
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures LDP interfaces and parameters applied to LDP interfaces.
bfd-enable
Syntax
bfd-enable
no bfd-enable
Context
config>router>ldp>targ-session
config>router>ldp>targ-session>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of bidirectional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a specific protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.
The no form of this command removes BFD from the associated IGP/BGP protocol adjacency.
Default
no bfd-enable
p2mp-ipv4
Syntax
p2mp-ipv4 {enable | disable}
Context
config>router>ldp>interface-params>interface>ipv4>fec-type-capability
config>router>ldp>interface-params>interface>ipv6>fec-type-capability (supported only on 7210 SAS-Mxp)
Platforms
7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables and disables the IPv4 P2MP FEC capability on the interface.
Parameters
- enable
Keyword to enable the IPv4 P2MP FEC capability.
- disable
Keyword to disable the IPv4 P2MP FEC capability.
prefix-ipv4
Syntax
prefix-ipv4 {enable | disable}
Context
config>router>ldp>interface-params>interface>ipv4>fec-type-capability
config>router>ldp>interface-params>interface>ipv6>fec-type-capability (supported only on 7210 SAS-Mxp)
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables and disables the IPv4 prefix FEC capability on the interface.
Parameters
- enable
-
Keyword to enable the IPv4 prefix FEC capability.
- disable
-
Keyword to disable the IPv4 prefix FEC capability.
prefix-ipv6
Syntax
prefix-ipv6 {enable | disable}
Context
config>router>ldp>interface-params>interface>ipv4>fec-type-capability
config>router>ldp>interface-params>interface>ipv6>fec-type-capability (supported only on 7210 SAS-Mxp)
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables and disables the IPv6 prefix FEC capability on the interface.
Parameters
- enable
-
Keyword to enable the IPv6 prefix FEC capability.
- disable
-
Keyword to disable the IPv6 prefix FEC capability.
hello
Syntax
hello timeout factor
no hello
Context
config>router>ldp>interface-parameters>interface>ipv4
config>router>ldp>interface-parameters>ipv4
config>router>ldp>interface-parameters>interface>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>interface-parameters>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>targ-session>ipv4
config>router>ldp>targ-session>ipv6 (supported only on 7210 SAS-Mxp)
config>router>ldp>targ-session>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the time interval to wait before declaring a neighbor down. The factor parameter derives the Hello interval.
The hold time is local to the system and sent in the Hello messages to the neighbor. The hold time cannot be less than three times the hello interval.
When the LDP session is being set up, the hold down time is negotiated to the lower of the two peers. After an operational value is agreed upon, the hello factor is used to derive the value of the hello interval.
The session must be flapped for the new settings to operate.
The no form of this command at the targeted-session level sets the hello timeout and the hello factor to the default values.
The no form of this command at the peer level sets the hello timeout and the hello factor to the value defined under the targeted-session level.
Default
The following table lists the default values for the timeout and factor parameters.
Context |
Timeout |
Factor |
|---|---|---|
config>router>ldp>if-params |
15 |
3 |
config>router>ldp>targ-session |
45 |
3 |
config>router>ldp>if-params>if |
Inherits values from the interface-parameters context |
|
config>router>ldp>targ-session>peer |
Inherits values from the targeted-session context |
|
Parameters
- timeout
Specifies the time interval, in seconds, that LDP waits before a neighbor goes down.
- factor
Specifies the number of keepalive messages that should be sent on an idle LDP session in the hello timeout interval.
hello-reduction
Syntax
hello-reduction {enable factor | disable}
no hello-reduction
Context
config>router>ldp>targ-session>ipv4
config>router>ldp>targ-session>ipv6 (supported only on 7210 SAS-Mxp)
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the suppression of periodic targeted Hello messages between LDP peers after the targeted LDP session is brought up.
When this feature is enabled, the target Hello adjacency is brought up by advertising the hold-time value configured in the hello timeout parameter for the targeted session. The LSR node starst advertising an exponentially increasing hold-time value in the Hello message as soon as the targeted LDP session to the peer is up. Each new incremented hold-time value is sent in a number of Hello messages equal to the value of the argument factor, which represents the dampening factor, before the next exponential value is advertised. This provides time for the two peers to settle on the new value. When the hold-time reaches the maximum value of 0xffff (binary 65535), the two peers send Hello messages at a frequency of every [(65535-1)/local helloFactor] seconds for the lifetime of the targeted LDP session. For example, if the local Hello factor is 3, Hello messages are sent every 21844 seconds.
The LSR node continues to compute the frequency of sending the Hello messages based on the minimum of its local hold-time value and the one advertised by its peer, as described in RFC 5036. Therefore, for the targeted LDP session to suppress the periodic Hello messages, both peers must bring their advertised hold-time to the maximum value. If one of the LDP peers does not, the frequency of the Hello messages sent by both peers continues to be governed by the smaller of the two hold-time values.
When the user enables the hello reduction option on the LSR node while the targeted LDP session to the peer is operationally up, the change takes effect immediately.That is, the LSR node starts advertising an exponentially increasing hold time value in the Hello message, starting with the current configured hold time value.
When the user disables the hello reduction option while the targeted LDP session to the peer is operationally up, the change in the hold time value from 0xffff (binary 65535) to the user-configured value for this peer takes effect immediately. The local LSR immediately advertises the value of the user-configured hold time and does not wait until the next scheduled time to send a Hello to make sure the peer adjusts its local hold timeout value immediately.
In general, any configuration change to the parameters of the T-LDP Hello adjacency (modifying the hello adjacency Hello timeout or factor, enabling or disabling hello reduction, or modifying the hello reduction factor) causes the LSR node to immediately trigger an updated Hello message with the updated hold-time value without waiting for the next scheduled time to send a Hello.
The no form of this command disables the hello reduction feature.
Default
no hello-reduction
Parameters
- disable
Keyword to disable hello reduction.
- factor
Specifies the hello reduction dampening factor.
interface
Syntax
interface ip-int-name [dual-stack]
no interface ip-int-name
Context
config>router>ldp>if-params
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables LDP on the specified IP interface.
The LDP interface must be disabled using the shutdown command before it can be deleted.
The no form of this command deletes the LDP interface and all configuration information associated with the LDP interface.
Parameters
- ip-int-name
Specifies the name of an existing interface. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- dual-stack
-
Optional keyword that allows the user to explicitly indicate whether this interface should automatically create the IPv4 context. With the introduction of LDP IPv6, the creation of the interface does not automatically imply it is used for IPv4, simular to earlier IPv4 only interfaces. Therefore, the dual-stack keyword is an indication to the system that the user manually enables the IPv4, IPv6, or the dual-stack IPv4 and IPv6 contexts.
The following applies to the dual-stack keyword:- If this keyword is configured, the IPv4 interface context is not created automatically. If it is not configured, the IPv4 interface context is created similar to the single stack LDP IPv4 interface behavior.
- This keyword is always displayed in a configuration.
- When entering an already configured interface, configuring this keyword is not required; it is ignored if configured.
- When deleting a configured interface, this keyword is not accepted in the no form of this command.
bfd-enable
Syntax
bfd-enable
no bfd-enable
Context
config>router>ldp>interface-parameters>interface>ipv4
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables tracking of the Hello adjacency to an LDP peer using BFD.
When this command is enabled on an LDP interface, LDP registers with BFD and starts tracking the LSR ID of all peers with which it formed Hello adjacencies over that LDP interface. The LDP hello mechanism is used to determine the remote address to be used for the BFD session. The parameters used for the BFD session, that is, transmit-interval, receive-interval, and multiplier, are those configured under the IP interface in existing implementation: config>router>interface>bfd.
When multiple links exist to the same LDP peer, a Hello adjacency is established over each link and a separate BFD session is enabled on each LDP interface. If a BFD session times out on a specific link, LDP will immediately associate the LDP session with one of the remaining Hello adjacencies and trigger the LDP FRR procedures. As soon as the last Hello adjacency goes down because of BFD timing out, the LDP session goes down and the LDP FRR procedures will be triggered.
The no form of this command disables BFD on the LDP interface.
Default
no bfd-enable
ipv4
Syntax
ipv4
Context
config>router>ldp>interface-parameters>interface
config>router>ldp>interface-parameters
config>router>ldp>targeted-session
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure IPv4 LDP parameters for the interface.
transport-address
Syntax
transport-address {interface | system}
no transport-address
Context
config>router>ldp>interface-parameters>interface>ipv4
config>router>ldp>interface-parameters>ipv4
config>router>ldp>interface-parameters>interface>ipv6 (supported only on the 7210 SAS-Mxp)
config>router>ldp>interface-parameters>ipv6 (supported only on the 7210 SAS-Mxp)
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the transport address used when setting up LDP TCP sessions. The transport address, which can be set to interface or system, can be configured globally (applies to all LDP interfaces) or per interface. The most specific value is used.
With this command, you can set up the LDP interface to the connection, which can be set to the interface address or the system address. However, there can be an issue of which address to use when there are parallel adjacencies. This situation can also occur with a link and a targeted adjacency, because targeted adjacencies request the session to be set up only to the system IP address.
The transport-address value should not be interface if multiple interfaces exist between two LDP neighbors. The chosen TCP endpoint depends on the first adjacency to be formed. That is, if one LDP interface is set up as transport-address interface and another as transport-address system, the TCP endpoint addresses are determined depending on which adjacency was set up first, the TCP. After that, because the Hello message contains the LSR ID, the LDP session can be checked to verify that it is set up and match the adjacency to the session.
For any ILDP interface, as the local-lsr-id parameter is changed to interface, the transport-address configuration loses effectiveness because it is ignored and the ILDP sessions always uses the relevant interface IP address as transport address even though system is configured.
The no form of this command at the global level sets the transport address to the default value.
The no form of this command at the interface level sets the transport address to the value defined under the global level.
Default
system
Parameters
- interface
Keyword to specify that the IP interface address is used to set up the LDP session between neighbors. The transport address interface cannot be used if multiple interfaces exist between two neighbors, because only one LDP session is set up between two neighbors.
- system
Keyword to specify that the system IP address is used to set up the LDP session between neighbors.
prefer-tunnel-in-tunnel
Syntax
[no] prefer-tunnel-in-tunnel
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies to use tunnel-in-tunnel over a simple LDP tunnel. Specifically, the user packets for LDP FECs learned over this targeted LDP session can be sent inside an RSVP LSP, which terminates on the same egress router as the destination of the targeted LDP session. The user can specify an explicit list of RSVP LSP tunnels under the targeted LDP session or LDP will perform a lookup in the TTM for the best RSVP LSP. In the former case, only the specified LSPs will be considered to tunnel LDP user packets. In the latter case, all LSPs available to the TTM and that terminate on the same egress router as this targeted LDP session will be considered. In both cases, the metric specified under the LSP configuration is used to control this selection.
The lookup in the TTM will prefer an LDP tunnel over an LDP-over-RSVP tunnel if both are available. The tunneling operates on the data plane only. Control packets of this targeted LDP session are sent over the IGP path.
ipv6
Syntax
ipv6
Context
config>router>ldp>interface-parameters>interface
config>router>ldp>interface-parameters
config>router>ldp>targeted-session
Platforms
7210 SAS-Mxp
Description
Commands in this context configure IPv6 LDP parameters for the interface.
Session parameters commands
session-parameters
Syntax
session-parameters
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure peer-specific parameters.
peer
Syntax
[no] peer ip-address
Context
config>router>ldp>session-parameters
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures parameters for an LDP peer.
Parameters
- ip-address
Specifies the IP address of the LDP peer in dotted-decimal notation.
adv-adj-add-only
Syntax
[no] adv-adj-addr-only
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command provides a means for an LDP router to advertise only the local IPv4 or IPv6 interfaces it uses to establish hello adjacencies with an LDP peer. By default, when a router establishes an LDP session with a peer, it advertises in an LDP Address message the addresses of all local interfaces to allow the peer to resolve LDP FECs distributed by this router. Similarly, a router sends a Withdraw Address message to all its peers to withdraw a local address if the corresponding interface went down or was deleted.
This new option reduces CPU processing when a large number of LDP neighbors come up or go down. The new CLI option is strongly recommended in mobile backhaul networks where the number of LDP peers can be large.
The no form of this command reverts LDP to the default behavior of advertising all local interfaces.
Default
no adv-adj-addr-only
dod-label-distribution
Syntax
[no] dod-label-distribution
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of the LDP Downstream-on-Demand (DoD) label distribution procedures.
When this option is enabled, LDP sets the A-bit in the Label Initialization message when the LDP session to the peer is established. When both peers set the A-bit, they will both use the DoD label distribution method over the LDP session (RFC 5036).
This feature can only be enabled on a link-level LDP session and therefore applies to prefix labels only, not service labels.
As soon as the link LDP session comes up, the router sends a label request to its DoD peer for the FEC prefix corresponding to the peer LSR ID. The DoD peer LSR ID is found in the basic Hello discovery messages the peer used to establish the Hello adjacency with the router.
Similarly, if the router and the directly attached DoD peer enters into extended discovery and established a targeted LDP session, the router immediately sends a label request for the FEC prefix corresponding to the peer LSR ID found in the extended discovery messages.
However, the router will not advertise any <FEC, label> bindings, including the FEC of its own LSR-id, unless the DoD peer requested it using a Label Request Message.
When the DoD peer sends a label request for any FEC prefix, the router replies with a <FEC, label> binding for that prefix if the FEC was already activated on the router. If not, the router replies with a notification message containing the status code of ‟no route.” The router will not attempt in the latter case to send a label request to the next-hop for the FEC prefix when the LDP session to this next-hop uses the DoD label distribution mode, therefore the reference to single-hop LDP DoD procedures.
As soon as the link LDP session comes up, the router sends a label request to its DoD peer for the FEC prefix corresponding to the peer LSR ID. The DoD peer LSR ID is found in the basic Hello discovery messages the peer used to establish the Hello adjacency with the router.
Similarly, if the router and the directly attached DoD peer enter into extended discovery and established a targeted LDP session, the router immediately sends a label request for the FEC prefix corresponding to the peer LSR ID found in the extended discovery messages. The peer address must be the peer LSR ID address.
The no form of this command disables the DoD label distribution with an LDP neighbor.
Default
no dod-label-distribution
export-addresses
Syntax
export-addresses policy-name [policy-name ... (up to 5 max)]
no export-addresses
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the export prefix policy to local addresses advertised to this peer.
Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified.
The no form of this command removes the policy from the configuration.
Default
no export-addresses
Parameters
- policy-name
Specifies the export prefix route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters excluding double quotes. If the string contains spaces, use double quotes to delimit the start and end of the string. The specified names must already be defined.
export-prefixes
Syntax
export-prefixes policy-name [policy-name ... (up to 5 max)]
no export-prefixes
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the export route policy used to determine which prefixes received from other LDP and T-LDP peers are redistributed to this LDP peer via the LDP/T-LDP session to this peer. A prefix that is filtered out (deny) will not be exported. A prefix that is filtered in (accept) will be exported.
If no export policy is specified, all FEC prefixes learned will be exported to this LDP peer. This policy is applied in addition to the global LDP policy and targeted session policy.
Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified. The peer address must be the peer LSR ID address.
The no form of this command removes the policy from the configuration.
Default
no export-prefixes
Parameters
- policy-name
Specifies the export prefix route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters excluding double quotes. If the string contains spaces, use double quotes to delimit the start and end of the string. The specified names must already be defined.
fec-limit
Syntax
fec-limit limit [log-only] [threshold percentage]
no fec-limit
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures a limit on the number of FECs that an LSR will accept from a specific peer and add into the LDP label database. The limit applies to the aggregate count of all FEC types including service FEC. When the limit is reached, any FEC received will be released back to the peer. This behavior is different from the per-peer import policy, which will still accept the FEC into the label database but will not resolve it.
When the FEC limit for a peer is reached, the LSR performs the following actions:
generates a trap and a syslog message
generates an LDP notification message with the LSR overload status TLV for each LDP FEC type, including service FEC, to this peer only if this peer advertised support for the LSR overload sub-TLV via the LSR Overload Protection Capability TLV at session initialization
releases, with LDP Status Code of "No_Label_Resources", any new FEC, including service FEC, from this peer that exceeds the limit
If a legitimate FEC is released back to a peer while the FEC limit was exceeded, the user must have a means to replay that FEC back to the router LSR after the condition clears. This is done automatically if the peer is an SR OS-based router and supports the LDP overload status TLV (SR OS 11.0.R5 and higher). Third-party peer implementations must support the LDP overload status TLV or provide a manual command to replay the FEC.
The threshold percentage option allows to set a threshold value when a trap and a syslog message are generated as a warning to the user in addition to when the limit is reached. The default value for the threshold when not configured is 90%.
The log-only option causes a trap and syslog message to be generated when reaching the threshold and limit. However, LDP labels are not released back to the peer.
If the user decreases the limit value such that it is lower than the current number of FECs accepted from the peer, the LDP LSR raises the trap for exceeding the limit. In addition, it will set overload for peers that signaled support for the LDP overload protection capability TLV. However, no existing resolved FECs from the peer that does not support the overload protection capability TLV should be deprogrammed or released.
A different trap is released when crossing the threshold in the upward direction, when reaching the FEC limit, and when crossing the threshold in the downward direction. However the same trap will not be generated more often than two minutes apart if the number of FECs oscillates around the threshold or the FEC limit.
The no form of this command disables FEC limiting.
Default
no fec-limit
Parameters
- limit
Specifies the aggregate count of FECs of all types that can be accepted from this LDP peer.
- log-only
Keyword to enable generation of a syslog message when the threshold and limit has been reached. However, LDP labels are not released back to the peer.
- percentage
Specifies the threshold value, as a percentage, that triggers a warning and syslog message and trap to be sent.
fec-type-capability
Syntax
fec-type-capability
Context
config>router>ldp>session-params>peer
config>router>ldp>interface-params>interface>ipv4
config>router>ldp>interface-params>interface>ipv6 (supported on 7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure FEC type capabilities for the session or interface.
p2mp
Syntax
p2mp {enable | disable}
Context
config>router>ldp>session-params>peer>fec-type-capability
Platforms
7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables or disables P2MP FEC capability for the session.
Default
p2mp disable
Parameters
- enable
Keyword to enable P2MP FEC capability for the session.
- disable
Keyword to disable P2MP FEC capability for the session.
prefix-ipv4
Syntax
prefix-ipv4 {enable | disable}
Context
config>router>ldp>session-params>peer>fec-type-capability
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables or disables the IPv4 prefix FEC capability on the session or interface.
Default
prefix-ipv4 enable
Parameters
- enable
Keyword to enable IPv4 prefix FEC capability on the session or interface.
- disable
Keyword to disable IPv4 prefix FEC capability on the session or interface.
prefix-ipv6
Syntax
prefix-ipv6 {enable | disable}
Context
config>router>ldp>session-params>peer>fec-type-capability
Platforms
7210 SAS-Mxp
Description
This command enables or disables the IPv6 prefix FEC capability on the session or interface.
Default
prefix-ipv4 enable
Parameters
- enable
Keyword to enable IPv6 prefix FEC capability on the session or interface.
- disable
Keyword to disable IPv6 prefix FEC capability on the session or interface.
fec129-cisco-interop
Syntax
[no] fec129-cisco-interop
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures whether LDP will provide translation between non-compliant FEC 129 Cisco formats. Peer LDP sessions must be manually configured toward the non-compliant Cisco PEs.
When enabled, Cisco non-compliant format is used to send and interpret received label release messages. The FEC129 SAII and TAII fields will be reversed.
The no form of this command disables use and support of Cisco non-compliant forms. The peer address must be the peer LSR ID address.
Default
no fec129-cisco-interop
import-prefixes
Syntax
import-prefixes policy-name [policy-name ... (up to 5 max)]
no import-prefixes
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the import FEC prefix policy to determine which prefixes received from this LDP peer are imported and installed by LDP on this node. If resolved, these FEC prefixes are redistributed to other LDP and T-LDP peers. A FEC prefix that is filtered out (deny) will not be imported. A FEC prefix that is filtered in (accept) will be imported.
If no import policy is specified, the node will import all prefixes received from this LDP/T-LDP peer. This policy is applied in addition to the global LDP policy and targeted session policy. Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified. The specified names must already be defined. The peer address must be the peer LSR ID address.
The no form of this command removes the policy from the configuration.
Default
no import-prefixes
Parameters
- policy-name
Specifies the import prefix route policy name. Allowed values are any string up to 32 characters composed of printable, 7-bit ASCII characters excluding double quotes. If the string contains spaces, use double quotes to delimit the start and end of the string.
pe-id-mac-flush-interop
Syntax
[no] pe-id-mac-flush-interop
Context
config>router>ldp>session-params>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the addition of the PE-ID TLV in the LDP MAC withdrawal (mac-flush) message, under specific conditions, and modifies the mac-flush behavior for interoperability with other vendors that do not support the flush-all-from-me vendor-specific TLV. This flag can be enabled on a per LDP peer basis and allows the flush-all-from-me interoperability with other vendors. When the pe-id-mac-flush-interop flag is enabled for a specific peer, the current mac-flush behavior is modified in terms of mac-flush generation, mac-flush propagation and behavior upon receiving a mac-flush.
The mac-flush generation will be changed depending on the type of event and according to the following rules.
Any all-from-me mac-flush event will trigger a mac-flush all-but-mine message (RFC 4762 compliant format) with the addition of a PE-ID TLV. The PE-ID TLV contains the IP address of the sending PE.
Any all-but-mine mac-flush event will trigger a mac-flush all-but-mine message without the addition of the PE-ID TLV, as long as the source spoke-SDP is not part of an end-point.
Any all-but-mine mac-flush event will trigger a mac-flush all-but-mine message with the addition of the PE-ID TLV, if the source spoke-SDP is part of an end-point and the spoke-SDP goes from the down/standby state to the active state. In this case, the PE-ID TLV will contain the IP address of the PE to which the previous active spoke-SDP was connected.
Any other case will follow the existing mac-flush procedures.
When the pe-id-mac-flush-interop flag is enabled for a specific LDP peer, the mac-flush ingress processing is modified according to the following rules.
Any received all-from-me mac-flush will follow the existing mac-flush all-from-me rules, regardless of the existence of the PE-ID.
Any received all-but-mine mac-flush will take into account the received PE-ID, that is, all the MAC addresses associated with the PE-ID will be flushed. If the PE-ID is not included, the MAC addresses associated with the sending PE will be flushed.
Any other case will follow the existing mac-flush procedures.
When a mac-flush message has to be propagated (for an ingress SDP-binding to an egress SDP-binding) and the pe-id-mac-flush-interop flag is enabled for the ingress and egress TLDP peers, the following behavior is observed.
If the ingress and egress bindings are spoke-SDP, the PE will propagate the mac-flush message with its own PE-ID.
If the ingress binding is an spoke-SDP and the egress binding a mesh-SDP, the PE will propagate the mac-flush message without modifying the PE-ID included in the PE-ID TLV.
If the ingress binding is a mesh-SDP and the egress binding a spoke-SDP, the PE will propagate the mac-flush message with its own PE-ID.
When ingress and egress bindings are mesh-SDP, the mac-flush message is never propagated. This is the behavior regardless of the pe-id-mac-flush-interop flag configuration.
The PE-ID TLV is never added when generating a mac-flush message on a B-VPLS if the send-bvpls-flush command is enabled in the I-VPLS. In the same way, no PE-ID is added when propagating mac-flush from a B-VPLS to a I-VPLS when the propagate-mac-flush-from-bvpls command is enabled. Mac-flush messages for peers within the same I-VPLS or within the same B-VPLS domain follow the preceding procedures.
Default
no pe-id-mac-flush-interop
Targeted session commands
targeted-session
Syntax
targeted-session
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures targeted LDP sessions. Targeted sessions are LDP sessions between non-directly connected peers. Hello messages are sent directly to the peer platform instead of to all the routers on this subnet multicast address.
The discovery messages for an indirect LDP session are addressed to the specified peer and not to the multicast address.
disable-targeted-session
Syntax
[no] disable-targeted-session
Context
config>router>ldp>targ-session
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command disables support for targeted sessions. Targeted sessions are LDP sessions between non-directly connected peers. The discovery messages for an indirect LDP session are addressed to the specified peer and not to the multicast address.
The no form of this command enables the set up of any targeted sessions.
Default
no disable-targeted-session
peer
Syntax
[no] peer ip-address
Context
config>router>ldp>targeted-session
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures parameters for an LDP peer.
Parameters
- ip-address
Specifies the IP address of the LDP peer in dotted-decimal notation.
tunneling
Syntax
[no] tunneling
Context
config>router>ldp>targ-session>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables LDP over tunnels.
The no form of this command disables tunneling.
Default
no tunneling
lsp
Syntax
[no] lsp lsp-name
Context
config>router>ldp>targ-session>tunneling
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures a specific LSP destined for this peer to be used for tunneling of LDP FEC over RSVP. A maximum of four RSVP LSPs can be explicitly used for tunneling LDP FECs to the T-LDP peer.
It is not necessary to specify any RSVP LSP in this context unless there is a need to restrict the tunneling to selected LSPs. All RSVP LSPs with a to address matching that of the T-LDP peer are eligible by default. The user can also exclude specific LSP names by using the ldp-over-rsvp exclude command in the configure>router>mpls>lsp context.
Default
no tunneling
TCP session parameters commands
tcp-session-parameters
Syntax
tcp-session-parameters
Context
config>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure parameters for the TCP transport session of an LDP session to a remote peer.
peer-transport
Syntax
peer-transport ip-address
no peer-transport
Context
config>router>ldp>tcp-session-parameters
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the peer transport address, which is the destination address of the TCP connection, and not the address corresponding to the LDP LSR ID of the peer.
Default
no peer-transport
Parameters
- ip-address
Specifies the IPv4 or IPv6 address of the TCP connection to the LDP peer.
auth-keychain
Syntax
auth-keychain name
Context
config>router>ldp>tcp-session-params>peer-transport
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the TCP authentication keychain to use for the session.
Parameters
- name
Specifies the name of the keychain, up to 32 characters, to use for the specified TCP session or sessions. This keychain allows the rollover of authentication keys during the lifetime of a session. The peer address must be the TCP session transport address.
authentication-key
Syntax
authentication-key [authentication-key | hash-key] [hash | hash2]
no authentication-key
Context
config>router>ldp>tcp-session-params>peer-transport
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the authentication key to be used between LDP peers before establishing sessions. Authentication uses the MD-5 message-based digest. The peer address must be the TCP session transport address.
The no form of this command disables authentication.
Default
none
Parameters
- authentication-key
Specifies the authentication key. The key can be any combination of ASCII characters up to 16 characters (unencrypted). If spaces are used in the string, enclose the entire string in quotation marks (‟ ”).
- hash-key
Specifies the hash key. The key can be any combination of up 33 alphanumeric characters. If spaces are used in the string, enclose the entire string in quotation marks (‟ ”).
This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.
- hash
Keyword to enter the key in an encrypted form. If the hash keyword is not used, the key is assumed to be in a non-encrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash parameter specified.
- hash2
Keyword to enter the key in a more complex encrypted form. If the hash2 parameter is not used, the less encrypted hash form is assigned.
path-mtu-discovery
Syntax
[no] path-mtu-discovery
Context
config>router>ldp>tcp-session-params>peer-transport
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables path MTU discovery for the associated TCP connections. When enabled, the MTU for the associated TCP session is initially set to the egress interface MTU. The DF bit is also set so that if a router along the path of the TCP connection cannot handle a packet of a particular size without fragmenting, it sends back an ICMP message to set the path MTU for the specific session to a lower value that can be forwarded without fragmenting.
Default
no path-mtu-discovery
ttl-security
Syntax
ttl-security min-ttl-value
no ttl-security
Context
config>router>ldp>tcp-session-params>peer-transport
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures TTL security parameters for incoming packets. When the feature is enabled, BGP/LDP will accept incoming IP packets from a peer only if the TTL value in the packet is greater than or equal to the minimum TTL value configured for that peer. The peer address must be the TCP session transport address.
The no form of this command disables TTL security.
Default
no ttl-security
Parameters
- min-ttl-value
Specifies the minimum TTL value for an incoming packet.
Show LDP commands
bindings
Syntax
bindings active [fec-type prefixes] [prefix ip-prefix/mask] [egress-nh ip-address | egress-if port-id | egress-lsp tunnel-id] [summary]
bindings active active-ecmp
bindings active [fec-type p2mp] [p2mp-id identifier root ip-address] [egress-nh ip-address | egress-if port-id | egress-lsp tunnel-id] [summary]
bindings active [fec-type p2mp] [source ip-address] group mcast-address root ip-address]] [egress-nh ip-address] | egress-if port-id | egress-lsp tunnel-id] [summary]
bindings active prefixes [family] [{summary | detail}] [egress-if port-id]
bindings active prefixes [family] [{summary | detail}] [egress-lsp tunnel-id]
bindings active prefixes [egress-nh ip-address] [family] [{summary | detail}]
bindings prefix ip-prefix/ip-prefix-length [{summary | detail}] [egress-if port-id]
bindings prefix ip-prefix/ip-prefix-length [{summary | detail}] [egress-lsp tunnel-id]
bindings prefix ip-prefix/ip-prefix-length [egress-nh ip-address] [{summary | detail}]
bindings fec-type {prefixes|services} [session ip-addr 4c5]] [summary| detail]
bindings fec-type p2mp [session ip-addr[:label-space]] [summary|detail]
bindings fec-type p2mp p2mp-id identifier root ip-address [session ip-addr[:label-space]] [summary|detail]
bindings p2mp-id identifier root ip-address [detail]
bindings fec-type p2mp root ip-address [session ip-addr[:label-space]] [summary|detail] source ip-address group mcast-address
bindings [fec-type fec-type [detail]] [session ip-addr[:label-space]]
bindings label-type start-label [end-label]
bindings {prefix ip-prefix/mask [detail]} [session ip-addr[:label-space]]
bindings prefixes prefix ip-prefix/ip-prefix-length [{summary | detail}] [session ip-addr[:label-space]]
bindings prefixes [family] [{summary | detail}] [session ip-addr[:label-space]]
bindings active [prefix ip-prefix/mask]
bindings service-id service-id [detail]
bindings vc-type vc-type [{vc-id vc-id | agi agi} [session ip-addr[:lab el-space]]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays the contents of the label information base.
Parameters
- family
Specifies the family type.
- fec-type fec-type
Specify the kind of FEC that the label mapping, withdraw, release and request messages are referring to.
- summary
Displays information in a summarized format.
- detail
Displays detailed information.
- active-ecmp
Displays the LDP active bindings with ECMP routes that have been successfully installed in the hardware FIB.
- session ip-addr
Displays configuration information about LDP sessions.
- ip-prefix
Specify information for the specified IP prefix and mask length. Host bits must be 0.
- ip-prefix-length
Specifies the length of the IP prefix.
- label-space
Specifies the label space identifier that the router is advertising on the interface.
- mask
Specifies the 32-bit address mask used to indicate the bits of an IP address that are being used for the subnet address.
- port-id
Specifies the port ID.
- tunnel-id
Specifies the tunnel ID.
- ip-address
Specifies the egress IP address.
- start-label
Specifies a label value to begin the display.
- end-label
Specifies a label value to end the display.
- vc-type
Specifies the VC type to display.
- vc-id
Specifies the VC ID to display.
- group multicast-address
Displays the P2MP group multicast address bindings.
- p2mp-identifier
Displays LDP active P2MP identifier bindings.
- service-id
Specifies the service ID number to display.
Output
The following outputs are examples of LDP bindings information, and Output fields: LDP bindings describes the output fields.
Sample outputA:7210SAS# show router ldp bindings
===============================================================================
LDP LSR ID: 2.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending
BU - Alternate Next-hop for Fast Re-Route, TLV - (Type, Length: Value)
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl EgrIntf/ EgrNextHop
Peer LspId
-------------------------------------------------------------------------------
10.1.1.1/32 -- 262143 1/1/3:12 10.11.12.1
1.1.1.1
10.1.1.1/32 131069U 131069 -- --
6.6.6.6
10.2.2.2/32 131071U -- -- --
1.1.1.1
10.2.2.2/32 131071U -- -- --
6.6.6.6
..........
10.6.6.6/32 -- 131071 1/1/9:26 10.11.26.6
6.6.6.6
-------------------------------------------------------------------------------
No. of Prefix Bindings: 10
===============================================================================
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
P2MP-Id RootAddr
Interface Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
LspId
-------------------------------------------------------------------------------
8193 10.1.1.1
73732 1.1.1.1 131065U -- -- --
8193 10.2.2.2
73728 1.1.1.1 -- 262139 1/1/3:12 10.11.12.1
88194 10.6.6.6
73738 6.6.6.6 131054U -- -- --
8195 10.6.6.6
73739 6.6.6.6 131053U -- -- --
-------------------------------------------------------------------------------
No. of Generic P2MP Bindings: 13
===============================================================================
===============================================================================
LDP In-Band-SSM P2MP Bindings
===============================================================================
Source
Group
Interface RootAddr
Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type VCId SvcId SDPId Peer IngLbl EgrLbl LMTU RMTU
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
AGI SAII
TAII
Type SvcId SDPId Peer IngLbl EgrLbl LMTU RMTU
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings detail
===============================================================================
LDP P2MP Bindings
===============================================================================
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 100
-------------------------------------------------------------------------------
Ing Lbl : 131065 Peer : 10.20.1.1
Egr Lbl : 131069 Peer : 10.20.1.2
Egr Int/LspId : 1/1/2 EgrNextHop : 10.10.2.2
Egr. Flags : None Ing. Flags : None
Egr Lbl : 131067 Peer : 10.20.1.3
Egr Int/LspId : 1/1/3 EgrNextHop : 10.10.3.2
Egr. Flags : None Ing. Flags : None
Egr Lbl : 131064 Peer : 10.20.1.4
Egr Int/LspId : 1/1/3 EgrNextHop : 10.10.4.2
Egr. Flags : None Ing. Flags : None
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 200
-------------------------------------------------------------------------------
Ing Lbl : 131066 Peer : 10.20.1.1
Egr Lbl : 131063 Peer : 10.20.1.2
Egr Int/LspId : 1/1/2 EgrNextHop : 10.10.2.2
Egr. Flags : None Ing. Flags : None
Egr Lbl : 131068 Peer : 10.20.1.3
Egr Int/LspId : 1/1/3 EgrNextHop : 10.10.3.2
Egr. Flags : None Ing. Flags : None
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings p2mp-id 8193 root 10.2.2.2 detail
===============================================================================
LDP LSR ID: 10.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 8193
Root-Addr : 10.2.2.2
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 1.1.1.1
Egr Lbl : 262139
Egr Int/LspId : 1/1/3:12
EgrNextHop : 10.11.12.1
Egr. Flags : None Ing. Flags : None
Metric : 1 Mtu : 1560
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 8193
Root-Addr : 10.2.2.2
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 6.6.6.6
Egr Lbl : 131059
Egr Int/LspId : 1/1/9:26
EgrNextHop : 10.11.26.6
Egr. Flags : None Ing. Flags : None
Metric : 1 Mtu : 1560
===============================================================================
No. of Generic P2MP Bindings: 2
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings active fec-type p2mp
===============================================================================
LDP Generic P2MP Bindings (Active)
===============================================================================
P2MP-Id RootAddr
Interface Op IngLbl EgrLbl EgrIntf/ EgrNextHop
LspId
-------------------------------------------------------------------------------
8193 10.1.1.1
73731 Pop 131064 -- -- --
8193 10.1.1.1
7
8195 10.6.6.6
73738 Pop 131058 -- -- --
-------------------------------------------------------------------------------
No. of Generic P2MP Active Bindings: 15
===============================================================================
===============================================================================
LDP In-Band-SSM P2MP Bindings (Active)
===============================================================================
Source
Group
Interface RootAddr
Op IngLbl EgrLbl EgrIntf/ EgrNextHop
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings fec-type p2mp detail
===============================================================================
LDP LSR ID: 2.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 8193
Root-Addr : 10.1.1.1
-------------------------------------------------------------------------------
Ing Lbl : 131053U Peer : 6.6.6.6
Egr Lbl : --
Egr Int/LspId : --
EgrNextHop : --
Egr. Flags : None Ing. Flags : None
===============================================================================
No. of Generic P2MP Bindings: 13
===============================================================================
===============================================================================
LDP In-Band-SSM P2MP Bindings
===============================================================================
No Matching Entries Found
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings p2mp-id 8193 root 10.2.2.2 detail
===============================================================================
LDP LSR ID: 10.2.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 8193
Root-Addr : 10.2.2.2
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 1.1.1.1
Egr Lbl : 262139
Egr Int/LspId : 1/1/3:12
EgrNextHop : 10.11.12.1
Egr. Flags : None Ing. Flags : None
Metric : 1 Mtu : 1560
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 8193
Root-Addr : 10.2.2.2
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 6.6.6.6
Egr Lbl : 131059
Egr Int/LspId : 1/1/9:26
EgrNextHop : 10.11.26.6
Egr. Flags : None Ing. Flags : None
Metric : 1 Mtu : 1560
===============================================================================
No. of Generic P2MP Bindings: 2
===============================================================================
A:7210SAS#
The following outputs pertain to unicast FEC resolved over an unnumbered interface.
A:7210SAS# # show router ldp bindings active
===============================================================================
Legend: (S) - Static (M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop
-------------------------------------------------------------------------------
10.20.1.1/32 Push -- 262143 1/1/1 Unnumbered
10.20.1.1/32 Swap 262138 262143 1/1/1 Unnumbered
10.20.1.2/32 Push -- 262143 lag-1 Unnumbered
10.20.1.2/32 Swap 262139 262143 lag-1 Unnumbered
10.20.1.3/32 Pop 262143 -- -- --
10.20.1.4/32 Push -- 262143 2/1/2 Unnumbered
10.20.1.4/32 Swap 262142 262143 2/1/2 Unnumbered
10.20.1.5/32 Push -- 262143 2/1/1 Unnumbered
10.20.1.5/32 Swap 262141 262143 2/1/1 Unnumbered
10.20.1.6/32 Push -- 262140 2/1/2 Unnumbered
10.20.1.6/32 Swap 262140 262140 2/1/2 Unnumbered
-------------------------------------------------------------------------------
No. of Prefix Active Bindings: 11
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings
===============================================================================
LDP LSR ID: 10.20.1.3
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
BU - Alternate For Fast Re-Route, TLV - (Type, Length: Value)
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl EgrIntf/ EgrNextHop
Peer LspId
-------------------------------------------------------------------------------
10.20.1.1/32 -- 262143 1/1/1 Unnumbered
10.20.1.1
10.20.1.1/32 262138U 262142 -- --
10.20.1.2
10.20.1.1/32 262138U 262138 -- --
10.20.1.4
10.20.1.1/32 262138U 262138 -- --
10.20.1.5
10.20.1.2/32 262139U 262142 -- --
10.20.1.1
10.20.1.2/32 -- 262143 lag-1 Unnumbered
10.20.1.2
10.20.1.2/32 262139U 262139 -- --
10.20.1.4
10.20.1.2/32 262139U 262139 -- --
10.20.1.5
10.20.1.3/32 262143U -- -- --
10.20.1.1
10.20.1.3/32 262143U -- -- --
10.20.1.2
10.20.1.3/32 262143U -- -- --
10.20.1.4
10.20.1.3/32 262143U -- -- --
10.20.1.5
10.20.1.4/32 262142U 262141 -- --
10.20.1.1
10.20.1.4/32 262142U 262141 -- --
10.20.1.2
10.20.1.4/32 -- 262143 2/1/2 Unnumbered
10.20.1.4
10.20.1.4/32 262142U 262141 -- --
10.20.1.5
10.20.1.5/32 262141U 262138 -- --
10.20.1.1
10.20.1.5/32 262141U 262139 -- --
10.20.1.2
10.20.1.5/32 262141U 262141 -- --
10.20.1.4
10.20.1.5/32 -- 262143 2/1/1 Unnumbered
10.20.1.5
10.20.1.6/32 262140U 262140 -- --
10.20.1.1
10.20.1.6/32 262140U 262138 -- --
10.20.1.2
10.20.1.6/32 262140N 262140 2/1/2 Unnumbered
10.20.1.4
10.20.1.6/32 262140U 262140 -- --
10.20.1.5
-------------------------------------------------------------------------------
No. of Prefix Bindings: 24
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings detail
===============================================================================
LDP LSR ID: 10.20.1.3
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
BU - Alternate For Fast Re-Route, TLV - (Type, Length: Value)
===============================================================================
LDP Prefix Bindings
===============================================================================
-------------------------------------------------------------------------------
Prefix : 10.20.1.1/32
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 10.20.1.1
Egr Lbl : 262143
Egr Int/LspId : 1/1/1
EgrNextHop : Unnumbered
Egr. Flags : None Ing. Flags : None
Egr If Name : ip-10.10.2.3
Metric : 1000 Mtu : 1500
-------------------------------------------------------------------------------
Prefix : 10.20.1.1/32
-------------------------------------------------------------------------------
Ing Lbl : 262138U Peer : 10.20.1.2
Egr Lbl : 262142
Egr Int/LspId : --
EgrNextHop : --
Egr. Flags : None Ing. Flags : None
Egr If Name : n/a
-------------------------------------------------------------------------------
Prefix : 10.20.1.1/32
-------------------------------------------------------------------------------
Ing Lbl : 262138U Peer : 10.20.1.4
Egr Lbl : 262138
Egr Int/LspId : --
EgrNextHop : --
Egr. Flags : None Ing. Flags : None
Egr If Name : n/a
-------------------------------------------------------------------------------
Prefix : 10.20.1.1/32
-------------------------------------------------------------------------------
Ing Lbl : 262138U Peer : 10.20.1.5
Egr Lbl : 262138
Egr Int/LspId : --
EgrNextHop : --
Egr. Flags : None Ing. Flags : None
Egr If Name : n/a
-------------------------------------------------------------------------------
Prefix : 10.20.1.2/32
-------------------------------------------------------------------------------
Ing Lbl : 262139U Peer : 10.20.1.1
Egr Lbl : 262142
Egr Int/LspId : --
EgrNextHop : --
Egr. Flags : None Ing. Flags : None
Egr If Name : n/a
-------------------------------------------------------------------------------
A:7210SAS# show router ldp session local-addresses
===============================================================================
LDP Session Local-Addresses
===============================================================================
-------------------------------------------------------------------------------
Session with Peer 10.20.1.2:0, Local 10.20.1.3:0
-------------------------------------------------------------------------------
Sent Addresses: 10.1.1.1 10.10.12.3 10.10.22.3 10.20.1.3
10.180.2.3 10.180.3.3 10.180.5.3 10.180.11.3
10.181.2.3 10.181.3.3 10.181.5.3 10.181.11.3
10.182.2.3 10.182.3.3 10.182.5.3 10.182.11.3
Recv Addresses: 10.2.2.2 10.10.12.2 10.20.1.2 10.180.1.2
10.180.3.2 10.180.4.2 10.181.1.2 10.181.3.2
10.181.4.2 10.182.1.2 10.182.3.2 10.182.4.2
-------------------------------------------------------------------------------
Session with Peer 10.20.1.4:0, Local 10.20.1.3:0
-------------------------------------------------------------------------------
Sent Addresses: 10.1.1.1 10.10.12.3 10.10.22.3 10.20.1.3
10.180.2.3 10.180.3.3 10.180.5.3 10.180.11.3
10.181.2.3 10.181.3.3 10.181.5.3 10.181.11.3
10.182.2.3 10.182.3.3 10.182.5.3 10.182.11.3
Recv Addresses: 10.10.22.4 10.20.1.4 10.180.4.4 10.180.6.4
10.180.9.4 10.180.11.4 10.181.4.4 10.181.6.4
10.181.9.4 10.181.11.4 10.182.4.4 10.182.6.4
10.182.9.4 10.182.11.4
-------------------------------------------------------------------------------
Session with Peer 10.20.1.5:0, Local 10.20.1.3:0
-------------------------------------------------------------------------------
Sent Addresses: 10.1.1.1 10.10.12.3 10.10.22.3 10.20.1.3
10.180.2.3 10.180.3.3 10.180.5.3 10.180.11.3
10.181.2.3 10.181.3.3 10.181.5.3 10.181.11.3
10.182.2.3 10.182.3.3 10.182.5.3 10.182.11.3
Recv Addresses: 10.20.1.5 10.180.5.5 10.180.6.5 10.180.10.5
10.181.5.5 10.181.6.5 10.181.10.5 10.182.5.5
10.182.6.5 10.182.10.5
===============================================================================
A:7210SAS#
The following outputs pertain to multicast P2MP FEC resolved over an unnumbered interface.
P2MP LSPs are only supported on 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T.
A:7210SAS# show router ldp bindings active fec-type p2mp
===============================================================================
LDP Generic P2MP Bindings (Active)
===============================================================================
P2MP-Id RootAddr
Interface Op IngLbl EgrLbl EgrIntf/ EgrNextHop
LspId
-------------------------------------------------------------------------------
1 10.20.1.3
73728 Push -- 262142 1/1/2:0 Unnumbered
1 10.20.1.3
73728 Push -- 262137 2/1/2:0 Unnumbered
2 10.20.1.3
73729 Push -- 262141 1/1/2:0 Unnumbered
2 10.20.1.3
73729 Push -- 262136 2/1/2:0 Unnumbered
3 10.20.1.3
73730 Push -- 262140 1/1/2:0 Unnumbered
3 10.20.1.3
73730 Push -- 262135 2/1/2:0 Unnumbered
4 10.20.1.3
73731 Push -- 262139 1/1/2:0 Unnumbered
4 10.20.1.3
73731 Push -- 262134 2/1/2:0 Unnumbered
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings fec-type p2m
===============================================================================
LDP LSR ID: 10.20.1.3
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
P2MP-Id RootAddr
Interface Peer IngLbl EgrLbl EgrIntf/ EgrNextHop
LspId
-------------------------------------------------------------------------------
1 10.20.1.3
73728 10.20.1.2 -- 262142 1/1/2:0 Unnumbered
1 10.20.1.3
73728 10.20.1.4 -- 262137 2/1/2:0 Unnumbered
2 10.20.1.3
73729 10.20.1.2 -- 262141 1/1/2:0 Unnumbered
2 10.20.1.3
73729 10.20.1.4 -- 262136 2/1/2:0 Unnumbered
3 10.20.1.3
73730 10.20.1.2 -- 262140 1/1/2:0 Unnumbered
3 10.20.1.3
73730 10.20.1.4 -- 262135 2/1/2:0 Unnumbered
4 10.20.1.3
73731 10.20.1.2 -- 262139 1/1/2:0 Unnumbered
4 10.20.1.3
73731 10.20.1.4 -- 262134 2/1/2:0 Unnumbered
===============================================================================
A:7210SAS#
A:7210SAS# show router ldp bindings fec-type p2mp detail
===============================================================================
LDP LSR ID: 10.20.1.3
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 1
Root-Addr : 10.20.1.3
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 10.20.1.2
Egr Lbl : 262142
Egr Int/LspId : 1/1/2:0
EgrNextHop : Unnumbered
Egr. Flags : None Ing. Flags : None
Egr If Name : ip-10.180.3.3
Metric : 1 Mtu : 1496
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 1
Root-Addr : 10.20.1.3
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 10.20.1.4
Egr Lbl : 262137
Egr Int/LspId : 2/1/2:0
EgrNextHop : Unnumbered
Egr. Flags : None Ing. Flags : None
Egr If Name : ip-10.180.11.3
Metric : 1 Mtu : 1496
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 2
Root-Addr : 10.20.1.3
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 10.20.1.2
Egr Lbl : 262141
Egr Int/LspId : 1/1/2:0
EgrNextHop : Unnumbered
Egr. Flags : None Ing. Flags : None
Egr If Name : ip-10.180.3.3
Metric : 1 Mtu : 1496
-------------------------------------------------------------------------------
P2MP Type : 1 P2MP-Id : 2
Root-Addr : 10.20.1.3
-------------------------------------------------------------------------------
Ing Lbl : -- Peer : 10.20.1.4
Egr Lbl : 262136
Egr Int/LspId : 2/1/2:0
EgrNextHop : Unnumbered
Egr. Flags : None Ing. Flags : None
Egr If Name : ip-10.180.11.3
Metric : 1 Mtu : 1496
-------------------------------------------------------------------------------
A:7210SAS#
A:7210SAS# show router ldp session local-addresses
===============================================================================
LDP Session Local-Addresses
===============================================================================
-------------------------------------------------------------------------------
Session with Peer 10.20.1.2:0, Local 10.20.1.3:0
-------------------------------------------------------------------------------
Sent Addresses: 10.1.1.1 10.10.12.3 10.10.22.3 10.20.1.3
10.180.2.3 10.180.3.3 10.180.5.3 10.180.11.3
10.181.2.3 10.181.3.3 10.181.5.3 10.181.11.3
10.182.2.3 10.182.3.3 10.182.5.3 10.182.11.3
Recv Addresses: 10.2.2.2 10.10.12.2 10.20.1.2 10.180.1.2
10.180.3.2 10.180.4.2 10.181.1.2 10.181.3.2
10.181.4.2 10.182.1.2 10.182.3.2 10.182.4.2
-------------------------------------------------------------------------------
Session with Peer 10.20.1.4:0, Local 10.20.1.3:0
-------------------------------------------------------------------------------
Sent Addresses: 10.1.1.1 10.10.12.3 10.10.22.3 10.20.1.3
10.180.2.3 10.180.3.3 10.180.5.3 10.180.11.3
10.181.2.3 10.181.3.3 10.181.5.3 10.181.11.3
10.182.2.3 10.182.3.3 10.182.5.3 10.182.11.3
Recv Addresses: 10.10.22.4 10.20.1.4 10.180.4.4 10.180.6.4
10.180.9.4 10.180.11.4 10.181.4.4 10.181.6.4
10.181.9.4 10.181.11.4 10.182.4.4 10.182.6.4
10.182.9.4 10.182.11.4
-------------------------------------------------------------------------------
Session with Peer 10.20.1.5:0, Local 10.20.1.3:0
-------------------------------------------------------------------------------
Sent Addresses: 10.1.1.1 10.10.12.3 10.10.22.3 10.20.1.3
10.180.2.3 10.180.3.3 10.180.5.3 10.180.11.3
10.181.2.3 10.181.3.3 10.181.5.3 10.181.11.3
10.182.2.3 10.182.3.3 10.182.5.3 10.182.11.3
Recv Addresses: 10.20.1.5 10.180.5.5 10.180.6.5 10.180.10.5
10.181.5.5 10.181.6.5 10.181.10.5 10.182.5.5
10.182.6.5 10.182.10.5
===============================================================================
A:7210SAS#
Label |
Description |
|---|---|
|
Displays the LDP label switch router ID |
|
U: Label In Use N: Label Not In Use W: Label Withdrawn S: Status Signaled Up D: Status Signaled Down E: Epipe service V: VPLS service M: Mirror service A: Apipe service F: Fpipe service I: IES service R: VPRN service P: Ipipe service WP: Label Withdraw Pending C: Cpipe service TLV: (Type, Length: Value) |
|
Displays the service type exchanging labels; possible types displayed are VPLS, Epipe, Spoke, and Unknown |
|
Displays the value used by each end of an SDP tunnel to identify the VC |
|
Displays the unique service identification number identifying the service in the service domain |
|
Displays the IP address of the peer |
|
Displays the P2MP ID assigned by the root to this MVPN instance |
|
Displays the logical identifier assigned locally to identify the P2MP tunnel |
|
Displays the IP address of the root of the P2MP tree |
|
Displays the label operation carried out (can be one of pop | swap | push) |
|
Displays the next hop gateway IP address |
|
Displays the LSP tunnel ID (not the LSP path ID) |
|
Displays the ingress LDP label U — Label in use R — Label released |
|
Displays the egress LDP label |
|
Displays the local MTU value |
|
Displays the remote MTU value |
|
Displays the total number of LDP bindings on the router |
active
Syntax
active
Context
show>router>ldp>bindings
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context display information about LDP active bindings.
Output
The following output is an example of LDP active bindings information, and Output fields: LDP active bindings describes the LDP active bindings output fields.
Sample output*A:Dut-A# /show router ldp bindings active
===============================================================================
LDP Bindings (IPv4 LSR ID 10.20.1.1:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
(S) - Static (M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
(C) - FEC resolved for class-based-forwarding
===============================================================================
LDP IPv4 Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl
EgrNextHop EgrIf/LspId
-------------------------------------------------------------------------------
No. of IPv4 Prefix Active Bindings: 10
===============================================================================
===============================================================================
LDP IPv6 Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl
EgrNextHop EgrIf/LspId
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:Dut-A#
|
Label |
Description |
|---|---|
|
|
Displays the LDP IPv4 and IPv6 bindings |
|
|
Description of the legend used in LDP active binding output U: Label In Use N: Label Not In Use W: Label Withdrawn WP: Label Withdraw Pending BU: Alternate For Fast Re-Route (S): Static (M): Multi-homed Secondary Support (B): BGP Next Hop (BU): Alternate Next-hop for Fast Re-Route (C): FEC resolved for class-based-forwarding |
|
|
Displays the active LDP IPv4 bindings |
|
|
Displays the label binding for the LDP prefix |
|
|
Displays the label operation (can be either pop, swap, or push) |
|
|
Displays the ingress LDP label |
|
|
Displays the egress LDP label |
|
|
Displays the next-hop information for the LDP prefix |
|
|
Displays the egress interface information for the LSP tunnel ID (not the LSP path ID) |
|
|
Displays the number of active IPv4 prefix bindings |
|
|
Displays the active LDP IPv6 bindings |
|
|
Displays the active generic LDP IPv4 P2MP bindings |
|
|
Displays the P2MP ID |
RootAddr |
Displays the root address |
|
|
Displays egress next-hop information |
ipv4
Syntax
ipv4 [summary | detail] [egress-if port-id]
ipv4 [summary | detail] [egress-lsp tunnel-id]
ipv4 [summary | detail] [egress-nh ip-address]
Context
show>router>ldp>bindings>active
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays LDP active IPv4 bindings.
Parameters
- port-id
-
Displays LDP active bindings by matching the egress interface.
- tunnel-id
-
Specifies the tunnel identifier for the egress LSP.
- ip-address
-
Displays LDP active bindings by matching the egress next hop.
- detail
-
Displays detailed information about LDP active IPv4 bindings.
- summary
-
Displays LDP active IPv4 bindings information in a summarized format.
Output
The following output is an example of LDP active IPv4 bindings information, and Output fields: LDP active IPv4 bindings describes the LDP active IPv4 bindings output fields.
Sample output*A:Dut-A# /show router ldp bindings active ipv4
===============================================================================
LDP Bindings (IPv4 LSR ID 10.20.1.1:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
(S) - Static (M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
(C) - FEC resolved for class-based-forwarding
===============================================================================
LDP IPv4 Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl
EgrNextHop EgrIf/LspId
-------------------------------------------------------------------------------
10.20.1.1/32 Pop 131071 --
-- --
10.20.1.2/32 Push -- 131071
10.10.1.2 1/1/6
10.20.1.2/32 Swap 131064 131071
10.10.1.2 1/1/6
10.20.1.3/32 Push -- 131071
10.10.2.3 1/1/4
10.20.1.3/32 Swap 131063 131071
10.10.2.3 1/1/4
10.20.1.4/32 Push -- 131056
10.10.2.3 1/1/4
10.20.1.4/32 Swap 131049 131056
10.10.2.3 1/1/4
10.20.1.6/32 Push -- 131054
10.10.2.3 1/1/4
10.20.1.6/32 Swap 131048 131054
10.10.2.3 1/1/4
11.11.11.0/32(S) Pop 131070 --
-- --
-------------------------------------------------------------------------------
No. of IPv4 Prefix Active Bindings: 30
===============================================================================
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:Dut-A#
|
Label |
Description |
|---|---|
|
|
Displays the LDP IPv4 bindings |
|
|
Description of the legend used in LDP active IPv4 binding output U: Label In Use N: Label Not In Use W: Label Withdrawn WP: Label Withdraw Pending BU: Alternate For Fast Re-Route (S): Static (M): Multi-homed Secondary Support (B): BGP Next Hop (BU): Alternate Next-hop for Fast Re-Route (C): FEC resolved for class-based-forwarding |
|
|
Displays the active LDP IPv4 bindings |
|
|
Displays the label binding for the LDP prefix |
|
|
Displays the label operation (can be either pop, swap, or push) |
|
|
Displays the ingress LDP label |
|
|
Displays the egress LDP label |
|
|
Displays the next-hop information for the LDP prefix |
|
|
Displays the egress interface information for the LSP tunnel ID (not the LSP path ID) |
|
|
Displays the number of active IPv4 prefix bindings |
|
|
Displays the active generic LDP IPv4 P2MP bindings |
|
|
Displays the P2MP ID |
RootAddr |
Displays the root address |
|
|
Displays egress next-hop information |
ipv6
Syntax
ipv6 [summary | detail] [egress-if port-id]
ipv6 [summary | detail] [egress-lsp tunnel-id]
ipv6 [summary | detail] [egress-nh ip-address]
Context
show>router>ldp>bindings>active
Platforms
7210 SAS-Mxp and 7210 SAS-Sx/S 1/10GE (standalone)
Description
This command displays LDP active IPv6 bindings.
Parameters
- port-id
-
Displays LDP active bindings by matching the egress interface.
- tunnel-id
-
Specifies the tunnel identifier for the egress LSP.
- ip-address
-
Displays LDP active bindings by matching the egress next-hop.
- detail
-
Displays detailed information about LDP active IPv6 bindings.
- summary
-
Displays LDP active IPv6 bindings information in a summarized format.
Output
The following output is an example of LDP active IPv6 bindings information, and Output fields: LDP active IPv6 bindings describes theLDP active IPv6 bindings output fields.
Sample output*A:Dut-A# /show router ldp bindings active ipv6
===============================================================================
LDP Bindings (IPv4 LSR ID 10.20.1.1:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
(S) - Static (M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
(C) - FEC resolved for class-based-forwarding
===============================================================================
LDP IPv6 Prefix Bindings (Active)
===============================================================================
Prefix Op IngLbl EgrLbl
EgrNextHop EgrIf/LspId
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:Dut-A#
|
Label |
Description |
|---|---|
|
|
Displays the LDP IPv6 bindings |
|
|
Description of the legend used in LDP active IPv6 binding output U: Label In Use N: Label Not In Use W: Label Withdrawn WP: Label Withdraw Pending BU: Alternate For Fast Re-Route (S): Static (M): Multi-homed Secondary Support (B): BGP Next Hop (BU): Alternate Next-hop for Fast Re-Route (C): FEC resolved for class-based-forwarding |
|
|
Displays the active LDP IPv6 bindings |
|
|
Displays the label information for the IPv6 prefix |
|
|
Displays the label operation (can be either pop, swap, or push) |
|
|
Displays the ingress LDP label |
|
|
Displays the egress LDP label |
|
|
Displays the next-hop information for the LDP prefix |
|
|
Displays the egress interface information for the LSP tunnel ID (not the LSP path ID) |
ipv4
Syntax
ipv4 [session ip-addr[label-space]] [summary | detail]
Context
show>router>ldp>bindings
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays LDP IPv4 bindings.
Parameters
- ip-addr[label-space]
-
Specifies the IP address and label space identifier.
- detail
-
Displays detailed information about LDP IPv4 bindings.
- summary
-
Displays LDP IPv4 bindings information in a summarized format.
Output
The following output is an example of LDP IPv4 bindings information, and Output fields: LDP IPv4 bindings describes the LDP IPv4 bindings output fields.
Sample output*A:Dut-A# /show router ldp bindings ipv4
===============================================================================
LDP Bindings (IPv4 LSR ID 10.20.1.1:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending
BU - Alternate For Fast Re-Route, TLV - (Type, Length: Value)
===============================================================================
LDP IPv4 Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl
Peer EgrIntf/LspId
EgrNextHop
-------------------------------------------------------------------------------
10.20.1.1/32 131071U --
10.20.1.2:0 --
--
10.20.1.1/32 131071U --
10.20.1.3:0 --
--
10.20.1.2/32 -- 131071
10.20.1.2:0 1/1/6
10.10.1.2
10.20.1.2/32 131064U 131063
10.20.1.3:0 --
--
10.20.1.3/32 131063U 131057
10.20.1.2:0 --
--
10.20.1.3/32 -- 131071
10.20.1.3:0 1/1/4
10.10.2.3
10.20.1.4/32 131049U 131056
10.20.1.2:0 --
--
-------------------------------------------------------------------------------
No. of IPv4 Prefix Bindings: 40
===============================================================================
===============================================================================
LDP Generic IPv4 P2MP Bindings
===============================================================================
P2MP-Id
RootAddr Interface IngLbl EgrLbl
EgrNH EgrIf/LspId
Peer
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:Dut-A#
|
Label |
Description |
|---|---|
|
|
Displays the LDP IPv4 bindings |
|
|
Description of the legend used in LDP IPv4 binding output U: Label In Use N: Label Not In Use W: Label Withdrawn WP: Label Withdraw Pending BU: Alternate For Fast Re-Route (S): Static (M): Multi-homed Secondary Support (B): BGP Next Hop (BU): Alternate Next-hop for Fast Re-Route (C): FEC resolved for class-based-forwarding |
|
|
Displays the LDP IPv4 bindings |
|
|
Displays the label binding for the LDP prefix |
|
|
Displays the label operation (can be either pop, swap, or push) |
|
|
Displays the ingress LDP label |
|
|
Displays the egress LDP label |
|
|
Displays the next-hop information for the LDP prefix |
|
|
Displays the egress interface information for the LSP tunnel ID (not the LSP path ID) |
|
|
Displays the number of IPv4 prefix bindings |
|
|
Displays the generic LDP IPv4 P2MP bindings |
|
|
Displays the P2MP ID |
RootAddr |
Displays the root address |
|
|
Displays egress next-hop information |
ipv6
Syntax
ipv6 [session ip-addr[label-space]] [summary | detail]
Context
show>router>ldp>bindings
Platforms
7210 SAS-Mxp
Description
This command displays LDP IPv6 bindings.
Parameters
- ip-addr[label-space]
-
Specifies the IP address and label space identifier.
- detail
-
Displays detailed information about LDP IPv6 bindings.
- summary
-
Displays LDP IPv6 bindings information in a summarized format.
Output
The following output is an example of LDP IPv6 bindings information, and Output fields: LDP IPv6 bindings describes the LDP IPv6 bindings output fields.
Sample output*A:Dut-A# /show router ldp bindings ipv6
===============================================================================
LDP Bindings (IPv4 LSR ID 10.20.1.1:0)
(IPv6 LSR ID ::[0])
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending
BU - Alternate For Fast Re-Route, TLV - (Type, Length: Value)
===============================================================================
LDP IPv6 Prefix Bindings
===============================================================================
Prefix IngLbl EgrLbl
Peer EgrIntf/LspId
EgrNextHop
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:Dut-A#
|
Label |
Description |
|---|---|
|
|
Displays the LDP IPv6 bindings |
|
|
Description of the legend used in LDP IPv6 binding output U: Label In Use N: Label Not In Use W: Label Withdrawn WP: Label Withdraw Pending BU: Alternate For Fast Re-Route (S): Static (M): Multi-homed Secondary Support (B): BGP Next Hop (BU): Alternate Next-hop for Fast Re-Route (C): FEC resolved for class-based-forwarding |
|
|
Displays the LDP IPv6 bindings |
|
|
Displays the label information for the IPv6 prefix |
|
|
Displays the label operation (can be either pop, swap, or push) |
|
|
Displays the ingress LDP label |
|
|
Displays the egress LDP label |
|
|
Displays the next-hop information for the LDP prefix |
|
|
Displays the egress interface information for the LSP tunnel ID (not the LSP path ID) |
discovery
Syntax
discovery [{peer [ip-address]} | {interface [ip-int-name]}] [state state] [detail] [adjacency-type type]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays the status of the interfaces participating in LDP discovery.
Parameters
- ip-address
Specifies the IP address of the peer.
- ip-int-name
Specifies the name of an existing interface. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- state
Specifies to display the current operational state of the adjacency.
- detail
Specifies to display detailed information.
- adjacency-type type
Specifies to display the adjacency type.
Output
The following output is an example of LDP discovery information, and Output fields: LDP discovery describes the LDP discovery output fields.
Sample output*A:Dut-A# show router ldp discovery
===============================================================================
LDP IPv4 Hello Adjacencies
===============================================================================
Interface Name Local Addr State
AdjType Peer Addr
-------------------------------------------------------------------------------
N/A 10.20.1.1:0 Estab
targ 10.20.1.2:0
N/A 10.20.1.1:0 Estab
targ 10.20.1.3:0
N/A 10.20.1.1:0 Estab
targ 10.20.1.7:0
a2c 10.20.1.1:0 Estab
link 10.20.1.3:0
a2b 10.20.1.1:0 Estab
link 10.20.1.2:0
-------------------------------------------------------------------------------
No. of IPv4 Hello Adjacencies: 5
===============================================================================
===============================================================================
LDP IPv6 Hello Adjacencies
===============================================================================
Interface Name Local Addr State
AdjType Peer Addr
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:Dut-A#
Label |
Description |
|---|---|
|
Displays the name of the interface |
|
Displays the IP address of the originating (local) router |
|
Displays the IP address of the peer |
|
Displays the adjacency type between the LDP peer and LDP session is targeted |
|
Established — The adjacency is established Trying — The adjacency is not yet established |
|
Displays the total number of hello adjacencies discovered |
|
Displays the amount of time the adjacency has been enabled |
|
Displays the time left before a neighbor is declared to be down |
|
Displays the number of hello messages received for this adjacency |
|
Displays the number of hello messages that have been sent for this adjacency |
|
Displays the configuration sequence number that was in the hello received when this adjacency started up. This configuration sequence number changes when there is a change of configuration. |
|
Displays the IP address used on the remote end for the LDP session |
|
Displays the configuration sequence number that was used in the hello sent when this adjacency started up. This configuration sequence number changes when there is a change of configuration. |
|
Displays the IP address used locally for the LDP session |
interface
Syntax
interface [ip-int-name | ip-address] [detail]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays configuration information about LDP interfaces.
Parameters
- ip-int-name
Specifies the name of an existing interface. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- ip-address
Specifies the IP address of the LDP neighbor.
- detail
Displays detailed information.
Output
The following output is an example of LDP interface information, and Output fields: LDP interface describes the output fields.
Sample output
*A:ALU_SIM11>show>router>ldp# interface
===============================================================================
LDP Interfaces
===============================================================================
Interface Adm Opr Hello Hold KA KA Transport
Factor Time Factor Timeout Address
-------------------------------------------------------------------------------
a Up Up 3 15 3 30 System
-------------------------------------------------------------------------------
No. of Interfaces: 1
===============================================================================
*A:ALU_SIM11>show>router>ldp# interface detail
*A:ALU_SIM11>show>router>ldp#
===============================================================================
LDP Interfaces (Detail)
===============================================================================
Interface "a"
-------------------------------------------------------------------------------
Admin State : Up Oper State : Up
Hold Time : 15 Hello Factor : 3
Keepalive Timeout : 30 Keepalive Factor : 3
Transport Addr : System Last Modified : 07/06/2010 10:36:59
Active Adjacencies : 1
Tunneling : Disabled
Lsp Name : None
===============================================================================
*A:ALU_SIM11>show>router>ldp#
Label |
Description |
|---|---|
|
Displays the interface associated with the LDP instance |
|
Up — The LDP is administratively enabled Down — The LDP is administratively disabled |
|
Up — The LDP is operationally enabled Down — The LDP is operationally disabled |
|
Displays the value by which the hello timeout should be divided to give the hello time, for example, the time interval, in seconds, between LDP hello messages. LDP uses hello messages to discover neighbors and to detect loss of connectivity with its neighbors. |
|
Displays the hello time, also known as hold time. It is the time interval, in seconds, that LDP waits before declaring a neighbor to be down. Hello timeout is local to the system and is sent in the hello messages to a neighbor. |
|
Displays the value by which the keepalive timeout should be divided to give the keepalive time, for example, the time interval, in seconds, between LDP keepalive messages. LDP keepalive messages are sent to keep the LDP session from timing out when no other LDP traffic is being sent between the neighbors. |
|
Displays the time interval, in seconds, that LDP waits before tearing down a session. If no LDP messages are exchanged during this time interval, the LDP session is torn down. Generally the value is configured to be 3 times the keepalive time (the time interval between successive LDP keepalive messages). |
|
Enabled — Authentication using MD5 message based digest protocol is enabled Disabled — No authentication is used |
|
Displays the total number of LDP interfaces |
parameters
Syntax
parameters
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays configuration information about LDP parameters.
Output
The following output is an example of LDP parameter information, and Output fields: LDP parameters describes the output fields.
Sample output*A:SRU4>config>router>ldp# show router ldp parameters
===============================================================================
LDP Parameters (LSR ID 10.20.1.4)
===============================================================================
-------------------------------------------------------------------------------
Graceful Restart Parameters
-------------------------------------------------------------------------------
Nbor Liveness Time : 5 sec Max Recovery Time : 30
-------------------------------------------------------------------------------
Interface Parameters
-------------------------------------------------------------------------------
Keepalive Timeout : 30 sec Keepalive Factor : 3
Hold Time : 15 sec Hello Factor : 3
Propagate Policy : system Transport Address : system
Deaggregate FECs : False Route Preference : 9
Label Distribution : downstreamUnsolicited Label Retention : liberal
Control Mode : ordered Loop Detection : none
-------------------------------------------------------------------------------
Targeted Session Parameters
-------------------------------------------------------------------------------
Keepalive Timeout : 40 sec Keepalive Factor : 4
Hold Time : 45 sec Hello Factor : 3
Passive Mode : False Targeted Sessions : Enabled
===============================================================================
*A:SRU4>config>router>ldp#
Label |
Description |
|---|---|
|
Displays the factor used to derive the Keepalive interval |
|
Displays the time interval, in seconds, that LDP waits before tearing down the session |
|
Displays the time left before a neighbor is declared to be down |
|
Displays the value by which the hello timeout should be divided to give the hello time, for example, the time interval, in seconds, between LDP hello messages. LDP uses hello messages to discover neighbors and to detect loss of connectivity with its neighbors. |
|
Enabled — Authentication using MD5 message based digest protocol is enabled Disabled — No authentication is used |
|
true — LDP responds only when it gets a connect request from a peer and will not attempt to actively connect to its neighbors false — LDP actively tries to connect to its peers |
|
true — Targeted sessions are enabled false — Targeted sessions are disabled |
session
Syntax
session [ip-addr[:label-space]] [detail | statistics [packet-type]] [session-type]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays configuration information about LDP sessions.
Parameters
- ip-address
Specifies the IP address of the LDP peer.
- label-space
Specifies the label space identifier that the router is advertising on the interface.
- detail
Displays detailed information.
- statistics packet-type
Specifies the packet type.
- session-type
Specifies to display the session type.
Output
The following output is an example of LDP session information, and Output fields: LDP session describes the output fields.
Sample output*A:SRU4>config>router>ldp# show router ldp session
==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time
------------------------------------------------------------------------------
10.1.1.1:0 Link Nonexistent 2 1 0d 00:00:04
10.8.100.15:0 Both Nonexistent 14653 21054 0d 12:48:25
10.20.1.20:0 Both Established 105187 84837 0d 12:48:27
10.20.1.22:0 Both Established 144586 95148 0d 12:48:23
10.22.10.2:0 Link Nonexistent 4 2 0d 00:00:16
10.22.11.2:0 Link Nonexistent 4 4 0d 00:00:14
10.22.13.2:0 Link Nonexistent 5 6 0d 00:00:20
10.66.33.1:0 Link Nonexistent 6 7 0d 00:00:25
10.66.34.1:0 Link Nonexistent 2 2 0d 00:00:05
10.66.35.1:0 Link Nonexistent 4 4 0d 00:00:14
10.20.1.1:0 Targeted Nonexistent 0 1 0d 00:00:04
10.20.1.3:0 Both Established 94 97 0d 00:00:55
10.20.1.5:0 Both Established 230866 286216 0d 12:48:27
10.20.1.110:0 Link Nonexistent 2 2 0d 00:00:05
10.0.0.1:0 Link Nonexistent 2 2 0d 00:00:05
------------------------------------------------------------------------------
No. of Sessions: 15
==============================================================================
*A:SRU4>config>router>ldp#
*A:SRU4>config>router>ldp# show router ldp session 10.20.1.20:0
==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time
------------------------------------------------------------------------------
10.20.1.20:0 Both Established 105204 84859 0d 12:49:05
------------------------------------------------------------------------------
No. of Sessions: 1
==============================================================================
*A:SRU4>config>router>ldp#
*7210SAS# show router ldp session detail
===============================================================================
LDP Sessions (Detail)
===============================================================================
Legend: DoD - Downstream on Demand (for address FEC's only)
DU - Downstream Unsolicited
===============================================================================
-------------------------------------------------------------------------------
Session with Peer 10.3.3.3:0
-------------------------------------------------------------------------------
Adjacency Type : Link State : Established
Up Time : 0d 16:59:13
Max PDU Length : 4096 KA/Hold Time Remaining: 26
Link Adjacencies : 1 Targeted Adjacencies : 0
Local Address : 10.1.1.1 Peer Address : 10.3.3.3
Local TCP Port : 646 Peer TCP Port : 59116
Local KA Timeout : 30 Peer KA Timeout : 30
Mesg Sent : 22100 Mesg Recv : 21926
FECs Sent : 16 FECs Recv : 13
GR State : Capable Label Distribution : DU
Nbr Liveness Time : 0 Max Recovery Time : 0
Number of Restart : 0 Last Restart Time : Never
P2MP : Capable MP MBB : Capable
Dynamic Capability: Yes
Advertise : Address
-------------------------------------------------------------------------------
Session with Peer 10.2.2.2:0, Local 10.1.1.1:0
-------------------------------------------------------------------------------
Adjacency Type : Both State : Established
Up Time : 0d 00:07:48
Max PDU Length : 4096 KA/Hold Time Remaining: 29
Link Adjacencies : 1 Targeted Adjacencies : 1
Local Address : 10.1.1.1 Peer Address : 10.2.2.2
Local TCP Port : 646 Peer TCP Port : 50980
Local KA Timeout : 30 Peer KA Timeout : 30
Mesg Sent : 478 Mesg Recv : 480
FECs Sent : 182 FECs Recv : 170
Addrs Sent : 13 Addrs Recv : 16
GR State : Capable Label Distribution : DU
Nbr Liveness Time : 0 Max Recovery Time : 0
MP MBB : Not Capable
Dynamic Capability: Not Capable
Advertise : Address/Servi* BFD Operational Status: inService
-------------------------------------------------------------------------------
Session with Peer 10.3.3.3:0, Local 10.1.1.1:0
-------------------------------------------------------------------------------
Adjacency Type : Both State : Established
Up Time : 0d 00:07:48
Max PDU Length : 4096 KA/Hold Time Remaining: 29
Link Adjacencies : 1 Targeted Adjacencies : 1
Local Address : 10.1.1.1 Peer Address : 10.3.3.3
Local TCP Port : 646 Peer TCP Port : 49823
Local KA Timeout : 30 Peer KA Timeout : 30
Mesg Sent : 502 Mesg Recv : 418
FECs Sent : 124 FECs Recv : 124
Addrs Sent : 13 Addrs Recv : 5
GR State : Capable Label Distribution : DU
Nbr Liveness Time : 0 Max Recovery Time : 0
MP MBB : Not Capable
Dynamic Capability: Not Capable
Advertise : Address/Servi* BFD Operational Status: inService
-------------------------------------------------------------------------------
Session with Peer 10.4.4.4:0, Local 10.1.1.1:0
-------------------------------------------------------------------------------
Adjacency Type : Targeted State : Established
Up Time : 0d 00:07:47
Max PDU Length : 4096 KA/Hold Time Remaining: 36
Link Adjacencies : 0 Targeted Adjacencies : 1
Local Address : 10.1.1.1 Peer Address : 10.4.4.4
Local TCP Port : 646 Peer TCP Port : 51307
Local KA Timeout : 40 Peer KA Timeout : 40
Mesg Sent : 122 Mesg Recv : 124
FECs Sent : 36 FECs Recv : 36
Addrs Sent : 13 Addrs Recv : 3
GR State : Capable Label Distribution : DU
Nbr Liveness Time : 0 Max Recovery Time : 0
MP MBB : Not Capable
Dynamic Capability: Not Capable
Advertise : Service BFD Operational Status: inService
===============================================================================
* indicates that the corresponding row element may have been truncated.
Label |
Description |
|---|---|
|
Displays the IP address of the LDP peer |
|
Specifies that the adjacency type between the LDP peer and LDP session is targeted Link — Specifies that this adjacency is a result of a link hello Targeted — Specifies that this adjacency is a result of a targeted hello |
|
Established — The adjacency is established Trying — The adjacency is not yet established |
|
Displays the number of messages sent |
|
Displays the number of messages received |
|
Displays the amount of time the adjacency has been enabled |
session-parameters
Syntax
session-parameters [family]
session-parameters [peer-ip-address]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays LDP peer information.
Parameters
- family
Specifies a peer family for which to display information.
- peer-ip-address
Specifies the IP address of a targeted LDP peer for which to display information.
Output
The following output is an example of LDP peer information.
Sample output===============================================================================
LDP IPv4 Session Parameters
===============================================================================
-------------------------------------------------------------------------------
Peer : 10.12.12.12
-------------------------------------------------------------------------------
DOD : Disabled Adv Adj Addr Only : Disabled
FEC129 Cisco Inter*: Disabled
PE-ID MAC Flush In*: Disabled
Fec Limit : 0 Fec Limit Threshold: 90
Fec Limit Log Only : Disabled
Import Policies : None Export Policies : None
IPv4 Prefix Fec Cap: Enabled IPv6 Prefix Fec Cap: Disabled
P2MP Fec Cap : Disabled
Address Export : None
===============================================================================
No. of IPv4 Peers: 1
===============================================================================
* indicates that the corresponding row element may have been truncated.
===============================================================================
LDP IPv6 Session Parameters
===============================================================================
No Matching Entries Found
===============================================================================
statistics
Syntax
statistics
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays LDP statistics information.
Output
The following output is an example of LDP statistics information.
Sample output===============================================================================
LDP Statistics for IPv4 LSR ID 10.20.1.1:0
IPv6 LSR ID 2001:db8::4444[0]
===============================================================================
Session/Discovery
-------------------------------------------------------------------------------
Active IPv4 Sess : 5 Active IPv6 Sess : 0
Active IPv4 LinkAdj: 21 Active IPv6 LinkAdj : 0
Active IPv4 TargAdj: 5 Active IPv6 TargAdj : 0
Active IPv4 If : 31 Inactive IPv4 If : 0
Active IPv6 If : 0 Inactive IPv6 If : 0
Active IPv4 Peers : 5 Inactive IPv4 Peers : 0
Active IPv6 Peers : 0 Inactive IPv6 Peers : 0
IPv4 Attempted Sess: 40 IPv6 Attempted Sess : 0
IPv4 OLoad If : 0 IPv4 OLoad Targ Peers: 0
IPv6 OLoad If : 0 IPv6 OLoad Targ Peers: 0
-------------------------------------------------------------------------------
Protocol Stats
-------------------------------------------------------------------------------
No Hello Err : 0 Param Adv Err : 0
Max PDU Err : 0 Label Range Err : 0
Bad LDP Id Err : 0 Bad PDU Len Err : 0
Bad Mesg Len Err : 0 Bad TLV Len Err : 0
Unknown TLV Err : 0 Bad Proto Ver Err : 0
Malformed TLV Err : 0 Keepalive Expired Err: 9
Shutdown Notif Sent: 0 Shutdown Notif Recv : 0
-------------------------------------------------------------------------------
Prefixes
-------------------------------------------------------------------------------
IPv4 Pfx FECs Sent : 25 IPv4 Pfx FECs Recv : 25
IPv6 Pfx FECs Sent : 0 IPv6 Pfx FECs Recv : 0
IPv4PfxFecOLSessSnt: 0 IPv4PfxFecOLSessRecv : 0
IPv6PfxFecOLSessSnt: 0 IPv6PfxFecOLSessRecv : 0
IPv4PfxFecInOLoad : 0 IPv6PfxFecInOLoad : 0
-------------------------------------------------------------------------------
P2MP
-------------------------------------------------------------------------------
IPv4 P2MP FECs Sent: 0 IPv4 P2MP FECs Recv : 0
IPv6 P2MP FECs Sent: 0 IPv6 P2MP FECs Recv : 0
IPv4P2MPFecOLSessSn: 0 IPv4P2MPFecOLSessRecv: 0
IPv6P2MPFecOLSessSn: 0 IPv6P2MPFecOLSessRecv: 0
IPv4P2MPFecInOLoad : 0 IPv6P2MPFecInOLoad : 0
-------------------------------------------------------------------------------
Services
-------------------------------------------------------------------------------
Svc FEC128s Sent : 0 Svc FEC128s Recv : 0
Svc FEC129s Sent : 0 Svc FEC129s Recv : 0
Svc Fec128 OLSessSn: 0 Svc Fec128 OLSessRecv: 0
Svc Fec129 OLSessSn: 0 Svc Fec129 OLSessRecv: 0
Svc Fec128 InOLoad : 0 Svc Fec129 InOLoad : 0
===============================================================================
status
Syntax
status
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays LDP status information.
Output
The following output is an example of LDP status information, and Output fields: LDP status describes the output fields.
Sample outputA:7210SAS# show router ldp status
===============================================================================
LDP Status for LSR ID 10.1.1.1
===============================================================================
Admin State : Up Oper State : Up
Created at : 11/30/2009 21:22:31 Up Time : 0d 16:45:41
Oper Down Reason : n/a Oper Down Events : 1
Last Change : 11/30/2009 21:22:31 Tunn Down Damp Time : 20 sec
Label Withdraw Del*: 120 sec Implicit Null Label : Disabled
Short. TTL Prop Lo*: Enabled Short. TTL Prop Tran*: Enabled
Import Policies : Export Policies :
None ldp-reject
Aggregate Prefix : True Agg Prefix Policies: None
Dynamic Capability : True P2MP Capable : True
MP MBB Capable : True MP MBB Timer : 3
Active Adjacencies : 3 Active Sessions : 2
Active Interfaces : 23 Inactive Interfaces : 8
Active Peers : 4 Inactive Peers : 1
Addr FECs Sent : 34 Addr FECs Recv : 15
Serv FECs Sent : 0 Serv FECs Recv : 0
P2MP FECs Sent : 0 P2MP FECs Recv : 0
Attempted Sessions : 0
No Hello Err : 0 Param Adv Err : 0
Max PDU Err : 0 Label Range Err : 0
Bad LDP Id Err : 4296 Bad PDU Len Err : 0
Bad Mesg Len Err : 0 Bad TLV Len Err : 0
Unknown TLV Err : 0
Malformed TLV Err : 0 Keepalive Expired Err: 0
Shutdown Notif Sent: 0 Shutdown Notif Recv : 0
No Matching Entries Found
===============================================================================
A:7210SAS#
Label |
Description |
|---|---|
|
Up — The LDP is administratively enabled Down — The LDP is administratively disabled |
|
Up — The LDP is operationally enabled Down — The LDP is operationally disabled |
|
Displays the date and time when the LDP instance was created |
|
Displays the time, in hundredths of seconds, that the LDP instance has been operationally up |
|
Displays the date and time when the LDP instance was last modified |
|
Displays the number of times the LDP instance has gone operationally down since the instance was created |
|
Displays the number of active adjacencies (established sessions) associated with the LDP instance |
|
Displays the number of active sessions (session in some form of creation) associated with the LDP instance |
|
Displays the number of active (operationally up) interfaces associated with the LDP instance |
|
Displays the number of inactive (operationally down) interfaces associated with the LDP instance |
|
Displays the number of active LDP peers |
|
Displays the number of inactive LDP peers |
|
Displays the number of labels that have been sent to the peer associated with this FEC |
|
Displays the number of labels that have been received from the peer associated with this FEC |
|
Displays the number of labels that have been sent to the peer associated with this FEC |
|
Displays the number of labels that have been received from the peer associated with this FEC |
|
Displays the total number of attempted sessions for this LDP instance |
|
Displays the total number of ‟Session Rejected” or ‟No Hello Error” notification messages sent or received by this LDP instance |
|
Displays the total number of ‟Session Rejected” or ‟Parameters Advertisement Mode Error” notification messages sent or received by this LDP instance |
|
Displays the total number of ‟Session Rejected” or ‟Parameters Max PDU Length Error” notification messages sent or received by this LDP instance |
|
Displays the total number of ‟Session Rejected” or ‟Parameters Label Range Error” notification messages sent or received by this LDP instance |
|
Displays the number of bad LDP identifier fatal errors detected for sessions associated with this LDP instance |
|
Displays the number of bad PDU length fatal errors detected for sessions associated with this LDP instance |
|
Displays the number of bad message length fatal errors detected for sessions associated with this LDP instance |
|
Displays the number of bad TLV length fatal errors detected for sessions associated with this LDP instance |
|
Displays the number of malformed TLV value fatal errors detected for sessions associated with this LDP instance |
|
Displays the number of shutdown notifications sent related to sessions associated with this LDP instance |
|
Displays the number of session Keepalive timer expired errors detected for sessions associated with this LDP instance |
|
Displays the number of shutdown notifications received related to sessions associated with this LDP instance |
targ-peer
Syntax
targ-peer [ip-address] [detail]
targ-peer [detail] family
targ-peer resource-failures [family]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays targeted LDP peer information.
Parameters
- detail
Displays detailed information.
- family
Specifies a peer family for which to display information.
- ip-address
Specifies the IP address of a targeted LDP peer for which to display information.
- resource-failures
Displays resource failure information for targeted LDP peers.
Output
The following output is an example of targeted LDP peer information, and Output fields: LDP targeted peers describes the output fields.
Sample output===============================================================================
LDP IPv4 Targeted Peers
===============================================================================
Peer Adm/ Hello Hold KA KA Auto
Opr Fctr Time Fctr Time Created
-------------------------------------------------------------------------------
10.1.1.1 Up/Up 3 45 4 40 yes
10.2.2.2 Up/Up 3 45 4 40 yes
10.3.3.3 Up/Up 3 45 4 40 yes
10.5.5.5 Up/Up 3 45 4 40 yes
10.6.6.6 Up/Up 3 45 4 40 yes
-------------------------------------------------------------------------------
No. of IPv4 Targeted Peers: 5
===============================================================================
===============================================================================
LDP IPv6 Targeted Peers
===============================================================================
Peer Adm/ Hello Hold KA KA Auto
Opr Fctr Time Fctr Time Created
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
Label |
Description |
|---|---|
Peer |
Displays the IP address of the peer |
Adm |
Up — indicates that LDP is administratively enabled Down — indicates that LDP is administratively disabled |
Opr |
Up — indicates that LDP is operationally enabled Down — indicates that LDP is operationally disabled |
Hello Factor |
The value by which the hello timeout should be divided to give the hello time; that is, the time interval, in seconds, between LDP Hello messages. LDP uses hello messages to discover neighbors and to detect loss of connectivity with its neighbors. |
Hold Time |
Displays the time interval, in seconds, that LDP waits before declaring a neighbor to be down. Hold time (also known as Hello time) is local to the system and is sent in the hello messages to a neighbor. |
Keepalive Factor |
Displays the value by which the keepalive timeout should be divided to give the keepalive time; that is, the time interval, in seconds, between LDP keepalive messages. LDP keepalive messages are sent to keep the LDP session from timing out when no other LDP traffic is being sent between the neighbors. |
Keepalive Timeout |
Displays the time interval, in seconds, that LDP waits before tearing down a session. If no LDP messages are exchanged during this time interval, the LDP session is torn down. Generally the value is configured to be three times the keepalive time (the time interval between successive LDP keepalive messages). |
Auto Create |
Specifies whether a targeted peer was automatically created through a Service Manager. For an LDP interface, this value is always false. |
No. of Peers |
Displays the total number of LDP peers |
tcp-session-parameters
Syntax
tcp-session-parameters [family]
tcp-session-parameters [keychain keychain]
tcp-session-parameters [transport-peer-ip-address]
Context
show>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays information about the TCP transport session of an LDP peer.
Parameters
- family
Specifies a peer family for which to display information.
- keychain
Specifies the name of an auth-keychain, up to 32 characters.
- transport-peer-ip-address
Specifies the IP address of a TCP transport peer for which to display information.
Clear commands
instance
Syntax
instance
Context
clear>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command resets the LDP instance.
interface
Syntax
interface [ip-int-name] [family]
Context
clear>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command restarts or clears statistics for LDP interfaces.
Parameters
- ip-int-name
Specifies the name of an existing interface. If the string contains special characters (#, $, spaces and other special characters), the entire string must be enclosed within double quotes.
- family
Specifies the family type.
peer
Syntax
peer [ip-address] [statistics]
Context
clear>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command restarts or clears statistics for LDP targeted peers.
Parameters
- ip-address
Specifies the IP address of a targeted peer.
- statistics
Clears only the statistics for a targeted peer
session
Syntax
session [ip-addr[:label-space]] [statistics]
Context
clear>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command restarts or clears statistics for LDP sessions.
Parameters
- label-space
Specifies the label space identifier that the router is advertising on the interface.
- statistics
Clears only the statistics for a session.
statistics
Syntax
statistics
Context
clear>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command clears LDP instance statistics.
Debug commands
ldp
Syntax
[no] ldp
Context
debug>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures LDP debugging.
interface
Syntax
[no] interface interface-name family
Context
debug>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs an LDP interface.
Parameters
- interface-name
Specifies the name of an existing interface.
- family
Specifies the family type.
peer
Syntax
[no] peer ip-address
Context
debug>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs an LDP peer.
Parameters
- ip-address
Specifies the IP address of the LDP peer.
event
Syntax
[no] event
Context
debug>router>ldp>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures debugging for specific LDP events.
bindings
Syntax
[no] bindings
Context
debug>router>ldp>peer>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays debugging information about addresses and label bindings learned from LDP peers for LDP bindings.
The no form of this command disables the debugging output.
messages
Syntax
[no] messages
Context
debug>router>ldp>peer>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays specific information (for example, message type, source, and destination) about LDP messages sent to and received from LDP peers.
The no form of this command disables debugging output for LDP messages.
packet
Syntax
packet [detail]
no packet
Context
debug>router>ldp>peer
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for specific LDP packets.
The no form of this command disables the debugging output.
Parameters
- detail
Keyword to display detailed information.
hello
Syntax
hello [detail]
no hello
Context
debug>router>ldp>peer>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for LDP hello packets.
The no form of this command disables the debugging output.
Parameters
- detail
Keyword to display detailed information.
init
Syntax
init [detail]
no init
Context
debug>router>ldp>peer>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for LDP Init packets.
The no form of this command disables the debugging output.
Parameters
- detail
Displays detailed information.
keepalive
Syntax
[no] keepalive
Context
debug>router>ldp>peer>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for LDP Keepalive packets.
The no form of this command disables the debugging output.
label
Syntax
label [detail]
no label
Context
debug>router>ldp>peer>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for LDP Label packets.
The no form of this command disables the debugging output.
Parameters
- detail
Keyword to display detailed information.