BGP Case Studies

MPLS Configuration Guide
for E-Series ExaScale

Version 8.3.1.0 December 21, 2009
Copyright 2009 Force10 Networks
All rights reserved. Printed in the USA. January 2009.
Force10 Networks® reserves the right to change, modify, revise this publication without notice.
Trademarks
Force10 Networks® and E-Series® are registered trademarks of Force10 Networks, Inc. Force10, the Force10 logo, E1200, E600, E600i,
E300, EtherScale, TeraScale, FTOS, C-Series, and S-Series are trademarks of Force10 Networks, Inc. All other brand and product names are
registered trademarks or trademarks of their respective holders.
Statement of Conditions
In the interest of improving internal design, operational function, and/or reliability, Force10 Networks reserves the right to make changes to
products described in this document without notice. Force10 Networks does not assume any liability that may occur due to the use or
application of the product(s) described herein.
New Features
Label Distribution Protocol

• Global Label Space—A per-interface label space exists when an LSR binds a label to more than one
FEC and distributes each binding to a different system connected to it by a point-to-point link. Because
of the point-to-point connection, the LSR can discern which FEC a label represents based on the
ingress interface. A per-platform label space exists when all of the binding created by the system are
unique. Only per-platform label space is available on FTOS. See Creating Labels on page 53.
• Unsolicited Downstream—LDP has two label advertisement modes. In Downstream-on-Demand
mode, an LSR advertises a label mapping only upon request from the upstream neighbor. In
Unsolicited Downstream mode, an LSR advertises its label mappings without request. Only
Unsolicited Downstream is available on FTOS. See Label Advertisement Modes on page 55.
• Liberal Label Retention—LDP has two methods for deciding when to retain and discard received
labels. In Conservative Label Retention mode, an LSR retains label mappings only if they will be used
to forward packets. In Liberal Label Retention mode, an LSR retains every label mapping received
from a peer. Only Liberal Label Retention is available on FTOS. See Label Retention on page 56.
• Ordered LSP Control—LDP has two methods for deciding when to create a label. In Independent
Label Distribution Control mode, an LSR, when it recognizes an FEC, binds a label to it, and
distributes it. In Ordered Label Distribution Control mode, an LSR binds a label to an FEC only if it is
the egress LSR or if it has received a binding for an FEC from its next hop. See Label Control Modes
on page 54.
• Neighbor Discovery—Periodic Discovery Hellos are sent out of every interface on which LDP is
enabled, and neighboring LSRs for peerships. See Enable LDP on page 65.
• LDP MIB—FTOS supports the LDP MIB (RFC3815). See Label Distribution Protocol MIB on
page 105.
• LDP Router Identifier—The router ID is an IP address that identifies the LSR and is used to decide
whether the local or remote LSR is active. The LSR with the highest IP address becomes the active
LSR for session initialization. The default router ID is the IP address of the interface that originated the
hello. See Change the LSR Router ID on page 65.
• Discovery Holdtime—Discovery Hellos are broadcast to discover new peers and by default are sent
every 15 seconds. The holdtime for Discovery Hellos is different from the holdtime for Link Hellos.
See Change the Holdtimes on page 65.
• Session Holdtime—The holdtime for Link and Targeted Hellos is the interval at which hellos are sent
to peers to keep the adjacency alive. The FTOS default for both holdtimes is 180 seconds. See Change
the Holdtimes on page 65.
• Penultimate Hop Popping—FTOS performs penultimate hop popping (PHP) by default. FTOS binds
an “Implicit Null” label to FECs for which it is the egress LSR, and distributes the label upstream. For
those FECs, the upstream neighbor removes the current top label, rather than swapping it. This relieves
the egress LSR of having to perform two lookups, one for the top label which it will remove after
discovering it is the egress, and another for the new top label. See Reserved Labels—Penultimate Hop
Popping on page 64.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 3
• Control Label Advertisement—Change the label distribution mode from Ordered Control, which is
the default, to Independent Control. A mode change triggers an LDP re-init, which results in recycling
all sessions and flushing all learned label bindings. See Change the Label Distribution Mode on
page 66.
• Inbound Label Binding Filtering—Choose the labels that an LSR will accept from a neighbor. See
Filter Incoming Label Bindings on page 67.
• LDP Show and Debug Commands— Display bindings, discoveries, interfaces, neighbors, and
parameters using the commands under the show mpls ldp command tree. Display binding, error,
event, and routing events and address, hello, init, keepalive, label and notification messages using the
commands under the debug mpls ldp command tree. See LDP show and debug Commands on
page 69.
• Log Neighbor Changes— The LDP session initialization state machine consists of five possible
states. The system reaches operational state when a TCP connection is established, LDP parameters
have been negotiated, and keepalives are being periodically transmitted. Log a state change whenever
a neighbor transitions to or from operational state. See Manage and Monitor your LDP Configuration
on page 68.
• Clear Sessions and Counters—Clear LDP sessions for a specified neighbor or all neighbors using the
command clear mpls ldp neighbor {ip-address | *}. Clear LDP statistics for a specified neighbor or all
neighbors using the command clear mpls ldp statistics neighbor {ip-address | *}. See Clear Sessions
and Counters on page 69.
• MD5 Authentication—MD5 Authentication is a method that each LSR may use to authenticates its
peer LSRs. Each LSR stores the MD5 password, and only after password verification during the TCP
handshake is the TCP session established. See MD5 Authentication on page 67.
Constrained Shortest Path First

• Admin Group Alias—An admin group is a group of resources, in this case, links, that have the same
characteristics (or colors); the characteristics that are significant are decided by the administrator.
Admin groups are advertised via IGP. Create an admin group using a mnemonic character string and
assign interfaces and tunnels to it. See Resource Class Attribute on page 28.
• Administrative Weight—Administrative Weight is an administratively assigned metric for an
interface participating in IGP traffic engineering. It is advertised by IGPs and overrides the TE metric
for CSPF computation. See Administrative Weight on page 33.
• Explicit Path IP Address Exclusion—You can direct CSPF to exclude one or more addresses when
selecting a path. You may exclude addresses only if you have specified no other strict or loose hops in
the explicit path list. See Exlude an Address from an Explicit Route on page 28.
• Explicit Paths with Strict and Loose Hops—There are two types of nodes in an explicit route. A
strict node must be directly connected to the previous hop in the explicit path. A loose node may or
may not be directly connected, and the path between the loose node the previous node is computed by
the IGP. See Explicit Routes on page 27.
• Path Selection by Highest Available Bandwidth or Minimum Hop Count—When the CSPF
algorithm encounters multiple equal cost paths to a particular node, it can either choose the path that
has the highest maximum reservable bandwidth (default) or the path that has the minimum hop count.
See Equal Cost Path Selection on page 33.
4 New Features
• Resource Class— A resource class is a group of resources, in this case, links, that have the same
characteristics (or “colors”). The characteristics that are significant are decided by the administrator.
OSPF-TE provides 32 possible resource classes. See Resource Class Attribute on page 28.
• Verbatim Path Support—You can configure multiple paths for an LSP with the tunnel mpls
path-option command. The paths are configured with sequence numbers so that the most preferred
path is selected. If the preferred path is an explicit path, but CSPF cannot find a path to the tunnel
destination using the explicit path list, the first hop in the explicit path list may be resolved using a
routing table lookup so that RSVP signaling can be performed. See Verbatim Path Support on page 34.
MPLS High Availability

• BFD for RSVP—Bidirectional Forwarding Detection (BFD) is a protocol that is used to detect at
sub-second intervals communication failures between two adjacent systems. It is a simple and
lightweight replacement for existing routing protocol link state detection mechanisms. The purpose of
RSVP-BFD coordination is to detect network failures quickly so Fast Re-route can take place as soon
as possible in case of a link or node failure. Without BFD, the system must wait for the IGP dead time
to expire, which might take seconds. BFD failure detection is sub-second. See BFD for RSVP on
page 46.
• Fast Reroute Link Protection—Fast Reroute RSVP-TE extensions establish backup LSPs for
explicit LSPs. In the event of a link failure, traffic can be re-directed to a backup LSP. Redirection
takes place in milliseconds because the path computation and signaling is completed in advance. See
Protect an LSP from Link Failure on page 40.
• Fast Reroute Node Protection— Traffic can be re-directed to a backup LSP in the event of a node
failure. See Protect an LSP from Node Failure on page 42.
• Fast Reroute Bandwidth Protection—More than one backup tunnel may be configured for an
interface. See RSVP-TE Fast Reroute Extensions on page 39.
• Tunnel Reoptimization Per-Tunnel—Whenever a path or a portion of a path is computed by the IGP,
there is an opportunity to discover better routes. LSP reoptimization is an RSVP-TE extension that
enables the ingress LSP node to request that each node that has a loose next hop recalculate the route to
its next hop in an attempt to discover a better route. You can manually trigger reoptimization for an
individual tunnel. See Configure Tunnel Reoptimization on page 38.
• Tunnel Reoptimization Interval—Periodic reoptimization is enabled by default. You can configure
the frequency of reoptimization. See Configure Tunnel Reoptimization on page 38.
• Tunnel Reoptimization Link-up Trigger—You can the system to reoptimize whenever a new link
comes online in a TE-enabled OSPF or IS-IS area. See Configure Tunnel Reoptimization on page 38.
• Multiple Bypass Tunnels per Interface—You can configure multiple backup tunnels for Fast
Reroute and Path Protection. See RSVP-TE Fast Reroute Extensions on page 39 and Path Protection
on page 49.
• Path Protection—Each primary LSP may be backed up by one or more standby LSPs. Both the
primary and backup LSPs are configured at the head-end LSR. Both are signaled ahead of time on the
control plane. The primary and backup LSPs might have the same constraints, which preserves the
end-to-end tunnel characteristics. See Path Protection on page 49.
• Tunnel Reoptimization Make-Before-Break—Make-before-break Tunnel Rerouting is a method of
rerouting traffic from one LSP to another without disrupting traffic by establishing the new LSP before
tearing down the original. While establishing the new LSP, the old and new LSP share resources for
the links they have in common. Reoptimization uses this technique to switch to an optimal route. See
Make-before-break Tunnel Rerouting on page 38.
• RSVP-TE Graceful Restart Helper Mode—When RSVP-TE Graceful Restart is enabled, Graceful
Restart Helper is also enabled. See RSVP-TE Graceful Restart Helper on page 38.
• RSVP-TE Graceful Restart Recovery Mode—The graceful restart extensions add the ability for an
ingress router to recover Path state and for ingress and transit nodes to recover objects they previously
transmitted. Among the recoverable objects is EXPLICIT_ROUTE and SESSION_ATTRIBUTES.
See RSVP-TE Graceful Restart on page 36.
• Restart and Recovery Time Intervals—Graceful Restart uses two timers. Restart Time is the amount
of time a recovering node requires to bring up RSVP communication after a failure. Recovery Time is
the period after communication is re-established during which the recovering node and neighbor
resynchronize Path state. See Enable RSVP-TE Graceful Restart on page 37.
• MPLS over LAG Interfaces—Link aggregation group (LAG) virtual interfaces support MPLS traffic
engineering tunnels.
• LAG Hashing on MPLS Packets—FTOS includes a default CAM profile and microcode that treats
MPLS packets as follows: when MPLS IP packets are received, hashing is based on the label + IP 5
tuple (source IP address, destination IP address, IP protocol, and source and destination UDP or TCP
port number). If the packet is part of a VPN, hashing is based on the inner and outer labels.
Multi-Protocol Label Switching—Traffic Engineering

• Static Route to Tunnel Mapping—Static routing is one of three methods for mapping a prefix to a
tunnel. See Map Traffic to Tunnels using Static Routes on page 88.
• OSPF-TE and IS-IS-TE Extensions—OSPF-TE Extensions adds a Type 10 LSA to advertise
administrator-defined link attributes. These link attributes are used to create a TE database, separate
from the OSPF link state database, which is used by CSPF to compute constraint-based routes.
Similarly, IS-IS-TE Extensions defines new IS Neighbor and IP Reachability TLVs to add link
characteristics. The link characteristics are encoded in sub-TLVs, an encoding format not used in
standard IS-IS. You can enable MPLS-TE in one or more areas including on ABR LSRs, and a tunnel
may span more than one area. See OSPF—Traffic Engineering on page 84 and IS-IS—Traffic
Engineering on page 87.
• Flooding Thresholds—You can set bandwidth usage values on an interface that when crossed trigger
a TE advertisement from IGPs to propagate this information to neighbors. See OSPF—Traffic
Engineering on page 84 and IS-IS—Traffic Engineering on page 87.
• Periodic Flooding of Link Bandwidth Usage—LSAs are flooded immediately upon a topology
change and when a bandwidth change crosses a threshold value in the up or down direction. You can
configure the periodic-flooding interval. See OSPF—Traffic Engineering on page 84 and IS-IS—
Traffic Engineering on page 87.
6 New Features
• Forwarding Adjacency Per-Tunnel Configuration—A tunnel forwarding adjacency instructs OSPF
or IS-IS to treat the tunnel as a link and as directly connected to the head-end LSR. The head-end IGP
includes the tunnel in its advertisements. While Autoroute is available to only the head-end of a tunnel,
Forwarding Adjacency makes tunnels available to all area routers. The tunnel cost is the same as the
IGP calculated cost for the link. See Enable IGP Forwarding Adjacency on page 91.
• Forwarding Adjacency Hold Timer to Delay Tunnel Down Advertisements— Forwarding
adjacency hold time is the amount of time the local IGP waits before advertising a local tunnel-down
event to IGP neighbors. Delaying the advertisements avoids frequent updates in all routers in an area in
case of tunnel flapping. See Enable IGP Forwarding Adjacency on page 91.
• Autoroute Per-Tunnel Configuration—Autoroute enables OSPF or IS-IS on the head-end to use a
tunnel to reach a destination. The tunnel destination becomes the next hop for its prefix. All traffic
bound for the tunnel destination is routed through the tunnel. The tunnel may also be used for traffic
bound for a destination topologically behind the it if the cost of using it is the lowest compared to other
IGP routes. See Enable IGP Autoroute on page 89.
• Autoroute Absolute, Relative, and Explicit Metrics—The cost of using a tunnel to reach prefixes
beyond it is the tunnel cost plus the IGP link cost from the tunnel destination to the ultimate
destination. You can assign one of three types of metrics to a tunnel. Metric is used to reach the tunnel
destination; beyond the tunnel destination, the IGP metric is used. Absolute Metric is used to reach the
tunnel destination and any destination topologically behind the tunnel. Relative Metric is added or
subtracted from the IGP metric to the tunnel destination; beyond the tunnel destination, the IGP metric
is used. See Enable IGP Autoroute on page 89.
Resource Reservation Protocol—Traffic Engineering

• Global Bandwidth Pools—Global bandwidth pools define the shared amount of interface bandwidth
available for RSVP reservations. By default, FTOS allocates 75% of interface bandwidth for RSVP
purposes. See Specify the Reservable Amount of Interface Bandwidth on page 76.
• Ingress Resource Affinity Check—An ingress resource affinity check looks at the affinity and link
color of an RSVP Path message and verifies that they match the incoming interface. By default, only
the outgoing interface is checked before a Path message is forwarded through it. This feature provides
additional control over what LSPs can pass through an MPLS node. See Resource Class Affinity
Ingress Check on page 32.
• Disable Resource Affinity Object—The disable resource affinity object option disables sending
resource affinity details in RSVP messages. Although RFC 2205 specifies that all MPLS routers
forward a packet unmodified when they do not understand this object, some vendors will reject an
RSVP message containing this attribute. See Disable Resource Affinity on page 32.
• Bandwidth Usage Log at Interface High Watermark—Configure FTOS to log a message when
LSP bandwidth consumption on an interface exceeds 90% of the available RSVP bandwidth on the
interface. See Enable Bandwidth Logging on page 76.
• Refresh Bundling and Reduction—RSVP uses refresh messages to synchronize state and recover
from lost RSVP messages. This method, however, has scaling, reliability, and latency limitations.
Refresh Reduction Extensions address refresh volume and reliability with message bundling,
acknowledgements, and Srefresh messages. See Enable Signaling Refresh Reduction on page 79.
• No-Ack Option—One of the refresh reduction extensions is an acknowledgement object. Each
message sent the ACK_Desired flag is set must be acknowledged using this object. You can choose to
not set this flag in Resv messages; received messages with the flag set are still acknowledged. See
Enable Signaling Refresh Reduction on page 79.
• Configurable Message Refresh Interval—RSVP stores reservations as soft state, which must be
periodically refreshed through the receipt of a matching path or reservation message. The default
refresh period (R) is 30 seconds; unrefreshed state is deleted after the local state lifetime (L) expires.
See Specify the Signaling Refresh Interval on page 79.
• Configurable Refresh Limit—Specify the number of hello packets that must be unacknowledged to
consider the neighbor down. See Enable RSVP Hello Signaling on page 77.
• Graceful-Shutdown—The RSVP graceful shutdown feature provides a user-initiated approach to
shutting down RSVP. By default, graceful shutdown is disabled since a large number of RSVP
sessions may take a long time to shut down, and a session timeout on neighbor routers may be
preferred. See Graceful Shutdown on page 77.
• TTL Check—The TTL Check feature enables checking the time-to-live (TTL) field in the header of
RSVP and IP packets. When enabled, only PATH messages are dropped if the TTL check fails. See
Enable TTL Checking on page 81.
• Bandwidth Holding with RSVP Path Messages—When an LSR receives a Path message indicating
a bandwidth requirement, it earmarks the bandwidth on the interface until a Reservation message is
received. You can configure the amount of time the LSR holds the bandwidth before releasing it for
other reservations in case a reservation is unacceptably delayed or never arrives. See Bandwidth
Holding for Path Messages on page 81.
Tunnel Management
• Tunnel Attributes: Bandwidth—Specify a tunnel bandwidth requirement. If none is configured then
the tunnel is assumed to have no specific bandwidth requirement.
• Tunnel Attributes: Multiple Path Options with Priority—Configure an ordered set of
traffic-engineering options, including the verbatim path option to skip CSPF computation. Path options
with the lowest sequence numbers are preferred.
• Tunnel Attributes: Record Route—Include the RECORD_ROUTE (RRO) object in Path messages
and Resv messages, which collects a list of nodes in the path to the tunnel destination. See Enable
Record Route on page 77.
• Tunnel Attributes: Setup and Hold Priorities—Setup and hold priorities are used when determining
whether a particular tunnel can receive or hold on to a bandwidth reservation. See Session Attributes
on page 28.
• Retry Interval—The retry interval sets the time, in seconds, between attempts to establish an LSP.
This feature is useful in cases when the primary LSP of a tunnel cannot be established; the primary
LSP is up, but its corresponding standby LSP is not up; or a make-before-break LSP is attempted due
to a resource change or reoptimization to determine the time interval between retries. See LSP Retry
Interval on page 51.
• Pre-Signaled Standby LSP Support—Every path option can be configured with a standby path
option that will be signaled when the primary LSP is established. If the primary goes down due to a
RSVP signaling failure, traffic fails over to standby. See Path Protection on page 49.
8 New Features
MPLS QoS
• MPLS-EXP Marking using Class Maps—create a class map match against the incoming DSCP
value and map the value to the MPLS-EXP bit for MPLS marking. See MPLS-EXP Marking using
Class Maps on page 71.
• MPLS-EXP Marking using QoS Policies—create a QoS policy to match against the incoming DSCP
value and map the value to the MPLS-EXP bit for MPLS marking. See MPLS-EXP Marking using
Qos Policies on page 72.
• MPLS-EXP Propagation with PHP—By default, MPLS-EXP is propagated from the top label to the
next label or to the DSCP value. Disable this behavior by entering no mpls ip propagate-exp from
CONFIGURATION mode. See Propagating MPLS-EXP when Penultimate Hop Popping on page 72.
• Explicit Null—The Explicit-Null label alerts the Egress LSR that it is the egress so that it can
immediately remove the top label, a process called Ultimate-Hop Popping. Ultimate-hop popping
ensures that any packets traversing an MPLS network include a label so that Class of Service is
consistent across the entire LSP. See Advertising Explicit-Null on page 73.
• Short-Pipe and Uniform Models—FTOS supports both the short-pipe model and the uniform model
for differentiated services with MPLS. The uniform model is the default; the IP packet DSCP value is
propagated to the MPLS experimental bits field. Optionally, the set-dscp command in an input policy
map can be used to mark the EXP bit field. Setting the DSCP value also sets the EXP bit value; there is
no separate command to set only the EXP bit. See Quality of Service on page 22.
MPLS ECMP
• 16 ECMPs with MPLS—The FTOS implementation of MPLS ECMP requires that the ECMP
number be a power of 2. For example, if 5 ECMPs are available, 8 ECMPs are written into hardware -
12345123. To ensure an even distribution of traffic, a bit mask, based on the number of ECMP entries,
is used for CAM entry matching. See MPLS ECMP on page 9.
MPLS Monitoring and Network Management

• MPLS Ping—The MPLS ping command provides a means to check MPLS LSP connectivity. See
MPLS ping and traceroute on page 95.
• LDP Ping—Ping an LDP prefix. See MPLS ping and traceroute on page 95.
• MPLS Traceroute—The MPLS traceroute command provides a means to discover MPLS LSP routes
that packets actually take when traveling to their destinations. See MPLS ping and traceroute on
page 95.
• LDP Traceroute—Trace the route to an LDP prefix. See MPLS ping and traceroute on page 95.
• No Propagate TTL—Disabling TTL propagation changes how ingress and egress LSR nodes read
and process the TTL value in a label. A label must have a value in the TTL field. By default, an ingress
LSR reads the TTL field in the IP header of the incoming packet, decrements it by 1, and copies what
is left into the TTL field of the MPLS header. Core LSRs forward the packet if the TTL value in the
uppermost label is not 0. With the no mpls ip propagate-ttl command, the behavior changes such that
the IP header TTL does not reflect the hops taken across the MPLS core; and the routers in the MPLS
core network do not appear in the traceroute information. See Disable TTL Propagation on page 104.
• LSR MIB—The LSR MIB, based on RFC 3813, MPLS-LSR-STD-MIB, provides information on the
status, character, and performance of MPLS-capable interfaces on the LSR, incoming MPLS segments
(labels) at an LSR and their associated parameters, and outgoing segments at an LSR and their
associated parameters. See Label Switch Router MIB on page 105.
• TE MIB—The Traffic Engineering (TE) MIB, defined in 3812, provides SNMP OIDs equivalent to
the fields in show mpls traffic-eng tunnels. Use the TE MIB to view display status at the head-end,
information on traffic flows on the tunnels, TE parameters, and MPLS TE tunnel routes, including the
configured route, the Interior Gateway Protocol (IGP) calculated route, and the actual route traversed.
The mplsTunnelTable, mplsTunnelResourceTable, mplsTunnelHopTable, mplsTunnelARHopTable,
and mplsTunnelCHopTable tables are supported. See Traffic Engineering MIB on page 110.
10 New Features
Contents
New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Constrained Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
MPLS High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Multi-Protocol Label Switching—Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Resource Reservation Protocol—Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Tunnel Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
MPLS QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
MPLS ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
MPLS Monitoring and Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 1
Multiprotocol Label Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
MPLS packet header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

TTL handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
MTU discovery and packet fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
MPLS components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
MPLS labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
MPLS label swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Label Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Content Addressable Memory (CAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Resource Reservation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 2
MPLS CAM Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
CAM Profile and CAM Usage for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Microcodes for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Chapter 3
Constrained Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Explicit Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Exlude an Address from an Explicit Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Session Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Resource Class Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Resource Class Affinity Ingress Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Disable Resource Affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Setup and Holding Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Equal Cost Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Administrative Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Verbatim Path Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 4
MPLS High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
RSVP-TE Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Node Fault Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
RSVP-TE Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Enable RSVP-TE Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
RSVP-TE Graceful Restart Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Tunnel Reoptimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Make-before-break Tunnel Rerouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Configure Tunnel Reoptimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
RSVP-TE Fast Reroute Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Protect an LSP from Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Protect an LSP from Node Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Protect the LSP Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
BFD for RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Enable BFD for RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Path Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
LSP Retry Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
MPLS on LAGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapter 5
Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
When do LSRs Create Labels? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Label Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Label Advertisement Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Label Distribution Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Label Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
LDP Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
LDP Protocol Data Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Peering Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Label Distribution Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12 Contents
Reserved Labels—Penultimate Hop Popping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Configure Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Enable LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Change the LSR Router ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Change the Holdtimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Change the Label Distribution Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Direct the Flow of Label Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Filter Incoming Label Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Manage and Monitor your LDP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Log Neighbor Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Clear Sessions and Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
LDP show and debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Chapter 6
MPLS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
MPLS-EXP Marking using Class Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

MPLS-EXP Marking using Qos Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Propagating MPLS-EXP when Penultimate Hop Popping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Advertising Explicit-Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Chapter 7
RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Configure RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Related Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Enable RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Specify the Reservable Amount of Interface Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Enable Bandwidth Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Graceful Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Enable Record Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Enable RSVP Hello Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Specify the Signaling Refresh Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Enable Signaling Refresh Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Bandwidth Holding for Path Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Enable TTL Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 8
MPLS Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Create a Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Allocate Bandwidth to a Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
OSPF—Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Enable MPLS-TE in an OSPF Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Configure Bandwidth Usage Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
IS-IS—Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Route Traffic though Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Map Traffic to Tunnels using Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Enable IGP Autoroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Enable IGP Forwarding Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapter 9
MPLS System Management and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
MPLS ping and traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
traffic-eng ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
traffic-eng traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
ldp ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
ldp traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
FTOS-supported-Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Disable TTL Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 10
MPLS MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Label Distribution Protocol MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Label Switch Router MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Traffic Engineering MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
mplsTunnelTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
TE Scalars MIB Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Chapter 11
FTOS-supported RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
14 Contents
Chapter 1 Multiprotocol Label Switching
Multiprotocol Label Switching is supported only on platform ex

This chapter includes the following sections:
• MPLS packet header

• TTL handling
• MTU discovery and packet fragmentation
• MPLS components
• MPLS labels
• Content Addressable Memory (CAM)
• Features:
• High Availability
• Label Distribution Protocol
• Resource Reservation Protocol
• Traffic Engineering
• Quality of Service
• LDP - Label Distribution Protocol
• ECMP
• Terms and Definitions
Multiprotocol Label Switching (MPLS) is a set of protocols that together combine Layer 3 routing with
Layer 2 switching according to the architecture defined in RFC 3031. Multiprotocol Label Switching
(MPLS) directs and carries data from one network node to the next, and makes it easy to create virtual
links between distant nodes.
MPLS is independent of Layer 2 and :Layer 3 technologies, so it allows integration of networks with
different Layer 2 and Layer 3 protocols
In conventional IP routing, each router in the path from source to destination determines the next hop by
matching the destination IP address to the longest matching address-prefix in the routing table. Any packet
that matches the same entry in the routing table takes the same next-hop, and in this way, the lookup can be
considered a type of forwarding classification.
In an MPLS network, classification may be based on any information in the Layer 3 header, for example,
IP Precedence, or information not contained in the packet, for example, ingress port; classification is not
limited to the results of the routing table lookup. Classification is only performed once, as the packet enters
the network, by the ingress MPLS router, which marks (labels) each packet with its class; downstream
routers then determine the next-hop based on the MPLS label.
Unlike IP, the MPLS packet classification/label can be based on:
• Destination Unicast address

• Traffic Engineering
• VPN
• QoS
Thus, the Forwarding Equivalence Class (FEC) can represent any of the following:
• Destination address prefix

• VPN
• Traffic engineering tunnel
• Class of service
MPLS works within the core of an IP network. The core routers have MPLS enabled on interfaces. Labels
are added to IP packets when entering MPLS network, and removed from IP packets when leaving an
MPLS network.
Figure 1 MPLS within core network

IP Routing Packet Label Switching IP Routing
Provider IP Network
Customer IP Customer IP
Network Running MPLS Network
Router Switch/Router Switch/Router Router
Forwarding packets based on labels rather than headers results in several important advantages:
• When a packet is assigned a Forwarding Equivalence Class (FEC) when it enters the network,
information that is not taken from the network layer header can be used for FEC assignment. For
example, classification of packets based on the source of the packets.
• Packets can be assigned a priority label, making Frame Relay and ATM-like quality-of-service
guarantees possible.
• The considerations that determine how a packet is assigned to an FEC can become very complex,
without impacting routers that merely forward labeled packets.
• Packet payloads are not examined by the forwarding routers which allows for different levels of traffic
encryption and the transport of multiple protocols.
• A packet can be forced to follow an explicit route rather than the route chosen by normal dynamic
algorithm as the packet travels through the network.
16 Multiprotocol Label Switching

MPLS packet header
MPLS uses a shim header to integrate into a packet header between the Layer 2 and Layer 3 portions of the
IP datagram. The MPLS header is added when the packet enters the MPLS network and is removed when
the packet exits the MPLS network.
A packet may need to cross several different nested MPLS domains. A nested domain is an MPLS domain
included in another MPLS domain. In this case, the MPLS headers may be stacked, so that there is more
than one 32-bit header in the packet header.
Figure 2 MPLS shim header
Link Layer MPLS SHIM Network Layer

Header Header Header
Label EXP S TTL
The MPLS header is 32 bits long.
• The Label field is 20 bits and carries the actual label value. Label numbering follows these rules:
• 0 - IPv4 explicit NULL label
• 1 - Router alert label
• 2 - IPv6 explicit NULL label
• 3 - Implicit NULL label
• 4-15 - Reserved for future use
• 15 - 1, 048,575 are assigned by the LSR
• The Exp (Experimental) field is 3 bits, and is used to identify traffic classes or congestion. This field is
used for QoS.
• The S (Stacking) portion is 1 bit, and is used when the MPLS headers are stacked to support multiple
header within the packet.
• 1 - indicates that this is the last MPLS header in the packet
• 0 - identifies the header as a stacked MPLS header
• The TTL (Time To Live) portion is 8 bits and shows the remaining number of hops left. This is the
same as the standard IP datagram TTL identifier.
TTL handling
In IP networks, the TTL field is used to prevent packets from travelling indefinitely in the network, and so
preventing loops due to mis-configuration or temporary convergence issues.
MPLS uses the same mechanism as IP, but not on all encapsulations:
• The TTL is present in the label header for PPP and LAN headers as part of the shim header.
• When a packet moves through through one or more LSPs, it will have the same TTL as if it was
forwarded without MPLS.
MTU discovery and packet fragmentation

A packet may become too large for the egress MTU as it travels through the MPLS network due to label
stack additions. If a labeled packet is too large, the system break it into fragments of supported size and
prepends each fragment with the label stack and Layer 2 headers.
On E-Series ExaScale, tunnel packets are fragmented based on physical port MTU. You must ensure that
the link MTU is sufficiently greater than the IP MTU to accommodate Ethernet and MPLS headers.
In the event of fragmentation, tunnel interface counters do not reflect the actual number of packets sent
over the tunnel. Instead, the number of packets shown in the "Output statistics" field reflect only the
number of first fragments.
MPLS components
MPLS works within the core networks. The key components to that ability are described here and
illustrated in Figure 3.
• Customer Edge Router:

• The Customer Edge router (CE) is the router at the customer premises that is connected to the
Provider Edge (PE) of a MPLS network.
• Ingress LSR:
• The ingress LSR receives the IP traffic from the customer’s IP network. The router classifies
the packet based primarily on the IP destination, although it can use other fields.
• The ingress LSR then generates an MPLS header and assigns a label based on the
classification. It encapsulates the packet into an MPLS protocol data unit (PDU) and forwards
the packet to the next hop.
• Transit LSR:
• The transit LSR is also referred to as an Interior LSR. It receives the MPLS packet and uses
the MPLS header to determine forwarding.
• The transit LSR performs any required MPLS label swapping.
• Egress LSR

• The egress LSR removes the MPLS label as the packet exits the MPLS network. It forwards
the packet based on the IP forwarding table.
Figure 3 MPLS components
IP Routing Packet Label Switching IP Routing
Customer IP Provider IP Network Customer IP

Network Running MPLS Network
Customer Edge Ingress LSR Egress LSR Customer Edge

Transit LSR
Router Router
MPLS labels
A label defines the path through an MPLS network to reach a destination based on one or more criteria.A
set of parameters that determine the next-hop of a packet is called a Forwarding Equivalence Class (FEC).
A label is a (in most cases) unique, arbitrary value that represents an FEC and is inserted into a packet. A
label-FEC pair is called a binding; bindings are local to adjacent MPLS routers (LSR) and are exchanged
using a label distribution protocol; Label Distribution Protocol (LDP) is available on FTOS. Labels may be
added or removed in transit from ingress MPLS Label Switch Router (LSR) to egress MPLS LSR, so
packets may have multiple labels.
Label stacking
A labeled packet can carry one or more labels. These labels are organized on a last-in-first-out (LIFO)
basis.
If a packet consists of more than 1 label, the label at the bottom of the stack is referred to as level 1, the
next label is level 2, and so on. When a packet arrives at an LSR, the processing is based on the top-most
label and the underlying labels are not considered.
Label merging
A label can be merged or aggregated. For example, an LSR can have multiple incoming labels for a
particular FEC. When forwarding packets from that FEC the LSR can use a single outgoing label
An LSR that perform this type of merging is identified as a merge capable LSR. The merge-capable LSR is
is one that can receive two packets with two different labels, two packets with same label but from two
different interfaces, and send both packets out the same outgoing interface with same label.
When label merge is used, the number of incoming labels that an LSR needs is never greater than the
number of adjacencies.
Without label merge, the number of incoming labels that an LSR needs is as large as the number of
upstream routers, which forward traffic from this FEC to this LSR.
MPLS supports both merge and non-merge LSR.
Note: A label is in most cases globally unique. However, a system may bind the same label to more than
one FEC when FECs are used in different applications, or contexts. The context in which the label is used
is called a label space, and is represented by a bit value concatenated with the LDP Identifier for label
distribution. There are two types of label spaces, per-interface and per-platform.
• A per-interface label space exists when an LSR binds a label to more than one FEC and distributes
each binding to a different system connected to it by a point-to-point link. Because of the point-to-point
connection, the LSR can discern which FEC a label represents based on the ingress interface.
• A per-platform label space exists when all of the binding created by the system are unique.
MPLS label swapping

Since the LSR alters the label stack from its ingress form at each hop, label-based switching in MPLS is
called label swapping.
To perform label-based switching, some mapping tables are required:
• Incoming Label Map (ILM)—used for labeled packets, maps an incoming label to a Next Hop Label
Forwarding Entry (NHLFE).
• FEC-to-NHLFE Map (FTN)—used for unlabeled packets, maps an FEC to an NHLFE.
The NHLFE contains, among other information, the next hop and an action that the LSR must perform on
the the label stack. The actions can be:
• replace the top label (with a new label that represents an FEC that has the same egress LSR as the
replaced label)
• remove (pop) the top label
• replace the top label and insert (push) an additional label
Forwarding labeled packets
When a labeled packet arrives at the LSP ingress LSR, it performs the following actions:
1. Looks up the label in the ILM.

2. Looks up the NHLFE to determine the next hop and action.
Forwarding unlabeled packets
When an unlabeled packet arrives at the LSP ingress LSR, it performs the following actions:

1. Determines the packet FEC.
2. Maps the FEC to the NHLFE using the FTN.
3. Looks up the NHLFE to determine the next hop and action.
Figure 4 Label-based Switching
Next-hop Label
FEC-to-NHLFE Forwarding Entry
Unlabeled
Map (FTN): label (NHLFE): next-hop,
unlabeled Packets action (pop,replace,
or replace and push)
Incoming Label
Labeled Map (ILM): maps
labels to NHLFE
Label Switched Paths

A Label Switched Path (LSP) is a sequence of routers that operate on a stack of labels of the same depth
(m) from ingress LSR to egress; that is, the top label m is used for the ILM lookup. An LSP exists for each
FEC. The ingress LSR pushes on the label stack to create a depth (m), and the the penultimate hop in the
LSP, the hop before the LSP egress LSR, removes (pops) the top label before forwarding the packet to the
LSP egress LSR. At every hop, the top label is used for referencing the ILM.
The FEC LSP can use hop-by-hop routing, or explicit routing. Explicit routing can be loose or strict.
• A hop-by-hop routed LSP is created by allowing each LSR to select the next hop.
• An explicitly routed LSP is when the ingress or egress LSR chooses some or all of the LSRs in the
LSP.
• If some of the LSRs are chosen the route is loosely explicit.
• If all of the LSRs are chosen the route is strictly explicit.
Content Addressable Memory (CAM)

Content Addressable Memory (CAM) is a type of memory that stores information in the form of a lookup
table. On Force10 systems, the CAM stores Layer 2 and Layer 3 forwarding information, access-lists
(ACL), flows, and routing policies.
FTOS supports MPLS with the Default CAM-profile and Microdcode only.
High Availability
Force10 Networks supports multiple MPLS High Availability (HA) features:
• RSVP-TE Graceful Restart

• RVSVP -TE Fast Reroute Extensions
• LSP Graceful Reoptimization
• BFD for RSVP
Refer to Chapter 4, MPLS High Availability for complete information regarding MPLS HA.
Label Distribution Protocol

Label Distribution Protocol (LDP) distributes labels between two LSRs for traffic flowing between and
through them. LDP associates an FEC with each LSP that it creates, and the FEC associated with an LSP
defines which packets are mapped to that LSP.
Refer to Chapter 2, Label Distribution Protocol for complete information regarding LDP.
Resource Reservation Protocol

Resource Reservation Protocol (RSVP) coordinates routers in a data path to deliver continuous QoS to a
data flow from source to receiver. It is a generic QoS signaling protocol that uses IP as its network layer.
RSVP uses the IGP to determine paths. Extended RSVP uses label extensions to support establishing and
maintaining LSPs.
Refer to Chapter 3, RSVP-TE for complete information regarding RSVP.
Quality of Service
MPLS Quality of Service (QoS) does not define a new QoS architecture. It leverages the IP DiffServ QoS
architecture and applies it to the MPLS network. MPLS uses the EXP field in the header rather than the
DCSP field used by IP.
FTOS supports DSCP in IP networks and EXP in MPLS networks. When DSCP is configured , EXP is
also enabled and takes its value from the DSCP settings. If DCSP is not enabled, EXP is not enabled.
The EXP field is 3 bits in the MPLS header while the DSCP field is 6 bits in the IP header. This difference
is managed in two ways, and both can use either LDP or RSVP to signal and distribute labels.

• E-LSP
• If 8 or fewer Per-Hop Behaviors (PHB) are needed, they are statically mapped from DSCP to
EXP.
• All PHBs for a given FEC share one LSP, and queuing is done based on the EXP field.
• L-LSP
• If more then 8 PHBs are needed, they are mapped into both the label and EXP bits.
• Multiple LSPs are required and a given FEC is encoded into a specific LSP and EXP fields.
• Up to 64 classes are supported.
There are three tunneling models: Uniform, Pipe, and Short Pipe. FTOS supports the short-pipe and
uniform models.
In the pipe and short pipe models, any traffic conditioning that is applied when traffic goes through the
tunnel has no effect on the EXP bits coding in the inner header. In other words, when traffic exits an LSP
(when a label is popped) or when traffic enters an LSP, the inner header's EXP bits coding is not changed.
The pipe and short-pipe models differ in the header that the tunnel egress uses when it determines the PHB
of an incoming packet. With the short-pipe model, the tunnel egress uses an inner header that is used for
forwarding. With the pipe model, the outermost label is always used.
The uniform model is the default FTOS behavior; the IP packet's DSCP value is propagated to the MPLS
experimental bit field.
Optionally, the set-dscp command in an input policy map can be used to mark the EXP bit field. Setting
the DSCP value also sets the EXP bit value; no separate command exists to set only the EXP bit. Also,
Marking is supported only for IP Packet DSCP to EXP and not for EXP to EXP.
Traffic Engineering
MPLS Traffic Engineering (TE) provides the means to direct and manage the traffic between LSRs. MPLS
tunnels can be routed around network congestion or failures. Resource affinities can be defined to include
or exclude specific links during path selection. Explicit paths can be defined for LSPs.
Refer to Chapter 8, MPLS Traffic Engineering for complete information regarding TE.
ECMP
FTOS supports 16 ECMPs with MPLS. The FTOS implementation of MPLS ECMP requires that the
ECMP number be a power of 2. For example, if 5 ECMPs are available, 8 ECMPs are written into
hardware - 12345123. Thus, the first 3 paths are written into hardware two times and are therefore more
likely to be used, potentially resulting in an uneven distribution of traffic.
We program the mask in the CAM for lookup. The mask is based on the number of ECMP entries. If there
are 2 ECMP entries, then the mask is 1 bit. If there are 16 ECMP entries, then the mask is 4 bits. So if the
mask is 4 bits, in the last 4 bits of the destination IP address (host portion) are used for matching to hit the
appropriate CAM entry. For example if the mask is 1 bit, with 2 CAM entries programmed as follows:
1. CAM entry 1: IPDA value 0 and mask 0x1.

2. CAM entry 2: IPDA value 1 and mask 0x01.
If an IP packet destined for 10.0.0.1 (with an in-label that matches the in-label of the above ILM entries),
this packet hits CAM entry 2 since the last bit of the address is 1. Similarly, an IP packet destined to IP
10.0.0.4 hits CAM entry 1 since the last bit is 0.
LAG hashing and ECMP on the ingress and iransit routers:
• LAG hashing on ingress and transit routers—second label from the top + 5 tuple on a label stack
packet
• ECMP hashing for LDP on transit routers—label + IP Destination Address (last few bits)
• LDP with RSVP on ingress router—5-tuple based
Terms and Definitions

• CE - Customer Edge
• Customer Edge Router - The router in the customer’s IP network that connects to the MPLS LSRs
• Ingress LSR - Translates an IP destination address to a label
• Transit LSR - Switches packets based on the labels
• Egress LSR - Removes the label and forwards packet to the customer edge router
• PDU - Protocol Data Unit
• PE - Provider Edge
• Provider Edge Router - The ingress or egress LSRs in the MPLS network
• PHB - Per-Hop Behavior defines the policy and priority applied to a packet when traversing a hop
(such as a router) in an MPLS network.
• LSP - Label Switched Path
• LDP - Label Distribution Protocol

Chapter 2 MPLS CAM Configurations
MPLS CAM Configurations is supported only on platform ex

This chapter contains the following sections:
• CAM Profile and CAM Usage for MPLS on page 25

• Microcodes for MPLS on page 26
CAM Profile and CAM Usage for MPLS

The MPLS portion of the CAM profile is configurable. MPLS entries are stored in three locations:
1. MPLS ILM Table—60K entries

2. Next-Hop Table
• MPLS uses first 10K entries
• Next 12K entries for IPv4 FIB
• Next 12K entries for IPv6 FIB
3. First-Hop Table
• IPv6 FIB uses first 2K entries
• IPv4 FIB uses next 2K entries
• MPLS uses next 45K entries
You can modify the number of ILM entries in the MPLS ILM table using the command mpls ilm.
Number of Next-Hop and First-Hop entries are fixed and based on the line card CAM type. When the
CAM reaches 90% usage, FTOS displays a Syslog message.
Display the MPLS CAM region using the command show cam-usage from EXEC Privilege mode.
Force10#show cam-usage
Linecard|Portpipe| CAM Partition | Total CAM | Used CAM |Available CAM
========|========|=================|=============|=============|==============
8 | 0 | IN-L2 ACL | 5120 | 0 | 5120
| | IN-L2PT | 266 | 0 | 266
| | IN-L2-SysFlow | 102 | 6 | 96
| | IN-L2-FRRP | 102 | 0 | 102
| | IN-L2-Qos | 500 | 0 | 500
| | IN-L2 FIB | 16384 | 1129 | 15255
| | IN-L3 ACL | 16384 | 1 | 16383
| | IN-L3 FIB | 524285 | 9 | 524276
| | IN-L3-SysFlow | 4096 | 35 | 4061
| | IN-L3-McastFib | 9216 | 0 | 9216
| | IN-L3-Qos | 10240 | 0 | 10240
| | IN-L3-PBR | 1024 | 0 | 1024
| | IN-MPLS-ILM | 61440 | 0 | 61440
| | IN-V6 ACL | 6144 | 0 | 6144
| | IN-V6 FIB | 12287 | 0 | 12287
| | IN-V6-SysFlow | 2048 | 0 | 2048
| | IN-V6-McastFib | 3072 | 4 | 3068
| | OUT-L2 ACL | 1729 | 0 | 1729
| | OUT-L2PT | 256 | 0 | 256
| | OUT-L2 SysFlow | 63 | 2 | 61
| | OUT-L3 ACL | 4096 | 0 | 4096
| | OUT-V6 ACL | 1024 | 1 | 1023
...
Microcodes for MPLS

Table 1 shows how packets are handled (routed or switched) based on microcode.
Table 1 MPLS Packet Handling based on Microcode
Microcode Packet Handling

default routed
vrf routed
lag-hash-align routed
ipv6-switched routed
26 MPLS CAM Configurations

Chapter 3 Constrained Shortest Path First
The Shortest Path First (SPF) algorithm solves the problem of finding the shortest path from a source to a
destination. SPF is used in OSPF and IS-IS and generally finds the shortest route from one router to all
other routers in the network.
The Constrained Shortest Path First (CSPF) algorithm is an advanced form of SPF. The path
determination process in CSPF is not designed to find the best path to all routers, but rather only to a
particular router (the tunnel destination). CSPF is used in computing paths that are subject to multiple
constraints and not just the distance metric. When computing paths for Label Switched Paths (LSPs),
CSPF considers not only the topology of the network, but also the attributes of the LSP and the links, and it
attempts to minimize congestion by intelligently balancing the network load.
CSPF maintains the Traffic Engineering Database (TED). The TED is populated by the traffic engineering
related route/link updates from OSPF-TE and ISIS-TE. This consolidated TED is queried by RSVP-TE
when establishing LSPs. CSPF resolves the Quality of Service routing queries, finds the best route that
meets the specified constraints, such as a specified minimum bandwidth, priority, and number of hops.
The following features are configurable constraints which CSPF may use for path selection:
• Explicit Routes on page 27

• Session Attributes on page 28
• Equal Cost Path Selection on page 33
• Administrative Weight on page 33
• Verbatim Path Support on page 34
Explicit Routes
You can define some or all of the nodes in the LSP before the path message is sent. In this case, the LSP is
called an explicit route. Explict routes are used to optimize network resource utilization and reroute around
failures and congestion. The nodes in the explict path are specified in the EXPLICT_ROUTE object
(ERO), which is included in Path messages.
Figure 5 EXPLICIT_ROUTE Object
Object Header L Type Length IPv4 Addr Prefix Resvd

Length
Set if loose hop

1: for IPv4 prefix
There are two types of nodes in an explicit route:
• A strict node must be directly connected to the previous hop in the explicit path.
• A loose node may or may not be directly connected, and the path between the loose node the previous
node may be computed by the IGP.
Step Task Command Syntax Command Mode
1 Give the LSP a name. This command moves ip explicit-path name name CONFIGURATION
you to the EXPLICIT PATH context.
2 Specify some or all of the nodes in the path, [seq number] next-address EXPLICIT PATH
one by one, in downstream order using ip-address [strict | loose]
sequence numbers. Make the node a strict or Default: Strict
loose hop.
Exlude an Address from an Explicit Route

You can direct CSPF to exclude one or more addresses when selecting a path. You may exclude addresses
only if you have specified no other strict or loose hops in the explicit path list.
Task Command Syntax Command Mode
Direct CSPF to exclude one or more exclude-address ip-address EXPLICIT PATH

addresses when selecting a path.
Session Attributes
Attributes are topology state parameters that are used to constrain path selection to specific resources.
Session attributes are contained in the SESSION_ATTRIBUTES object.
Figure 6 Session Attributes Object
Object Header Exclude Include Include Setup Holding Flags Name Session Name
Any Any All Priority Priority Length
Affinity 0x01: Local Protection Desired

0x02: Label Recording Desired
0x04: SE Style Desired
Resource Class Attribute

A resource class, also called admin group, is a group of resources, in this case, links, that have the same
characteristics (or colors). The characteristics that are significant are decided by the administrator. IGP TE
extensions provide 32 possible resource classes.
28 Constrained Shortest Path First

Admin groups provides a user-friendly alternative to the common approach of using hex-based affinity
values to identify the group of resources (links), which are to be included or excluded from the path of a
traffic trunk. For example, if a network has OC-192, OC-48, and OC-12 links, OC-192 links could be
assigned to the “Green 01” admin group, while OC-48 links could be assigned to the “Brown 02” admin
group.
1 Create an admin group and mpls admin-group group-name CONFIGURATION

assign it a number. group-number
Range: 0-31
Force10(conf)#mpls traffic-eng admin-group premium 0

Force10(conf)#mpls traffic-eng admin-group leased 5
Force10(conf)#mpls traffic-eng admin-group high_latency 31
Force10(conf)#do show run mpls
!
mpls traffic-eng admin-group premium 0
mpls traffic-eng admin-group leased 5
mpls traffic-eng admin-group high_latency 31
mpls rsvp enable
mpls traffic-eng enable
Force10(conf)#do show mpls traffic-eng admin-group
Admin Group Bit index Use count
-------------------------------- --------- ----------
premium 0 0
leased 5 0
high_latency 31 0
2 Assign interfaces and/or tunnels to groups:
Assign a tunnel to an tunnel mpls traffic-eng admin-group INTERFACE TUNNEL

administrative group. If you do [include-any | exclude] group-name
not assign the tunnel to any
groups, the interfaces does
not belong to any group.
Force10(conf)#inter tun 1
Force10(conf-if-tu-1)#tunnel destination 100.1.1.4
Force10(conf-if-tu-1)#tunnel mode mpls
Force10(conf-if-tu-1)#tunnel mpls traffic-eng path-option 10 dynamic
Force10(conf-if-tu-1)#tunnel mpls traffic-eng admin-group include premium
Force10(conf-if-tu-1)#tunnel mpls traffic-eng admin-group exclude leased
Force10(conf-if-tu-1)#no shut
Force10(conf-if-tu-1)#show conf
!
interface Tunnel 1
tunnel destination 100.1.1.4
tunnel mode mpls
tunnel mpls traffic-eng path-option 10 dynamic
tunnel mpls traffic-eng admin-group exclude leased
tunnel mpls traffic-eng admin-group include premium
no shutdown
mp-e600i-1(conf-if-tu-1)#do show mpls traffic-eng tunnels tunnel 1
Tunnel name mp-e600i-1_T1 (Tunnel1) Destination 100.1.1.4

Status:
Admin: up Oper: up Path: valid Signalling: connected
Path protection is not available, path weight: 1
Config Parameters:
Configured path options:
path option 10, type dynamic
Tunnel level config:
Bandwidth: 0 kbps (Global) Priority: 7 7
Include admin-group: premium
Exclude admin-group: leased
Retry Timer: 30 seconds
Fast reroute: disabled
[output omitted]
Assign an interface to an mpls traffic-eng admin-group INTERFACE

administrative group. If you do group-name
assign the interface to any
groups, the interfaces does
not belong to any group.

Force10(conf-if-gi-0/12)#mpls traffic-eng admin-group premium

Force10(conf-if-gi-0/12)#mpls traffic-eng admin-group leased
Force10(conf-if-gi-0/12)#show conf
!
interface GigabitEthernet 0/12
ip address 192.168.20.1/24
mpls traffic-eng admin-group leased
mpls traffic-eng admin-group premium
mpls rsvp bandwidth global-pool
no shutdown
Force10(conf-if-gi-0/12)#do show mpls rsvp bandwidth interface
gigabitethernet 0/12
General Parameters::
Bandwidth Hold time: 15 secs
Interface Bandwidth Information::
Interface:: GigabitEthernet 0/12

Physical Bandwidth: 1000000 kbits/sec
Max Res Global BW: 750000 kbits/sec
Max Res Sub BW: 0 kbits/sec
Admin Groups: premium, leased
Flooded flag: off
Reservations: total 3, active 3
[output omitted]
mp-e600i-1(conf-if-gi-0/12)#do show ip ospf mpls traffic-eng interface
gigabitethernet 0/12
OSPF Router with ID (100.1.2.1) (Process ID 55)
Area 1 has 3 MPLS TE links.
GigabitEthernet 0/12 :
Link connected to multiaccess network
Link ID : 192.168.20.2
Interface Address : 192.168.20.1
Admin Metric te: 1 igp: 1
Maximum bandwidth : 125000000
Maximum reservable bandwidth : 93750000
Number of Priority : 8
Priority 0 : 93750000 Priority 1 : 93750000
Affinity Bit : 0x21
[output omitted]
3 Display configured admin show mpls traffic-eng admin-group EXEC Privilege

groups.
Force10(conf)#do show mpls traffic-eng admin-group

Admin Group Bit index Use count
-------------------------------- --------- ----------
premium 0 0
leased 5 0
high_latency 31 0
Resource Class Affinity Ingress Check

Verify that the resource affinity and link color match at the incoming interface of a PATH message. Usually
only the outgoing interface is checked before forwarding a PATH message onto it. This feature gives
additional control over what LSPs can pass through the router.
Enable ingress affinity verification. mpls traffic-eng affinity ingress-check INTERFACE

TUNNEL
Disable Resource Affinity

Ecxlude resource affinity from RSVP messages to interoperate with routers that do not process
resource affinity in the SESSION_ATTRIBUTE (C_Type = 1) object. RFC 2205 requires that all
routers forward the packet unmodified even if they do not understand this object. However, some
third-party vendors reject RSVP messagse containing this attribute.
Send RSVP messages without the mpls traffic-eng affinity send-non-ra INTERFACE
affinity attribute. TUNNEL
Setup and Holding Priority

• Setup Priority—the priority value of a new flow that is compared to the holding priority of an already
admitted flow in order to preempt it when bandwidth is no longer available.

• Holding Priority—the priority value of an admitted flow that is being compared to the setup priority
of a new flow that is competing for bandwidth.
Configure tunnel traffic-engineering tunnel mpls traffic-eng setup-priority spriority EXPLICIT PATH
setup and hold priorities. These are hold-priority hpriority
used when determining whether a Default (spriority and hpriority): 7. 0 is the
particular tunnel can receive or hold on highest priority.
to a bandwidth reservation.
Equal Cost Path Selection

When the CSPF algorithm encounters multiple equal cost paths to a particular node, it can either choose
the path that has the highest maximum reservable bandwidth (default) or, when configured by this
command, the path that has the minimum hop count.
Chose the criterion for selecting one of mpls traffic-eng path-selection CONFIGURATION
multiple equal cost paths to a particular hop-count
node.
Administrative Weight
Adminstrative Weight, also called TE metric, is an administratively assigned metric for an interface
participating in IGP traffic engineering. It is advertised by IGPs and overrides the IGP cost for CSPF
computation.
FTOS always advertises the TE metric; it does not support the IGP metric. So, if no TE metric is
configured, then the advertised TE metric value is equal to the IGP cost. For example, if the IGP cost is 10
and no TE metric is configured, then the advertised TE metric value is 10. If the IGP cost is 10 and a TE
metric of 5 (or any other value) is configured, the advertised TE metric value is 5.
When there are multiple equal cost paths to reach the next-hop, by default, path with highest available
bandwidth is selected. If a tie still exists, a link is selected at random. Optionally, you can configure the
system to select the path with the lowest hop count. If there is a tie break in this case, a link is selected at
random.
Configure a TE metric for an interface for administrative-weight weight CONFIGURATION

use when the interface is advertised as part
of IGP TE extensions.
Verbatim Path Support
You can configure multiple paths for an LSP with the tunnel mpls path-option command. The paths are
configured with sequence numbers so that the most preferred path is selected. If the preferred path is an
explicit path, but CSPF cannot find a path to the tunnel destination using the explicit path list, the first hop
in the explicit path list may be resolved using a routing table lookup so that RSVP signaling can be
performed.
Enable Verbatim Path Support for a path tunnel mpls traffic-eng path-option EXPLICIT PATH
option. [protect] path-num explicit name
path-name verbatim [lockdown]
[bandwidth bandwidth]

Chapter 4 MPLS High Availability
MPLS High Availability is supported only on platform ex

• RSVP-TE Graceful Restart on page 35
• Tunnel Reoptimization on page 38
• RSVP-TE Fast Reroute Extensions on page 39
• BFD for RSVP on page 46
• Path Protection on page 49
• LSP Retry Interval on page 51
• MPLS on LAGs on page 52
RSVP-TE Graceful Restart

RSVP-TE is based on two sets of extensions: RSVP-TE Node Fault Recovery and RSVP Graceful Restart.
Node Fault Recovery

RFC 3473 extends RSVP-TE with the RESTART_CAP object for recovery from two types of faults:
• Nodal fault—control state lost, forwarding state preserved

• Control channel fault—control communication lost
Nodes include RESTART_CAP in hello messages to advertise restart capability. The object contains two
values:
• Restart Time—the amount of time the node requires to bring up RSVP communication after a failure.
• Recovery Time—the period after communication is re-established during which the node and
neighbor resynchronize.
Neighbors that receive a hello with RESTART_CAP store these parameters. If communication with a
remote node is lost, the local node waits an amount of time equal to Restart Time, as if it is still receiving
periodic refreshes. During this time, the local node preserves all RSVP forwarding state for LSPs that
include the link between the local node and the neighbor, but does not send refresh messages. Neighbors
continue to send hello messages to the recovering router.
When hellos are re-established, the local node examines the hello instance from the neighbor. If the
instance value is the same as before communication was lost, the failure was limited to the control channel.
If the instance is different, the local node can assume that the neighbor reset. In either case, the Recovery
Time is used to refresh Path state in the failed node.
In the case of a nodal fault, the neighbor of the recovering node refreshes all Path state shared with the
neighbor using Path messages. The Path messages carry the RECOVERY_LABEL object, instead of a
LABEL object; it is the same as a LABEL, but indicates to the recovering node that it has existing state for
the label. RECOVERY_LABEL contains the same label value as the most recently received Resv message.
When the recovering node receives a Path message during the recovery period, the node: 1) looks for
matching RSVP state entries and refreshes them, or 2) looks for matching forwarding state and installs
RSVP state for them. If no matching state is found, the Path message is treated as setup for a new LSP.
When sending the corresponding outgoing Path message downstream, the message includes the
SUGGESTED_LABEL object, rather than LABEL, indicating that the recovering node used the label
before the failure.
For a control channel failure, no recovery procedure is executed, and though the upstream router sends
RECOVERY_LABEL objects, they are not processed.
Figure 7 RSVP-TE Node Fault Recovery
RSVP-TE Graceful Restart

The node fault recovery extensions defined in RFC 3473 enable a transit node to recover Path and Resv
state through resynchronization with neighbors, but no recovery capability is provided for ingress nodes.
The graceful restart extensions add the ability for an ingress to recover Path state, and for ingress and
transit nodes to recover other objects they previously transmitted, as they might have modified the Path
state they received before forwarding it downstream. Among the recoverable objects are the
EXPLICIT_ROUTE and SESSION_ATTRIBUTES objects. The graceful restart extensions are used in
conjunction with the node fault recovery extensions.
The graceful restart extensions create one new message and one new object:
• RecoveryPath message—this message has the same structure as Path messages, but carries upstream
objects previously sent by the recovering neighbor.
• CAPABILITY object—Carried in hello messages, this object indicates to neighbors that the node is
graceful-restart capable.
36 MPLS High Availability

A node indicates its desire for RecoveryPath messages by including the CAPABILITY object with the
RecoveryPath Desired Flag set in the hellos it sends to its downstream neighbor. Downstream neighbors
advertise the ability to send RecoveryPath messages by including the CAPABILITY object with the
RecoveryPath Transmit Enabled Flag set.
After RSVP communication is reestablished, the downstream neighbor sends one RecoveryPath message
for every LSP for which it sent a Resv message. The objects in the message are copied from the last
received Path message for the LSP.
When the recovering node receives a RecoveryPath message, it uses the information in the message to
locate an existing forwarding state entry, or if no forwarding state is found, setup a new LSP based on the
contents of both messages. The downstream data interface and corresponding label and all other
information in the RecoveryPath message are reused when setting up the LSP.
Figure 8 RSVP Node Fault Recovery plus Graceful Restart
Enable RSVP-TE Graceful Restart
Enable RSVP-TE Graceful Restart. mpls rsvp signaling hello graceful-restart CONFIGURATION
When enabled, the system includes enable
the RESTART_CAP object in hellos. Default: Disabled
(OPTIONAL) Set the Restart Time mpls rsvp signaling hello graceful-restart CONFIGURATION
and Recovery Time. When the {restart-time interval | recovery-time interval}
system is not recovering from a Default Restart Time: 60000 milliseconds
failure, it sets the Recovery Time to 0
in its hellos. It sends hellos with a Default Recovery Time: 120000 milliseconds
Recovery Time to a value greater
than 0 only when the node is in
recovery mode.
Display your graceful restart configuration using the command show mpls rsvp hello graceful-restart:
Force10# show mpls rsvp hello graceful-restart

RSVP Graceful Restart: Disabled
RestartTime: 60000
RecoveryTime: 120000
RSVP-TE Graceful Restart Helper
When graceful restart is enabled, the system is restart-capable and a graceful-restart helper.
Tunnel Reoptimization
Loosely routed LSPs are those that are defined entirely by the IGP, or explicitly routed paths with one or
more loose hops. There are two types of nodes in an explicit route:
• A strict node is directly connected to the previous hop in the explicit path.
• A loose node might or might not be directly connected, but the path between the node and the previous
strict node is computed by the IGP.
Whenever a path or a portion of a path is computed by the IGP, there is an opportunity to discover better
routes—better meaning lower cost—that are created due to network topology changes.
Make-before-break Tunnel Rerouting

Make-before-break Tunnel Rerouting is a method of rerouting traffic from one LSP to another without
disrupting traffic by establishing the new LSP before tearing down the original. While establishing the new
LSP, the old and the new LSPs share resources for the links they have in common. When the ingress node
receives a Resv message for the new LSP, it reroutes traffic and then tears down the original LSP.
Configure Tunnel Reoptimization

You may request reoptimization three ways; requesting reoptimization does not necessarily trigger an LSP
reroute; the path changes only if a different, optimal route is found.
Reoptimize all tunnels or a specific mpls traffic-eng reoptimize [all | tunnel EXEC Privilege
tunnel on demand. number]
Periodic reoptimization of all LSPs is mpls traffic-eng tunnels reoptimize CONFIGURATION

enabled by default. You may change frequency interval
the frequency of reoptimization. Default: 3600 seconds
Range: 10 to 604800 seconds
Configure the system to reoptimize mpls traffic-eng tunnels reoptimize CONFIGURATION

whenever a new link comes online in events link-up
a TE-enabled OSPF or IS-IS area.

Display your reoptimization configuration using the command show mpls traffic-eng tunnel summary:
Force10#show mpls traffic-eng tunnel summary

Traffic-engineering Process: running
RSVP Process: running
Tunnel Management Process: running
MPLS traffic forwarding: running
Periodic reoptimization: every 240 seconds, next in 1 seconds
Signalling summary:
Tunnel interfaces 1500, currently signalling 1500, established 1500
Headend tunnel instance activations 3000, deactivations 1500
LSP count midpoint 0, tailend 0
RSVP-TE Fast Reroute Extensions

RFC 4090 defines RSVP-TE extensions to establish backup LSPs for explicit LSPs. In the event of a
failure, traffic can be re-directed to a backup LSP. Redirection takes place in milliseconds because the path
compution and signaling is completed in advance.
An explicit LSP that has a backup LSP is a protected LSP. You can protect an LSP from link failure, node
failure, or bandwidth exhaustion. More than one backup tunnel may be configured for an interface.
Enable RSVP-TE Fast Reroute for a tunnel. tunnel mpls traffic-eng fast-reroute INTERFACE
Optionally set the bandwidth protection desired [bw-protect || node-protect] TUNNEL
and/or node protection desired flag.
FTOS Behavior: MPLS TTL, IP TTL, MPLS EXP, and IP DSCP may change when FRR is triggered. If
FRR is triggered on the topology in Figure 9 for example, and IP traffic with IP TTL = 100 and IP DSCP
= 011000 is sent to R1:
On egress of R1: IP to MPLS TTL copy
• MPLS label TTL = 99
• MPLS EXP = 3 (011)
On egress of R2:
• MPLS label TTL = 98
• MPLS EXP = 3 (011)
• FRR Push Label TTL = 254 (FRR push TTL is 254 by default)
• FRR Push Label EXP = 0 (FRR push EXP is 0 by default)
On egress of R5: PHP of backup tunnel
• FRR push label TTL is copied to MPLS Label TTL: MPLS label TTL = 253
• FRR push label EXP is copied to MPLS Label EXP: MPLS EXP = 0 (000)
On egress of R3: PHP of primary tunnel
• MPLS Label TTL is copied to IP TTL: IP TTL = 252
• MPLS Label EXP is copied to IP DSCP: IP DSCP = 000000
Protect an LSP from Link Failure
In the Figure 9, the R2 is the Point of Local Repair (PLR), and R3 is the Merge Point.
Figure 9 Protecting LSPs from Link Failure

R2 R3
Transit-PLR Transit-MP
100.1.1.2 100.1.1.3
R1 R4
Head-end Tail-end
Gig 0/0 Tunnel 1
Gig 0/18
Gig 0/60
R5
100.1.1.1 100.1.1.4
Gig 0/5
Tunnel 2
100.1.1.5
Step Task Command Syntax
1 On the Head LSR [R1], create a interface tunnel 1

tunnel numbered tunnel 1, the ip unnumbered loopback 0
destination of which is the Tail tunnel destination 100.1.1.4
LSR [R4] loopback address.
tunnel mode mpls
Borrow the IP address from the
no shutdown
loopback interface. This will be
the primary path.
Force10#show mpls traffic-eng tunnels brief
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
Force10_T1 100.1.1.4 - Gi 0/0 up/up
Force10#show run interface tunnel 1
!
interface Tunnel 1
ip unnumbered Loopback 0
tunnel mode mpls
no shutdown
2 On the PLR [R2], create a second interface tunnel 2

destination of which is the tunnel destination 100.1.1.3
next-hop Transit LSR [R3].
tunnel mode mpls
Borrow the IP address from the
no shutdown
loopback interface. This will be
the backup path.


Force10_T2 100.1.1.3 - Gi 0/5 up/up
Force10_T1 100.1.1.4 Gi 0/60 Gi 0/18 up/up
!
interface Tunnel 2
tunnel mode mpls
no shutdown
3 On the Head LSR interface that is interface gig 0/18

directly connected to the next-hop mpls traffic-eng backup-path tunnel 2
Transit LSR [R2], configure
Tunnel 2 as the interface’s
backup path.
Force10(conf-if-gi-0/18)#mpls traffic-eng backup-path tunnel 2
4 Enable Fast Reroute (FRR) on interface tunnel 1

Tunnel 1. tunnel mpls traffic-eng fast-reroute
Force10(conf-if-tu-1)#tunnel mpls traffic-eng fast-reroute
5 Verify that the backup path status show mpls traffic-eng fast-reroute database
is Ready.
Force10#show mpls traffic-eng fast-reroute database
Tunnel head end item frr information:
Protected tunnel In-label Out intf/label FRR intf/label Status
---------------- -------- -------------- -------------- ------
LSP midpoint item frr information:

LSP identifier In-label Out intf/label FRR intf/label Status
---------------- -------- -------------- -------------- ------
100.1.1.1 1 [3] 16 Gi 0/18:16 Tu 2:16 Ready
6 Verify that the backup tunnel type show mpls rsvp fast-reroute
is Nhop, which means that the
LSP is protected from a link
failure.
Force10#show mpls rsvp fast-reroute
Primary Protect BW Backup
Tunnel I/F BPS:Type Tunnel:Label State Level Type
------ ------- -------- ------------- ------ ----- -----
Force10_T1 Gi 0/18 0K:G Tu 2:16 Ready any-unl Nhop
Below, FRR is triggered by shutting down Gig 0/18, and the backup path is activated. Then the original
link is restored by reenabling the interface.
Force10(conf)#int gi 0/18
Force10(conf-if-gi-0/18)#shut
Sep 23 07:20:41: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi
0/18
Force10(conf-if-gi-0/18)#Sep 23 07:20:41: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface
state to down: Gi 0/18
Force10(conf-if-gi-0/18)#do show mpls traffic-eng fast-reroute database
---------------- -------- -------------- -------------- ------

---------------- -------- -------------- -------------- ------
100.1.1.1 1 [3] 16 Gi 0/18:16 Tu 2:16 Active
Force10(conf-if-gi-0/18)#no shut
Sep 23 07:21:31: %RPM0-P:CP %IFMGR-5-ASTATE_UP: Changed interface Admin state to up: Gi 0/
18
Force10(conf-if-gi-0/18)#
Force10(conf-if-gi-0/18)#Sep 23 07:21:34: %RPM0-P:CP %IFMGR-5-OSTATE_UP: Changed interface
state to up: Gi 0/18

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

---------------- -------- -------------- -------------- ------
100.1.1.1 1 [3] 17 Gi 0/18:17 Tu 2:17 Ready
Protect an LSP from Node Failure

In the following example, the Head LSR in Figure 10 is the PLR.
Figure 10 Protecting LSPs from Node Failure

R2 R3
Transit-PLR Transit
R1 100.1.1.2 100.1.1.3 R4
Head-end Tail-end-MP
100.1.1.1 100.1.1.4
Gig 0/0 Tunnel 1
Gig 0/66
Gig 0/60
Gig 0/31
Tunnel 2

1 On the Head LSR [R1], create a interface tunnel 1

destination of which is the Tail tunnel destination 100.1.1.4
LSR [R4]. Borrow an IP address
tunnel mode mpls
from the loopback interface. This
no shutdown
will be the primary path.
Force10_T1 100.1.1.4 - Gi 0/60 up/up
Force10#show run int tu 1
!
interface Tunnel 1
tunnel mode mpls
no shutdown
2 On the PLR, create a second interface tunnel 2

destination of which is the tunnel destination 100.1.1.4
Tail-end LSR [R4]. Borrow an IP
tunnel mode mpls
address from the loopback
no shutdown
interface. This will be the backup
path.
Force10_T2 100.1.1.4 - Gi 0/31up/up
Force10_T1 100.1.1.4 Gi 0/0 Gi 0/66 up/up
Force10#show running-config int tunnel 2
!
interface Tunnel 2
tunnel mode mpls
no shutdown
3 On the PLR [R2] that is directly mpls traffic-eng backup-path tunnel 2

connected to the next-hop Transit
LSR [R3], configure Tunnel 2 as
the interface’s backup path.
Force10(conf-if-gi-0/66)#mpls traffic-eng backup-path tunnel 2
4 Enable Fast Reroute (FRR) on tunnel mpls traffic-eng fast-reroute

Tunnel 1.
Force10(conf-if-tu-1)#tunnel mpls traffic-eng fast-reroute
Verify that the backup path status show mpls traffic-eng fast-reroute database
is Ready.

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

---------------- -------- -------------- -------------- ------
100.1.1.1 1 [3] 16 Gi 0/66:16 Tu 2:3 Ready
Verify that the backup tunnel type show mpls rsvp fast-reroute
is N-Nhop, which means that the
LSP is protected from a failure of
the Transit LSR (node failure
protection is enabled).
Force10#show mpls rsvp fast-reroute
Tunnel I/F BPS:Type Tunnel:Label State Level Type
------ ------- -------- ------------- ------ ----- -----
Force10_T1 Gi 0/66 0K:G Tu 2:3 Ready any-unl N-Nhop
Below, FRR is triggered by shutting down Gig 0/66, and the backup path is activated. Then the original
link is restored by reenabling the interface.
Force10(conf)#int gi 0/66
00:32:51: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi 0/66
Force10(conf-if-gi-0/66)#00:32:51: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state
to down: Gi 0/66
---------------- -------- -------------- -------------- ------

---------------- -------- -------------- -------------- ------
100.1.1.1 1 [3] 16 None Tu 2:3 Active
Force10(conf-if-gi-0/66)#no shutdown
00:33:42: %RPM0-P:CP %IFMGR-5-ASTATE_UP: Changed interface Admin state to up: Gi 0/66
Force10(conf-if-gi-0/66)#00:33:46: %RPM0-P:CP %IFMGR-5-OSTATE_UP: Changed interface state
to up: Gi 0/66
---------------- -------- -------------- -------------- ------

---------------- -------- -------------- -------------- ------
100.1.1.1 1 [7] 17 Gi 0/66:17 Tu 2:3 Ready

Protect the LSP Bandwidth
Bandwidth protection uses RSVP to signal the requirement for a backup tunnel to offer the same amount of
bandwidth as the primary tunnel. It enables the concept of shared backup bandwidth, in which several
primary tunnels are covered by a single backup tunnel.
Fast reroute provides bandwidth and node protection by default, though there are no commands.
Bandwidth protection enhances fast rerouteby providing a maximum protectable capacity during a failure.
Unprotected LSPs may use remaining capacity. The maximum utilization may be greater than 100%.
The following points describe bandwidth protection behavior:
• If there is no bandwidth configuration on either the primary or the backup, then the primary receives
protection since, this is essentially an unlimited bandwidth situation.
• If the primary tunnel has 100m but the backup tunnel has no bandwidth configuration, the primary
tunnel still receives protection since the default is unlimited bandwidth on backup tunnels.
• If there is no bandwidth configuration on the primary tunnel and this a bandwidth configuration on the
backup tunnel, then the primary tunnel does not receive protection.
• For example, if primary tunnel 1 has 100m, primary tunnel 2 has 100m, but the backup tunnel has only
100m bandwith, then only one of the primary tunnels receives protection. If the backup tunnel was
increased to 200m, then both tunnels receive protection.
1 Configure the primary tunnel and enable FRR.

!
interface Tunnel 3
tunnel mode mpls
tunnel mpls traffic-eng path-option 1 explicit name p-2
tunnel mpls traffic-eng fast-reroute
no shutdown
2 Configure the backup tunnel and enable FRR and bandwidth protection.
!
interface Tunnel 1
tunnel mode mpls
tunnel mpls traffic-eng fast-reroute bw-protect
no shutdown
3 Verify your configuration using show mpls show mpls rsvp EXEC Privilege
rsvp fast-reroute bw-protect. The value of fast-reroute bw-protect
BW-P will be "ON" only if fast-reroute with
bw-protect is configured.
Force10#show mpls rsvp fas bw

Tunnel I/F BPS:Type Tunnel:Label State BW-P Type
------ ------- -------- ------------- ------ ----- -----
Force10_T1 Gi 0/60 1M:G Tu 11:3 Active ON N-Nhop
Force10_T3 Gi 0/61 0K:G Tu 2:17 Active ON Nhop
FTOS Behavior: When FRR is triggered and the backup tunnel becomes active, the BFD
neighborship for the backup tunnel at the merge point shows the neighbor in down state although it is
up. In the following example, Transit R2 is the PLR and Transit R3 is the merge point.
R2 R3
Transit-PLR Transit-MP
R1 R4
Head-end Tail-end
2/12 2/16
2.1.1.1 Tunnel 1 2.1.1.2 3.1.1.1
5.1.1.1 2/13
5.1.1.2
Tunnel 2
When the Tunnel 1 link between R2 and R3 fails, the backup tunnel is activated. On the merge point,
R3, the BFD state for the session with 100.1.1.2 is shows as Down, although the link is in fact up.
Force10#show bfd neighbors
[output omitted]
LocalAddr RemoteAddr Interface State Rx-int Tx-int Mult Clients
* 2.1.1.2 2.1.1.1 Gi 2/12 Up 100 100 3 M
* 3.1.1.1 3.1.1.2 Gi 2/16 Up 100 100 3 M
* 5.1.1.2 5.1.1.1 Gi 2/13 Up 100 100 3 M
Force10#Jul 24 19:51:11: %RPM0-P:CP %BFDMGR-1-BFD_STATE_CHANGE: Changed session
state to Down for
neighbor 2.1.1.1 on interface Gi 2/12 (diag: TMR_EXP)
Force10#show bfd neighbors
[output omitted]
* 2.1.1.2 2.1.1.1 Gi 2/12 Down 1000 1000 3 M
* 3.1.1.1 3.1.1.2 Gi 2/16 Up 100 100 3 M
* 5.1.1.2 5.1.1.1 Gi 2/13 Up 100 100 3 M
* 0.0.0.0 100.1.1.2 Gi 2/13 Down 1000 1000 3 M
BFD for RSVP

Bidirectional Forwarding Detection (BFD) is a protocol that is used to detect at sub-second intervals
communication failures between two adjacent systems. It is a simple and lightweight replacement for
existing routing protocol link state detection mechanisms. The purpose of RSVP-BFD coordination is to
detect network failures quickly so Fast Re-route can take place as soon as possible in case of a link or node
failure. Without BFD, the system must wait for the IGP dead time to expire, which might take seconds.
BFD failure detection is sub-second.

BFD is a simple hello mechanism. Two neighboring systems running BFD establish a session using a
three-way handshake. After the session has been established, the systems exchange periodic control
packets at sub-second intervals. If a system does not receive a hello packet within a specified amount of
time, routing protocols are notified that the forwarding path is down. In addition, systems send a control
packet immediately upon any state change or change in a session parameter. On Force10 routers, BFD
Agents on the line card report session state changes to the BFD Manager (on the RPM), which in turn
notifies the protocols that are registered with it, in this case, RSVP.
Two important parameters are calculated using the values contained in the control packet.
• Transmit interval — Transmit interval is the agreed-upon rate at which a system sends control
packets. Each system has its own transmit interval, which is the greater of the last received remote
Desired TX Interval and the local Required Min RX Interval.
• Detection time — Detection time is the amount of time that a system does not receive a control
packet, after which the system determines that the session has failed. Each system has its own
detection time.
BFD must be enabled on both sides of a link in order to establish a session. The two participating systems
can assume either of two roles:
• Active—The active system initiates the BFD session. Both systems can be active for the same session.
• Passive—The passive system does not initiate a session. It only responds to a request for session
initialization from the active system.
A session can have four states: Adminstratively Down, Down, Init, and Up.
• Administratively Down—The local system will not participate in a particular session.
• Down—The remote system is not sending any control packets or at least not within the detection time
for a particular session.
• Init—The local system is communicating.
• Up—The both systems are exchanging control packets.
Enable BFD for RSVP

When using BFD with RSVP, the RSVP registers with the BFD manager on the RPM. BFD sessions are
established with all neighboring interfaces participating in RSVP. If a neighboring interface fails, the BFD
agent on the line card notifies the BFD manager, which in turn notifies the RSVP protocol that a link state
change occurred.
1 Verify that you have RSVP neighbors. show mpls rsvp neighbors EXEC Privilege
Force10(conf-if-range-tu-1-3)#do show mpls rsvp neighbor
Neighbor Interface Time since Msg rcvd Msg sent
10.1.1.2 Gi 3/0 00:00:05 00:00:20
11.1.1.2 Gi 3/1 00:00:00 00:00:10
12.1.1.2 Gi 3/2 00:00:18 00:00:16
2 Enable the BFD protocol. bfd enable CONFIGURATION
Force10 (conf)#bfd enable
3 Establish sessions with all RSVP mpls rsvp bfd all-neighbors CONFIGURATION/
neighbors, or all RSVP neighbors out of an INTERFACE
interface.
4 Display established sessions using the show bfd neighbors EXEC Privilege
command .
Force10(conf)#do show bfd neighbors
* - Active session role

Ad Dn - Admin Down
C - CLI
I - ISIS
O - OSPF
R - Static Route (RTM)
M - MPLS
V - VRRP
* 10.1.1.1 10.1.1.2 Gi 3/0 Up 100 100 3 M
* 11.1.1.1 11.1.1.2 Gi 3/1 Up 100 100 3 M
* 12.1.1.1 12.1.1.2 Gi 3/2 Up 100 100 3 M
Change RSVP session parameters
BFD sessions are configured with default intervals and a default role. The parameters that can be
configured are: Desired TX Interval, Required Min RX Interval, Detection Multiplier, and system role. If
you change a parameter globally, the change affects all RSVP neighbors sessions. If you change a
parameter at interface level, the change affects all RSVP sessions on that interface, and it supercedes the
global parameter value.
Change parameters for all RSVP mpls rsvp bfd all-neighbors interval seconds CONFIGURATION/
sessions on an interface. min_rx min_rx multiplier value role {active | INTERFACE
passive}
Force10(conf-if-gi-3/1)#do show mpls rsvp neighbor detail

Neighbor: 10.1.1.1
Interface GigabitEthernet 3/0, BFD enabled
Refresh reduction feature is currently disabled
Refresh reduction capability is unavailable
Reliable messaging support is available
Remote epoch 0x000, Retransmitted messages: 0
Number of LSPs referring to this neighbor 1
Highest rcvd message id 0x0
Time since last RSVP signaling message received 00:00:13
Time since last RSVP signaling message sent 00:00:37

Disabling BFD for RSVP
If BFD is disabled globally, all sessions are torn down, and sessions on the remote system are placed in a
Down state. If BFD is disabled on an interface, sessions on the interface are torn down, and sessions on the
remote system are placed in a Down state. Disabling BFD does not trigger a change in BFD clients; a final
Admin Down packet is sent before the session is terminated.
Disable BFD sessions with all RSVP mpls rsvp bfd all-neighbors disable CONFIGURATION
neighbors.
Disable BFD sessions with all RSVP mpls rsvp bfd all-neighbors disable INTERFACE
neighbors out of an interface when BFD is
enabled globally
Path Protection
Path Protection is essentially the establishment of an additional LSP in parallel with an existing LSP, where
the additional LSP is used only in case of failure. This LSP is sometimes called the backup, secondary, or
standby LSP. The backup LSP is not used to carry traffic except during a failure condition.
The backup LSP is built along paths that are as diverse as possible from the LSP they are protecting. This
ensures that a failure along the path of the primary LSP does not also affect the backup LSP.
Path protection is a simple concept. Each primary LSP is backed up by a standby LSP. Both the primary
and backup LSPs are configured at the head-end LSR. Both are signalled ahead of time on the control
plane. The primary and backup LSPs might have the same constraints. If the primary LSP has a bandwidth
reservation of 100 Mbps, the backup LSP may also reserve 100 Mbps. This way, the end-to-end
characteristics essentially remain the same, regardless of whether the LSP used to carry the traffic is the
primary LSP or secondary LSP.
Path protection has better convergence than IGP convergence in an IP network or MPLS TE LSP reroute
because it makes use of a presignalled LSP that is ready to go in case the primary LSP fails. With path
protection, the relationship between the backup LSP and the number of primary LSPs it is protecting is 1:1.
In other words, for every LSP you want to protect, you have to signal another LSP.
Figure 11 Path Protection
R2
Transit R3
R1
Head-end Gig 0/60 1.1.2.2 1.1.3.2 Tail-end
Tunnel 1 Primary Path
Tunnel 1 Standby Path

Gig 0/61 1.1.11.2 1.1.4.2
R-ID: 100.1.1.1 R-ID: 100.1.1.2 R-ID: 100.1.1.3
1 On the Head-end LSR [R1], create a tunnel show mpls traffic-eng tunnels EXEC Privilege
numbered tunnel 1, the destination of which brief
is the Tail-end LSR [R3] router-ID. Borrow an
IP address from any configured loopback
interface or physical interface. This will be the
primary path.
Force10_T1 100.1.1.3 - Gi 0/60 up/up
Force10#show running-config interface tunnel 1
!
interface Tunnel 1
tunnel mode mpls
no shutdown
2 Create a new explicit path, and configure the ip explicit-path name name CONFIGURATION
next addresses so that a link different from next-address ip-address {strict |
the primary tunnel is chosen from the loose}
head-end through the transit router to the
tail-end.
Force10(conf)#ip explicit-path name standbylsp
Force10(conf-ip-exp-path)#next-address 1.1.11.2 strict
Force10(conf-ip-exp-path)#next-address 1.1. 4.2 strict
3 Add the explicit path to the primary tunnel as tunnel mpls traffic-eng CONFIGURATION
protection. path-option protect path-num
{dynamic | explicit name
path-name} [lockdown]
[bandwidth bandwidth]
Force10(conf)#int tunnel 1
Force10(conf-if-tu-1)#$fic-eng path-option protect 1 explicit name standbylsp
Force10(conf-if-tu-1)#show config
!
interface Tunnel 1
tunnel mode mpls
tunnel mpls traffic-eng path-option protect 1 explicit name standbylsp
no shutdown

4 Verify that the primary path is protected, and show mpls traffic-eng tunnels EXEC Privilege
that the secondary path is up. protection
Force10#show mpls traffic-eng tunnels protection
Tunnel name Force10_T1 (Tunnel1) Destination 100.1.1.3

Status:
Admin: up Oper: up Path: valid Signalling: connected
Primary lsp path: 1.1.2.1 1.1.2.2 1.1.3.1 1.1.3.2

Protect lsp path: 1.1.11.1 1.1.11.2 1.1.4.1 1.1.4.2
Path Protect Parameters:
Bandwidth: 0 kbps Priority: 7 7 Affinity: 0x0/0xFFFF
In Label: -
Out Label: GigabitEthernet 0/61, 20
RSVP Signalling Information:
Src 100.1.1.1, Dst 100.1.1.3, Tunnel Id 1, Instance 7
RSVP Path Info:
Local IP: 100.1.1.1
Explicit Route: 1.1.11.1 1.1.11.2 1.1.4.1 1.1.4.2
Record Route: None
Tspec: ave rate 0 kbits, burst 0 bytes peak rate 0 kbits
RSVP Resv Info:
Record Route: None
Fspec: ave rate 0 kbits, burst 0 bytes, peak rate 0 kbits
5 To trigger a failover, administratively shutdown INTERFACE

shutdown the primary path link so that the
standby LSP becomes active.
Force10(conf)#int gigabitethernet 0/60
Sep 24 04:02:03: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi 0/60
Sep 24 04:02:03: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Gi 0/60
Force10#show mpls traffic-eng tunnels protection
Tunnel name Force10_T1 admin up oper status up

Destination 100.1.1.3, Source 100.1.1.1
Standby path is currently in use
LSP Retry Interval

The retry interval sets the time, in seconds, between attempts to establish an LSP. This feature is useful in
cases when the primary LSP of a tunnel cannot be established; the primary LSP is up, but its corresponding
standby LSP is not up; or a make-before-break LSP is attempted due to a resource change or
reoptimization to determine the time interval between retries.
Configure the retry interval for tunnel mpls traffic-eng retries INTERFACE
establishing LSPs. TUNNEL
MPLS on LAGs
FTOS includes a default CAM profile and microcode that treats MPLS packets as follows:
• When MPLS IP packets are received, hashing is based on the label + IP 5 tuple (source IP address,
destination IP address, IP protocol, and source and destination UDP or TCP port number).
• If the packet is part of a VPN, hashing is based on the inner and outer labels.
Below, MPLS is enabled on a port-channel interface.
Force10#sh run inter po 10

!
interface Port-channel 10
ip address 1.2.1.1/24
channel-member TenGigabitEthernet 6/0-1,3-4
noshutdown

Chapter 5 Label Distribution Protocol
Label Distribution Protocol is supported only on platform ex

Label Distribution Protocol—defined in RFC 5036—is a Layer 3 protocol that Label Switching Routers
(LSRs) use to exchange their Forwarding Equivalency Class (FEC)-to-Label mappings.
Creating Labels
In conventional IP routing, each router determines the next hop by matching the destination IP address to
the longest matching address-prefix in the routing table. Packets that match the same routing table entry
normally take the same path, and in this way, the lookup can be considered a type of packet classification.
In an MPLS network, a group of packets that take the same path from ingress to egress is called a
Forwarding Equivelance Class (FEC). Packets are classified (the next hop is determined) by matching the
destination IP against one or both of two criteria.
• an address prefix—the network address portion of the destination IP of the packet, and/or
• a host address—the complete destination IP address of the packet
Host address FEC elements are explicitly configured, while address prefixes are found in the routing table,
which is primarily populated by a routing protocol. So, generally, each address prefix in the routing table is
an FEC.
If an FEC has more than one element, the LSR matches according to the following rules:
1. if a match against a host address element occurs, then the packet is classified to the corresponding
FEC, else
2. the packet is classified to the FEC that has the longest matching address prefix.
When do LSRs Create Labels?
A label is a (in most cases) unique, arbitrary value that represents an FEC and is inserted into a packet. A
label-FEC pair is called a binding; bindings are local to adjacent MPLS routers (LSR) and are exchanged
using LDP.
Note: A label is in most cases globally unique. However, a system may bind the same label to more than
one FEC when FECs are used in different applications, or contexts. The context in which the label is used
is called a label space, and is represented by a16- bit value concatenated with the LSR Identifier for label
distribution. There are two types of label spaces, per-interface and per-platform.
• A per-interface label space exists when an LSR binds a label to more than one FEC and distributes
each binding to a different system connected to it by a point-to-point link. Because of the point-to-point
connection, the LSR can discern which FEC a label represents based on the ingress interface.
• A per-platform label space (global label space) exists when all of the binding created by the sytem
are unique.
MPLS is designed so that only one router performs the routing table lookup for a given address prefix. It
then creates a label so that the remaining routers switch based on the label. So which LSR performs the
lookup and creates the label for a given prefix? Each LSR looks into its routing table and decides for which
address prefixes (FECs) it will create labels based on its Label Control Mode.
Label Control Modes
MPLS architecture defines two label control modes. Although both modes may be used in the same
network, ordered control is achieved only when all LSRs in the network use ordered control.
• Independent Label Distribution Control—an LSR, when it recognizes an FEC, binds a label to it,
and distributes it.
• Ordered Label Distribution Control—an LSR binds a label to an FEC only if it is the egress LSR or
if it has received a binding for an FEC from its next hop. This is the FTOS default.
An LSR is the egress LSR if:
• The FEC refers one of the LSRs directly connected interfaces (R3, Figure 12).
54 Label Distribution Protocol

• The next-hop for the FEC is outside the MPLS network (R2, Figure 12).
Figure 12 MPLS Egress LSRs
Label Information Base
Address Prefix LDP Identifier Label Routing Table
10.11.1.0/24 R3 Label A Address Prefix Next Hop
10.11.2.0/24 R2 Label B 10.11.1.0/24 Direct
MPLS Network
R1 R2 R3
LSP A,B LSP B
Ingress LSR Egress LSR Egress LSR

10.11.2.1/24 10.11.1.254/24
for FEC B for FEC A
Label Distribution
Labels are distributed in the direction of egress to ingress LSR (upstream) for a given FEC. The
distribution procedure is based on the combination of Label Advertisement Mode and Label Control
Mode.
Label Advertisement Modes

There are two label advertisement modes, which are prescribed by MPLS architecture. Both of these
methods may be used in the same network at the same time, but each adjacency must use only one.
• Downstream-on-Demand—an LSR distributes (advertises) a particular FEC-label mapping (label

mapping) only upon request from the upstream neighbor.
• Unsolicited Downstream—an LSR advertises its label mappings without request. This is the FTOS
default.
Label Distribution Procedures

There are four label distribution procedures:
• PushUnconditional—Unsolicited Downstream + Independent Control. An LSR advertises a label

mapping for any FEC it recognizes, at any time.
• PushConditional—Unsolicited Downstream + Ordered Control. An LSR advertises label mappings at
any time if only if it is the egress LSR for the FEC or it received the label mapping from the next-hop.
This is the FTOS default.
• PulledUnconditional—Downstream-on-Demand + Independent Control. An LSR answers requests
for label mappings immediately, without being the egress LSR or waiting for a label mapping from the
next hop.
• PulledConditional—Downstream-on-Demand + Ordered Control. An LSR responds to a request for a
label mapping only if it is the egress LSR for the FEC, or if it has received a label mapping from the
next-hop.
Label Retention
Self-recognized and learned labels are stored in a Label Information Base (LIB). Each entry contains an
address prefix and a collection of (LDP Identifier, label) pairs, one from each advertising peer. The label
that is used for forwarding is the one with an LDP Identifier that belongs to the next hop.
Each LSR independently decides whether to keep or discard the label mappings it receives.
• Conservative Label Retention Mode—In Unsolicited Downstream mode, label mapping

advertisements for all routes may be received from all peers. In Downstream-on-Demand mode,
advertisements are received only from the label next hop.
When using conservative label retention, advertised label mappings are retained only if they will be
used to forward packets (if the FEC next hop is an LDP peer); Downstream-on-Demand is typically
used with the conservative label retention mode.
The advantage of the conservative mode is that only the labels that are required for forwarding are
maintained. A disadvantage of the conservative mode is that if routing changes the next hop for a given
destination, a new label must be obtained from the new next hop before labeled packets can be for-
warded.
• Liberal Label Retention Mode— When using liberal label retention, every label mapping received
from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping.
When operating in Downstream-on-Demand mode with liberal label retention, an LSR might choose
to request label mappings for all known prefixes from all peer LSRs.
The advantage of the liberal label retention mode is that reaction to routing changes can be quick
because labels already exist. The main disadvantage of the liberal mode is that unneeded label map-
pings are distributed and maintained. This is the FTOS default.
LDP Peering
In order to exchange label mappings, two LSRs must peer. LSRs may peer even if they are directly are not
directly connected. A peership is a TCP session between the two LSRs.
1. Discovery—Before establishing a peership, LSRs must discover each other. To discover

directly-connected neighbors, an LSR periodically sends UDP LDP Link Hellos to the all-routers
multicast address, 224.0.0.2. To discover neighbors that are not directly connected, an LSR
periodically sends an LDP Targeted Hello addressed to a specific LSR; the target LSR decides whether
to respond. When each LSR receives a discovery from the other, a hello adjacency is formed between
the two LSRs.
2. Session Establishment—Once an adjacency is formed, the LSR with the highest IP address becomes
the active LSR, which is responsible for establishing a TCP connection to the LDP port 646. The IP
address used for comparison is either the source address of the discovery message, or an IP address
that may be optionally specified within the hello.

3. Session Initialization—The LSRs negotiate LDP parameters such as label advertisement mode, label
control mode, and keepalive holdtime.
Figure 13 LDP Peering Session Creation
ACTIVE System PASSIVE System
LDP Link Hellos Exchange
Initialization Message
Response Initialization + Keepalive

session operational
session operational
LDP Protocol Data Units

LDP peers exchange information using messages inside protocol data units (PDUs) over a TCP
connection. Each LDP PDU carries one or more messages which are in Type, Length, Value (TLV) format.
The information contained in messages is also in TLV format.
LDP PDUs begin with a header that contains three fields, as shown in Figure 14.
• Version—LDP is currently on version 1.

• PDU Length—an integer specifying the length of the PDU, including the header in, octets. The
maximum length is negotiated.
• LDP Identifier—a six octet, globally unique value. The first four octets are the router ID, the last two
identify the label space. For a platform-wide label space, these two octets are zero.
Peering Messages
Peering messages are used to establish LDP adjacencies and sessions.
Hello Messages
Hello messages are used to discover LDP neighbors. LSRs may be in active mode or passive mode. Active
mode LSRs send hello messages out of all interfaces; passive LSRs only respond to hellos.
Figure 14 Hello Message
Protocol Header Src IP Addr Dest IP Addr Options Padding UDP Packet
(17) Checksum (224.0.0.2)
Source Port Destination Port Length Checksum LDPDU

(646) (646)
Version PDU Length LDP Identifier U Message Type Msg Msg ID U F Type Length Hold Time T R Reserved Optional Parameters
(1) (0) (0x0100) Length (0) (0) (0x0400)
Common Hello Parameters TLV Optional Parameters TLV
LDPDU Header Hello Message
Table 2 Hello Message TLVs
Type Parameter Description

0x0400 Common Hello Parameters
Hold Time Functions as a keepalive for the adjacency. Hellos must be sent
periodically to refresh the timer.
Default: 15 seconds for Link Hellos, 45 seconds for Targeted
Hellos. The default is indicated by a value of 0 in this field.
T (Targeted Hello) 1 indicates that the message is a Targeted Hello.
0 indicates that the message is a Link Hello.
R (Request Send Targeted Hello) 1 indicates that the sender is requesting that the receiver send
Targeted Hellos.
0 makes no request.
Optional Parameters
0x0401 IPv4 Transport Address Specifies the IP address to use during TCP session establishment.
If this TLV is not used, the source address for the hello is used for
the TCP connection.
0x0402 Configuration Sequence Number Whenever there is a configuration change on the sending LSR, it
increments the configuration sequence number.
0x0403 IPv6 Transport Address Specifies the IP address to use during for TCP session
establishment. If this TLV is not used, the source address for the
hello is used for the TCP connection.

Initialization Messages
Initialization messages are used to negotiate or advertise session parameters such as label advertisement
mode and loop detection.
Figure 15 Initialization Message

Version PDU Length LDP Identifier U Message Type Msg Msg ID U F Type Protocol KeepAlive A D Reserved PVLim Max PDU Receiver LDP Optional Parameters
(1) (0) (0x0200) Length (0) (0) (0x0500) Version Time Length Identifier
Common Session Parameters TLV Optional Parameters TLV
Initialization Message
Table 3 Initialization Message TLVs

0x0500 Common Session Parameters
KeepAlive Time One session is created per label space. This timer is reset upon
receipt of an LDPDU. The session is torn down if the timer expires.
This timer is separate from Hold Time, which maintains the
adjacency.
A (Label Advertisement Discipline) Indicates the Label Advertisement Mode.
0: Unsolicited Downstream
1: Downstream-on-Demand
In case of conflict in negotiation, Unsolicited Downstream is used.
D (Loop Detection) Indicates whether loop detection is enabled.
0: Disabled
1: Enabled
PVLim Path Vector Length is used to detect loops. Path Vector Limit
indicates the maximum path vector length; PVLim is 0 if loop
detection is disabled.
Max PDU Length Maximum allowable length for LDPDUs for the session.
Default: 4096 bytes.
Receiver LDP Identifier Identifies the receivers label space. Combined with the sender’s
LDP Identifier, the receiver can match the message to one of its
adjacencies.
Notification Messages
Notification messages communicate the outcome of processing an LDP message or the state of the LDP
session, including:
• Unacceptable initialization parameters

• Loop detected
• No route (in case a requested FEC is not in the routing table)
• Session or adjacency teardown
Figure 16 Notification Message
Notification Message
Version PDU Length LDP Identifier U Message Type Msg Msg ID StatusTLV Optional Parameters
(1) (0) (0x0001) Length
U F Type Length Status Code Message ID Message Type

(0) (0) (0x0300)
E F Status Data
Table 4 Initialization Message TLVs

0x0300 Status TLV
U (Unknown) Set to 0 when the TLV appears in a Notification message.
Set to 1 when the TLV is sent in another type of message.
F (Forward Unknown) Same as the Fatal Error bit.
Status Code
E (Fatal Error) Set to 0 if the notification message is an advisory.
Set to 1 if the notification message signals a fatal error. Fatal errors
cause both LSRs to terminate the session.
F (Forward) Set to 0 if not to forward.
Set to 1 if the notification should be forwarded upstream or
downstream.
Status Data Integer representing the status. 0 signals success.
Message ID Refers to the message ID to which the notification is in response.
Message Type Refers to the type of peer message to which the notification is in
response.

Label Distribution Messages
Label distribution messages propagate label mappings across a series of LSRs to create label switched
paths (LSPs) for each FEC.
Address Message
Each LSR sends to its peer active interface addresses. This list is used to determine whether the next hop
for an address prefix is an LDP peer. When an LSR receives an label mapping from a downstream peer, it
determines if the source LSR is the next hop for the FEC. If it is, the LSR installs and uses the label for
forwarding. If it is not, the LSR either installs (but does not use) or releases the label based on its label
retetion mode.
Address Withdraw messages are used to signal to a peer that a previously advertised address is no longer
valid.
Figure 17 Address Message

Address Message
Version PDU Length LDP Identifier U Message Type Msg Msg ID Address List TLV Optional Parameters
(1) (0) (0x0300) Length
None defined
0 0 Type Length Address Family Addresses

(0x0101)
Code:
1: IPv4
2: IPv6
Label Mapping Message
LSRs use label mapping messages to advertise label mappings to upstream peers. An LSR advertises a
label mapping to a peer when:
• it recognizes a new FEC in its forwarding table, and its distribution mode is Unsolicited Downstream,
• it receives a request for a label mapping, or
• it receives a mapping from a downstream peer that has not yet been distributed upstream.
Figure 18 Label Mapping Message
Label Exp S TTL
Value
U F Type Length Label

(0) (0) (0x0100)
Version PDU Length LDP Identifier U Message Type Msg Msg ID FEC TLV Label TLV Optional Parameters
(1) (0) (0x0400) Length
U F Type Length FEC Element 1 FEC Element n

(0) (0) (0x0100)
Element Type Address Family Prefix Length Prefix

(2) (1)
Label Mapping Message
Table 5 Label MappingTLVs

0x0400 Label Mapping Message
0x0100 FEC TLV
FEC Element Type 0x02: Address Prefix
0x03: Host Address
Address Family 1: IPv4
2: IPv6
Prefix Length The number of bits that comprise the address prefix.
Prefix The address prefix.
0x0200 Generic Label TLV
Label Value An 8-bit arbitrary number in a 20-bit field. Bits 4-15 are
reserved.
Experimental Reserved
S Set to 1 if the label is the last entry in a label stack. Zero for all
other positions.
Time-to-Live When a label is inserted into a packet, the TTL value is the
same as the IP TTL field. The TTL is decremented by one at
each LSR.
Optional Parameters
Label Request Message ID TLV If the label mapping message is a response to a request, the
label request message ID must be included. This TLV type
0x0600.

Table 5 Label MappingTLVs

Hop Count TLV Used to count the number of LSRs in the LSP.
Path Vector TLV Used for loop detection.
Label Request Message
An LSR requests a label mapping from a downstream peer when:
• the LSR recognizes a new FEC via the forwarding table, or

• the LSR receives a request for an FEC from an upstream peer and the LSR does not already have a
mapping for it.
The receiving LSR looks into its routing table to determine the label mapping. It responds to the request
message with the label mapping or with a notification message indicating why it cannot satisfy the request.
Figure 19 Label Request Message

Hop Count TLV
Path Vector TLV
Version PDU Length LDP Identifier U Message Type Msg Msg ID FEC TLV Optional Parameters
(1) (0) (0x0401) Length
Label Request Message
Label Release Message
A Label Release Message signals to a peer that the LSR is no longer using a label mapping that either it
requested or was advertised to it. A label is released when:
• the advertisting LSR is no longer the next hop for the advertised FEC, and the releasing LSR is in
conservative label retention mode
• an LSR receives a label mapping from an LSR that is not the next hop for the FEC
• an LSR receives a withdraw message
Label Withdraw Message
A Label Withdraw Message signals to a peer that a label mapping that the LSR no longer recognizes an
FEC that it previously advertised.
Reserved Labels—Penultimate Hop Popping
FTOS performs penultimate hop popping (PHP) by default. FTOS binds an “Implicit Null” label to FECs
for which it is the egress LSR, and distributes the label upstream. For those FECs, the upstream neighbor
removes the current top label, rather than swapping it. This relieves the egress LSR of having to perform
two lookups, one for the top label which it will remove after discovering it is the egress, and another for the
new top label. The “Implict Null” label has a value of 3, which is a reserved value. Though the label is
assigned and distributed, forwarded packets are never actually labeled.
Implementation Information
• The FTOS implementation of Label Distribution Protocol is based on RFC 3036.
• Per-interface label space is not available; only per-platform label space is available.
• Downstream-on-Demand advertisement mode is not available; only Unsolicited Downstream is
available because it converges faster.
• Conservative Label Retention is not available; only Liberal Label Retention is available.
Configure Label Distribution Protocol

Enabling LDP is a two-step process:
1. Enable LDP globally. See page 65.

2. Enable LDP on an interface. See page 65.
Related Configuration Tasks

• Enable LDP on page 65
• Change the LSR Router ID on page 65
• Change the Holdtimes on page 65
• Change the Label Distribution Mode on page 66
• Direct the Flow of Label Advertisement on page 67
• Filter Incoming Label Bindings on page 67
• Manage and Monitor your LDP Configuration on page 68

Enable LDP
LDP is disabled by default. You may enable it globally, or on an individual interface. Periodic hellos are
sent out of all LDP-enabled interfaces once LDP is globally enabled.
1 Start the LDP process. mpls ldp enable CONFIGURATION
2 Enable LDP on an interface mpls ldp enable INTERFACE
Change the LSR Router ID

The router ID is an IP address that identifies the LSR and is used to decide whether the local or remote
LSR is active. The LSR with the highest IP address becomes the active LSR for session initialization. By
default, the highest interface IP address configured on the LSR, or the loopback address with highest IP
address is selected as LDP router-id; loopback interfaces are preferred.
Change the LSR router ID. mpls ldp router-id interface CONFIGURATION
The router ID is contained in the optional hello parameter IPv4 Transport Address. When you enter this
command, the router ID is not immediately changed; FTOS uses the new ID when it has to compute one,
most likely when LDP is globally disabled and re-enabled. At this time, the specified interface is used if:
• it is not a managment interface, and

• it has an IP address assigned, and
• it is not on a logical line card
If the conditions are not satisfied upon entering the configuration, but are later satisfied, FTOS uses the
new router ID at that time. If the interface currently chosen for router ID is deleted, or if the IP address is
removed, FTOS computes a new router ID. LDP reinitializes when the router ID is re-computed.
Change the Holdtimes

Between any two routers, there may be multiple hello adjacencies, but single LDP session.
• The Hello Adjacency Holdtime a timeout value for an adjacency, and by default is 15 seconds; hellos
are sent every 5 seconds.
• The Session Holdtime is the timeout value for the LDP Session. The default is 40 seconds for holdtime
and keepalives are sent every 13 seconds.
Change the timeout value for an LDP mpls ldp discovery holdtime seconds CONFIGURATION
adjacency. Default: 15 seconds
Change the timeout value for an LDP mpls ldp holdtime seconds CONFIGURATION
session.
Change the Label Distribution Mode

Change the label distribution mode from Ordered Control, which is the default, to Independent Control. A
mode change triggers an LDP re-init, which results in recycling all sessions and flushing all learned label
bindings.
• Independent Label Distribution Control—an LSR, when it recognizes an FEC, binds a label to it,
and distributes it.
• Ordered Label Distribution Control—an LSR binds a label to an FEC only if it is the egress LSR or
if it has received a binding for an FEC from its next hop.
An LSR is the egress LSR if:
• The FEC refers one of the LSRs directly connected interfaces.

• The next-hop for the FEC is outside the MPLS network.
Note: Force10 recommends configuring Independent Control mode before enabling LDP. If LDP is
already enabled, you must disable LDP globally (no mpls ldp enable) from CONFIGURATION mode, and
then re-enable LDP globally (mpls ldp enable) for the mpls ldp independent-control configuration to
take effect. After you enter this command, FTOS prompts you to execute the disable/re-enable with the
following message:
%% Configuration change will be in effect after LDP is disabled and enabled
globally.
1 Change the label distribution mpls ldp independent-control CONFIGURATION

mode. Default: ordered-control
2 Disable LDP globally. no mpls ldp enable CONFIGURATION
3 Re-enable LDP globally. mpls ldp enable CONFIGURATION

Direct the Flow of Label Advertisement
LDP uses the PushConditional distribution procedure by default; LDP is in Unsolicted Downstream and
Independent Label Distribution modes by default. LDP creates labels for all recognized FECs, and floods
local and learned labels are flooded to all peers. The result of this behavior is that an LSR might advertise
a label for an FEC, for which it is not the egress, before it receives a label for that FEC from its
downstream peer. Between advertising its label and receiving the label from downstream, if the LSR
receives a packet for that FEC, it either drops the packet or is forced to route the packet by IP. Even if this
does not occur, more labels are advertised than necessary.
To control the flow of advertisment, you may:
• allocated for a label for the IP address of an interface and advertise it to neighbors with /32 mask, or
• select the prefixes for which labels are advertised, and
• optionally, select the peers to which specified prefixes are advertised.
Allocate a label for an interface IP mpls ldp advertise-labels [interface interface | CONFIGURATION
address, or select the prefixes for for prefix-list [to peer-list]]
which labels are advertised.
Filter Incoming Label Bindings

Choose the labels that an LSR will mpls ldp neighbor ip-address labels accept CONFIGURATION
accept from a neighbor. prefix-list
MD5 Authentication
LDP uses the TCP/IP protocol suite; LDP listens on well-known TCP port 646 for incoming messages.
MD5 Authentication is a method that each LSR may use to authenticates its peer LSRs. Each LSR stores
the MD5 password, and only after password verification during the TCP handshake is the TCP session
established.
Enable neighbor authentication [no] mpls ldp neighbor ip-address password [ 7 CONFIGURATION
using an MD5 password. encrypted-pass | clear-pass]
Force10#show mpls ldp neighbor

Peer LDP Ident: 101.1.1.10:0: Local LDP Ident: 101.1.1.2:0
TCP connection: 101.1.1.2.646 - 101.1.1.10.35749
LDP session is MD5 authenticated
State: Oper; Msgs sent/rcvd: 4/20; Downstream
Up/Down Time: 00:00:12
Keepalive holdtime: sent/rcvd/neg 40/300/40 sec
Max PDU length: 4096 bytes
LDP discovery sources:
GigabitEthernet 8/6
Addresses bound to peer LDP Ident:
100.200.200.1
101.1.1.10
10.11.205.240
Whenever the MD5 password is updated (added/deleted/modified), the affected LDP sessions are
reinitialized, and FTOS displays Message 1.
Message 1 LDP MD5 Authentication
Jun 23 15:22:07: %RPM0-P:RP1 %LDP-5-NBRCHG: Connection with LDP neighbor 101.1.1.10:0 closed.
(Password Changed)
If the MD5 passwords do not match, FTOS displays Message 2.
Message 2 LDP MD5 Authentication Misconfiguration
Jun 21 15:39:11: %RPM0-P:RP1 %KERN-6-INT: LDP MD5 password mismatch from 101.1.1.10:11082 to
101.1.1.2:646
If the MD5 password is not configured on one LSR, FTOS displays Message 3.
Message 3 LDP MD5 Authentication Misconfiguration
Jun 21 11:25:09: %RPM0-P:RP1 %KERN-6-INT: No LDP MD5 from 101.1.1.10:57045 to 101.1.1.2:646
Manage and Monitor your LDP Configuration

FTOS offers the following tools to manage and monitor your LDP configuration:
• Log Neighbor Changes on page 69

• Clear Sessions and Counters on page 69

Log Neighbor Changes
The LDP session initialization state machine consists of five possible states. The system reaches
operational state when a TCP connection is established, LDP parameters have been negotiated, and
keepalives are being periodically transmitted. FTOS logs a state change whenever a neighbor transitsions
to or from operational state.
Enable or disable logging of LDP mpls ldp log-neighbor-changes EXEC Privilege

neighbor state changes. Logging is
enabled by default.
Clear Sessions and Counters
Clear LDP sessions for a specified clear mpls ldp neighbor {ip-address | *} EXEC Privilege
neighbor or all neighbors.
Clear LDP statistics for a specified clear mpls ldp statistics neighbor EXEC Privilege
neighbor or all neighbors. This {ip-address | *}
command clears the statistics
displayed in show mpls ldp
neighbor.
LDP show and debug Commands
Display LDP label errrors and debug mpls ldp {binding | error | events | EXEC Privilege
events. routing}
Display LDP protocol messages in debug mpls ldp dump [in | out | [address | EXEC Privilege
hexadecimal format. hello | init | keepalive | label | notification]
[in | out]]
Display LDP protocol messages in debug mpls ldp messages [in | out | EXEC Privilege
clear text. [address | hello | init | keepalive | label |
notification]] [in | out]
Display the LDP Label Information show mpls ldp bindings [ip-address/mask] EXEC Privilege
Base (LIB). [{local-label | remote-label} label] [neighbor
ip-address] [local]
Display sources for locally show mpls ldp discovery [detail] [interface] EXEC Privilege
generated discovery hello PDUs.
Display MPLS interfaces. show mpls ldp interfaces {interface | brief | EXEC Privilege
advertise-label}
Display LDP neighbor information. show mpls ldp neighbor [ip-address [detail] | EXEC Privilege
brief]
Display LDP configuration show mpls ldp parameters EXEC Privilege

parameters.

Chapter 6 MPLS Quality of Service
MPLS Quality of Service is supported only on platform ex

• MPLS-EXP Marking using Class Maps

• MPLS-EXP Marking using Qos Policies
• Propagating MPLS-EXP when Penultimate Hop Popping
• Advertising Explicit-Null
At ingress, MPLS-EXP is set based on the packet DSCP value. The incoming DSCP value can be matched
and mapped to the MPLS-EXP bit using class maps or QoS policies. Marking is based only on the DSCP
value, and marking is done on ingress only.
Note: It is possible to mark packets in the MPLS-EXP bit using both class maps and policy maps. In this
case, the class-map configuration takes precedence. If DSCP marking is also configured then the three
most significant bytes of the DSCP value, and the MPLS-EXP value, wherever configured (in a class map
or policy map), must match. It is possible that DSCP marking is configured with one value, and in another
context, MPLS-EXP marking is configured with a different value. In this case, the MPLS-EXP value used for
both DSCP and MPLS-EXP.
MPLS-EXP Marking using Class Maps

You can create a class map match against the incoming DSCP value and map the value to the MPLS-EXP
bit for MPLS marking. Use the match ip dscp value command with the option set-mpls-exp from the
CLASS-MAP context, as shown below.
Force10(conf)#class-map match-any BB
Force10(conf-class-map)#match ip dscp 4 ?
multicast Multicast entry
set-ip-dscp Mark input traffic
set-mpls-exp Mark input traffic from ip to mpls
<cr>
MPLS-EXP marking is independent of DSCP marking, so marking MPLS-EXP alone does not mark a
DSCP value.
Force10(conf-class-map)#match ip dscp 32 set-mpls-exp 3

% Info: To set the specified EXP value 3 (011 b) the class-map must be
mapped to queue3 (011 b).
MPLS-EXP and DSCP can be marked at the same point in time, but you must configure them with the
same value.
Force10(conf-class-map)#match ip dscp 32 set-mpls-exp 4 set-ip-dscp 33

% Info: To set the specified DSCP/EXP values's 33/4 (100-001 b) the
class-map must be mapped to queue4 (100 b).
Force10(conf-class-map)#
Force10(conf-class-map)#match ip dscp 32 set-mpls-exp 4 set-ip-dscp 20

% Error: IP-DSCP's first 3 MSB Bits must be same as MPLS-EXP's.
Force10#sh qos class-map BB
Class-map match-any BB
Match ip dscp 4 DSCP marking 3 EXP marking 3
By the usual Force10 QoS architecture, once you create a class map, you must map it to a policy map,
which must then be mapped to a service-policy on an interface.
Force10(conf)#policy-map-input BB
Force10(conf-policy-map-in)#service-queue 0 class-map BB
Force10(conf-policy-map-in)#int gig1/6
Force10(conf-if-gi-1/6)#service-policy input BB
MPLS-EXP Marking using Qos Policies

You can create a QoS policy to match against the incoming DSCP value and map the value to the
MPLS-EXP bit for MPLS marking. Use the set command with the option mpls-exp from the
QOS-POLICY-INPUT context.
Force10(conf)#qos-policy-input BB
Force10(conf-qos-policy-in)#set ?
ip-dscp Specify dscp values
mac-dot1p Specify dot1p values
mpls-exp Specify mpls exp values
Force10(conf-qos-policy-in)#set mpls-exp 3
Force10(conf-qos-policy-in)#show conf
!
qos-policy-input BB
set mpls-exp 3
By the usual Force10 QoS architecture, this QoS policy must be mapped to a policy map, which must then
be mapped to a service-policy on an interface
Propagating MPLS-EXP when Penultimate Hop Popping

By default, MPLS-EXP is propagated from the top label to the next label or to the DSCP value. To disable
this behavior, enter no mpls ip propagate-exp from CONFIGURATION mode. If disabled and then
re-enabled, only ILM entries that are created after mpls ip propagate-exp is re-enabled are propagated.
The following is a mapping from MPLS-EXP to DSCP when mpls ip propagate-exp is configured:
72 MPLS Quality of Service

• When EXP is 0, DSCP is 0
• When EXP is 1, DSCP is AF11 (001010)
• When EXP is 5, DSCP is Expedite forwarding (101110)
• When EXP is 6, DSCP is Network Control Low (110000)
• When EXP is 7, DSCP is Network Control High (111000)
Figure 20 MPLS-EXP at Transit Routers
Transit Penultimate Hop
Head-end Tail-end
EXP of outgoing packet is copied By default, MPLS-EXP is propagated

from incoming packet EXP. from the top label to the next label or
to the DSCP value.
FTOS Behavior: When two labels remain, and no mpls ip propagate-ttl is configured, mpls ip
propagate-exp (default) does not work. If you want to propagate MPLS-EXP in this case, you must
enable TTL Propagation (mpls ip propagate-ttl).
Advertising Explicit-Null
The Implicit-Null label is advertised by the Egress LSR, and it instructs the penultimate hop to remove the
top label before forwarding the packet, a process called Penultimate-Hop Popping (PHP). Explicit-Null is
also available on FTOS. At the penultimate hop, the incoming label is swapped for the Explicit-Null label
(Label 0 for IPv4, and Label 2 for IPv6). The Explicit-Null label alerts the Egress LSR that it is the egress
so that it can immediately remove the top label, a process called Ultimate-Hop Popping. Ultimate-hop
popping ensures that any packets traversing an MPLS network include a label. This is important for MPLS
Class of Service because packets are classified using the MPLS-EXP bits contained in the label. If PHP is
used, the MPLS-EXP bits are removed before the packet can be switched across the entire LSP. When the
top label is Explicit-Null, and only one label remains queuing is based on the packet DSCP value.
Note: After you configure mpls traffic-eng advertise label explicit-null you restart RSVP on the
interface by executing shutdown followed by no shutdown. Sessions through the interface are torn down
but Path Tear messages are not sent.
Force10(conf-if-gi-1/6)#mpls traffic-eng advertise label explicit-null
% Warning: Requires shut/noshut of GigabitEthernet 1/6
On the penultimate LSR, configure the mpls traffic-eng advertise explicit-null INTERFACE
system to swap the incoming top label
with the Explicit-Null label.
FTOS Behavior: With explicit-null, the penultimate hop queues packets based on the MPLS-EXP
value. However, on egress of the ultimate hop, Force10 systems queue based on the DSCP value.
Transit
Head-end Tail-end
3 MPLS EXP = 5 4 Queued according

IP DSCP = 4 to IP DSCP, Queue 4
1 Advertise
Explicit-Null
2 Outlabel =
Explicit-Null
74 MPLS Quality of Service

Chapter 7 RSVP-TE
RSVP-TE is supported only on platform ex

RSVP-TE is a set of extensions to RSVP that enable the use of RSVP with MPLS to establish label
switched paths. RSVP-TE extensions allow you to:
• establish LSPs with or without QoS requirements

• dynamically reroute LSPs
• preempt an established LSP based on administrative policy
• allocate and distribute labels
The following describes how LSPs are created in RSVP-TE:
1. RSVP-TE uses the Downstream-on-Demand label advertisement mode. The ingress LSR creates an
RSVP Path message with a LABEL_REQUEST object, and sends the message to the tunnel
destination.
2. The tunnel destination allocates a label and responds to the label request with an RSVP Resv message
containing a LABEL object, which label object immediately follows the relevant filter spec.
3. Each node along the LSP that receives the Resv message updates the Incoming Label Map (ILM) with
the label.
LSP are identified by a collection of three objects: SESSION, SENDER_TEMPLATE, and

FILTER_SPEC.
• The SESSION object contains the tunnel destination address, the tunnel ID, and the extended tunnel
ID, which is the ingress node’s address.
• The SENDER_TEMPLATE and FILTER_SPEC objects are identical. They contain the ingress node’s
address and the LSP ID.
• RSVP-TE is not available on VLAN interfaces.
Configure RSVP-TE
1. Enable RSVP globally. See page 76.
2. Enable RSVP on an interface by making a portion of the interface bandwidth reservable. See page 76.
Related Configuration Tasks
• Enable Bandwidth Logging on page 76
• Graceful Shutdown on page 77
• Enable Record Route on page 77
• Enable RSVP Hello Signaling on page 77
• Specify the Signaling Refresh Interval on page 79
• Enable Signaling Refresh Reduction on page 79
• Bandwidth Holding for Path Messages on page 81
• Enable TTL Checking on page 81
Enable RSVP
RSVP is disabled by default.
Enable the protocol globally. mpls rsvp enable CONFIGURATION
Specify the Reservable Amount of Interface Bandwidth

Global bandwidth pools define the shared amount of interface bandwidth available for RSVP reservations.
By default, FTOS allocates 75% of interface bandwidth for RSVP purposes.
Make a specific amount of interface bandwidth mpls rsvp bandwidth INTERFACE

reservable. global-pool [bandwidth]
Enable Bandwidth Logging

You can configure FTOS to log a message when LSP bandwidth consumption on an interface exceeds 90%
of the available RSVP bandwidth on the interface.
Enable bandwidth logging. mpls rsvp bandwidth logging INTERFACE
76 RSVP-TE
Graceful Shutdown
RSVP Graceful Shutdown provides a user-initiated approach to shutting down RSVP. By default, graceful
shutdown is disabled since a large number of RSVP sessions may take a long time to shut down, and a
session timeout on neighbor routers may be preferred.
Enable graceful shutdown. mpls rsvp graceful-shutdown CONFIGURATION
Enable Record Route

RECORD_ROUTE (RRO) is an object included in Path messages (and reflected back in Resv messages)
that collects a list of nodes in the path to the tunnel destination. This object may optionally record labels, if
the Label_Recording flag is set in the SESSION_ATTRIBUTES object. RRO has three possible uses:
• discover routing loops or loops in an explicit path

• notifiy the sender of path changes due to network topology changes
• identify the nodes in a path through IP routing to later create the same path explicitly
Recording starts when the tunnel ingress sends a Path message with this object, which contains the
sender’s IP address, and the tunnel ingress optionally sets the Label_Recording flag. Each node that
receives either a Path or Resv message with an RRO, prior to any other RRO processing, inspects each
address in the list. If the router’s own address appears in the list, a loop exists. If a loop is found in a Path
message, a PathErr message is sent to the originator. If a loop is found in a Resv message, the message is
dropped. Assuming no loop, each intermediate node stores the RRO as path state, adds a label, if required,
and then adds the address of the message’s outgoing interface. When the destination node receives the Path
message, it sends back a Resv message also with an RRO, and the process is completed in reverse, towards
the sender. Each node from source to destination is then aware of the entire route, which is useful for
network managment.
Enable route recording. Enabling recording after a tunnel traffic-eng record-route INTERFACE TUNNEL
tunnel is established does not re-establish it.
Recording begins when the next Path message is
sent.
Enable RSVP Hello Signaling

Hello signaling is an RSVP-TE extension that enables RSVP nodes to detect a failed neighbor through a
sub-second packet exchange. A node sends an RSVP message with the HELLO REQUEST object to its
immediate neighbor and expects a HELLO ACK object in return, within the hello interval.
Each node uses only one hello exchange per neighbor. The local node inserts an arbitrary instance value in
the request to identify the hello exchange that which must be reflected by the remote node in its ACK. The
local node assumes that the remote node has failed if it does not respond to a consecutive number of
requests, or the local node assumes that the remote node has reset if the the instance value in the ACK does
not match the value in the request. When communication with the remote node is lost, the remote node
resets, or the local node resets, the local node changes its instance value.
Enable RSVP hello signaling. mpls rsvp signalling hello enable INTERFACE
Optionally, choose a hello interval, mpls rsvp signalling hello {interval milliseconds | INTERFACE
and the number of hello packets misses number}
that must be unacknowledged to
consider the neighbor down.
78 RSVP-TE
You can display all of the active and inactive hello sessions in which the system is particpating, clear
message counters, and clear session statistics.
Display the hello sessions in which show mpls rsvp hello instance {summary | detail} EXEC Privilege
the system is participating.
Force10#show mpls rsvp hello instance summary
Active Instances:
Neighbor I/F State Num Lost LSPs Interval
192.168.53.4 Gi 0/21 Active 1 1 1000
Inactive instances:
- None -
Force10#show mpls rsvp hello instance detail

Neighbor 192.168.53.4, Source 192.168.53.1, Interface Gi 0/21
Session type is active
Session with neighbor up for 00:00:14
Last src instance 0x96988, neighbor instance 0x3DAE3C
Hello message received 85, sent 90
suppressed 57
Protected LSPs 1, Refresh interval 1000 msecs
Current missed acknowledgments 0, IP DSCP 0x30
Communication with neighbor lost 1 time(s), time since last 00:00:23
Reasons:
Session timeout 1, bad src instance 0, bad neighbor instance 0
Interface down 0
Clear hello counters for all clear mpls rsvp hello counters {packets | EXEC Privilege
instances. statistics}
Specify the Signaling Refresh Interval

RSVP stores reservations as soft state, which must be periodically refreshed through the receipt of a
matching path or reservation message. The default refresh period (R) is 30 seconds; unrefreshed state is
deleted after the local state lifetime (L) expires, which on FTOS is 4R and is equivalent to the number of
refresh messages that may be missed.
Configure the signaling refresh mpls rsvp signalling refresh {interval seconds | CONFIGURATION
values R and L. misses number}
Enable Signaling Refresh Reduction

RSVP uses refresh messages to synchronize state and recover from lost RSVP messages. This method,
however, has scaling, reliablility, and latency limitations.
• Refresh messages increase proportionally with the number of sessions. Processing resources are
required for generating, transmitting, and receiving refresh messages every R seconds.
• RSVP messages are transmitted using unreliable IP. Latency is introduced when non-refresh messages
are lost in transmission because RSVP recovers from lost messages via the next periodic refresh. When
R is large, there is a delay in changing reservation state, but when R is small, processing overhead
increases.
• RSVP recovers from loss of tear down messages through the local state lifetime timer (L), which clears
unrefreshed state, but this means that resources are allocated 4R longer than necessary.
The refresh reduction extensions address refresh volume and reliability with mechanisms other than
adjusting the refesh interval. RFC 2691 - RSVP Refresh Overhead Reduction Extensions introduces:
• Bundle Message—When configured, RSVP can delay messages so that many messages can be
combined into a single PDU. Bundle messages are exchanged between neighbors and can contain any
message (ACK, Srefresh, Resv, Path, PathTear) which has a destination address of a next hop.
Bundling conserves bandwidth and reduces processing overhead.
• MESSAGE_ID—Each RSVP Path and Resv message carries this object which contains an arbitrary
value that, combined with the sender’s IP address, uniquely identifes the message. The receiver uses
the message ID to determine if the message represents new state or a state refresh, and in the case of
new state, stores the message ID as part of the path or reservation state for future reference. The sender
may also set the ACK_Desired flag in this object to request an ACK from the next hop to ensure
reliability. Messages that are not acknowleged are retransmitted.
• MESSAGE_ID ACK—Each message in which the ACK_Desired flag is set must be acknowledged
using this object, which contains the ID of the message being acknowledged. One object is generated
per message ID, and they may be included in any RSVP message that is addressed to the node that
generated the original MESSAGE_ID object.
• Srefresh Message—Srefresh messages contain a list of previously advertised messages
(MESSAGE_ID_LIST) for which the state is unchanged. Since the receiver has stored the
MESSAGE_ID that contained the original state, it can refresh the corresponding entries. Srefresh
messages reduce processing overhead for the sender and receiver because complete Path and Resv
messages are not required to refresh state.
Enable RSVP signalling refresh mpls rsvp signalling refresh reduction enable CONFIGURATION
reduction. Default: Disabled
Do not set the ACK_Desired flag mpls rsvp signalling refresh reduction no-ack CONFIGURATION
for RSVP messages. Received Default: ACK enabled
messages with this flag set are still
acknowleged.
80 RSVP-TE
Bandwidth Holding for Path Messages
When an LSR receives a Path message indicating a bandwidth requirement, it earmarks the bandwidth on
the interface until a Reservation message is received. You can configure the amount of time the LSR holds
the bandwidth before releasing it for other reservations in case a reservation is unacceptably delayed or
never arrives.
Enter number of seconds bandwidth is held on an mpls traffic-eng CONFIGURATION

interface upon receiving a PATH message before it link-management timers
is confirmed by a RESV message. bandwidth-hold seconds
Enable TTL Checking

The TTL Check feature enables checking the time-to-live (TTL) field in the header of RSVP and IP
packets. When enabled, only PATH messages are dropped if the TTL check fails.
Enable TTL checking. mpls rsvp signalling ttl-check CONFIGURATION
82 RSVP-TE
Chapter 8 MPLS Traffic Engineering
A traffic trunk is a path along which a set of flows of the same FEC is switched. One of many possible
LSPs can be created for an FEC depending upon traffic engineering parameters, and so trunks can be
treated as movable objects that can be routed away from network failures, congestion, and bottlenecks.
Create a Tunnel
1 Tunnels are virtual interfaces like interface tunnel tunnel-id CONFIGURATION

port-channels and VLANs. Create one by Range: 1-16383
assigning a tunnel ID. This command
moves you to the INTERFACE TUNNEL
context.
2 Borrow an IP address from an interface. ip unnumbered interface INTERFACE TUNNEL
3 Specify the tunnel destination. tunnel destination ip-address INTERFACE TUNNEL
4 Enable the tunnel to operate in MPLS-TE tunnel mode mpls INTERFACE TUNNEL
mode.
FTOS Behavior: In a triangular configuration, prefixes before the tail-end are shown as reachable via
the tunnel. In the following configuration, Tunnel 2 is established through Te 5/1 and ends at R3.
Though the 21.1 network is before the tail-end, its is shown as reachable via Tunnel 2.
R1 R3
1.1.1.1 3.3.3.3
Force10(conf)#do sh run ospf
! 5/5 (15.1.1.1) 6/5
router ospf 10
network 0.0.0.0/0 area 0 5/6 (16.1.1.1) 6/6
mpls traffic-eng router-id Loopback 0
mpls traffic-eng area 0
Force10(conf)#do sh ip route ospf
Destination Gateway Dist/Metric Last Change Te 5/2
----------- ------- ----------- -----------
O 2.2.2.2/32 via 11.1.1.2, Te 5/1 110/2 00:09:55 11.1 21.1
O 3.3.3.3/32 via 0.0.0.0, Tu 2 110/2 00:07:06
O 21.1.1.0/24 via 11.1.1.2, Te 5/1 110/2 00:07:06 Tunnel 2 Tunnel 2
via 0.0.0.0, Tu 2
Force10(conf)#do sh mpl traffic-eng tunnels tunnel 2 | grep Exp
Explicit Route: 11.1.1.1 11.1.1.2 21.1.1.1 21.1.1.2
R2
2.2.2.2
Allocate Bandwidth to a Tunnel
1 Allocate bandwidth to a tunnel. tunnel mpls traffic-eng bandwidth INTERFACE TUNNEL

bandwidth
FTOS supports over subscription up to 65000%. Bandwidth reservation is available on port-channels. As

with physical interfaces, when channel members join and leave a port-channel, the physical bandwidth is
adjusted accordingly. If reservations on the port-channel are greater than what is currently available, low
priority tunnels are preempted.
OSPF—Traffic Engineering
OSPF—Traffic Engineering (OSPF-TE) Extensions is a set of administrator-defined link attributes, not
advertised in OSPF itself, that administrators can use to manipulate the standard OSPF topology. These
link attributes, primarily bandwidth-reservation constraints, are advertised in Type 10 Opaque LSAs, and
used by TE-capable routers to create an extended link state database (TE database), separate from the
OSPF link state database. Routers can then use the TE database to compute constraint-based (CSPF)
optimal routes from source to destination.
OSPF-TE extensions, defined in RFC 3630, capture the reservation state of primarily point-to-point links.
It defines a new Type 10, Opaque LSA, with an intra-area flooding scope, called the Traffic Engineering
LSA (TE LSA). Since Type 10 LSAs are intra-area, FTOS maintains a separate TE database for each area.
• Routers flood TE LSAs whenever the topology changes or required by OSPF.

• Receiving routers use the LSAs to update the TE database; TE LSAs are not used to perform
shortest-path first (SPF) calculations.
The TE LSA is Type 1 and starts with a standard LSA header. The payload is in Type, Length, Value (TLV)
format. There are two types of TLVs, both of which are mandatory in each LSA:
• Type 1: Router Address—always reachable IP address on the advertising router, typically a loopback
address.
• Type2: Link—describes a single link, and the descriptors are in TLV format. Each sub-TLV appears in
an LSA only once.
Table 6 Link TLV Sub-types
Type Name Description

1 Link Type 1: Point-to-Point
2: Multi-access
2 Link ID IP address of the remote end of the link; this TLV contains the same
information as the Router LSA. On a point-to-point link, this is the
router ID of the remote system
84 MPLS Traffic Engineering

Table 6 Link TLV Sub-types

3 Local Interface IP Address IP address of the local Interface. If there are multiple local
addresses, all are listed.
4 Remote Interface IP Address IP address of the remote interface. The local and remote addresses
are used to distinguish parallel links between systems. For
multi-access links, the remote interface IP address is 0.0.0.0, or not
sent.
5 Traffic Engineering Metric The link metric used for traffic engineering purposes. This value
might be different from the standard OSPF metric.
6 Maximum Bandwidth The uni-directional (local to remote) maximum bandwidth; the true
link capacity.
7 Maximum Reservable Bandwidth The uni-directional reservable bandwith; it may exceed the maximum
bandwidth, indicating oversubscription.
8 Unreserved Bandwidth Indicates the amount of unreserved bandwidth for each of 8 priority
levels, listed in increasing order.
9 Administrative Group Indicates membership to one or more of 32 administrative groups.
Enable MPLS-TE in an OSPF Area

OSPF-TE advertises RSVP bandwidth, Administrative Weight, and Administrative Groups for TE-enabled
links. You can enable MPLS-TE in one or more areas including on ABR LSRs. Although MPLS-TE can be
enabled in more than one IGP area, a single TE LSP is confined to a single area. Each area has a unique
Router ID.
1 Enable MPLS-TE in an OSPF area or mpls traffic-eng area number ROUTER OSPF
on an interface. INTERFACE
2 Select a router ID for the area. mpls traffic-eng router-id interface ROUTER OSPF
Display the TE advertisements that OSPF is sending on behalf of a particular interface or for all interfaces
using the command show ip ospf mpls traffic-eng interface. The advertised information includes the
bandwidth that is currently available with OSPF after threshold filtering is done by link management:
Force10#show ip ospf mpls traffic-eng interface

Area 0 has 1 MPLS TE links.
GigabitEthernet 5/7 :
Link connected to multiaccess network
Link ID : 17.1.1.2
Interface Address : 17.1.1.1
Admin Metric te: 1 igp: 1
Maximum bandwidth : 125000000
Maximum reservable bandwidth : 93750000
Number of Priority : 8
Affinity Bit : 0x0
Configure Bandwidth Usage Advertisement

You can set bandwidth usage values on an interface that when crossed trigger a TE advertisement from
IGPs to propagate this information to neighbors.
Set bandwidth usage mpls traffic-eng flooding thresholds {up | down} {value} INTERFACE
threshold values, that [[value] …]
when crossed, trigger
an IGP TE
advertisement.
LSAs are flooded immediately upon a topology change and when a bandwidth change crosses a threshold
value in the up or down direction. You can configure the periodic-flooding interval.
Set the flooding mpls traffic-eng link-management timers periodic-flooding CONFIGURATION

interval for bandwidth
usage triggered TE
advertisements.

IS-IS—Traffic Engineering
Each Intermediate System router advertises its links in Link State Protocol Data Units (LSPs) composed in
TLV format. IS-IS Traffic Engineering Extensions define new IS Neighbor and IP Reachability TLVs to
add link characteristics. The link characteristics are encoded in sub-TLVs, an encoding format not used in
standard IS-IS.
• The IS Reachability TLV is replaced by the Extended IS Reachability TLV, which contains the
sub-TLVs in Table 7.
• The IS IP Reachability TLV is replaced by the Extended IS Reachability TLV, which increases the
metric range.
Table 7 Extended IS Reachabiltiy Sub-TLVs

3 Administrative Group The administrative group sub-TLV contains a 4-octet bit mask
assigned by the network administrator. Each set bit corresponds to
one administrative group assigned to the interface.
6 IPv4 Interface Address Contains the IPv4 address for the interface described by the
reachability TLV.
8 IPv4 Neighbor Address The maximum bandwidth in bytes/second that can be used on this
link in the direction originator to neighbor.
9 Maximum Link Bandwidth Contains the maximum amount of bandwidth in bytes/second that
can be reserved in the direction originator to neighbor. For
oversubscription purposes, this can be greater than the bandwidth of
the link.
10 Reservable Link Bandwidth Contains the amount of bandwidth reservable. For oversubscription
purposes, this can be greater than the bandwidth of the link.
11 Unreserved Bandwidth The amount of bandwidth reservable in this direction on this link. For
oversubscription purposes, this can be greater than the bandwidth of
the link.
18 TE Default Metric A 24-bit administratively assigned metric used to present a
differently weighted topology to traffic engineering SPF calculations.
IS-IS-TE can be enabled on one or both levels.
1 Set the metric style to Wide. metric-style wide ROUTER ISIS
2 Enable TE on IS-IS Level 1 or Level 2. mpls traffic-eng {level-1 | level-2} ROUTER ISIS
3 Configure a traffic engineering router ID. mpls traffic-eng router-id ROUTER ISIS
interface
Route Traffic though Tunnels
There are three methods you can use to route traffic through tunnels rather than normal IGP routes:
• Map Traffic to Tunnels using Static Routes on page 88

• Enable IGP Autoroute on page 89
• Enable IGP Forwarding Adjacency on page 91
Map Traffic to Tunnels using Static Routes

Configuring a static route with tunnel as egress interface for a prefix installs the routes in routing table if
the tunnel is operationally up.
1 Enable RSVP and mpls rsvp enable CONFIGURATION

MPLS-TE globally. mpls traffic-eng enable
Force10(conf)#do show running-config mpls

!
mpls rsvp enable
2 Enable RSVP and traffic mpls rsvp bandwidth global-pool INTERFACE

engineering on mpls traffic-eng enable
interfaces.
Force10(conf-if-te-6/2)#show config
!
interface TenGigabitEthernet 6/2
ip address 1.4.1.1/24
no shutdown
3 Enable IGP-TE for mpls traffic-eng router-id interface ROUTER OSPF

adjacencies. mpls traffic-eng area number
Force10(conf-router_ospf-100)#show config
!
router ospf 100
network 100.0.0.0/8 area 100
network 1.0.0.0/8 area 100
mpls traffic-eng router-id Loopback 1
mpls traffic-eng area 100
4 Create a tunnel. interface tunnel number CONFIGURATION

ip unnumbered interface INTERFACE TUNNEL
tunnel destination ip-address
tunnel mode mpls
interface Tunnel 1
tunnel mode mpls
no shutdown

5 Create a static route with ip route ip-address/mask tunnel number CONFIGURATION

the tunnel as the egress
interface.
Force10#configure terminal
Force10(conf)#ip route 55.0.0.0 /8 tunnel 1
6 Display the configured show ip route static EXEC Privilege

static routes.
Force10#show ip route static
Destination Gateway Dist/Metric Last Change
----------- ------- ----------- -----------
S 55.0.0.0/8 via 0.0.0.0, Tu 1 0/0 00:00:08
show mpls forwarding table displays the incoming and outgoing labels of the tunnel, the outgoing
interface, and the next hop in the tunnel path.
Force10#show mpls forwarding table

Local Outgoing Prefix Outgoing Next Hop
tag tag or VC or Tunnel Id interface
16 16 1.3.2.2 1 [1] Po 10 1.2.1.2
show mpls forwarding entries linecard tunnel lists line card entries installed for a tunnel. The output
shows the labels per tunnel, outgoing interfaces, and packet and byte counters. When a packet is
forwarded through a tunnel the counters increment. In the output below, ten 1500-byte packets were sent
over the tunnel 1.
Force10#show mpls forwarding entries linecard 6 tunnel

Flags: H - entry in hardware, F - fast FRR is enabled, T - FRR triggered
TunnelID OutLabel Out-If Packets-Out Bytes-Out Flags
1 3 Po 10 10 15000 H
Enable IGP Autoroute

Autoroute enables OSPF or IS-IS to use a tunnel to reach a destination. The tunnel destination becomes the
next hop for its prefix. All traffic bound for the tunnel destination is routed through the tunnel. The tunnel
may also be used for traffic bound for a destination topologically behind it if the cost of using it is the
lowest compared to other IGP routes.
The cost of using a tunnel to reach prefixes beyond it is the tunnel cost plus the IGP link cost from the
tunnel destination to the ultimate destination. You can assign one of three types of metrics to a tunnel:
• metric— the specified value is used to reach the tunnel destination. Beyond the tunnel destination, the
IGP metric is used.
• absolute metric—the specified value is used to reach the tunnel destination and any destination
topologically behind the tunnel.
• relative metric— the specified value is added or subtracted from the IGP metric for the tunnel
destination. Beyond the tunnel destination, the IGP metric is used.
Figure 21 IGP Autoroute Metrics
destination topologically
Head-end Transit Tail-end behind the tunnel destination
LSP LSP
Absolute / Relative / Metric
Absolute
1 Make a tunnel tunnel mpls traffic-eng autoroute announce INTERFACE TUNNEL

available to OSPF for
best-path selection.
2 Display the tunnels show mpls traffic-eng autoroute EXEC Privilege

that are considered
during IGP best-path
calculations.
Force10#show mpls traffic-eng autoroute
MPLS TE autoroute is enabled
area ospf 0 area 0, has 3 tunnels
Tu 3 destination 60.60.60.60 (load balancing metric 0, nexthop 60.60.60.60)
(flags: Announce)
(flags: Announce)
(flags: Announce)
3 Assign a metric to the tunnel mpls traffic-eng autoroute metric {value | INTERFACE TUNNEL
tunnel. absolute absolute-metric | relative relative-metric}
Below are routes advertised by downstream routers before autoroute is enabled.
Force10(conf)#do show ip route
Codes: C - connected, S - static, R - RIP,

B - BGP, IN - internal BGP, EX - external BGP,LO - Locally Originated,
O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
E2 - OSPF external type 2, i - IS-IS, L1 - IS-IS level-1,
L2 - IS-IS level-2, IA - IS-IS inter area, * - candidate default,
> - non-active route, + - summary route
Gateway of last resort is not set

----------- ------- ----------- -----------
C 1.1.1.1/32 Direct, Lo 0 0/0 23:54:13
i L1 3.3.3.3/32 via 10.1.1.2, Gi 3/0 115/30 17:28:09
via 11.1.1.2, Gi 3/1
via 12.1.1.2, Gi 3/2

Tunnel 1 is created from Router A to downstream Router C and announced.
Force10(conf)#int tun 1
Force10(conf-if-tu-1)#tunnel mpls traffic-eng autoroute announce
Force10(conf-if-tu-1)#show config
!
interface Tunnel 1
tunnel mode mpls
tunnel mpls traffic-eng path-option 1 explicit name Tunnel1
tunnel mpls traffic-eng autoroute announce
no shutdown
Destinations reachable through Router C now have Tunnel 1 as their egress interface.
Force10(conf-if-tu-1)#do show ip route


----------- ------- ----------- -----------
C 1.1.1.1/32 Direct, Lo 0 0/0 1d0h
i L1 3.3.3.3/32 via 0.0.0.0, Tu 1 115/30 00:01:15
Enable IGP Forwarding Adjacency

A tunnel forwarding adjacency instructs OSPF or IS-IS to treat the tunnel as a link and as directly
connected to the head-end LSR. The head-end IGP includes the tunnel in its advertisements. While
Autoroute makes tunnels available only to the head-end, while Forwarding Adjacency makes tunnels
available to all area routers. Forwarding Adjacency advertises the tunnel interface as a normal
point-to-point link into the IGP with a default IGP cost of 1, and the tunnel destination is the neighbor’s
router-ID.
Note: Do not configure Autoroute and Forwarding Adjacency together; this yeilds undesirable results.
Enabling Forwarding Adjacency increases the size of the routing table in all systems in the area.
Following conditions are must for Forwarding Adjacency to work successfully.
• Verify that the tunnel’s borrowed IP address is advertised into the IGP.
• Verify that the tunnel destination is the TE router-ID of the tail-end.
• Verify that the IP address used as TE router-ID is advertised into the IGP.
• For OSPF, the tail-end must be in the same area.
1 Between two routers, create two tunnels, one in each direction.
2 Enable Forwarding Adjacency on each router. tunnel mpls traffic-eng INTERFACE TUNNEL
forwarding-adjacency
3 Optionally, configure a hold time. Forwarding mpls traffic-eng INTERFACE TUNNEL

adjacency hold time is the amount of time the forwarding-adjacency
local IGP waits before advertising a local holdtime interval
tunnel-down event to IGP neighbors. Delaying
the advertisements avoids frequent updates in
all routers in an area in case of tunnel flapping.
Prior to enabling Forwarding Adjacenty the head-end route table contains the following routes:
Force10#show ip route


----------- ------- ----------- -----------
C 100.1.1.1/32 Direct, Lo 0 0/0 00:00:23
O 100.1.1.2/32 via 192.168.20.2, Gi 3/14 110/2 00:00:18
O 100.1.1.3/32 via 192.168.20.2, Gi 3/14 110/3 00:00:01
The tunnel configuration is:

!
interface Tunnel 1
tunnel mode mpls
tunnel mpls traffic-eng forwarding-adjacency
no shutdown

Display the IGP-advertised tunnels:
Force10#show mpls traffic-eng forwarding-adjacency

MPLS TE forwarding adjacency is enabled
area ospf 0 area 0, has 1 tunnels
(flags: Forward-Adjacency, holdtime 0)
Force10#show ip route


----------- ------- ----------- -----------
C 100.1.1.1/32 Direct, Lo 0 0/0 00:08:23
O 100.1.1.2/32 via 192.168.20.2, Gi 3/14 110/2 00:03:24
O 100.1.1.3/32 via 0.0.0.0, Tu 1 110/2 00:01:13
The head-end advertises the link as a point-to-point:
Force10#show ip ospf database router adv-router 100.1.1.1
Router (Area 0)
LS age: 138
Options: (No TOS-capability, No DC, E)
LS type: Router
Link State ID: 100.1.1.1
Advertising Router: 100.1.1.1
LS Seq Number: 0x80000010
Checksum: 0xea91
Length: 60
Number of Links: 3
Link connected to: a Point-to-Point Network

(Link ID) Neighbor Router ID: 100.1.1.3
(Link Data) Router Interface address: 66.6.192.1
Number of TOS metric: 0
TOS 0 Metric: 1
The the tailend router in the reverse direction:
Force10#show ip ospf database router adv-router 100.1.1.3
Router (Area 0)
LS age: 29
LS type: Router
LS Seq Number: 0x8000000a
Checksum: 0x2d39
Length: 60
Number of Links: 3

The IGP cost of the tunnel interface is configurable:
Force10(conf-if-tu-1)#ip ospf cost 15

Force10(conf-if-tu-1)#show conf
!
interface Tunnel 1
tunnel mode mpls
tunnel mpls traffic-eng forwarding-adjacency
ip ospf cost 15
no shutdown
Force10(conf-if-tu-1)#do show ip ospf database router adv-router 100.1.1.1
Router (Area 0)
LS age: 5
LS type: Router
LS Seq Number: 0x80000017
Checksum: 0xd98d
Length: 60
Number of Links: 3

TOS 0 Metric: 15

Chapter 9 MPLS System Management and
Troubleshooting
• MPLS ping and traceroute on page 95
• Disable TTL Propagation on page 104
• Neither MPLS nor LDP ping will be sucessful if the frame is framented at any transit router.
MPLS ping and traceroute

The ping and traceroute commands help monitor LSPs and isolate MPLS forwarding problems.
MPLS echo packets are sent to the tunnel destination using the LSP label stack. MPLS echo packets use
127.X.X.X/8 as a destination address to prevent the packet from being IP routed to the destination if the
LSP is broken. MPLS echo replies are IP packets and can be IP routed or MPLS switched.
traffic-eng ping
Figure 22 MPLS ping and Extended MPLS ping
Tail-end
Head-end
1.3.4.1 Transit 1.4.1.2
1.4.1.1
1.3.4.2
Tunnel must be operationally up and have a borrowed IP address, as shown below.
Force10#show running-config interface tunnel 1

!
interface Tunnel 1
tunnel mode mpls
tunnel mpls traffic-eng path-option 1 explicit name 1241
tunnel mpls traffic-eng autoroute announce
no shutdown
Force10#show mpls forwarding table tunnel tunnel 1
Local Outgoing Prefix Outgoing Next Hop
tag tag or VC or Tunnel Id interface
- 35 100.1.1.3 1 [69] Te 6/0 1.2.1.2
Force10_T1 100.1.1.3 - Te 6/0 up/up
Ping a tunnel destination. ping mpls traffic-eng tunnel number EXEC Privilege
Force10#ping mpls traffic-eng tunnel 1
Codes: ! - success . - timeout . L - no label mapping

U - unsupported TLV M - malformed request F - no FEC mapping
D - mapping mismatch I - unknown upstream interface
S - label switched at stack depth f - FEC mismatch
x - unknown return code X - return code 0
Type Ctrl-C to abort.
Lsp Ping: Sending 5, 100-byte MPLS Echos on Tunnel 1, timeout is 3 seconds:

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
Ping a tunnel destination ping EXEC Privilege

using extended MPLS
ping options. When
prompted for the
protocol, enter the
keyword mpls.
96 MPLS System Management and Troubleshooting

Force10#ping
Protocol [ip] : mpls
Type: Traffic engineering or ldp
Type [Traffic-eng]: Traffic-eng
Tunnel Id: 1
Repeat Count [5]: 1
Datagram size [100]: 200
Timeout in secs [3]:
Verbose [n]:
Extended commands [n]: y
Source IP address: 100.1.1.1
Reply with Router-alert [n]:
Exp bits: 4
Time to live [255]:
Padding data pattern [0xABCD]:
Destination start address [127.0.0.1]: 127.0.0.1
Destination end address [127.0.0.1]: 127.0.0.10
Destination address increment [0.0.0.1]:
Sweep range of sizes [n]:

Lsp Ping: Sending 5, 100-byte MPLS Echos on Tunnel 1, timeout is 3 seconds:

Destination address 127.0.0.1
!
!
!
!
!
!
!
!
!
!
traffic-eng traceroute
Figure 23 MPLS traceroute and Extended MPLS traceroute
Tail-end
Head-end
1.3.4.1
Transit 1.4.1.2
1.4.1.1
1.3.4.2
Trace the route through a traceroute mpls traffic-eng tunnel number EXEC Privilege
tunnel.
Force10#traceroute mpls traffic-eng tunnel 1

LSP Traceroute: Tracing the route to Tunnel 1, 255 hops max

0 Self MTU 1554 [Labels: 16 EXP: 0]
S 1 1.3.4.2 MTU 1554 [Labels: implicit-null Exp: 0] 0 ms
! 2 1.4.1.2 MTU 0 0 ms
Trace the route through a traceroute EXEC Privilege

tunnel using extended
MPLS traceroute
options. When prompted
for the protocol enter the
keyword mpls.

Force10#traceroute
Type [Traffic-eng]: Traffic-eng
Tunnel Id: 1
Exp bits: 4
Time to live [255]:

LSP Traceroute: Tracing the route to Tunnel 1, 255 hops max

! 2 1.4.1.2 MTU 0 0 ms
ldp ping
Figure 24 LDP Ping and Extended LDP ping
Tail-end
R-ID: Lo 100.1.1.3./32
Head-end
192.168.20.1
Transit 192.168.30.3
R-ID: Lo 100.1.1.1./32 192.168.30.3
Force10#show mpls ldp bindings

192.168.20.0/24 192.168.20.2
Local binding: label Implicit-Null
Remote binding: lsr: 100.1.1.2, label: Implicit-Null
192.168.30.0/24
Local binding: label Not-Assigned R-ID: Lo 100.1.1.2./32
100.1.1.1/32
Remote binding: None
100.1.1.2/32
Local binding: label Not-Assigned
100.1.1.3/32
Remote binding: lsr: 100.1.1.2, label: 100004
Ping an LDP prefix. ping mpls ldp ip-address/mask EXEC Privilege
Force10# ping mpls ldp 100.1.1.3/32
Codes: ! - success, . - timeout, L - no label at stack depth

U - unsupported TLV, M - malformed request
D - DS mapping mismatch, I - unknown upstream interface
S - label switched at stack depth, N - no mpls fwd at stack depth
F - no FEC mapping at stack depth, f - FEC mismatch
P - no rx intf protocol, p - premature termination
X - unknown return code, x - return code 0
Lsp Ping: Sending 5, 100-byte MPLS Echos to 100.1.1.3/32, timeout is 3 seconds:

!!!!!
Ping an LDP prefix using ping EXEC Privilege

extended ldp ping
options. When prompted
for “Type,” enter the
keyword ldp.

Force10#ping
Type [Traffic-eng]: ldp
Target FEC IPv4 address: 100.1.1.3
Target FEC mask length: 32
Repeat Count [5]: 1
Datagram size [100]: 200
Verbose [n]:
Exp bits: 4
Time to live [255]:
Padding data pattern [0xABCD]:
Destination start address [127.0.0.1]: 127.0.0.1
Destination end address [127.0.0.1]: 127.0.0.10
Destination address increment [0.0.0.1]:
Sweep range of sizes [n]:

Lsp Ping: Sending 1, 200-byte MPLS Echos to 100.1.1.3/32, timeout is 3 seconds:

!
!
!
!
!
!
!
!
!
!

Force10#
ldp traceroute
Figure 25 LDP traceroute and Extended LDP traceroute
Tail-end
R-ID: Lo 100.1.1.3./32
Head-end
192.168.20.1
Transit 192.168.30.3
R-ID: Lo 100.1.1.1./32 192.168.30.3
Force10#show mpls ldp bindings

192.168.20.0/24 192.168.20.2
192.168.30.0/24
Local binding: label Not-Assigned R-ID: Lo 100.1.1.2./32
100.1.1.1/32
Remote binding: None
100.1.1.2/32
100.1.1.3/32
Remote binding: lsr: 100.1.1.2, label: 100004
Trace the route to an traceroute mpls ldp ip-address/mask EXEC Privilege

LDP prefix.
Force10#traceroute mpls ldp 100.1.1.3/32

LSP Traceroute: Tracing the route to 100.1.1.3/32, 255 hops max

! 2 192.168.30.3 MTU 0 0 ms
Trace the route to an traceroute EXEC Privilege

LDP prefix. When
prompted for “Type,”
enter the keyword ldp.

Force10#traceroute
Type [Traffic-eng]: ldp
Target FEC IPv4 address: 100.1.1.3
Target FEC mask length: 32
Exp bits: 4
Time to live [255]:

LSP Traceroute: Tracing the route to 100.1.1.3/32, 255 hops max

! 2 192.168.30.3 MTU 0 0 ms
FTOS-supported-Error Codes
Table 8 is a list of the error codes—defined in RFC 4379, Detecting Multi-Protocol Label Switched
(MPLS) Data Plane Failures—which FTOS supports.
Table 8 FTOS-supported MPLS ping and traceroute Error Codes
Output Code Echo Return Code Description

X Unknown Unknown error
x 0 No return code
M 1 Malformed echo request received
U 2 One or more TLVs not understood
F 4 Replying router has no mapping for the FEC at stack-depth
D 5 Downstream mapping mismatch
I 6 Upstream interface index unknown
S 8 Label switched at stack-depth
N 9 Label switched but no MPLS forwarding at stack-depth
f 10 Mapping for this FEC is not the given label at stack-depth
L 11 No label entry at stack-depth
P 12 Protocol not associated with interface at FEC stack-depth
p 13 Premature termination of ping due to label stack shrinking to a single label
Disable TTL Propagation
Disabling TTL propagation changes how ingress and egress LSR nodes read and process the TTL value in
a label. A label must have a value in the TTL field. By default, an ingress LSR reads the TTL field in the IP
header of the incoming packet, decrements it by 1, and copies what is left into the TTL field of the MPLS
header. Core LSRs forward the packet only if the TTL value in the uppermost label is not 0. With the no
mpls ip propagate-ttl command, the behavior changes such that the IP header TTL does not reflect the
hops taken across the MPLS core. Routers in the MPLS core network do not appear in traceroute
information.
FTOS Behavior: mpls ip propagate-exp (default) does not work for MPLS label-stacked packets
(more than one label), when no mpls ip propagate-ttl is configured. If you want to propagate
MPLS-EXP in this case, you must enable TTL.
Disable TTL propagation. no mpls ip propagate-ttl CONFIGURATION

Chapter 10 MPLS MIBs
MPLS MIBs is supported only on platform ex

• Label Distribution Protocol MIB on page 105

• Label Switch Router MIB on page 105
• Traffic Engineering MIB on page 110
• TE Scalars MIB Table on page 114
Label Distribution Protocol MIB

FTOS fully supports the LDP MIB (RFC3815) except for object: mplsFecIndexNext, OID
.1.3.6.1.2.1.10.166.4.1.3.8.2.0.
Label Switch Router MIB

The following MIB tables defined by RFC 3813, Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB), are available on FTOS. The objects in these tables
are used to populate the output of show mpls forwarding.
• mplsinterfaceTable
• mplsInterfacePerfTable
• mplsInSegmentTable
• mplsInSegmentPerfTable
• mplsOutSegmentTable
• mplsOutSegmentPerfTable
• mplsXCTable
Table 9 mplsLSRMIB Tables and OIDs

Object OID Description
The minimum value of an MPLS label that this LSR is
willing to receive on this interface.
mplsInterfaceLabelMinIn .1.3.6.1.2.1.10.166.2.1.1.1.2 Return Value: 16
The maximum value of an MPLS label that this LSR is
willing to receive on this interface.
mplsInterfaceLabelMaxIn .1.3.6.1.2.1.10.166.2.1.1.1.3 Return Value: 1048575
mplsInterfaceTable—.1.3.6.1.2.1.10.166.2.1.1
The minimum value of an MPLS label that this LSR is
willing to send on this interface.
mplsInterfaceLabelMinOut .1.3.6.1.2.1.10.166.2.1.1.1.4 Return Value: 16
The maximum value of an MPLS label that this LSR is
willing to send on this interface.
mplsInterfaceLabelMaxOut .1.3.6.1.2.1.10.166.2.1.1.1.5 Return Value: 1048575
Indicates the total amount of usable bandwidth on this
interface and is specified in kilobits per second (Kbps).
This variable is not applicable when applied to the
interface with index 0. When this value cannot be
measured, this value should contain the nominal
bandwidth.
mplsInterfaceTotalBandwidth .1.3.6.1.2.1.10.166.2.1.1.1.6 Return Value: 0
Indicates the total amount of available bandwidth
available on this interface and is specified in kilobits per
second (Kbps). This value is calculated as the difference
between the amount of bandwidth currently in use and
that specified in mplsInterfaceTotalBandwidth. This
variable is not applicable when applied to the interface
with index 0. When this value cannot be measured, this
value should contain the nominal bandwidth.
mplsInterfaceAvailableBandwidth .1.3.6.1.2.1.10.166.2.1.1.1.7 Return Value: 0
If the value of the mplsInterfaceIndex for this entry is
zero, then this entry corresponds to the per-platform label
space for all interfaces configured to use that label
space. In this case the perPlatform(0) bit MUST be set;
the per Interface(1) bit is meaningless and MUST be
ignored.
mplsInterfaceLabelParticipationType .1.3.6.1.2.1.10.166.2.1.1.1.8 Return Value: 00
mplsInterfacePerfTable—.1.3.6.1.2.1.10.166.2.1.2
The index for this in-segment. The string containing the

mplsInSegmentIndex .1.3.6.1.2.1.10.166.2.1.4.1.1 single octet 0x00 MUST not be used as an index.
The interface index for the incoming MPLS interface. A
value of zero represents all interfaces participating in the
per-platform label space. This may only be used in cases
where the incoming interface and label are associated
with the same mplsXCEntry. Specifically, given a label
and any incoming interface pair from the per-platform
label space, the outgoing label/interface mapping
remains the same. If this is not the case, then individual
entries MUST exist that can then be mapped to unique
mplsXCEntries.
mplsInSegmentInterface .1.3.6.1.2.1.10.166.2.1.4.1.2 Return Value: 0
If the corresponding instance of mplsInSegmentLabelPtr
is zeroDotZero then this object MUST contain the
incoming label associated with this in-segment. If not this
object SHOULD be zero and MUST be ignored.
Return Value: Incoming label values on the transit router
mplsInSegmentLabel .1.3.6.1.2.1.10.166.2.1.4.1.3 for the tunnels.
106 MPLS MIBs

If the label for this segment cannot be represented fully
within the mplsInSegmentLabel object, this object MUST
point to the first accessible column of a conceptual row in
an external table containing the label. In this case, the
mplsInSegmentTopLabel object SHOULD be set to 0 and
ignored. This object MUST be set to zeroDotZero
otherwise.
mplsInSegmentLabelPtr .1.3.6.1.2.1.10.166.2.1.4.1.4 Return Value: 0.0
mplsInSegmentTable—.1.3.6.1.2.1.10.166.2.1.4
The number of labels to pop from the incoming packet.
Normally only the top label is popped from the packet
and used for all switching decisions for that packet. This
is indicated by setting this object to the default value of 1.
If an LSR supports popping of more than one label, this
object MUST be set to that number. This object cannot
be modified if mplsInSegmentRowStatus is active(1).
mplsInSegmentNPop .1.3.6.1.2.1.10.166.2.1.4.1.5 Return Value: 1
The IANA address family [IANAFamily] of packets
received on this segment, which is used at an egress
LSR to deliver them to the appropriate layer 3 entity. A
value of other(0) indicates that the family type is either
unknown or undefined; this SHOULD NOT be used at an
egress LSR. This object cannot be modified if
mplsInSegmentRowStatus is active(1).
mplsInSegmentAddrFamily .1.3.6.1.2.1.10.166.2.1.4.1.6 Return Value: 1
Index into mplsXCTable, which identifies which
cross-connect entry this segment is part of. The string
containing the single octet 0x00 indicates that this entry
is not referred to by any cross-connect entry. When a
cross-connect entry is created, which this in-segment is a
part of, this object is automatically updated to reflect the
value of mplsXCIndex of that cross-connect entry.
mplsInSegmentXCIndex .1.3.6.1.2.1.10.166.2.1.4.1.7 Return Value: mplsXCIndex of mplsXCTable
The entity that created and is responsible for managing
this segment.
Return Value: Returns a value of 6, which means
mplsInSegmentOwner .1.3.6.1.2.1.10.166.2.1.4.1.8 RSVP-TE.
A variable that represents a pointer to the traffic
parameter specification for this in-segment. This value
may point at an entry in the mplsTunnelResourceTable in
the MPLS-TE-STD-MIB (RFC3812) to indicate which
traffic parameter settings for this segment if it represents
an LSP used for a TE tunnel. This value may optionally
point at an externally defined traffic parameter
specification table. A value of zeroDotZero indicates
best-effort treatment. By having the same value of this
object, two or more segments can indicate resource
sharing of such things as LSP queue space, etc. This
object cannot be modified if mplsInSegmentRowStatus is
active(1). For entries in this table that are preserved after
a re-boot, the agent MUST ensure that their integrity be
preserved, or this object should be set to 0.0 if it cannot.
mplsInSegmentTrafficParamPtr .1.3.6.1.2.1.10.166.2.1.4.1.9 Return Value: 0.0
A variable that is used to create, modify, and/or delete a
row in this table. When a row in this table has a row in the
active(1) state, no objects in this row can be modified
except mplsInSegmentRowStatus and
mplsInSegmentStorageType.
mplsInSegmentRowStatus .1.3.6.1.2.1.10.166.2.1.4.1.10 Return Value: 1
A variable that indicates the storage type for this object.
The agent MUST ensure that this value remains
consistent with the associated mplsXCEntry. Conceptual
rows having the value
'permanent' need not allow write-access to any columnar
objects in the row.
mplsInSegmentStorageType .1.3.6.1.2.1.10.166.2.1.4.1.11 Return Value: 2
mplsInSegmentPerfTable—.1.3.6.1.2.1.10.166.2.1.5
A unique index for this row. While a value of a string
containing the single octet 0x00 is not valid as an index
for entries in this table, it can be supplied as a valid value
to index the mplsXCTable to represent entries for which
mplsOutSegmentIndex .1.3.6.1.2.1.10.166.2.1.7.1.1 no out-segment exists or has been configured.
The interface index of the outgoing interface. Cannot be
modified if mplsOutSegmentRowStatus is active(1).
mplsOutSegmentRowStatus cannot be set to active(1)
until this object is set to a value corresponding to a valid
ifEntry.
mplsOutSegmentInterface .1.3.6.1.2.1.10.166.2.1.7.1.2 Return Value: Interface index of the outgoing interface.
Indicates whether or not a top label should be pushed
onto the outgoing packet's label stack. The value of this
variable MUST be set to true(1) if the outgoing interface
does not support pop-and-go (and no label stack
remains). For example, on an ATM interface, or if the
segment represents a tunnel origination. Note that it is
considered an error in the case that
mplsOutSegmentPushTopLabel
is set to false, but the cross-connect entry which refers to
this out-segment has a non-zero mplsLabelStackIndex.
The LSR MUST ensure that this situation does not
happen. This object cannot be modified if
mplsOutSegmentRowStatus is active(1).
Return Value: 1 if an FRR swap label value is present. 0
mplsOutSegmentPushTopLabel .1.3.6.1.2.1.10.166.2.1.7.1.3 if the FRR swap label is Implicit-Null.
If mplsOutSegmentPushTopLabel is true then this
represents the label that should be pushed onto the top
of the outgoing packet's label stack. Otherwise this value
SHOULD be set to 0 by the management station and
MUST be ignored by the agent. This object cannot be
modified if mplsOutSegmentRowStatus is active(1).
Return Value: FRR swap label value. 3 if the FRR swap
mplsOutSegmentTopLabel .1.3.6.1.2.1.10.166.2.1.7.1.4 label is Implicit-Null.
If the label for this segment cannot be represented fully
within the mplsOutSegmentLabel object, this object
MUST point to the first accessible column of a
conceptual row in an external table containing the label.
In this case, the mplsOutSegmentTopLabel object
SHOULD be set to 0 and ignored. This object MUST be
set to zeroDotZero otherwise.
mplsOutSegmentTopLabelPtr .1.3.6.1.2.1.10.166.2.1.7.1.5 Return Value: 0.0
mplsOutSegmentTable—.1.3.6.1.2.1.10.166.2.1.7
Indicates the next-hop Internet address type. Only values
unknown(0), IPv4(1) or IPv6(2) are supported. A value of
unknown(0) is allowed only when the outgoing interface
is of type point-to-point. If any other unsupported values
are attempted in a set operation, the agent MUST return
an inconsistent-value error.
mplsOutSegmentNextHopAddrType .1.3.6.1.2.1.10.166.2.1.7.1.6 Return Value: Returns a value of 1, which maps to IPV4.
108 MPLS MIBs

The internet address of the next hop. The type of this
address is determined by the value of the
mplslOutSegmentNextHopAddrType object. This object
cannot be modified if mplsOutSegmentRowStatus is
active(1).
Return Value: Returns the next-hop address for all the
entries present on the transit router. It returns all the
next-hop addresses present including for the backup
mplsOutSegmentNextHopAddr .1.3.6.1.2.1.10.166.2.1.7.1.7 tunnels which are originated from the PLR.
Index into mplsXCTable which identifies which
cross-connect entry this segment is part of. A value of the
string containing the single octet 0x00indicates that this
entry is not referred to by any cross-connect entry. When
a cross-connect entry is created which this out-segment
is a part of, this object MUST be updated by the agent to
reflect the value of mplsXCIndex of that cross-connect
entry.
Return Value: Returns the same value as mplsxcindex
mplsOutSegmentXCIndex .1.3.6.1.2.1.10.166.2.1.7.1.8 of mplsxctable.
The entity which created and is responsible for managing
this segment.
Return Value: Returns a value of 6 which means
mplsOutSegmentOwner .1.3.6.1.2.1.10.166.2.1.7.1.9 RSVP-TE.
A pointer to the traffic parameter specification for this
out-segment. This value may point at an entry in the
MplsTunnelResourceEntry in the MPLS-TE-STD-MIB
(RFC3812) to indicate which traffic parameter settings for
this segment if it represents an LSP used for a TE tunnel.
This value may optionally point at an externally defined
traffic parameter specification table. A value of
zeroDotZero indicates best-effort treatment. By having
the same value of this object, two or more segments can
indicate resource sharing of such things as LSP queue
space, etc. This object cannot be modified if
lsOutSegmentRowStatus is active(1). For entries in this
table that are preserved after a re-boot, the agent MUST
ensure that their integrity be preserved, or this object
should be set to 0.0 if it cannot.
mplsOutSegmentTrafficParamPtr .1.3.6.1.2.1.10.166.2.1.7.1.10 Return Value: 0.0
For creating, modifying, and deleting this row. When a
row in this table has a row in the active(1) state, no
objects in this row can be modified except
mplsOutSegmentRowStatus or
mplsOutSegmentStorageType.
mplsOutSegmentRowStatus .1.3.6.1.2.1.10.166.2.1.7.1.11 Return Value: 1
This variable indicates the storage type for this object.
The agent MUST ensure that this object value remains
consistent with the associated mplsXCEntry. Conceptual
rows having the value 'permanent' need not allow
write-access to any columnar objects in the row.
mplsOutSegmentStorageType .1.3.6.1.2.1.10.166.2.1.7.1.12 Return Value: 2
mplsOutSegmentPerfTable—.1.3.6.1.2.1.10.166.2.1.8
Primary index for the conceptual row identifying a group

of cross-connect segments. The string containing a
mplsXCIndex .1.3.6.1.2.1.10.166.2.1.10.1.1 single octet 0x00 is an invalid index.
Incoming label index. If this object is set to the string
containing a single octet 0x00, this indicates a special
case outlined in the table's description above. In this
mplsXCInSegmentIndex .1.3.6.1.2.1.10.166.2.1.10.1.2 case no corresponding mplsInSegmentEntry shall exist.
Index of out-segment for LSPs not terminating on this
LSR if not set to the string containing the single octet
0x00. If the segment identified by this entry is
terminating, then this object MUST be set to the string
containing a single octet 0x00 to indicate that no
mplsXCOutSegmentIndex .1.3.6.1.2.1.10.166.2.1.10.1.3 corresponding mplsOutSegmentEntry shall exist.
Identifies the label switched path that this cross-connect
entry belongs to. This object cannot be modified if
mplsXCRowStatus is active(1) except for this object.
Return Value: The instance IDs of transit router tunnels,
which show the instance IDs of the tunnels originating
mplsXCLspId .1.3.6.1.2.1.10.166.2.1.10.1.4 from transit router as well.
mplsXCTable—.1.3.6.1.2.1.10.166.2.1.10
Primary index into mplsLabelStackTable identifying a
stack of labels to be pushed beneath the top label. Note
that the top label identified by the out-segment ensures
that all the components of a multipoint-to-point
connection have the same outgoing label. A value of the
string containing the single octet 0x00 indicates that no
labels are to be stacked beneath the top label. This
object cannot be modified if mplsXCRowStatus is
active(1).
mplsXCLabelStackIndex .1.3.6.1.2.1.10.166.2.1.10.1.5 Return Value: 0
The entity that created and is responsible for managing
this cross-connect.
Return Value: Returns a value of 6, which means
mplsXCOwner .1.3.6.1.2.1.10.166.2.1.10.1.6 RSVP-TE.
For creating, modifying, and deleting this row. When a
row in this table has a row in the active(1) state, no
objects in this row except this object and the
mplsXCStorageType can be modified.
mplsXCRowStatus .1.3.6.1.2.1.10.166.2.1.10.1.7 Return Value: 1
A variable that indicates the storage type for this object.
The agent MUST ensure that the associated in and out
segments also have the same StorageType value and
are restored consistently upon system restart. This value
SHOULD be set to permanent(4) if created as a result of
a static LSP configuration. Conceptual rows having the
value 'permanent' need not allow write-access to any
columnar objects in the row.
mplsXCStorageType .1.3.6.1.2.1.10.166.2.1.10.1.8 Return Value: 2
The desired operational status of this segment.
Return Value: “Up” if there is a tunnel/segment present,
mplsXCAdminStatus .1.3.6.1.2.1.10.166.2.1.10.1.9 and no value returned if no segment is present.
The actual operational status of this cross-connect.
Return Value: “Up” if there is a tunnel/segment present,
mplsXCOperStatus .1.3.6.1.2.1.10.166.2.1.10.1.10 and no value returned if no segment is present.
Traffic Engineering MIB

The following MIB tables defined by RFC3970, A Traffic Engineering MIB, are available on FTOS. The
objects in these tables are used to populate the output of show mpls traffic-eng tunnels.
• mplsTunnelTable
110 MPLS MIBs

• mplsTunnelResourceTable
• mplsTunnelHopTable
• mplsTunnelARHopTable
• mplsTunnelCHopTable
mplsTunnelTable
• Entries in this table with an instance of 0 and a source address of 0 represent tunnel head
configurations. All other entries in this table represent instances of LSPs, both signaled and standby.
• If a tunnel instance is signaled, its operating status (operStatus) is set to "up" (1), and its instance
corresponds to an active LSP.
• Tunnel configurations exist only on the tunnel head where the tunnel interface is defined. LSPs
traverse the network and involve tunnel heads, tunnel midpoints, and tunnel tails.
• Pointers in the tunnel table refer to corresponding entries in other MIB tables. By using these pointers,
you can find an entry in the mplsTunnelTable and follow a pointer to other tables for additional
information. The pointers are the following: mplsTunnelResourcePointer, mplsTunnelHopTableIndex,
mplsTunnelARHopTableIndex, and mplsTunnelCHopTableIndex.
Table 10 mplsTunnelTable MIB Objects
mplsTunnelName 1.3.6.1.2.1.10.166.3.2.2.1.5 The canonical name assigned to the

tunnel. By default, FTOS uses
“Hostname_TX”, where X indicates the
tunnel number.
mplsTunnelDescr .1.3.6.1.2.1.10.166.3.2.2.1.6 A text string containing information about

the tunnel. Empty by default.
mplsTunnelIsIf .1.3.6.1.2.1.10.166.3.2.2.1.7 A value of True indicates that the tunnel

interface corresponds to an interface object
in the IfTable of RFC 2863. If True, the
IfName and the mplsTunnelName matches.
This object applies to ingress and egress
LSRs only. Currently it returns a value of 2.
Return Value: 1
mplsTunnelIfIndex .1.3.6.1.2.1.10.166.3.2.2.1.8 A value of True for mplsTunnelIsIf means

that this value contains the LSR-assigned
ifIndex that corresponds to an entry in the
IfTable. A value of 0 indicates no valid
ifIndex is assigned to this tunnel interface.
mplsTunnelOwner .1.3.6.1.2.1.10.166.3.2.2.1.9 Denotes the entity that created and is

responsible for managing this tunnel. This
column is automatically filled by the agent
upon creation of a row.
Return Value: 6
mplsTunnelRole .1.3.6.1.2.1.10.166.3.2.2.1.10 Indicates position in tunnel: head, tail, or,

midpoint. Returns a value only for tunnel
head-end.
mplsTunnelXCPointer .1.3.6.1.2.1.10.166.3.2.2.1.11 A pointer to a row in the mplsXCTable,

which identifies the segments of a tunnel,
their characteristics, and their relationships
to each other. A value of zeroDotZero
indicates that no LSP has been associated
with this tunnel.
mplsTunnelSignallingProto .1.3.6.1.2.1.10.166.3.2.2.1.12 The signaling protocol used to setup this

tunnel.
mplsTunnelSetupPrio .1.3.6.1.2.1.10.166.3.2.2.1.13 The setup priority of the tunnel. Reflects the

value configured using mpls traffic-eng
setup-priority and using show mpls
traffic-eng tunnels tunnel. Default: 7
mplsTunnelHoldingPrio .1.3.6.1.2.1.10.166.3.2.2.1.14 The holding priority of the tunnel. Reflects

the value configured using mpls
traffic-eng setup-priority {value}
hold-priority {value} and verified using
show mpls traffic-eng tunnels tunnel.
Defaults: 7.
mplsTunnelSessionAttributes .1.3.6.1.2.1.10.166.3.2.2.1.15 A bit mask indicating the optional session

values for this tunnel.
mplsTunnelLocalProtectInUse .1.3.6.1.2.1.10.166.3.2.2.1.16 The local repair mechanism used for tunnel

maintenance. A value of 1 indicates local
protection is enabled. Default: 2
mplsTunnelResourcePointer .1.3.6.1.2.1.10.166.3.2.2.1.17 A pointer to the traffic parameter

specification for this tunnel.
mplsTunnelPrimaryInstance .1.3.6.1.2.1.10.166.3.2.2.1.18 The instance index of the primary instance

of this tunnel.
mplsTunnelInstancePriority .1.3.6.1.2.1.10.166.3.2.2.1.19 Displays the priority in descending order

within a group of tunnel instances. Zero is
the lowest priority.
mplsTunnelHopTableIndex .1.3.6.1.2.1.10.166.3.2.2.1.20 On a tunnel head-end, provides an index

into the mplsTunnelHopTable entry that
specifies the explicit route hops for this
tunnel.
mplsTunnelPathInUse .1.3.6.1.2.1.10.166.3.2.2.1.21 The configured path (by name) selected for

the tunnel.
112 MPLS MIBs

mplsTunnelARHopTableIndex .1.3.6.1.2.1.10.166.3.2.2.1.22 Index into the mplsTunnelARHopTable

entry that specifes the actual hops
traversed by the tunnel. Returns a value of
0.
mplsTunnelCHopTableIndex .1.3.6.1.2.1.10.166.3.2.2.1.23 Index into the mplsTunnelCHopTable entry

that specifies the computed hops traversed
by the tunnel. Returns a value of 1.
mplsTunnelIncludeAnyAffinity .1.3.6.1.2.1.10.166.3.2.2.1.24 A link satisfies the include-any constraint if

and only if the constraint is zero, or the link
and the constraint have a resource class in
common. This value is always set to zero.
mplsTunnelExcludeAnyAffinity .1.3.6.1.2.1.10.166.3.2.2.1.26 A link satisfies the exclude-any constraint if

and only if the link contains none of the
administrative groups specified in the
constraint. The test excludes a link from
consideration if the link carries any of the
attributes in the set. The value equates to
affinity minus the mask value.
mplsTunnelTotalUpTime .1.3.6.1.2.1.10.166.3.2.2.1.27 The aggregate uptime for all instances of

this tunnel. Returns a value 0 if the uptime
is unavailable.
mplsTunnelInstanceUpTime .1.3.6.1.2.1.10.166.3.2.2.1.28 The total time that this tunnel instance’s

operStatus has been Up (1).
mplsTunnelIncludeAllAffinity .1.3.6.1.2.1.10.166.3.2.2.1.25 A link satisfies the include-all constraint if

and only if the link contains all of the
administrative groups specified in the
constraint. This test accepts a link only if
the link carries all of the attributes in the
set. (include-all ==0) | (((link-attr &
include-all)^include-all)==0). This will be
equal to the affinity value set on the tunnel.
For exampls, if affinity is 8 and the mask is
F then the value returned is 8.
mplsTunnelPrimaryUpTime .1.3.6.1.2.1.10.166.3.2.2.1.29 The total time that the primary instance of

this tunnel has been active.
mplsTunnelPathChanges .1.3.6.1.2.1.10.166.3.2.2.1.30 The number of times that the actual path

for this tunnel instance has changed. For
example, changing the secondary link to a
primary link for a tunnel increments the
counter.
mplsTunnelLastPathChange .1.3.6.1.2.1.10.166.3.2.2.1.31 The time since the last change to the actual
path for this tunnel instance. A path change
inside a tunnel should change the value.
The value is reflected in the output of show
mpls traffic-eng tunnels tunnel.
mplsTunnelCreationTime .1.3.6.1.2.1.10.166.3.2.2.1.32 Specifies the value of SysUpTime when the

first instance fo this tunnel came into
existence. That is, when the value of
mplsTunnelOperStatus was first set to Up
(1). Displays the time when the tunnel was
first created, which also appears in the
output of show mpls traffic-eng tunnels.
mplsTunnelStateTransitions .1.3.6.1.2.1.10.166.3.2.2.1.33 Specifies the number of times the state

(mplsTunnelOperStatus) of this tunnel
instance has changed.
mplsTunnelAdminStatus .1.3.6.1.2.1.10.166.3.2.2.1.34 Indicates the desired operational status of

this tunnel. A value of 1 is returned when
the tunnel is “Admin Up,” and 2 is returned
when it is down.
mplsTunnelOperStatus .1.3.6.1.2.1.10.166.3.2.2.1.35 Indicates the actual operational status of

this tunnel, which is typically, but not limited
to, a function of the state of individual
segments of this tunnel. A value of 1 is
returned when the tunnel is operationally
up and 2 is returned when the tunnel is
down.
mplsTunnelRowStatus .1.3.6.1.2.1.10.166.3.2.2.1.36 Return a value fo 1.
mplsTunnelStorageType .1.3.6.1.2.1.10.166.3.2.2.1.37 Returns a value of 2.
TE Scalars MIB Table

TE Scalars is a MIB table in draft-ietf-ccamp-gmpls-ted-mib-05, Traffic Engineering Database
Management Information Base in support of MPLS-TE/GMPLS defines the Management Information
Base (MIB) objects for managing the traffic-engineering database.
Table 11 TE Scalars MIB Table
mplsTunnelConfigured .1.3.6.1.2.1.10.166.3.1.1.0 Total number of configured tunnels.
mplsTunnelActive .1.3.6.1.2.1.10.166.3.1.2.0 Total number of active configured tunnels.
114 MPLS MIBs

Table 11 TE Scalars MIB Table
mplsTunnelTEDistProto .1.3.6.1.2.1.10.166.3.1.3.0 Currently running distribution protocol.

Return Value: OSPF+ISIS
mplsTunnelMaxHops .1.3.6.1.2.1.10.166.3.1.4.0 Maximum number of hops in a tunnel.

Return Value: 65536
mplsTunnelConfigured .1.3.6.1.2.1.10.166.3.1.1.0 Total number of configured tunnels.
116 MPLS MIBs
Chapter 11 FTOS-supported RFCs
The FTOS implementation of MPLS is in accordance with the following RFCs:
E-Series
RFC Title ExaScale
2702 Requirements for Traffic Engineering Over MPLS 8.3.1.0
3031 Multiprotocol Label Switching Architecture 8.3.1.0
3032 MPLS Label Stack Encoding 8.3.1.0
3209 RSVP-TE: Extensions to RSVP for LSP Tunnels 8.3.1.0
3630 Traffic Engineering (TE) Extensions to OSPF Version 2 8.3.1.0
3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) 8.3.1.0
3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information 8.3.1.0
Base (MIB)
3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management 8.3.1.0
Information Base (MIB)
4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels 8.3.1.0
4379 Detecting Multi-Protocol Label Switched Data Plane Failures (MPLS TE/LDP Ping & 8.3.1.0
traceroute)
5036 LDP Specification 8.3.1.0
5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart 8.3.1.0
118 FTOS-supported RFCs

BGP Case Studies

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BGP Case Studies

Uploaded by

Copyright:

Available Formats

MPLS Configuration Guide

for E-Series ExaScale

Label Distribution Protocol

Constrained Shortest Path First

MPLS High Availability

Multi-Protocol Label Switching—Traffic Engineering

Resource Reservation Protocol—Traffic Engineering

MPLS Monitoring and Network Management

Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

MPLS packet header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CAM Profile and CAM Usage for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

RSVP-TE Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

MPLS-EXP Marking using Class Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Label Distribution Protocol MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Multiprotocol Label Switching is supported only on platform ex

• MPLS packet header

• Destination Unicast address

• Destination address prefix

Figure 1 MPLS within core network

Router Switch/Router Switch/Router Router

16 Multiprotocol Label Switching

Figure 2 MPLS shim header

Link Layer MPLS SHIM Network Layer

Label EXP S TTL

The MPLS header is 32 bits long.

MTU discovery and packet fragmentation

• Customer Edge Router:

18 Multiprotocol Label Switching

Customer IP Provider IP Network Customer IP

Customer Edge Ingress LSR Egress LSR Customer Edge

MPLS supports both merge and non-merge LSR.

MPLS label swapping

To perform label-based switching, some mapping tables are required:

Forwarding labeled packets

1. Looks up the label in the ILM.

Forwarding unlabeled packets

20 Multiprotocol Label Switching

Label Switched Paths

Content Addressable Memory (CAM)

• RSVP-TE Graceful Restart

Label Distribution Protocol

Resource Reservation Protocol

Refer to Chapter 3, RSVP-TE for complete information regarding RSVP.

22 Multiprotocol Label Switching

1. CAM entry 1: IPDA value 0 and mask 0x1.

LAG hashing and ECMP on the ingress and iransit routers:

Terms and Definitions

24 Multiprotocol Label Switching

MPLS CAM Configurations is supported only on platform ex

• CAM Profile and CAM Usage for MPLS on page 25

CAM Profile and CAM Usage for MPLS

1. MPLS ILM Table—60K entries

Microcodes for MPLS

Table 1 MPLS Packet Handling based on Microcode

Microcode Packet Handling

26 MPLS CAM Configurations

• Explicit Routes on page 27

Figure 5 EXPLICIT_ROUTE Object

Object Header L Type Length IPv4 Addr Prefix Resvd

Set if loose hop

There are two types of nodes in an explicit route:

Step Task Command Syntax Command Mode

Exlude an Address from an Explicit Route