MPLS Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 6.4.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Multiprotocol
Label Switching (MPLS) is a standards-based solution driven by the Internet
Engineering Task Force (IETF) that was devised to convert the Internet and IP
backbones from best-effort networks into business-class transport mediums.
MPLS, with its label
switching capabilities, eliminates the need for an IP route look-up and creates
a virtual circuit (VC) switching function, allowing enterprises the same
performance on their IP-based network services as with those delivered over
traditional networks such as Frame Relay or ATM.
Label Distribution
Protocol (LDP) performs label distribution in MPLS environments. LDP provides
the following capabilities:
LDP performs
hop-by-hop or dynamic path setup; it does not provide end-to-end switching
services.
LDP assigns labels
to routes using the underlying Interior Gateway Protocols (IGP) routing
protocols.
LDP provides
constraint-based routing using LDP extensions for traffic engineering.
Finally, LDP is
deployed in the core of the network and is one of the key protocols used in
MPLS-based Layer 2 and Layer 3 virtual private networks (VPNs).
Feature History
for Implementing MPLS LDP
Release
Modification
Release 3.7.2
This
feature was introduced.
Release 3.9.0
No
modification.
Release 4.0.1
Support was added for these
features:
IP
LDP Fast Reroute Loop Free Alternate
Downstream on Demand
Release 4.2.1
Support
was added for LDP Implicit Null for IGP Routes.
Release 5.1
Support
was added for MPLS over IRB.
Release 5.1.1
The
feature MPLS LDP Carrier Supporting Carrier for Multiple VRFs was introduced.
Release 5.3.0
IPv6
Support in MPLS LDP was introduced.
Release 6.0.1
Dual-Stack Capability TLV feature was introduced.
Release 7.0.1
The UDP Decapsulation of MPLS-Over-UDP Traffic feature was introduced.
Prerequisites for Implementing Cisco MPLS LDP
These prerequisites are required to implement MPLS LDP:
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include
the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact
your AAA administrator for assistance.
You must be running
Cisco IOS XR software.
You must install a composite mini-image and the MPLS package.
You must activate IGP.
We recommend to use a lower session holdtime bandwidth such as neighbors so that a session down occurs before an adjacency-down
on a neighbor. Therefore, the following default values for the hello times are listed:
Holdtime is 15 seconds.
Interval is 5 seconds.
For example, the LDP session holdtime can be configured as 30 seconds by using the holdtime command.
Information About Implementing Cisco MPLS LDP
To implement MPLS LDP, you should understand these concepts:
Overview of Label Distribution Protocol
LDP performs label distribution in MPLS environments. LDP uses hop-by-hop or dynamic path setup, but does not provide end-to-end
switching services. Labels are assigned to routes that are chosen by the underlying IGP routing protocols. The Label Switched
Paths (LSPs) that result from the routes, forward labeled traffic across the MPLS backbone to adjacent nodes.
Label Switched Paths
LSPs are created in the network through MPLS. They can be created statically, by RSVP traffic engineering (TE), or by LDP.
LSPs created by LDP perform hop-by-hop path setup instead of an end-to-end path.
LDP Control
Plane
The control plane
enables label switched routers (LSRs) to discover their potential peer routers
and to establish LDP sessions with those peers to exchange label binding
information.
Exchanging Label Bindings
LDP creates LSPs to perform the hop-by-hop path setup so that MPLS
packets can be transferred between the nodes on the MPLS network.
Figure 1. Setting Up Label Switched Paths .
This figure illustrates the process of label binding exchange for setting up LSPs.
For a given network (10.0.0.0), hop-by-hop LSPs are set up between each
of the adjacent routers (or, nodes) and each node allocates a local label and
passes it to its neighbor as a binding:
R4 allocates local label L4 for prefix 10.0.0.0 and advertises it to
its neighbors (R3).
R3 allocates local label L3 for prefix 10.0.0.0 and advertises it to
its neighbors (R1, R2, R4).
R1 allocates local label L1 for prefix 10.0.0.0 and advertises it to
its neighbors (R2, R3).
R2 allocates local label L2 for prefix 10.0.0.0 and advertises it to
its neighbors (R1, R3).
R1’s label information base (LIB) keeps local and remote labels
bindings from its neighbors.
R2’s LIB keeps local and remote labels bindings from its neighbors.
R3’s LIB keeps local and remote labels bindings from its neighbors.
R4’s LIB keeps local and remote labels bindings from its neighbors.
LDP
Forwarding
Once label bindings
are learned, the LDP control plane is ready to setup the MPLS forwarding plane
as shown in the following figure.
Figure 2. Forwarding
Setup. Once label
bindings are learned, the LDP control plane is ready to setup the MPLS
forwarding plane as shown in this figure.
Because R3 is next
hop for 10.0.0.0 as notified by the FIB, R1 selects label binding from R3 and
installs forwarding entry (Layer 1, Layer 3).
Because R3 is next
hop for 10.0.0.0 (as notified by FIB), R2 selects label binding from R3 and
installs forwarding entry (Layer 2, Layer 3).
Because R4 is next
hop for 10.0.0.0 (as notified by FIB), R3 selects label binding from R4 and
installs forwarding entry (Layer 3, Layer 4).
Because next hop
for 10.0.0.0 (as notified by FIB) is beyond R4, R4 uses NO-LABEL as the
outbound and installs the forwarding entry (Layer 4); the outbound packet is
forwarded IP-only.
Incoming IP
traffic on ingress LSR R1 gets label-imposed and is forwarded as an MPLS packet
with label L3.
Incoming IP
traffic on ingress LSR R2 gets label-imposed and is forwarded as an MPLS packet
with label L3.
R3 receives an
MPLS packet with label L3, looks up in the MPLS label forwarding table and
switches this packet as an MPLS packet with label L4.
R4 receives an
MPLS packet with label L4, looks up in the MPLS label forwarding table and
finds that it should be Unlabeled, pops the top label, and passes it to the IP
forwarding plane.
IP forwarding
takes over and forwards the packet onward.
Note
For local labels,
only up to 12000 rewrites are supported. If the rewrites exceed this limit,
MPLS LSD or MPLS LDP or both the processes may crash.
LDP Graceful Restart
LDP (Label Distribution Protocol) graceful restart provides a control plane mechanism to ensure high
availability and allows detection and recovery from failure conditions while
preserving Nonstop Forwarding (NSF) services. Graceful restart is a way to
recover from signaling and control plane failures without impacting forwarding.
Without LDP graceful restart, when an established session fails, the
corresponding forwarding states are cleaned immediately from the restarting and
peer nodes. In this case LDP forwarding restarts from the
beginning, causing a potential loss of data and connectivity.
The LDP graceful restart capability is negotiated between two peers
during session initialization time, in FT SESSION TLV. In this typed length
value (TLV), each peer advertises the following information to its peers:
Reconnect time
Advertises the maximum time that other peer will wait for this LSR
to reconnect after control channel failure.
Recovery time
Advertises the maximum time that the other peer has on its side to
reinstate or refresh its states with this LSR. This time is used only during
session reestablishment after earlier session failure.
FT flag
Specifies whether a restart could restore the preserved (local)
node state for this flag.
Once the graceful restart session parameters are conveyed and the
session is up and running, graceful restart procedures are activated.
When configuring the LDP graceful restart process in a network with multiple links, targeted LDP hello adjacencies with the
same neighbor, or both, make sure that graceful restart is activated on the session before any hello adjacency times out in
case of neighbor control plane failures. One way of achieving this is by configuring a lower session hold time between neighbors
such that session timeout occurs before hello adjacency timeout. It is recommended to set LDP session hold time using the
following formula:
This means that for default values of 15 seconds and 5 seconds for link Hello holdtime and interval respectively, session
hold time should be set to 30 seconds at most.
For more information about LDP commands, see MPLS Label Distribution Protocol Commands module of the
MPLS Command Reference for Cisco ASR 9000 Series Routers.
Control Plane Failure
When a control plane failure occurs, connectivity can be affected. The
forwarding states installed by the router control planes are lost, and the
in-transit packets could be dropped, thus breaking NSF.
Figure 3. Control Plane Failure. This figure illustrates a control plane failure and shows the process and results of a
control plane failure leading to loss of connectivity.
The R4 LSR control plane restarts.
LIB is lost when the control plane restarts.
The forwarding states installed by the R4 LDP control plane are
immediately deleted.
Any in-transit packets flowing from R3 to R4 (still labeled with L4)
arrive at R4.
The MPLS forwarding plane at R4 performs a lookup on local label L4
which fails. Because of this failure, the packet is dropped and NSF is not met.
The R3 LDP peer detects the failure of the control plane channel and
deletes its label bindings from R4.
The R3 control plane stops using outgoing labels from R4 and deletes
the corresponding forwarding state (rewrites), which in turn causes forwarding
disruption.
The established LSPs connected to R4 are terminated at R3, resulting
in broken end-to-end LSPs from R1 to R4.
The established LSPs connected to R4 are terminated at R3, resulting
in broken LSPs end-to-end from R2 to R4.
Phases in Graceful Restart
The graceful restart mechanism is divided into different phases:
Control communication failure detection
Control communication failure is detected when the system detects either:
Missed LDP hello discovery messages
Missed LDP keepalive protocol messages
Detection of Transmission Control Protocol (TCP) disconnection a with a peer
Forwarding state maintenance during failure
Persistent forwarding states at each LSR are achieved through persistent storage (checkpoint) by the LDP control plane. While
the control plane is in the process of recovering, the forwarding plane keeps the forwarding states, but marks them as stale.
Similarly, the peer control plane also keeps (and marks as stale) the installed forwarding rewrites associated with the node
that is restarting. The combination of local node forwarding and remote node forwarding plane states ensures NSF and no disruption
in the traffic.
Control state recovery
Recovery occurs when the session is reestablished and label bindings are exchanged again. This process allows the peer nodes
to synchronize and to refresh stale forwarding states.
Recovery with Graceful-Restart
Figure 4. Recovering with Graceful Restart. This figure
illustrates the process of failure recovery using graceful restart.
The router R4 LSR control plane restarts.
With the control plane restart, LIB is gone but forwarding states
installed by R4’s LDP control plane are not immediately deleted but are marked
as stale.
Any in-transit packets from R3 to R4 (still labeled with L4) arrive
at R4.
The MPLS forwarding plane at R4 performs a successful lookup for the
local label L4 as forwarding is still intact. The packet is forwarded
accordingly.
The router R3 LDP peer detects the failure of the control plane and
channel and deletes the label bindings from R4. The peer, however, does not
delete the corresponding forwarding states but marks them as stale.
At this point there are no forwarding disruptions.
The peer also starts the neighbor reconnect timer using the
reconnect time value.
The established LSPs going toward the router R4 are still intact,
and there are no broken LSPs.
When the LDP control plane recovers, the restarting LSR starts its
forwarding state hold timer and restores its forwarding state from the
checkpointed data. This action reinstates the forwarding state and entries and
marks them as old.
The restarting LSR reconnects to its peer, indicated in the FT Session
TLV, that it either was or was not able to restore its state successfully. If
it was able to restore the state, the bindings are resynchronized.
The peer LSR stops the neighbor reconnect timer (started by the
restarting LSR), when the restarting peer connects and starts the neighbor
recovery timer. The peer LSR checks the FT Session TLV if the restarting peer
was able to restore its state successfully. It reinstates the corresponding
forwarding state entries and receives binding from the restarting peer. When
the recovery timer expires, any forwarding state that is still marked as stale
is deleted.
If the restarting LSR fails to recover (restart), the restarting LSR
forwarding state and entries will eventually timeout and is deleted, while
neighbor-related forwarding states or entries are removed by the Peer LSR on
expiration of the reconnect or recovery timers.
Label Advertisement Control (Outbound Filtering)
By default, LDP advertises labels for all the prefixes to all its
neighbors. When this is not desirable (for scalability and security reasons),
you can configure LDP to perform outbound filtering for local label
advertisement for one or more prefixes to one more peers. This feature is known
as
LDP outbound label filtering, or
local label advertisement control.
Label Acceptance Control (Inbound Filtering)
By default, LDP accepts labels (as remote bindings) for all prefixes from all peers. LDP operates in liberal label retention
mode, which instructs LDP to keep remote bindings from all peers for a given prefix. For security reasons, or to conserve
memory, you can override this behavior by configuring label binding acceptance for set of prefixes from a given peer.
The ability to filter remote bindings for a defined set of prefixes is also referred to as LDP inbound label filtering.
Note
Inbound filtering can also be implemented using an outbound filtering policy; however, you may not be able to implement this
system if an LDP peer resides under a different administration domain. When both inbound and outbound filtering options are
available, we recommend that you use outbound label filtering.
Local Label Allocation Control
By default, LDP allocates local labels for all prefixes that are not Border Gateway Protocol (BGP) prefixes1. This is acceptable when LDP is used for applications other than Layer 3 virtual private networks (L3VPN) core transport.
When LDP is used to set up transport LSPs for L3VPN traffic in the core, it is not efficient or even necessary to allocate
and advertise local labels for, potentially, thousands of IGP prefixes. In such a case, LDP is typically required to allocate
and advertise local label for loopback /32 addresses for PE routers. This is accomplished using LDP local label allocation
control, where an access list can be used to limit allocation of local labels to a set of prefixes. Limiting local label allocation
provides several benefits, including reduced memory usage requirements, fewer local forwarding updates, and fewer network
and peer updates.
Tip
You can configure label allocation using an IP access list to specify a set of prefixes that local labels can allocate and
advertise.
Session Protection
When a link comes up, IP converges earlier and much faster than MPLS LDP
and may result in MPLS traffic loss until MPLS convergence. If a link flaps,
the LDP session will also flap due to loss of link discovery. LDP session
protection minimizes traffic loss, provides faster convergence, and protects
existing LDP (link) sessions by means of “parallel” source of targeted
discovery hello. An LDP session is kept alive and neighbor label bindings are
maintained when links are down. Upon reestablishment of primary link
adjacencies, MPLS convergence is expedited as LDP need not relearn the neighbor
label bindings.
LDP session protection lets you configure LDP to automatically protect
sessions with all or a given set of peers (as specified by peer-acl). When
configured, LDP initiates backup targeted hellos automatically for neighbors
for which primary link adjacencies already exist. These backup targeted hellos
maintain LDP sessions when primary link adjacencies go down.
The Session Protection figure
illustrates LDP session protection between neighbors R1 and R3. The primary
link adjacency between R1 and R3 is directly connected link and the backup;
targeted adjacency is maintained between R1 and R3. If the direct link fails,
LDP link adjacency is destroyed, but the session is kept up and running using
targeted hello adjacency (through R2). When the direct link comes back up,
there is no change in the LDP session state and LDP can converge quickly and
begin forwarding MPLS traffic.
Figure 5. Session Protection
Note
When LDP session protection is activated (upon link failure),
protection is maintained for an unlimited period time.
IGP Synchronization
Lack of synchronization between LDP and IGP can cause MPLS traffic loss. Upon link up, for example, IGP can advertise and
use a link before LDP convergence has occurred; or, a link may continue to be used in IGP after an LDP session goes down.
LDP IGP synchronization synchronizes LDP and IGP so that IGP advertises links with regular metrics only when MPLS LDP is converged
on that link. LDP considers a link converged when at least one LDP session is up and running on the link for which LDP has
sent its applicable label bindings and received at least one label binding from the peer. LDP communicates this information
to IGP upon link up or session down events and IGP acts accordingly, depending on sync state.
In the event of an LDP graceful restart session disconnect, a session is treated as converged as long as the graceful restart
neighbor is timed out. Additionally, upon local LDP restart, a checkpointed recovered LDP graceful restart session is used
and treated as converged and is given an opportunity to connect and resynchronize.
Under certain circumstances, it might be required to delay declaration of resynchronization to a configurable interval. LDP
provides a configuration option to delay declaring synchronization up for up to 60 seconds. LDP communicates this information
to IGP upon linkup or session down events.
Note
The configuration for LDP IGP synchronization resides in respective IGPs (OSPF and IS-IS) and there is no LDP-specific configuration
for enabling of this feature. However, there is a specific LDP configuration for IGP sync delay timer.
IGP Auto-configuration
To enable LDP on a large number of interfaces, IGP auto-configuration lets you automatically configure LDP on all interfaces
associated with a specified IGP interface; for example, when LDP is used for transport in the core network. However, there
needs to be one IGP set up to enable LDP auto-configuration.
Typically, LDP assigns and advertises labels for IGP routes and must often be enabled on all active interfaces by an IGP.
Without IGP auto-configuration, you must define the set of interfaces under LDP, a procedure that is time-intensive and error-prone.
Note
LDP auto-configuration is supported for IPv4 unicast family in the default VRF. The IGP is responsible for verifying and applying
the configuration.
You can also disable auto-configuration on a per-interface basis. This permits LDP to enable all IGP interfaces except those
that are explicitly disabled and prevents LDP from enabling an interface when LDP auto-configuration is configured under IGP.
LDP Nonstop
Routing
LDP nonstop routing
(NSR) functionality makes failures, such as Route Processor (RP) or Distributed
Route Processor (DRP) failover, invisible to routing peers with minimal to no
disruption of convergence performance. By default, NSR is globally enabled on
all LDP sessions except AToM.
A disruption in
service may include any of these events:
Route processor
(RP) or distributed route processor (DRP) failover
LDP process
restart
In-service system
upgrade (ISSU)
Minimum disruption
restart (MDR)
Note
Unlike graceful
restart functionality, LDP NSR does not require protocol extensions and does
not force software upgrades on other routers in the network, nor does LDP NSR
require peer routers to support NSR.
Process failures of
active TCP or LDP results in session loss and, as a result, NSR cannot be
provided unless RP switchover is configured as a recovery action. For more
information about how to configure switchover as a recovery action for NSR, see
Configuring
Transports module in
IP Addresses and Services Configuration Guide for Cisco ASR 9000 Series Routers.
IP LDP Fast Reroute Loop Free Alternate
The IP Fast Reroute is
a mechanism that enables a router to rapidly switch traffic,
after an adjacent link failure, node failure, or both, towards a
pre-programmed loop-free alternative (LFA) path. This
LFA path is used to switch traffic until the router installs a
new primary next hop again, as computed for the changed network
topology.
The goal of LFA FRR is to reduce failure reaction time to 50 milliseconds by using a pre-computed alternate next hop, in the
event that the currently selected primary next hop fails, so that
the alternate can be rapidly used when the failure is detected.
This feature targets to address the fast convergence ability by detecting, computing, updating or enabling prefix independent
pre-computed alternate loop-free paths at the time of failure.
IGP pre-computes a backup path per IGP prefix. IGP selects one and only one backup path per primary path. RIB installs the
best path and download path protection information to FIB by providing correct annotation for protected and
protecting paths. FIB pre-installs the backup path in dataplane. Upon the link or node failure, the routing protocol detects
the failure, all the backup paths of the impacted prefixes are enabled in a prefix-independent manner.
Prerequisites
The Label Distribution Protocol (LDP) can use the loop-free alternates as long as these prerequisites are met:
The Label Switching Router (LSR) running LDP must distribute its labels for the Forwarding Equivalence Classes (FECs) it can
provide to all its neighbors, regardless of whether they are upstream, or not.
There are two approaches in computing LFAs:
Link-based (per-link)--In link-based LFAs, all prefixes reachable
through the primary (protected) link share the same backup
information. This means that the whole set of prefixes, sharing the
same primary, also share the repair or fast reroute (FRR) ability. The per-link approach protects only the next hop address.
The per-link approach is suboptimal and not the best for capacity planning. This is because all traffic is redirected to
the next hop instead of being spread over multiple paths, which may lead to potential congestion on link to the next hop.
The per-link approach does not provide support for node protection.
Prefix-based (per-prefix)--Prefix-based LFAs allow computing backup
information per prefix. It protects the destination address. The per-prefix approach is the preferred approach due to its
greater applicability, and the greater protection and better bandwidth utilization that it offers.
Note
The repair or backup information
computed for a given prefix using prefix-based LFA may be different
from the computed by link-based LFA.
The per-prefix LFA approach is preferred for LDP IP Fast Reroute LFA for these reasons:
Better node failure resistance
Better capacity planning and
coverage
Features Not Supported
These interfaces and features are not supported for the IP LDP Fast Reroute Loop Free Alternate feature:
BVI interface (IRB) is not supported either as primary or backup path.
GRE tunnel is not supported either as primary or backup path.
Cisco ASR 9000 Series SPA Interface Processor-700 POS line card on Cisco ASR 9000 Series Router is not supported as primary
link. It can be used as LFA backup only on main interface.
In a multi-topology scenerio, the route in topology T can only use LFA within topology T. Hence, the availability of a backup
path depends on the topology.
For more information about configuring the IP Fast Reroute Loop-free alternate , see Implementing IS-IS on Cisco IOS XR
Software module of the
Routing Configuration Guide for Cisco ASR 9000 Series Routers.
Downstream on Demand
This Downstream on demand feature adds support for downstream-on-demand mode, where the label is not advertised to a peer,
unless the peer explicitly requests it. At the same time, since the peer does not automatically advertise labels, the label
request is sent whenever the next-hop points out to a peer that no remote label has been assigned.
To enable downstream-on-demand mode, this configuration must be applied at mpls ldp configuration mode:
mpls ldp downstream-on-demand withACL
The ACL contains a list of peer IDs that are configured for
downstream-on-demand mode. When the ACL is changed or configured,
the list of established neighbors is traversed. If a session's
downstream-on-demand configuration has changed, the session is
reset in order that the new down-stream-on-demand mode can be configured.
The reason for resetting the session is to ensure that the labels
are properly advertised between the peers. When a new session is
established, the ACL is verified to determine whether the session
should negotiate for downstream-on-demand mode. If the ACL
does not exist or is empty, downstream-on-demand mode is not configured for any
neighbor.
For it to be enabled, the Downstream on demand feature has to be configured on both peers of the session. If only one peer
in the session has downstream-on-demand feature configured, then the session does not use downstream-on-demand mode.
If, after, a label request is sent, and no remote label is received from the peer, the router will periodically resend the
label request. After the peer advertises a label after receiving the label request, it will automatically readvertise the
label if any label attribute changes subsequently.
Explicit-Null and Implicit-Null Labels
Cisco MPLS LDP uses null label, implicit or explicit, as local label
for routes or prefixes that terminate on the given LSR. These routes
include all local, connected, and attached networks. By default, the
null label is implicit-null that allows LDP control plane to implement penultimate hop popping (PHOP) mechanism. When this is not desirable, you can
configure explicit-null that allows LDP control plane to implement ultimate hop popping (UHOP) mechanism. You can configure this explicit-null feature
on the ultimate
hop LSR. This configuration knob includes an access-list to specify
the IP prefixes for which PHOP is desired.
This new enhancement allows you to configure implicit-null local label for non-egress (ultimate hop LSR) prefixes by using the implicit-null-override command. This enforces implicit-null local label for a specific prefix even if the prefix requires a non-null label to be
allocated by default. For example, by default, an LSR allocates and advertises a non-null label for an IGP route. If you
wish to terminate LSP for this route on penultimate hop of the LSR, you can enforce implicit-null label allocation and advertisement
for this prefix using implicit-null-override feature.
Note
If a given prefix is permitted in both explicit-null and implicit-null-override feature, then implicit-null-override supercedes
and an implicit-null label is allocated and advertised for the prefix.
In order to enable implicit-null-override mode, this configuration must be applied at MPLS LDP label configuration mode:
mpls ldp
label
implicit-null-override for <prefix><ACL>
!
This feature works with any prefix including static, IGP, and BGP, when specified in
the ACL.
MPLS over
IRB
The Integrated
Routing and Bridging (IRB) feature in Cisco IOS XR Software enables routing of
a given protocol between routed interfaces and bridge groups within a single
router. IRB support for MPLS introduces these capabilities:
Bridge-Group
Virtual Interface (BVI) support under MPLS LDP
Targeted LDP
session to BVI neighbor
MPLS OAM for BVI
interfaces
Netflow for BVI
interfaces while MPLS is enabled
L2VPN using
targeted MPLS LDP to BVI destination
L3VPN
6PE/6VPE
MPLS over IRB is
supported completely on ASR 9000 Enhanced Ethernet Line Card and Cisco ASR
9001. MPLS over IRB is not supported on ASR 9000 Ethernet Line Card.
For more information on MPLS over IRB, see the
Implementing MPLS
Label Distribution Protocol chapter in the
MPLS Configuration Guide for Cisco ASR 9000 Series Routers. For more
information on MPLS over IRB commands, see the
MPLS Label
Distribution Protocol Commands chapter in the
MPLS Command Reference for Cisco ASR 9000 Series Routers.
MPLS LDP Carrier
Supporting Carrier for Multiple VRFs
The carrier supporting carrier (CSC)
support for MPLS LDP feature enables MPLS label distribution protocol (LDP) to
provide CSC support for Layer 3 Virtual Private Networks (L3VPN). To support
LDP as label distribution protocol between PE-CE devices in an MPLS CSC L3VPN,
LDP is required to operate in multiple Virtual Private Network routing and
forwarding (VRF) contexts.
The carrier supporting carrier feature enables one MPLS VPN-based
service provider to allow other service providers to use a segment of its
backbone network. The service provider that provides the segment of the
backbone network to the other provider is called the
backbone carrier. The service provider that uses the segment
of the backbone network is called the
customer carrier.
A backbone carrier offers Border Gateway Protocol and Multiprotocol
Label Switching (BGP/MPLS) VPN services. The customer carrier can be either:
An Internet service provider
(ISP)
A BGP/MPLS VPN service provider
In either case, MPLS is run in the backbone network and between the
backbone and customer carrier (the PE-CE link).
Figure 6. MPLS Carrier Supporting Carrier L3VPN. This figure illustrates an MPLS CSC L3VPN.
The figure shows two customers, A and X, connecting their remote sites
through the backbone carrier. The PE device of the backbone network connects
with both customers through MPLS but under different VRFs according to
interface-VRF mapping. The MPLS label distribution protocol for PE-CE
connectivity can be either BGP or LDP, and requires them to run in a customer
VRF context on the PE device.
Benefits of MPLS LDP
CSC
The MPLS LDP CSC
provides the following benefits to service providers who are backbone carriers
and to customer carriers.
Benefits to the Backbone
Carrier
The backbone
carrier can accommodate many customer carriers and give them access to its
backbone. The backbone carrier does not need to create and maintain separate
backbones for its customer carriers. Using one backbone network to support
multiple customer carriers simplifies the backbone carrier's VPN operations.
The backbone carrier uses a consistent method for managing and maintaining the
backbone network. This is also cheaper and more efficient than maintaining
separate backbones.
The MPLS LDP CSC
feature is scalable. CSC can change the VPN to meet changing bandwidth and
connectivity needs. The feature can accommodate unplanned growth and changes.
The CSC feature enables tens of thousands of VPNs to be configured over the
same network, and it allows a service provider to offer both VPN and internet
services.
The MPLS LDP CSC
feature is a flexible solution. The backbone carrier can accommodate many types
of customer carriers. The backbone carrier can accept customer carriers who are
ISPs or VPN service providers or both. The backbone carrier can accommodate
customer carriers that require security and various bandwidths.
Benefits to the Customer
Carriers
The MPLS LDP CSC
feature removes from the customer carrier the burden of configuring, operating,
and maintaining its own backbone. The customer carrier uses the backbone
network of a backbone carrier, but the backbone carrier is responsible for
network maintenance and operation.
Customer carriers
who use the VPN services provided by the backbone carrier receive the same
level of security that Frame Relay or ATM-based VPNs provide. Customer carriers
can also use IPSec in their VPNs for a higher level of security; it is
completely transparent to the backbone carrier.
Customer carriers
can use any link layer technology (SONET, Digital Subscriber Line, Frame Relay,
and so on) to connect the CE routers to the PE routers and the PE routers to
the P routers. The MPLS LDP CSC feature is link layer independent. The CE
routers and PE routers use IP or MPLS to communicate, and the backbone carrier
uses MPLS.
The customer
carrier can use any addressing scheme and still be supported by a backbone
carrier. The customer address space and routing information are independent of
the address space and routing information of other customer carriers or the
backbone provider.
Multiple VRF
Support
To support multiple
VRFs, IOS XR LDP configuration model is extended to allow VRF submode and
per-VRF configuration and feature or interface enabling.
IOS XR LDP process is
not distributed nor it is multi-instance, hence the single LDP process services
all the configured VRFs. In large scale VRF deployment, it is recommended to
enable VRF under LDP with appropriate policies and label filtering.
RSI
To obtain VRF and routing tables’
related information, LDP interacts with the router space infrastructure (RSI)
server. For every LDP enabled non-default VRF, LDP registers with RSI to get
notifications upon VRF default (IPv4/IPv6) tables getting created or deleted,
and populate the LDP VRF database accordingly.
VRF Table ID
Database
A new database is
added in the LDP process to keep track of all VRFs enabled under LDP. This
database holds both active as well as forward-reference VRF records. In
addition to serving as an LDP context, each active record of this database also
holds VRF’s default (IPv4/IPv6 unicast) table IDs.
VRF-Interface
Mapping
To enable LDP on an
interface for a given address family under a VRF context , it is required to
list interface and its address family explicitly under a LDP VRF submode. LDP
does not enforce or check correctness of the interface and VRF mapping at the
time of configuration, and hence configuration may be accepted by LDP. The
interface with incorrect VRF mapping is not made operational by LDP and remains
down from the LDP point of view.
This means that an
interface remains LDP operationally down for which either:
LDP has not
received any address update, or
LDP has received
update with different table-id (VRF) than configured under LDP.
Also, a user must not
configure the same LDP interface under more than one VRF.
Context
Isolation
Each active VRF under LDP points to a
separate context under which LDP runs. This means that various variables,
database, tables, FSM are kept separate in their respective VRF contexts and do
not interfere or interact with each other. This allows the LDP to provide
per-VRF isolation and support CSC with customers with overlapping addresses or
routing information.
Default
Context
The default (global)
context is enabled at the time of the LDP process startup and remains enabled
always. It is not possible to disable IPv4 for the default context. Also, it is
required to explicitly enable IPv4 for non-default context. Therefore you can
effectively disable IPv4 for non-default context by not configuring it. This
means that, it is possible to enable or disable the non-default context under
LDP, whereas the same is not possible for a default context.
Restrictions and
Recommendations
The following
restrictions and recommendations apply to the MPLS LDP CSC feature:
Only IPv4 address
family is supported for a default or a non-default VRF.
No T-LDP support
in a VRF context.
An address family
under VRF and VRF interface must be configured for non-default VRFs.
Following
scenarios are not supported :
Different VRFs
between a given PE-CE device pair (VRFs configured on different links and
interfaces)
LDP/BGP CSC
co-existence on a given VRF between a given PE-CE device pair:
Single
link
Parallel
links: LDP CSC on one link and BGP CSC on the other
LDP router-id
must be configured per-VRF. If not configured for non-default VRF, LDP computes
router-id from available loopback interfaces under the VRF.
It is recommended
to configure a routable discovery transport address under a VRF IPv4
address-family submode for deterministic transport endpoint and connection.
When LDP CSC is
configured and in use:
BGP label
allocation policy for VRF prefixes must be per-prefix
Selective VRF
Download (SVD) feature must be disabled
IPv6 Support in MPLS
LDP
Internet Protocol
version 6 (IPv6) support in MPLS LDP (Label Distribution Protocol) feature
makes the LDP control plane to run on IPv6 in order to setup LSPs for IPv6
prefixes. This support enables most of the LDP functions supported on IPv4 to
be extended to IPv6. In this context, support for native MPLS LDP over IPv6 is
provided in order to seamlessly continue providing existing services while
enabling new ones.
LDP associates a
forwarding equivalence class (FEC) with each label switched path (LSP) it
creates. The FEC associated with an LSP specifies which packets are mapped to
that LSP. LDP establishes sessions with peers and exchanges FEC label bindings
with them to enable creation of LSPs to carry MPLS traffic destined to IP
prefixes.
LDP base
specification, RFC 5036 defines procedures and messages for exchanging bindings
for IPv4 and IPv6 addresses and routing prefixes. LDP IPv6 specification
(draft-ietf-mpls-ldp-ipv6) updates LDP base specifications for IPv6 support,
and further clarifies and focuses on the procedures for supporting LDP IPv6
control plane and binding advertisement.
The procedures of
address bindings, label bindings, and forwarding setup are same for IPv4 and
IPv6 address families in LDP. The only difference is that, a different address
format is used according to the IP address family. While a single-stack IP
address family (IPv4-only or IPv6-only) enabled interfaces between a set of
routers is the most typical deployment, scenarios for LSR interconnections
using both IPv4 and IPv6 interfaces are also supported.
IPv6 support in MPLS
LDP implements draft-ietf-mpls-ldp-ipv6 version12 issued by the Internet
Engineering Task Force (IETF).
LDP IPv6
Functionality
LDP functionality can
be broadly divided into two categories:
Control Plane
Control plane
includes functions such as: neighbor discovery (hello adjacencies), transport
connection/endpoint (TCP connection), session and peering, and bindings
exchange.
LSP Setup
LSP setup includes
functions such as: acquire FEC information through RIB, assign and advertise
local label bindings for FEC, advertise local (interface) IP address bindings
and setup forwarding rewrites.
For the control plane,
the underlying address family can be either IPv4-only, IPv6-only or both.
Whereas for the LSP setup, an LSP is setup for IPv4 or IPv6 FEC prefix.
Figure 7. LDP IPv6
Architecture. This figure
illustrates the main components that collaborate to achieve the required
functionality for the LDP IPv6 feature.
The functions of LDP
in the MPLS LDP IPv6 setup are as follows:
Receive routing
updates from routing information base (RIB) for global IPv6 prefixes
Assign local
labels for IPv6 prefixes
Receive IPv6
address or state notifications for local IPv6 enabled interfaces from IP
Address Repository Manager (IP-ARM/IM) and LAS for IPv6 link-local unicast
addresses
Advertise/Accept
IPv6 label bindings and address bindings to/from peers
Setup MPLS
forwarding to create IPv6 LSPs
Provide IPv6 LSP
information to MPLS OAM as and when requested
Service MIB
requests for IPv6 control plane queries and generate MIB traps
Provide LDPv6
convergence status for a link to IGP for LDP-IGP Sync feature for IPv6
Support IPv6
address family for all existing LDP features that intersect with prefixes
and/or addresses
Figure 8. LDP IPv6 Control
Plane and LSP Setup . This figure
illustrates the high level functionality of LDP in terms of control plane and
LSP setup in an IPv6 environment.
Topological
Scenarios
A typical
deployment scenario consists of single-stack IP address-family (IPv4-only or
IPv6-only) enabled interfaces between a set of routers.
Three topology
scenarios in which the LSRs are connected through one or more dual-stack LDP
enabled interfaces, or one or more single-stack LDP enabled interfaces are
defined as follows:
A description of
the control plane and LSP setup scenarios for the previously shown three
configurations are as follows:
Case 1:
Neighbor Discovery:
Both IPv4 and IPv6 Hellos sent on the interface to R1.
Transport
Connection: IPv4 endpoints or IPv6 endpoints (as per user preference).
Label binding
exchange: Both IPv4 and IPv6 prefixes.
Address binding
exchange: Both IPv4 and IPv6 addresses.
LSPs: Both IPv4 and
IPv6 over the same nexthop interface to R1.
Case 2:
Neighbor
Discovery: IPv4 Hellos on interface-1 to R1 and IPv6 Hellos on interface-2 to
R1.
Transport
Connection: IPv4 endpoints or IPv6 endpoints (as per user preference).
Label binding
exchange: Both IPv4 and IPv6 prefixes.
Address binding
exchange: Both IPv4 and IPv6 addresses.
LSPs: IPv4 over
nexthop interface-1 to R1 and IPv6 over nexthop interface-2 to R1.
Case 3:
Neighbor
Discovery: IPv4 Hellos on interface-1 to R1 and IPv6 Hellos on interface-2 to
R3.
Transport
Connection: IPv4 endpoints with R1 and IPv6 endpoints with R3.
Label binding
exchange: Both IPv4 and IPv6 prefixes to R1 and R3.
Note
Even if all
the three LSRs are dual-stack, traffic from R1 to R3 will not be completely
labeled.
If there
is IPv6 traffic, it is unlabeled from R1 to R2. Labels are imposed only at R2
(although in this specific case implicit null imposition) to R3.
If there
is IPv4 traffic, it is labeled from R1 to R2. But the traffic will go unlabeled
between R2 and R3 given that no IPv4 adjacency exists between R2 and R3.
Address binding
exchange: Both IPv4 and IPv6 addresses to R1 and R3.
LSPs: IPv4 over
nexthop interface-1 to R1 and IPv6 over nexthop interface-2 to R3.
Restrictions
IPv6 support in MPLS
LDP has the following restrictions and constraints:
IPv6 address
family is supported only under default VRF
Implicit enabling
of IPv6 address family is not allowed. It needs explicit enabling.
It is recommended
to configure a routable IPv6
discovery transport
address when only LDP IPv6 is configured without explicitly
specifying a router-id
Features Supported
in LDP IPv6
The following features
are supported in LDP IPv6:
Single-stack
(native IPv6) and dual-stack (IPv4+IPv6) topologies
New operating
modes in LDP:
Native LDP
IPv6
LDP IPv6 over
IPv4 and LDP IPv4 over IPv6 connection endpoints
LDP Hellos
carry optional transport address type length value (TLV) to notify a peer about
TCP or transport connection endpoint. An LSR can include either IPv4 or IPv6
transport address TLV in an IPv4 or IPv6 Hello message. There is no difference
in the TLV format of transport address for IPv4 and IPv6.
Only one
transport connection is established between two discovered peers, whether there
be single address family Hello adjacencies or multi-address family (both IPv4
and IPv6) Hello adjacencies.
In a
dual-stack setup, when LDP has the option to establish transport connection
either using IPv4 endpoints or IPv6 endpoints, IPv6 connection is preferred
over IPv4 connection. If LDP is locally enabled for both IPv4 and IPv6 address
families, every new session is treated as potential dual-stack connection.
Under such circumstances, IPv6 preference is kept in place for maximum fifteen
seconds for the session to establish, after which the LDP tries to establish a
connection with the peer using IPv4. A user can override this default behavior
by specifying the preference for a set of dual-stack peers to use IPv4
transport for the connection. Furthermore, a user may also specify maximum wait
time to wait to establish the preferred transport connection. If the preferred
transport establishment times out, LDP tries to establish connection with other
non-preferred transport address families. This applies to both the cases when
an LSR acts as active side or passive side for the TCP connection.
To override
default IPv6 transport preference for dual-stack cases, use the
mpls ldp neighbor
dual-stack transport-connection prefer ipv4 for-peers command. To
specify the maximum time the preferred address family connection must wait to
establish a connection before resorting to a non-preferred address family, use
the
mpls ldp neighbor
dual-stack transport-connection max-wait command.
Once a
transport connection is established, it is not torn down depending on
preferences. If the address family related to established transport connection
is disabled under LDP, the corresponding transport connection is reset to
reestablish the connection.
For a
single-stack setup, there is no contention; the transport connection uses the
given address family.
LDP Control Plane
is IPv6 aware
LDP IPv6 LSP
forwarding setup
LDP interacts
with LSD in order to setup IPv6 LSP forwarding. The steps involved in this
interaction are:
Label
allocation for an IPv6 prefix is learnt from RIB.
Setup
imposition and label switching forwarding path for given IPv6 prefix by
creating IPv6 forwarding rewrites.
Like LDP
IPv4, rewrite delete and label free operations are performed when a route
disappears or is disallowed under LDP due to label policy.
There is no
new requirement related to MPLS enabling or disabling. LDP also MPLS-enables in
LSD (if not already) any LDP enabled interface, which is in the
UP state for IP4 and/or IPv6 and has IPv4 and/or IPv6
addresses assigned.
In case of
dual-stack LDP, a single Resource-Complete is sent by LDP to LSD once
RIB-Converged notification is received for both IPv4 and IPv6 redistribute
tables.
Distribution of
IPv4 and IPv6 bindings over a single LDP session established over IPv4 or IPv6
LDP Downstream on
Demand
LDP session
protection
LDP session
protection is a feature to protect an IPv6 LDP session. In case of dual-stack
hello adjacencies with a peer, there is only a single targeted hello adjacency
to protect the session. Session protection forms targeted adjacency of address
family same as the transport connection. For IPv6, the target of the session
protection is the remote transport connection endpoint. For IPv4, the target of
the session protection is remote LSR ID.
LDP IGPv6 sync on
IPv6 interface
This feature
lets IGP support LDP IGP Sync feature for IPv6 address family. This means that
Intermediate System-to-Intermediate System (IS-IS) allows IGP under an
interface’s IPv6 address family, whereas OSPFv3 implements it just like
existing support in OSPF for IPv4. When the IGP Sync feature is enabled, LDP
convergence status on an interface is considered by the IGP under the context
of a given address family. This behavior applies to IGP Sync for both non-TE as
well as TE tunnel interfaces.
LDP Typed Wildcard
for IPv6 prefix FEC
This feature
adds support for Typed Wildcard for IPv6 Prefix FEC. The support includes:
Being able
to send or receive IPv6 Prefix Typed Wildcard FEC element in label messages.
Respond to
Typed Wildcard Label Requests received from peer by replaying its label
database for IPv6 prefixes.
Make use of
Typed Wildcard Label Requests towards peers to request replay of peer label
database for IPv6 prefixes. For example, on local inbound policy changes.
Label allocation,
advertisement and accept policies for IPv6 prefixes
Local label
assignment and advertisement for IPv6 default-route (::/0)
Session MD5
authentication for IPv6 transport
IPv6 Explicit-Null
label
IPv6 explicit
null label feature support includes:
Advertisement and receipt of IPv6 explicit-null label to and
from peers.
IPv6
explicit-null outgoing label in forwarding setup.
Explicit-null advertisement policy for a set of IPv6 prefixes
and/or set of peers.
Explicit-null configuration change. Change in explicit-null
configuration is handled by first transferring a wildcard withdraw with null
label to peer(s), followed by advertising the appropriate null (implicit or
explicit) label to the peer(s) again. This works without any issue as long as a
single IP address family is enabled. In case of a dual-stack LSR peer, a change
of configuration related to explicit-null advertisement for a given address
family may cause unnecessary mix-up in the other address family.
LDP IPv6 LFA FRR
Local LFA FRR
for IPv6 is supported. However, it is required that the primary and backup
paths are of the same address family type, that is, an IPv4 primary path must
not have an IPv6 backup path.
NSF for LDP IPv6
traffic
Non-stop
forwarding (NSF) support is either provided through LDP NSR or graceful restart
mechanisms.
IGP/LDP NSR for
IPv6
IGP/LDP Graceful
Restart for IPv6
LDP ICCP IPv6
neighbor node
LDP
Inter-Chassis Communication Protocol (ICCP) is supported with IPv6 neighbor
node. ICCP is used as a mechanism for multi-chassis LACP.
SSO/ISSU for LDP
IPv6
MPLS OAM: New
FECs
LSPV supports
two new FECs.
LDP IPv6
Prefix FEC Encoding/Decoding
Label
Switched Path Verification (LSPV) encodes/decodes the LDP IPv6 Prefix FEC.
Prefix is in the network byte order and the trailing bits are to be set to zero
when prefix length is shorter than 128 bits.
Generic IPv6
Prefix FEC Encoding/Decoding
LSPV
encodes/decodes the generic IPv6 Prefix FEC. Prefix is in the network byte
order and the trailing bits are to be set to zero when prefix length is shorter
than 128 bits.
Generic IPv6
FEC is used in addition to the LDP IPv6 FEC. This serves the following primary
purposes:
Allows
user to perform LSP ping and traceroute to verify data plane without involving
control plane of the FEC in echo request and response.
If
support for a new FEC is preferred in the future, the generic FEC can be used
until corresponding control plane is explicitly supported by LSPV.
IPv6 LSR MIB
MPLS OAM LDP
MIBS is extended to support IPv6. All LSR MIB objects that reference an
InSegment prefix and OutSegment next hop address are modified to support IPv6.
LSP ping support
for LDP IPv6
LSP trace-route
support for LDP IPv6
LSP tree-trace
support for LDP IPv6
The following features are
not supported in LDP IPv6:
LDPv6 over TEv4
(traffic engineering)
L2VPN/PW (over
IPv6 LSPs)
L3VPN (over IPv6
LSPs)
LDP auto-config
for IPv6 IGP/Interfaces
LDP ICCP with IPv6
neighbor node
Multicast
extension to LDP (mLDP) for IPv6 FEC with label binding through IPv4 and IPv6
transport
Native IPv4 and
IPv6 L3VPN over LDP IPv6 core
L2VPN signaling
with LDP when the nexthop address is IPv6
IPv6 LDP CSC
Implicit IPv4
Disable
The LDP configuration
model was changed with the introduction of explicit address family enabling
under LDP (VRF) global and LDP (VRF) interfaces. However, in order to support
backward compatibility, the old configuration model was still supported for
default VRF. There was, however, no option to disable the implicitly enabled
IPv4 address family under default VRF's global or interface level.
A new configuration
mpls ldp default-vrf
implicit-ipv4 disable is now available to the user to disable the
implicitly enabled IPv4 address family for the default VRF. The new
configuration provides a step towards migration to new configuration model for
the default VRF that mandates enabling address family explicitly. This means
that if the new option is configured, the user has to explicitly enable IPv4
address family for default VRF global and interface levels. It is recommended
to migrate to this explicitly enabled IPv4 configuration model.
LDP stores label
bindings associated with FEC prefix in its Label Information Base (LIB) [TIB in
Cisco LDP]. An entry in LIB corresponds to a prefix and holds the following
bindings:
Local binding:
Local label assigned for this prefix (which is learnt through local RIB).
Remote bindings:
Array of peer labels (prefix-label bindings received in label mapping message
from peer(s)).
An entry in LIB can
exist due to local binding presence, or due to remote binding(s) presence, or
due to both local and remote bindings presence. The forwarding setup, however,
mandates that local binding be present for a prefix.
Extensions have been
implemented to support IPv6 prefixes for LIB in LDP. For per-address family
convergence or preference reasons, separate or new LIB is implemented to keep
and maintain IPv6 prefixes. In case of dual-stack LDP, LIBv4 is preferred over
LIBv6 wherever possible. For example, during background
housekeeping function, LIBv4 is processed before LIBv6.
IPv6 Address
Bindings
LDP needs to maintain
IPv6 address database for local and peer interface addresses. The IPv4 address
module for local/peer addresses is extended to keep IPv4/IPv6 addresses in
their respective databases, much like LIB database. In case of a dual-stack
LDP, IPv4 local address database function is preferred over IPv6 local address
database function where ever possible.
Default Transport
Address
LDP computes default
local transport address for IPv6 from its IPv6 interface or address database by
picking the lowest operational loopback interface with global unicast IPv6
address. This means that any change in this loopback state or address, flaps or
changes the default transport address for IPv6 and may cause session flaps
using such an address as transport endpoint. For example, if a session is
currently active on Loopback2 as during it's inception it was the lowest
loopback with an IPv6 address, and a lower loopback, Loopback0, is configured
with an IPv6 address, the session does not flap. However, if it does flap, the
next time the session is attempted, Loopback0 is used.
The session flaps when
configuring discovery transport address explicitly.
Use the
discovery
transport-address command under the LDP address family submode to
specify the global transport address for IPv4 or IPv6.
It is recommended to
configure global transport-address for IPv6 address family to avoid a
potentially unstable default transport address.
LDP Control Plane:
Bindings Advertisement
LDP base specification
allows exchange of IPv4/IPv6 bindings (address/label) on an established
session. When both IPv4 and IPv6 address families are enabled under LDP, LDP
distributes address/label bindings for both address families to its established
peer according to local policies. Following are a few significant points
pertaining to bindings support for IPv6:
LDP
allocates/advertises local label bindings for link-local IPv6 address prefixes.
If received, such FEC bindings are ignored.
LDP sends only the
Prefix FEC of the single address family type in a FEC TLV and not include both.
If such a FEC binding is received, the entire message is ignored.
LDP sends only the
addresses belonging to same address family in a single address list TLV (in
address or address withdraw message).
If an address family
is not enabled on receiving LSR, LDP discards any bindings received from
peer(s) for the address family. This means that when address family is enabled,
LDP needs to reset existing sessions with the peers in order to re-learn the
discarded bindings. The implementation is optimized to reset only those
sessions which were previously known to be dual-stack and had sent bindings for
both address families.
LSP Mapping
LDP uses IPv6
adjacency information instead of IP address to map an IPv6 link-local nexthop
to an LDP peer.
In addition to other
usual checks before using a label from nexthop LDP peer, LDP uses the nexthop
label for a prefix of a given address family, if there are one or more LDP
hello adjacencies of the same address family type established with the peer.
Label
Policies
LDP allows a user to
configure label policies for allocation, acceptance, receipt, and advertisement
of labels for the given prefixes.
Following are the
significant points pertaining to the IPv6 support for label policies:
Label policies and
their configurations are allowed under address family IPv6.
Any policy that
specifies prefix or a set of prefixes through an ACL, supports both IPv4 and
IPv6 variants for address(s) or ACLs.
Any policy that
specifies peer address or set of peer addresses through an ACL, supports both
IPv4 and IPv6 variant for peer address(s) or ACL.
Any policy that
specifies the peer’s LSR ID in a peer ACL continues to take IPv4 ACL based
policy irrespective of the feature configuration.
IS-IS
Intermediate
System-to-Intermediate System (IS-IS) is an Interior Gateway Protocol (IGP)
that advertises link-state information throughout the network to create a
picture of the network topology. IPv6 IS-IS extends the address families
supported by IS-IS to include IPv6, in addition to IPv4.
Previously, IS-IS
supported registration of only LDP IPv4 sync status change. This has now been
enhanced to support registration of notifications of LDP IPv6 sync status
change. IS-IS determines the link-metrics to be advertised based on the LDP-IGP
sync status on the IPv4 and IPv6 address families.
IS-IS supports
non-stop forwarding (NSF) by preserving the LDPv6-IGP sync status across high
availability (HA) events of IS-IS process restarts and failover.
IS-IS also supports
LDPv6-IGP sync for LFA-FRR by checking the sync status of the backup interface
(if it is configured with LDP IPv6 sync).
Dual-Stack
Capability TLV
Clear rules are
specified in RFC 5036 to determine transport connection roles in setting up a
TCP connection for single-stack LDP. But RFC 5036 is not clear about dual-stack
LDP, in which an LSR may assume different roles for different address families,
causing issues in establishing LDP sessions.
To ensure a
deterministic transport connection role for the dual-stack LDP, the dual-stack
LSR conveys its transport connection preference in every LDP Hello message.
This preference is encoded in a new TLV (Type Length Value) called the
Dual-Stack Capability TLV. Dual-stack LSR always checks for the presence of the
dual-stack capability TLV in the received LDP Hello messages and takes
appropriate action for establishing or maintaining sessions.
RFC 7552 specifies
more details about updates to LDP for IPv6.
This
field is reserved. It must be set to zero on transmission and ignored on
receipt
MBZ
Must be
zero
Compliance
Check
The compliance check
prevents sessions being formed with prior RFC 7552 implementation of LDP IPv6.
If the dual-stack
capability TLV is not present in the received Hellos and the compliance check
is configured, the local and remote preferences must match to establish a
session. If the preferences do not match, the LDP Hellos are dropped and the
session is not established. Compliance check has therefore been disabled by
default.
Use the command
neighbor dual-stack
tlv-compliance in MPLS LDP configuration to enable the compliance
check.
How to Implement MPLS LDP
A typical MPLS LDP deployment requires coordination among several global
neighbor routers. Various configuration tasks are required to implement MPLS
LDP
:
Configuring LDP
Discovery Parameters
Perform this task to
configure LDP discovery parameters (which may be crucial for LDP operations).
Note
The LDP discovery
mechanism is used to discover or locate neighbor nodes.
In
Cisco IOS XR software, the router ID is specified as an interface IP address.
By default, LDP uses the global router ID (configured by the global router ID
process).
Specifies the
time that a discovered neighbor is kept without receipt of any subsequent hello
messages. The default value for the
seconds
argument is 15 seconds for link hello and 90 seconds for targeted hello
messages.
Selects the
period of time between the transmission of consecutive hello messages. The
default value for the
seconds
argument is 5 seconds for link hello messages and 10 seconds for targeted hello
messages.
Step 6
commit
Step 7
(Optional)
show mpls
ldp
[vrf
vrf-name] parameters
Example:
RP/0/RSP0/CPU0:router# show mpls ldp parameters
RP/0/RSP0/CPU0:router# show mpls ldp vrf red parameters
(Optional)
Displays all the current MPLS LDP parameters.
Displays the
LDP parameters for the specified VRF.
Configure Label Distribution Protocol Targeted Neighbor
LDP session between LSRs that are not directly connected is known as targeted LDP session. For LDP neighbors which are not
directly connected, you must manually configure the LDP neighborship on both the routers.
Configuration Example
This example shows how to configure LDP for non-directly connected routers.
RP/0/RSP0/CPU0:router#show mpls ldp discovery
Wed Nov 28 04:30:31.862 UTC
Local LDP Identifier: 192.0.2.1:0
Discovery Sources:
Targeted Hellos: <<< targeted hellos based session
192.0.2.1 -> 198.51.100.1(active/passive), xmit/recv <<< both transmit and receive of targeted hellos between the neighbors
LDP Id: 198.51.100.1:0
Hold time: 90 sec (local:90 sec, peer:90 sec)
Established: Nov 28 04:19:55.340 (00:10:36 ago)
RP/0/RSP0/CPU0:router#show mpls ldp neigbhor
Wed Nov 28 04:30:38.272 UTC
Peer LDP Identifier: 198.51.100.1:0
TCP connection: 198.51.100.1:0:13183 - 192.0.2.1:646; MD5 on
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 20/20; Downstream-Unsolicited
Up time: 00:10:30
LDP Discovery Sources:
IPv4: (1)
Targeted Hello (192.0.2.1 -> 198.51.100.1, active/passive) <<< targeted LDP based session
IPv6: (0)
Addresses bound to this peer:
IPv4: (4)
198.51.100.1 10.0.0.1 172.16.0.1 192.168.0.1
IPv6: (0)
Configuring LDP
Discovery Over a Link
Perform this task to
configure LDP discovery over a link.
Note
There is no need
to enable LDP globally.
Before you begin
A stable router ID
is required at either end of the link to ensure the link discovery (and session
setup) is successful. If you do not assign a router ID to the routers, the
system will default to the global router ID. Default router IDs are subject to
change and may cause an unstable discovery.
SUMMARY STEPS
configure
mpls
ldp
[vrfvrf-name] router-id
ip-addresslsr-id
interfacetype
interface-path-id
commit
(Optional)
show mpls
ldp discovery
(Optional) show mpls ldp vrfvrf-namediscovery
(Optional) show mpls ldp vrf all discovery summary
(Optional) show mpls ldp vrf all discovery brief
(Optional) show mpls ldp vrf all ipv4 discovery summary
In
Cisco IOS XR software,
the router ID is specified as an interface name or IP address. By default, LDP
uses the global router ID (configured by the global router ID process).
Enters interface
configuration mode for the LDP protocol. Interface type must be Tunnel-TE.
Step 5
commit
Step 6
(Optional)
show mpls
ldp discovery
Example:
RP/0/RSP0/CPU0:router# show mpls ldp discovery
(Optional)
Displays the status of the LDP discovery process. This command,
without an interface filter, generates a list of interfaces over which the LDP
discovery process is running. The output information contains the state of the
link (xmt/rcv hellos), local LDP identifier, the discovered peer’s LDP
identifier, and holdtime values.
Step 7
(Optional) show mpls ldp vrfvrf-namediscovery
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf red discovery
(Optional)
Displays the
status of the LDP discovery process for the specified VRF.
Step 8
(Optional) show mpls ldp vrf all discovery summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all discovery summary
(Optional)
Displays the
summarized status of the LDP discovery process for all VRFs.
Step 9
(Optional) show mpls ldp vrf all discovery brief
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all discovery brief
(Optional)
Displays the
brief status of the LDP discovery process for all VRFs.
Step 10
(Optional) show mpls ldp vrf all ipv4 discovery summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all ipv4 discovery summary
(Optional)
Displays the
summarized status of the LDP discovery process for all VRFs for the IPv4
address family.
Step 11
(Optional) show mpls ldp discovery summary all
Example:
RP/0/RSP0/CPU0:router# show mpls ldp discovery summary all
(Optional)
Displays the
aggregate summary across all the LDP discovery processes.
Configuring LDP
Discovery for Active Targeted Hellos
Perform this task to
configure LDP discovery for active targeted hellos.
Note
The active side
for targeted hellos initiates the unicast hello toward a specific destination.
Before you begin
These prerequisites
are required to configure LDP discovery for active targeted hellos:
Stable router ID
is required at either end of the targeted session. If you do not assign a
router ID to the routers, the system will default to the global router ID.
Please note that default router IDs are subject to change and may cause an
unstable discovery.
One or more MPLS
Traffic Engineering tunnels are established between non-directly connected
LSRs.
SUMMARY STEPS
configure
mpls
ldp
[vrfvrf-name] router-id
ip-addresslsr-id
interfacetype
interface-path-id
commit
(Optional)
show mpls
ldp discovery
(Optional) show mpls ldp vrfvrf-namediscovery
(Optional) show mpls ldp vrf all discovery summary
(Optional) show mpls ldp vrf all discovery brief
(Optional) show mpls ldp vrf all ipv4 discovery summary
In
Cisco IOS XR software,
the router ID is specified as an interface name or IP address or LSR ID. By
default, LDP uses the global router ID (configured by global router ID
process).
Enters interface
configuration mode for the LDP protocol.
Step 5
commit
Step 6
(Optional)
show mpls
ldp discovery
Example:
RP/0/RSP0/CPU0:router# show mpls ldp discovery
(Optional)
Displays the status of the LDP discovery process. This command,
without an interface filter, generates a list of interfaces over which the LDP
discovery process is running. The output information contains the state of the
link (xmt/rcv hellos), local LDP identifier, the discovered peer’s LDP
identifier, and holdtime values.
Step 7
(Optional) show mpls ldp vrfvrf-namediscovery
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf red discovery
(Optional)
Displays the
status of the LDP discovery process for the specified VRF.
Step 8
(Optional) show mpls ldp vrf all discovery summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all discovery summary
(Optional)
Displays the
summarized status of the LDP discovery process for all VRFs.
Step 9
(Optional) show mpls ldp vrf all discovery brief
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all discovery brief
(Optional)
Displays the
brief status of the LDP discovery process for all VRFs.
Step 10
(Optional) show mpls ldp vrf all ipv4 discovery summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all ipv4 discovery summary
(Optional)
Displays the
summarized status of the LDP discovery process for all VRFs for the IPv4
address family.
Step 11
(Optional) show mpls ldp discovery summary all
Example:
RP/0/RSP0/CPU0:router# show mpls ldp discovery summary all
(Optional)
Displays the
aggregate summary across all the LDP discovery processes.
Configuring LDP
Discovery for Passive Targeted Hellos
Perform this task to
configure LDP discovery for passive targeted hellos.
A passive side for
targeted hello is the destination router (tunnel tail), which passively waits
for an incoming hello message. Because targeted hellos are unicast, the passive
side waits for an incoming hello message to respond with hello toward its
discovered neighbor.
Before you begin
Stable router ID is
required at either end of the link to ensure that the link discovery (and
session setup) is successful. If you do not assign a router ID to the routers,
the system defaults to the global router ID. Default router IDs are subject to
change and may cause an unstable discovery.
SUMMARY STEPS
configure
mpls
ldp
[vrfvrf-name] router-id
ip-addresslsr-id
discovery
targeted-hello accept
commit
(Optional)
show mpls
ldp discovery
(Optional) show mpls ldp vrfvrf-namediscovery
(Optional) show mpls ldp vrf all discovery summary
(Optional) show mpls ldp vrf all discovery brief
(Optional) show mpls ldp vrf all ipv4 discovery summary
In
Cisco IOS XR software,
the router ID is specified as an interface IP address or LSR ID. By default,
LDP uses the global router ID (configured by global router ID process).
Directs the
system to accept targeted hello messages from any source and activates passive
mode on the LSR for targeted hello acceptance.
This command
is executed on the receiver node (with respect to a given MPLS TE tunnel).
You can
control the targeted-hello acceptance using the
discovery targeted-hello accept command.
Step 5
commit
Step 6
(Optional)
show mpls
ldp discovery
Example:
RP/0/RSP0/CPU0:router# show mpls ldp discovery
(Optional)
Displays the status of the LDP discovery process. This command,
without an interface filter, generates a list of interfaces over which the LDP
discovery process is running. The output information contains the state of the
link (xmt/rcv hellos), local LDP identifier, the discovered peer’s LDP
identifier, and holdtime values.
Step 7
(Optional) show mpls ldp vrfvrf-namediscovery
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf red discovery
(Optional)
Displays the
status of the LDP discovery process for the specified VRF.
Step 8
(Optional) show mpls ldp vrf all discovery summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all discovery summary
(Optional)
Displays the
summarized status of the LDP discovery process for all VRFs.
Step 9
(Optional) show mpls ldp vrf all discovery brief
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all discovery brief
(Optional)
Displays the
brief status of the LDP discovery process for all VRFs.
Step 10
(Optional) show mpls ldp vrf all ipv4 discovery summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all ipv4 discovery summary
(Optional)
Displays the
summarized status of the LDP discovery process for all VRFs for the IPv4
address family.
Step 11
(Optional) show mpls ldp discovery summary all
Example:
RP/0/RSP0/CPU0:router# show mpls ldp discovery summary all
(Optional)
Displays the
aggregate summary across all the LDP discovery processes.
Configuring Label
Advertisement Control (Outbound Filtering)
Perform this task to
configure label advertisement (outbound filtering).
By default, a label
switched router (LSR) advertises all incoming label prefixes to each
neighboring router. You can control the exchange of label binding information
using the
mpls ldp label
advertise command. Using the optional keywords, you can advertise
selective prefixes to all neighbors, advertise selective prefixes to defined
neighbors, or disable label advertisement to all peers for all prefixes.
Note
Prefixes and peers
advertised selectively are defined in the access list.
Before you begin
Before configuring
label advertisement, enable LDP and configure an access list.
SUMMARY STEPS
configure
mpls
ldp
[vrf
vrf-name]
address-family
{
ipv4 | ipv6}
label local advertise
[toldp-idforprefix-acl |
interfacetype
interface-path-id]
label local advertise
[toldp-idforprefix-acl |
interfacetype
interface-path-id]
Example:
RP/0/RSP0/CPU0:router(config-ldp-af)# label local advertise to 1.1.1.1:0 for pfx_acl1
RP/0/RSP0/CPU0:router(config-ldp-af)# label local advertise interface POS 0/1/0/0
Configures
outbound label advertisement control by specifying one of the following
options:
interface
Specifies an interface for label advertisement.
toldp-id
forprefix-acl
Specifies neighbors to advertise and receive label
advertisements.
Step 5
commit
Setting Up LDP
Neighbors
Perform this task to
set up LDP neighbors.
Before you begin
Stable router ID is
required at either end of the link to ensure the link discovery (and session
setup) is successful. If you do not assign a router ID to the routers, the
system will default to the global router ID. Default router IDs are subject to
change and may cause an unstable discovery.
Provides an
alternative transport address for a TCP connection.
Default
transport address advertised by an LSR (for TCP connections) to its peer is the
router ID.
Transport
address configuration is applied for a given LDP-enabled interface.
If the
interface version of the command is used, the configured IP address of the
interface is passed to its neighbors as the transport address.
Step 6
exit
Example:
RP/0/RSP0/CPU0:router(config-ldp-if)# exit
Exits the
current configuration mode.
Step 7
holdtimeseconds
Example:
RP/0/RSP0/CPU0:router(config-ldp)# holdtime 30
Changes the time
for which an LDP session is maintained in the absence of LDP messages from the
peer.
Outgoing
keepalive interval is adjusted accordingly (to make three keepalives in a given
holdtime) with a change in session holdtime value.
Session
holdtime is also exchanged when the session is established.
In this
example holdtime is set to 30 seconds, which causes the peer session to timeout
in 30 seconds, as well as transmitting outgoing keepalive messages toward the
peer every 10 seconds.
Configures
password authentication (using the TCP MD5 option) for a given neighbor.
Step 9
backoffinitial
maximum
Example:
RP/0/RSP0/CPU0:router(config-ldp)# backoff 10 20
Configures the
parameters for the LDP backoff mechanism. The LDP backoff mechanism prevents
two incompatibly configured LSRs from engaging in an unthrottled sequence of
session setup failures. If a session setup attempt fails due to such
incompatibility, each LSR delays its next attempt (backs off), increasing the
delay exponentially with each successive failure until the maximum backoff
delay is reached.
Step 10
commit
Step 11
(Optional)
show mpls
ldp neighbor
Example:
RP/0/RSP0/CPU0:router# show mpls ldp neighbor
(Optional)
Displays the status of the LDP session with its neighbors. This
command can be run with various filters as well as with the brief option.
Step 12
(Optional) show mpls ldp vrfvrf-nameneighbor
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf red neighbor
(Optional)
Displays the
status of the LDP session with its neighbors for the specified VRF. This
command can be run with the brief option.
Step 13
(Optional) show mpls ldp vrf all neighbor brief
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all neighbor brief
(Optional)
Displays the
brief LDP session neighbor information for all VRFs.
Step 14
(Optional) clear mpls ldp neighbor
Example:
RP/0/RSP0/CPU0:router# clear mpls ldp neighbor
(Optional)
Resets an LDP
session.
Step 15
(Optional) clear mpls ldp vrf all neighbor
Example:
RP/0/RSP0/CPU0:router# clear mpls ldp vrf all neighbor
(Optional)
Resets LDP
session for all VRFs.
Step 16
(Optional) clear mpls ldp vrfvrf-nameneighbor
Example:
RP/0/RSP0/CPU0:router# clear mpls ldp vrf red neighbor
(Optional)
Resets LDP
session for the specified VRF.
Setting Up LDP
Forwarding
Perform this task to
set up LDP forwarding.
By default, the LDP
control plane implements the penultimate hop popping (PHOP) mechanism. The PHOP
mechanism requires that label switched routers use the implicit-null label as a
local label for the given Forwarding Equivalence Class (FEC) for which LSR is
the penultimate hop. Although PHOP has certain advantages, it may be required
to extend LSP up to the ultimate hop under certain circumstances (for example,
to propagate MPL QoS). This is done using a special local label (explicit-null)
advertised to the peers after which the peers use this label when forwarding
traffic toward the ultimate hop (egress LSR).
Before you begin
Stable router ID is
required at either end of the link to ensure the link discovery (and session
setup) is successful. If you do not assign a router ID to the routers, the
system will default to the global router ID. Default router IDs are subject to
change and may cause an unstable discovery.
SUMMARY STEPS
configure
mpls
ldp
[vrfvrf-name]address-family
{ipv4 |
ipv6 }
label local advertise
explicit-null
commit
(Optional)
show mpls
ldp forwarding
(Optional) show mpls ldp vrf all forwarding
(Optional) show mpls ldp vrf all forwarding summary
(Optional) show mpls ldp vrfvrf-nameipv4
forwarding
RP/0/RSP0/CPU0:router(config-ldp-af)# label local advertise explicit-null
Causes a router
to advertise an explicit null label in situations where it normally advertises
an implicit null label (for example, to enable an ultimate-hop disposition
instead of PHOP).
Step 5
commit
Step 6
(Optional)
show mpls
ldp forwarding
Example:
RP/0/RSP0/CPU0:router# show mpls ldp forwarding
(Optional)
Displays the MPLS LDP view of installed forwarding states
(rewrites).
Note
For local
labels, only up to 12000 rewrites are supported. If the rewrites exceed this
limit, MPLS LSD or MPLS LDP or both the processes may crash.
Step 7
(Optional) show mpls ldp vrf all forwarding
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all forwarding
(Optional)
Displays the
forwarding setup information of all LDP configured VRFs.
Step 8
(Optional) show mpls ldp vrf all forwarding summary
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all forwarding summary
(Optional)
Displays the
forwarding setup summary of all LDP configured VRFs.
Step 9
(Optional) show mpls ldp vrfvrf-nameipv4
forwarding
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf red ipv4 forwarding
(Optional)
Displays the
forwarding setup information for the specified VRF for IPv4.
Step 10
(Optional) show mpls ldp forwarding summary all
Example:
RP/0/RSP0/CPU0:router# show mpls ldp forwarding summary all
(Optional)
Displays the
aggregate summary across LDP processes and all VRFs.
When you issue the
end command,
the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
Entering
yes saves configuration changes to the running configuration file, exits
the configuration session, and returns the router to EXEC mode.
Entering
no exits the configuration session
and returns the router to EXEC mode without committing the configuration
changes.
Entering
cancel leaves the router in the
current configuration session without exiting or committing the configuration
changes.
Use the
commit command
to save the configuration changes to the running configuration file and remain
within the configuration session.
Setting Up LDP NSF
Using Graceful Restart
Perform this task to
set up NSF using LDP graceful restart.
LDP graceful restart
is a way to enable NSF for LDP. The correct way to set up NSF using LDP
graceful restart is to bring up LDP neighbors (link or targeted) with
additional configuration related to graceful restart.
Before you begin
Stable router ID is
required at either end of the link to ensure the link discovery (and session
setup) is successful. If you do not assign a router ID to the routers, the
system will default to the global router ID. Default router IDs are subject to
change and may cause an unstable discovery.
SUMMARY STEPS
configure
mpls
ldp
interfacetype
interface-path-id
exit
graceful-restart
graceful-restart
forwarding-state-holdtimeseconds
graceful-restart
reconnect-timeoutseconds
commit
(Optional)
show mpls ldp
[vrf
vrf-name] parameters
(Optional)
show mpls
ldp neighbor
(Optional)
show mpls
ldp graceful-restart
(Optional) show mpls ldp vrf all graceful-restart
(Optional) show mpls ldp vrfvrf-namegraceful-restart
Specifies the length of time that forwarding can keep
LDP-installed forwarding states and rewrites, and specifies wh en the LDP
control plane restarts.
After
restart of the control plane, when the forwarding state holdtime expires, any
previously installed LDP forwarding state or rewrite that is not yet refreshed
is deleted from the forwarding.
Recovery
time sent after restart is computed as the current remaining value of the
forwarding state hold timer.
Specifies the length of time a neighbor waits before restarting
the node to reconnect before declaring an earlier graceful restart session as
down. This command is used to start a timer on the peer (upon a neighbor
restart). This timer is referred to as
Neighbor
Liveness timer.
Step 8
commit
Step 9
(Optional)
show mpls ldp
[vrf
vrf-name] parameters
Example:
RP/0/RSP0/CPU0:router# show mpls ldp parameters
RP/0/RSP0/CPU0:router# show mpls ldp vrf red parameters
(Optional)
Displays all the current MPLS LDP
parameters.
Displays the LDP parameters
for the specified VRF.
Step 10
(Optional)
show mpls
ldp neighbor
Example:
RP/0/RSP0/CPU0:router# show mpls ldp neighbor
(Optional)
Displays the status of the LDP session with its neighbors. This
command can be run with various filters as well as with the brief option.
Step 11
(Optional)
show mpls
ldp graceful-restart
Example:
RP/0/RSP0/CPU0:router# show mpls ldp graceful-restart
(Optional)
Displays the status of the LDP graceful restart feature. The
output of this command not only shows states of different graceful restart
timers, but also a list of graceful restart neighbors, their state, and
reconnect count.
Step 12
(Optional) show mpls ldp vrf all graceful-restart
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf all graceful-restart
(Optional)
Displays the
status of the LDP graceful restart for all VRFs.
Step 13
(Optional) show mpls ldp vrfvrf-namegraceful-restart
Example:
RP/0/RSP0/CPU0:router# show mpls ldp vrf red graceful-restart
(Optional)
Displays the
status of the LDP graceful restart for the specified VRF.
Configuring Label
Acceptance Control (Inbound Filtering)
Perform this task to
configure LDP inbound label filtering.
Note
By default, there
is no inbound label filtering performed by LDP and thus an LSR accepts (and
retains) all remote label bindings from all peers.
SUMMARY STEPS
configure
mpls
ldp
label accept
for
prefix-acl from
ip-address
[vrf
vrf-name]
address-family
{
ipv4 | ipv6}
label remote acceptfromldp-idforprefix-acl
commit
DETAILED STEPS
Command or Action
Purpose
Step 1
configure
Step 2
mpls
ldp
Example:
RP/0/RSP0/CPU0:router(config)# mpls ldp
Enters the MPLS
LDP configuration mode.
Step 3
label accept
for
prefix-acl from
ip-address
Example:
RP/0/RSP0/CPU0:router(config-ldp)# label accept for pfx_acl_1 from 192.168.1.1RP/0/RSP0/CPU0:router(config-ldp)# label accept for pfx_acl_2 from 192.168.2.2
Configures
inbound label acceptance for prefixes specified by prefix-acl from neighbor (as
specified by its IP address).
Enables LDP auto-configuration on the specified interface. The LDP
configurable limit for maximum number of interfaces does not apply to IGP
auto-config interfaces.
Step 6
commit
Disabling LDP Auto-Configuration
Perform this task to disable IGP auto-configuration.
You can disable auto-configuration on a per-interface basis. This lets
LDP enable all IGP interfaces except those that are explicitly disabled.
RP/0/RSP0/CPU0:router# clear mpls ldp vrf red nsr statistics neighbor
(Optional)
Resets LDP NSR statistics for the specified VRF for neighbor.
Configuring LDP
Downstream on Demand mode
SUMMARY STEPS
configure
mpls
ldp
[vrfvrf-namesession] downstream-on-demand
commit
DETAILED STEPS
Command or Action
Purpose
Step 1
configure
Step 2
mpls
ldp
Example:
RP/0/RSP0/CPU0:router(config)# mpls ldp
Enters MPLS LDP
configuration mode.
Step 3
[vrfvrf-namesession] downstream-on-demand
Example:
RP/0/RSP0/CPU0:router(config-ldp)# vrf red session downstream-on-demand with ABC
(Optional) Enters downstream on demand label advertisement mode
under the specified non-default VRF.
Enters
downstream on demand label advertisement mode. The ACL contains the list of
peer IDs that are configured for downstream-on-demand mode. When the ACL is
changed or configured, the list of established neighbor is traversed.
Step 4
commit
Setting Up
Implicit-Null-Override Label
Perform this task to
configure implicit-null label for non-egress prefixes.
Allows the
redistribution of BGP routes into an MPLS LDP processes.
Note
Autonomous
system numbers (ASNs) are globally unique identifiers used to identify
autonomous systems (ASs) and enable ASs to exchange exterior routing
information between neighboring ASs. A unique ASN is allocated to each AS for
use in BGP routing. ASNs are encoded as 2-byte numbers and 4-byte numbers in
BGP.
Step 4
end or
commit
When you issue the
end command,
the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
Entering
yes saves configuration changes to the running configuration file, exits
the configuration session, and returns the router to EXEC mode.
Entering
no exits the configuration session
and returns the router to EXEC mode without committing the configuration
changes.
Entering
cancel leaves the router in the
current configuration session without exiting or committing the configuration
changes.
Use the
commit command
to save the configuration changes to the running configuration file and remain
within the configuration session.
Step 5
show run
mpls ldp
Example:
RP/0/RSP0/CPU0:router# show run mpls ldp
Displays
information about the redistributed route information.
Enabling
MLDP
Perform this task to enable
Multicast Label Distribution Protocol (MLDP) in MPLS LDP.
The LDP configuration model is
extended to introduce IPv6 as an option under the address family submodes that
reside under LDP global and interface configurations. Address family IPv6 is
available as a submode under LDP global, LDP VRF global and interface
configurations. LDP IPv6 is supported only under default VRF.
Enabling LDP IPv6
Native
Perform this task to
enable LDP IPv6 native under LDP.
The user must enable
IPv6 address family under LDP submodes.