MPLS Configuration Guide for E-Series ExaScale › CSPortal20 › KnowledgeBase › D… · MPLS...

MPLS Configuration Guide for E-Series ExaScale

Version 8.3.1.0 December 21, 2009

Copyright 2009 Force10 NetworksAll rights reserved. Printed in the USA. January 2009.Force10 Networks® reserves the right to change, modify, revise this publication without notice.

TrademarksForce10 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 ConditionsIn 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.

MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 3

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.

New Features

4 New Features

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


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

6 New Features

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


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

8 New Features

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


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.

10 New Features

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


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 1Multiprotocol 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 2MPLS CAM Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

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

Microcodes for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 3Constrained Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Explicit Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Contents

12 Contents

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 4MPLS 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 5Label 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


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 6MPLS 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 7RSVP-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 8MPLS Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Create a Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Allocate Bandwidth to a Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

14 Contents

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 9MPLS 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 10MPLS MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

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

Label Switch Router MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Traffic Engineering MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110

mplsTunnelTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111

TE Scalars MIB Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Chapter 11FTOS-supported RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117


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.

Chapter 1 Multiprotocol Label Switching

16 Multiprotocol Label Switching

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

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.

Customer IP Network

Customer IP Network

Provider IP Network

Running MPLS

IP Routing Packet Label Switching IP Routing

Router RouterSwitch/Router Switch/Router


MPLS packet headerMPLS 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

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 handlingIn 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:

MPLS SHIM Header

Link Layer Header

Network Layer Header

Label EXP TTLS


• 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 fragmentationA 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 componentsMPLS 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

MPLS labelsA 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.

Customer IP Network

Customer IP Network

IP Routing Packet Label Switching IP Routing

Customer EdgeRouter

Ingress LSR Egress LSR Customer EdgeRouter

Transit LSR

Provider IP NetworkRunning MPLS


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.

.

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:

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.


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

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.

Next-hop LabelForwarding Entry(NHLFE): next-hop, action (pop,replace,or replace and push)

LabeledIncoming LabelMap (ILM): mapslabels to NHLFE

Unlabeled FEC-to-NHLFEMap (FTN): label unlabeled Packets


High AvailabilityForce10 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 ProtocolLabel 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 ProtocolResource 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 ServiceMPLS 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 EngineeringMPLS 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.

ECMPFTOS 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


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

Chapter 2 MPLS CAM Configurations

26 MPLS CAM Configurations

Display the MPLS CAM region using the command show cam-usage from EXEC Privilege mode.

Force10#show cam-usageLinecard|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 MPLSTable 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


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 RoutesYou 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

There are two types of nodes in an explicit route:

Chapter 3 Constrained Shortest Path First

L Type Length IPv4 AddrObject Header

Set if loose hop

1: for IPv4 prefix

PrefixLength

Resvd

28 Constrained Shortest Path First

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

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.

Session AttributesAttributes 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

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.

Step Task Command Syntax Command Mode

1 Give the LSP a name. This command moves you to the EXPLICIT PATH context.

ip explicit-path name name CONFIGURATION

2 Specify some or all of the nodes in the path, one by one, in downstream order using sequence numbers. Make the node a strict or loose hop.

[seq number] next-address ip-address [strict | loose]

Default: Strict

EXPLICIT PATH

Task Command Syntax Command Mode

Direct CSPF to exclude one or more addresses when selecting a path.

exclude-address ip-address EXPLICIT PATH

SetupPriority

HoldingPriority

Flags NameLength

Object Header Session Name

0x01: Local Protection Desired0x02: Label Recording Desired0x04: SE Style Desired

ExcludeAny

IncludeAny

IncludeAll

Affinity


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 assign it a number.

mpls admin-group group-name group-number

Range: 0-31

CONFIGURATION

Force10(conf)#mpls traffic-eng admin-group premium 0Force10(conf)#mpls traffic-eng admin-group leased 5Force10(conf)#mpls traffic-eng admin-group high_latency 31Force10(conf)#do show run mpls!mpls traffic-eng admin-group premium 0mpls traffic-eng admin-group leased 5mpls traffic-eng admin-group high_latency 31mpls rsvp enablempls traffic-eng enableForce10(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 administrative group. If you do not assign the tunnel to any groups, the interfaces does not belong to any group.

tunnel mpls traffic-eng admin-group [include-any | exclude] group-name

INTERFACE TUNNEL


Force10(conf)#inter tun 1Force10(conf-if-tu-1)#tunnel destination 100.1.1.4Force10(conf-if-tu-1)#tunnel mode mplsForce10(conf-if-tu-1)#tunnel mpls traffic-eng path-option 10 dynamicForce10(conf-if-tu-1)#tunnel mpls traffic-eng admin-group include premiumForce10(conf-if-tu-1)#tunnel mpls traffic-eng admin-group exclude leasedForce10(conf-if-tu-1)#no shutForce10(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 shutdownmp-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 administrative group. If you do assign the interface to any groups, the interfaces does not belong to any group.

mpls traffic-eng admin-group group-name

INTERFACE



Force10(conf-if-gi-0/12)#mpls traffic-eng admin-group premiumForce10(conf-if-gi-0/12)#mpls traffic-eng admin-group leasedForce10(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 mpls traffic-eng enable no shutdownForce10(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 Priority 2 : 68750000 Priority 3 : 68750000 Priority 4 : 68750000 Priority 5 : 68750000 Priority 6 : 68750000 Priority 7 : 68750000 Affinity Bit : 0x21[output omitted]

3 Display configured admin groups.

show mpls traffic-eng admin-group EXEC Privilege



Resource Class Affinity Ingress CheckVerify 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.

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.

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.

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


Enable ingress affinity verification. mpls traffic-eng affinity ingress-check INTERFACE TUNNEL


Send RSVP messages without the affinity attribute.

mpls traffic-eng affinity send-non-ra INTERFACE TUNNEL



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

Equal Cost Path SelectionWhen 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.

Administrative WeightAdminstrative 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 tunnel traffic-engineering setup and hold priorities. These are used when determining whether a particular tunnel can receive or hold on to a bandwidth reservation.

tunnel mpls traffic-eng setup-priority spriority hold-priority hpriority

Default (spriority and hpriority): 7. 0 is the highest priority.

EXPLICIT PATH


Chose the criterion for selecting one of multiple equal cost paths to a particular node.

mpls traffic-eng path-selection hop-count

CONFIGURATION


Configure a TE metric for an interface for use when the interface is advertised as part of IGP TE extensions.

administrative-weight weight CONFIGURATION


Verbatim Path SupportYou 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 option.

tunnel mpls traffic-eng path-option [protect] path-num explicit name path-name verbatim [lockdown] [bandwidth bandwidth]

EXPLICIT PATH


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

Chapter 4 MPLS High Availability

36 MPLS High Availability

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.


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

Display your graceful restart configuration using the command show mpls rsvp hello graceful-restart:

Force10# show mpls rsvp hello graceful-restartRSVP Graceful Restart: Disabled RestartTime: 60000 RecoveryTime: 120000


Enable RSVP-TE Graceful Restart. When enabled, the system includes the RESTART_CAP object in hellos.

mpls rsvp signaling hello graceful-restart enable

Default: Disabled

CONFIGURATION

(OPTIONAL) Set the Restart Time and Recovery Time. When the system is not recovering from a failure, it sets the Recovery Time to 0 in its hellos. It sends hellos with a Recovery Time to a value greater than 0 only when the node is in recovery mode.

mpls rsvp signaling hello graceful-restart {restart-time interval | recovery-time interval}

Default Restart Time: 60000 milliseconds

Default Recovery Time: 120000 milliseconds

CONFIGURATION


RSVP-TE Graceful Restart Helper

When graceful restart is enabled, the system is restart-capable and a graceful-restart helper.

Tunnel ReoptimizationLoosely 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 tunnel on demand.

mpls traffic-eng reoptimize [all | tunnel number]

EXEC Privilege

Periodic reoptimization of all LSPs is enabled by default. You may change the frequency of reoptimization.

mpls traffic-eng tunnels reoptimize frequency interval

Default: 3600 seconds

Range: 10 to 604800 seconds

CONFIGURATION

Configure the system to reoptimize whenever a new link comes online in a TE-enabled OSPF or IS-IS area.

mpls traffic-eng tunnels reoptimize events link-up

CONFIGURATION


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

Force10#show mpls traffic-eng tunnel summaryTraffic-engineering Process: runningRSVP Process: runningTunnel Management Process: runningMPLS traffic forwarding: runningPeriodic reoptimization: every 240 seconds, next in 1 seconds Signalling summary:Tunnel interfaces 1500, currently signalling 1500, established 1500Headend tunnel instance activations 3000, deactivations 1500LSP count midpoint 0, tailend 0

RSVP-TE Fast Reroute ExtensionsRFC 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. Optionally set the bandwidth protection desired and/or node protection desired flag.

tunnel mpls traffic-eng fast-reroute [bw-protect || node-protect]

INTERFACE TUNNEL

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

Step Task Command Syntax

1 On the Head LSR [R1], create a tunnel numbered tunnel 1, the destination of which is the Tail LSR [R4] loopback address. Borrow the IP address from the loopback interface. This will be the primary path.

interface tunnel 1

ip unnumbered loopback 0

tunnel destination 100.1.1.4

tunnel mode mpls

no shutdown

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/upForce10#show run interface tunnel 1!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.4 tunnel mode mplsno shutdown

2 On the PLR [R2], create a second tunnel numbered tunnel 2, the destination of which is the next-hop Transit LSR [R3]. Borrow the IP address from the loopback interface. This will be the backup path.

interface tunnel 2



tunnel mode mpls

no shutdown

Tunnel 2

Tunnel 1

R1Head-end

R4Tail-end

R2Transit-PLR

R3Transit-MP

R5

Gig 0/0

Gig 0/60 Gig 0/18

Gig 0/5100.1.1.1

100.1.1.5

100.1.1.4

100.1.1.2 100.1.1.3


Force10#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT Force10_T2 100.1.1.3 - Gi 0/5 up/up Force10_T1 100.1.1.4 Gi 0/60 Gi 0/18 up/upForce10#show run interface tunnel 2!interface Tunnel 2 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 tunnel mode mplsno shutdown

3 On the Head LSR interface that is directly connected to the next-hop Transit LSR [R2], configure Tunnel 2 as the interface’s backup path.

interface gig 0/18

mpls traffic-eng backup-path tunnel 2

Force10(conf-if-gi-0/18)#mpls traffic-eng backup-path tunnel 2

4 Enable Fast Reroute (FRR) on Tunnel 1.

interface 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 is Ready.

show mpls traffic-eng fast-reroute database

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 is Nhop, which means that the LSP is protected from a link failure.

show mpls rsvp fast-reroute

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/18Force10(conf-if-gi-0/18)#shutSep 23 07:20:41: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi 0/18Force10(conf-if-gi-0/18)#Sep 23 07:20:41: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Gi 0/18Force10(conf-if-gi-0/18)#do 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 ActiveForce10(conf-if-gi-0/18)#no shutSep 23 07:21:31: %RPM0-P:CP %IFMGR-5-ASTATE_UP: Changed interface Admin state to up: Gi 0/18Force10(conf-if-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/18Force10(conf-if-gi-0/18)#



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

Tunnel 2

Tunnel 1

R1Head-end

R4Tail-end-MP

R2Transit-PLR

R3Transit

Gig 0/0

Gig 0/60 Gig 0/66

Gig 0/31

100.1.1.1 100.1.1.4

100.1.1.2 100.1.1.3



1 On the Head LSR [R1], create a tunnel numbered tunnel 1, the destination of which is the Tail LSR [R4]. Borrow an IP address from the loopback interface. This will be the primary path.

interface tunnel 1



tunnel mode mpls

no shutdown

Force10#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT Force10_T1 100.1.1.4 - Gi 0/60 up/upForce10#show run int tu 1!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.4 tunnel mode mplsno shutdown

2 On the PLR, create a second tunnel numbered tunnel 2, the destination of which is the Tail-end LSR [R4]. Borrow an IP address from the loopback interface. This will be the backup path.

interface tunnel 2



tunnel mode mpls

no shutdown

Force10#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT Force10_T2 100.1.1.4 - Gi 0/31up/up Force10_T1 100.1.1.4 Gi 0/0 Gi 0/66 up/upForce10#show running-config int tunnel 2!interface Tunnel 2 ip unnumbered Loopback 0 tunnel destination 100.1.1.4 tunnel mode mplsno shutdown

3 On the PLR [R2] that is directly connected to the next-hop Transit LSR [R3], configure Tunnel 2 as the interface’s backup path.

mpls traffic-eng backup-path tunnel 2

Force10(conf-if-gi-0/66)#mpls traffic-eng backup-path tunnel 2

4 Enable Fast Reroute (FRR) on Tunnel 1.

tunnel mpls traffic-eng fast-reroute

Force10(conf-if-tu-1)#tunnel mpls traffic-eng fast-reroute

Verify that the backup path status is Ready.

show mpls traffic-eng fast-reroute database


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/66Force10(conf-if-gi-0/66)#shut00:32:51: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi 0/66Force10(conf-if-gi-0/66)#00:32:51: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Gi 0/66Force10(conf-if-gi-0/66)#do 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 None Tu 2:3 ActiveForce10(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/66Force10(conf-if-gi-0/66)#00:33:46: %RPM0-P:CP %IFMGR-5-OSTATE_UP: Changed interface state to up: Gi 0/66Force10(conf-if-gi-0/66)#do show mpls traffic-eng fast-reroute database Tunnel head end item frr information: Protected tunnel In-label Out intf/label FRR intf/label Status ---------------- -------- -------------- -------------- ------




Verify that the backup tunnel type is N-Nhop, which means that the LSP is protected from a failure of the Transit LSR (node failure protection is enabled).

show mpls rsvp fast-reroute

Force10#show mpls rsvp fast-reroute Primary Protect BW Backup 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



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.

Force10#show run int tu 3!interface Tunnel 3 ip unnumbered Loopback 0 tunnel destination 100.1.1.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.

Force10#show run int tu 1!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 tunnel mode mpls tunnel mpls traffic-eng path-option 1 explicit name p-1 tunnel mpls traffic-eng fast-reroute bw-protect no shutdown

3 Verify your configuration using show mpls rsvp fast-reroute bw-protect. The value of BW-P will be "ON" only if fast-reroute with bw-protect is configured.

show mpls rsvp fast-reroute bw-protect

EXEC Privilege


BFD for RSVPBidirectional 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.

Force10#show mpls rsvp fas bw Primary Protect BW Backup 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.

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 MForce10#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] LocalAddr RemoteAddr Interface State Rx-int Tx-int Mult Clients* 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


Tunnel 2

Tunnel 1

R1Head-end

R4Tail-end

R2Transit-PLR

R3Transit-MP

2/122.1.1.2

2/135.1.1.2

2/163.1.1.1

5.1.1.1

2.1.1.1


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 sent10.1.1.2 Gi 3/0 00:00:05 00:00:2011.1.1.2 Gi 3/1 00:00:00 00:00:1012.1.1.2 Gi 3/2 00:00:18 00:00:16

2 Enable the BFD protocol. bfd enable CONFIGURATION


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.

Force10 (conf)#bfd enable

3 Establish sessions with all RSVP neighbors, or all RSVP neighbors out of an interface.

mpls rsvp bfd all-neighbors CONFIGURATION/INTERFACE

4 Display established sessions using the command .

show bfd neighbors EXEC Privilege

Force10(conf)#do show bfd neighbors * - Active session roleAd Dn - Admin DownC - CLII - ISISO - OSPFR - Static Route (RTM)M - MPLSV - VRRP LocalAddr RemoteAddr Interface State Rx-int Tx-int Mult Clients* 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 parameters for all RSVP sessions on an interface.

mpls rsvp bfd all-neighbors interval seconds min_rx min_rx multiplier value role {active | passive}

CONFIGURATION/INTERFACE

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.

Path ProtectionPath 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.


Disable BFD sessions with all RSVP neighbors.

mpls rsvp bfd all-neighbors disable CONFIGURATION

Disable BFD sessions with all RSVP neighbors out of an interface when BFD is enabled globally

mpls rsvp bfd all-neighbors disable INTERFACE


Figure 11 Path Protection


1 On the Head-end LSR [R1], create a tunnel numbered tunnel 1, the destination of which 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.

show mpls traffic-eng tunnels brief

EXEC Privilege

Force10#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT Force10_T1 100.1.1.3 - Gi 0/60 up/upForce10#show running-config interface tunnel 1!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 tunnel mode mpls tunnel mpls traffic-eng path-option 1 explicit name p-1 no shutdown

2 Create a new explicit path, and configure the next addresses so that a link different from the primary tunnel is chosen from the head-end through the transit router to the tail-end.

ip explicit-path name name

next-address ip-address {strict | loose}

CONFIGURATION

Force10(conf)#ip explicit-path name standbylspForce10(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 protection.

tunnel mpls traffic-eng path-option protect path-num {dynamic | explicit name path-name} [lockdown] [bandwidth bandwidth]

CONFIGURATION

Force10(conf)#int tunnel 1Force10(conf-if-tu-1)#$fic-eng path-option protect 1 explicit name standbylspForce10(conf-if-tu-1)#show config !interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 tunnel mode mplstunnel mpls traffic-eng path-option 1 explicit name p-1tunnel mpls traffic-eng path-option protect 1 explicit name standbylsp no shutdown

Tunnel 1 Standby Path

Tunnel 1 Primary Path

R1Head-end

R3Tail-end

R2Transit

Gig 0/60 1.1.2.2

Gig 0/61 1.1.11.2

1.1.3.2

1.1.4.2

R-ID: 100.1.1.1 R-ID: 100.1.1.2 R-ID: 100.1.1.3


LSP Retry IntervalThe 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.

4 Verify that the primary path is protected, and that the secondary path is up.

show mpls traffic-eng tunnels protection

EXEC Privilege

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 the primary path link so that the standby LSP becomes active.

shutdown INTERFACE

Force10(conf)#int gigabitethernet 0/60Force10(conf-if-gi-0/60)#shutSep 24 04:02:03: %RPM0-P:CP %IFMGR-5-ASTATE_DN: Changed interface Admin state to down: Gi 0/60Sep 24 04:02:03: %RPM0-P:CP %IFMGR-5-OSTATE_DN: Changed interface state to down: Gi 0/60Force10#show mpls traffic-eng tunnels protection

Tunnel name Force10_T1 admin up oper status upDestination 100.1.1.3, Source 100.1.1.1Standby path is currently in use


Configure the retry interval for establishing LSPs.

tunnel mpls traffic-eng retries INTERFACE TUNNEL



MPLS on LAGsFTOS 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 mpls rsvp bandwidth global-pool mpls traffic-eng enable ip address 1.2.1.1/24 channel-member TenGigabitEthernet 6/0-1,3-4 noshutdown


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

Chapter 5 Label Distribution Protocol

54 Label Distribution Protocol

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.

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

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.


• The next-hop for the FEC is outside the MPLS network (R2, Figure 12).

Figure 12 MPLS Egress LSRs

Label DistributionLabels 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.

LSP A,B LSP B

MPLS Network

Ingress LSR Egress LSR for FEC A

Address Prefix Next Hop

Routing Table

10.11.1.254/24

10.11.1.0/24 Direct

Address Prefix LDP Identifier LabelLabel Information Base

10.11.1.0/24 R3 Label A10.11.2.0/24 R2 Label B

10.11.2.1/24Egress LSRfor FEC B

R1 R2 R3


• 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

LDP Protocol Data UnitsLDP 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.

ACTIVE System PASSIVE System

LDP Link Hellos Exchange

Initialization Message

Response Initialization + Keepalivesession operational

session operational


Figure 14 Hello Message

Table 2 Hello Message TLVs

Type Parameter Description

0x0400 Common Hello ParametersHold 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 Parameters0x0401 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.

Source Port (646)

Destination Port (646)

Length LDPDU

HeaderChecksum

Src IP Addr Protocol (17)

Dest IP Addr (224.0.0.2)

Options Padding UDP Packet

Checksum

Version (1)

PDU Length LDP Identifier Message Type (0x0100)

Msg ID Type(0x0400)

Common Hello Parameters TLV

U(0)

U(0)

F(0)

Length Hold Time T R Reserved Optional Parameters

Hello Message

Msg Length

Optional Parameters TLV

LDPDU Header


Initialization Messages

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

Figure 15 Initialization Message

Table 3 Initialization Message TLVs


0x0500 Common Session ParametersKeepAlive 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.

Version (1)


Msg ID Type(0x0500)

Common Session Parameters TLV

U(0)

U(0)

F(0)

Protocol Version

KeepAlive Time

A D Reserved

Initialization Message

Msg Length

Optional Parameters TLV

PVLim Max PDU Length

Receiver LDP Identifier

Optional Parameters


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

Table 4 Initialization Message TLVs


0x0300 Status TLVU (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.

Version (1)


Msg ID StatusTLV U(0)

Notification Message

Msg Length

Optional Parameters

Type(0x0300)

U(0)

F (0)

Length Status Code Message ID Message Type

E F Status Data


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

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.

Version (1)


Msg ID Address List TLV U(0)

Address Message

Msg Length

Optional Parameters

Type(0x0101)

0 0 Length Address Family Addresses

Code: 1: IPv4 2: IPv6

None defined


Figure 18 Label Mapping Message

Table 5 Label MappingTLVs


0x0400 Label Mapping Message0x0100 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 TLVLabel 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 ParametersLabel 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.

Type(0x0100)

U(0)

F(0)

Length

Version (1)


Msg ID FEC TLV U(0)

Label TLV

Label Mapping Message

Msg Length

Label

Optional Parameters

Type(0x0100)

U(0)

F(0)

Length FEC Element 1 FEC Element n

LabelValue

SExp TTL

Element Type (2)

Address Family (1)

Prefix Length Prefix


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

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.

Hop Count TLV Used to count the number of LSRs in the LSP.

Path Vector TLV Used for loop detection.

Table 5 Label MappingTLVs


Version (1)


Msg ID FEC TLV U(0)

Label Request Message

Msg Length

Optional Parameters

Hop Count TLVPath Vector TLV


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 ProtocolEnabling 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 LDPLDP 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.

Change the LSR Router IDThe 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.

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


1 Start the LDP process. mpls ldp enable CONFIGURATION

2 Enable LDP on an interface mpls ldp enable INTERFACE


Change the LSR router ID. mpls ldp router-id interface CONFIGURATION


• 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 Label Distribution ModeChange 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.


Change the timeout value for an LDP adjacency.

mpls ldp discovery holdtime seconds

Default: 15 seconds

CONFIGURATION

Change the timeout value for an LDP session.

mpls ldp holdtime seconds CONFIGURATION

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

mpls ldp independent-control

Default: ordered-control

CONFIGURATION

2 Disable LDP globally. no mpls ldp enable CONFIGURATION

3 Re-enable LDP globally. mpls ldp enable CONFIGURATION


Direct the Flow of Label AdvertisementLDP 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.

Filter Incoming Label Bindings

MD5 AuthenticationLDP 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.


Allocate a label for an interface IP address, or select the prefixes for which labels are advertised.

mpls ldp advertise-labels [interface interface | for prefix-list [to peer-list]]

CONFIGURATION


Choose the labels that an LSR will accept from a neighbor.

mpls ldp neighbor ip-address labels accept prefix-list

CONFIGURATION


Enable neighbor authentication using an MD5 password.

[no] mpls ldp neighbor ip-address password [ 7 encrypted-pass | clear-pass]

CONFIGURATION


Whenever the MD5 password is updated (added/deleted/modified), the affected LDP sessions are reinitialized, and FTOS displays Message 1.

If the MD5 passwords do not match, FTOS displays Message 2.

If the MD5 password is not configured on one LSR, FTOS displays Message 3.

Manage and Monitor your LDP ConfigurationFTOS offers the following tools to manage and monitor your LDP configuration:

• Log Neighbor Changes on page 69

• Clear Sessions and Counters on page 69

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

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)

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

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



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.

Clear Sessions and Counters

LDP show and debug Commands


Enable or disable logging of LDP neighbor state changes. Logging is enabled by default.

mpls ldp log-neighbor-changes EXEC Privilege


Clear LDP sessions for a specified neighbor or all neighbors.

clear mpls ldp neighbor {ip-address | *} EXEC Privilege

Clear LDP statistics for a specified neighbor or all neighbors. This command clears the statistics displayed in show mpls ldp neighbor.

clear mpls ldp statistics neighbor {ip-address | *}

EXEC Privilege


Display LDP label errrors and events.

debug mpls ldp {binding | error | events | routing}

EXEC Privilege

Display LDP protocol messages in hexadecimal format.

debug mpls ldp dump [in | out | [address | hello | init | keepalive | label | notification] [in | out]]

EXEC Privilege

Display LDP protocol messages in clear text.

debug mpls ldp messages [in | out | [address | hello | init | keepalive | label | notification]] [in | out]

EXEC Privilege

Display the LDP Label Information Base (LIB).

show mpls ldp bindings [ip-address/mask] [{local-label | remote-label} label] [neighbor ip-address] [local]

EXEC Privilege

Display sources for locally generated discovery hello PDUs.

show mpls ldp discovery [detail] [interface] EXEC Privilege

Display MPLS interfaces. show mpls ldp interfaces {interface | brief | advertise-label}

EXEC Privilege


Display LDP neighbor information. show mpls ldp neighbor [ip-address [detail] | brief]

EXEC Privilege

Display LDP configuration parameters.

show mpls ldp parameters EXEC Privilege



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.

MPLS-EXP Marking using Class MapsYou 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 BBForce10(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).

Chapter 6 MPLS Quality of Service

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.

72 MPLS Quality of Service

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 BBClass-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 BBForce10(conf-policy-map-in)#service-queue 0 class-map BBForce10(conf-policy-map-in)#int gig1/6Force10(conf-if-gi-1/6)#service-policy input BB

MPLS-EXP Marking using Qos PoliciesYou 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 BBForce10(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 PoppingBy 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:


• 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

Advertising Explicit-NullThe 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.

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

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

Head-end Tail-end

Transit Penultimate Hop

EXP of outgoing packet is copiedfrom incoming packet EXP.

By default, MPLS-EXP is propagatedfrom the top label to the next label or to the DSCP value.

74 MPLS Quality of Service


On the penultimate LSR, configure the system to swap the incoming top label with the Explicit-Null label.

mpls traffic-eng advertise explicit-null INTERFACE

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.

Head-end Tail-end

Transit

MPLS EXP = 5IP DSCP = 4

Outlabel = Explicit-Null

Advertise Explicit-Null

Queued accordingto IP DSCP, Queue 4

1

2

3 4


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.

Implementation Information• RSVP-TE is not available on VLAN interfaces.

Configure RSVP-TE1. Enable RSVP globally. See page 76.

2. Enable RSVP on an interface by making a portion of the interface bandwidth reservable. See page 76.

Chapter 7 RSVP-TE

76 RSVP-TE

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 RSVPRSVP is disabled by default.

Specify the Reservable Amount of Interface BandwidthGlobal bandwidth pools define the shared amount of interface bandwidth available for RSVP reservations. By default, FTOS allocates 75% of interface bandwidth for RSVP purposes.

Enable Bandwidth LoggingYou 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 the protocol globally. mpls rsvp enable CONFIGURATION


Make a specific amount of interface bandwidth reservable.

mpls rsvp bandwidth global-pool [bandwidth]

INTERFACE


Enable bandwidth logging. mpls rsvp bandwidth logging INTERFACE


Graceful ShutdownRSVP 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 Record RouteRECORD_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 RSVP Hello SignalingHello 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.


Enable graceful shutdown. mpls rsvp graceful-shutdown CONFIGURATION


Enable route recording. Enabling recording after a tunnel is established does not re-establish it. Recording begins when the next Path message is sent.

tunnel traffic-eng record-route INTERFACE TUNNEL

78 RSVP-TE

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, and the number of hello packets that must be unacknowledged to consider the neighbor down.

mpls rsvp signalling hello {interval milliseconds | misses number}

INTERFACE


You can display all of the active and inactive hello sessions in which the system is particpating, clear message counters, and clear session statistics.

Specify the Signaling Refresh IntervalRSVP 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.

Enable Signaling Refresh ReductionRSVP uses refresh messages to synchronize state and recover from lost RSVP messages. This method, however, has scaling, reliablility, and latency limitations.


Display the hello sessions in which the system is participating.

show mpls rsvp hello instance {summary | detail} EXEC Privilege

Force10#show mpls rsvp hello instance summary Active Instances:Neighbor I/F State Num Lost LSPs Interval192.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/21Session type is active Session with neighbor up for 00:00:14Last src instance 0x96988, neighbor instance 0x3DAE3CHello message received 85, sent 90suppressed 57Protected LSPs 1, Refresh interval 1000 msecsCurrent missed acknowledgments 0, IP DSCP 0x30Communication with neighbor lost 1 time(s), time since last 00:00:23Reasons:Session timeout 1, bad src instance 0, bad neighbor instance 0Interface down 0

Clear hello counters for all instances.

clear mpls rsvp hello counters {packets | statistics}

EXEC Privilege


Configure the signaling refresh values R and L.

mpls rsvp signalling refresh {interval seconds | misses number}

CONFIGURATION

80 RSVP-TE

• 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 reduction.

mpls rsvp signalling refresh reduction enable

Default: Disabled

CONFIGURATION

Do not set the ACK_Desired flag for RSVP messages. Received messages with this flag set are still acknowleged.

mpls rsvp signalling refresh reduction no-ack

Default: ACK enabled

CONFIGURATION


Bandwidth Holding for Path MessagesWhen 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.

Enable TTL CheckingThe 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.


Enter number of seconds bandwidth is held on an interface upon receiving a PATH message before it is confirmed by a RESV message.

mpls traffic-eng link-management timers bandwidth-hold seconds

CONFIGURATION


Enable TTL checking. mpls rsvp signalling ttl-check CONFIGURATION

82 RSVP-TE


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

Chapter 8 MPLS Traffic Engineering


1 Tunnels are virtual interfaces like port-channels and VLANs. Create one by assigning a tunnel ID. This command moves you to the INTERFACE TUNNEL context.

interface tunnel tunnel-id

Range: 1-16383

CONFIGURATION

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

tunnel mode mpls INTERFACE TUNNEL

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.

1.1.1.1 3.3.3.3

5/5 (15.1.1.1)

5/6 (16.1.1.1)

6/5

6/6

R1 R3

2.2.2.2

R2

Te 5/2

11.1 21.1

Force10(conf)#do sh run ospf !router ospf 10network 0.0.0.0/0 area 0mpls traffic-eng router-id Loopback 0mpls traffic-eng area 0Force10(conf)#do sh ip route ospf Destination Gateway Dist/Metric Last Change ----------- ------- ----------- ----------- O 2.2.2.2/32 via 11.1.1.2, Te 5/1 110/2 00:09:55 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 via 0.0.0.0, Tu 2Force10(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

Tunnel 2 Tunnel 2

84 MPLS Traffic Engineering

Allocate Bandwidth to a Tunnel

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 EngineeringOSPF—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.


1 Allocate bandwidth to a tunnel. tunnel mpls traffic-eng bandwidth bandwidth

INTERFACE TUNNEL

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


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.

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.


1 Enable MPLS-TE in an OSPF area or on an interface.

mpls traffic-eng area number ROUTER OSPF

INTERFACE

2 Select a router ID for the area. mpls traffic-eng router-id interface ROUTER OSPF

Table 6 Link TLV Sub-types



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 OSPF Router with ID (50.50.50.50) (Process ID 100)

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 Priority 0 : 93750000 Priority 1 : 93750000 Priority 2 : 93750000 Priority 3 : 93750000 Priority 4 : 93750000 Priority 5 : 93750000 Priority 6 : 93750000 Priority 7 : 93000000 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.

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 bandwidth usage threshold values, that when crossed, trigger an IGP TE advertisement.

mpls traffic-eng flooding thresholds {up | down} {value} [[value] …]

INTERFACE


Set the flooding interval for bandwidth usage triggered TE advertisements.

mpls traffic-eng link-management timers periodic-flooding CONFIGURATION


IS-IS—Traffic EngineeringEach 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.

IS-IS-TE can be enabled on one or both levels.

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.


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 interface

ROUTER ISIS


Route Traffic though TunnelsThere 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-TE globally.

mpls rsvp enable

mpls traffic-eng enable

CONFIGURATION

Force10(conf)#do show running-config mpls!mpls rsvp enablempls traffic-eng enable

2 Enable RSVP and traffic engineering on interfaces.

mpls rsvp bandwidth global-pool

mpls traffic-eng enable

INTERFACE

Force10(conf-if-te-6/2)#show config!interface TenGigabitEthernet 6/2 mpls rsvp bandwidth global-pool mpls traffic-eng enable ip address 1.4.1.1/24 no shutdown

3 Enable IGP-TE for adjacencies.

mpls traffic-eng router-id interface

mpls traffic-eng area number

ROUTER OSPF

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

ip unnumbered interface

tunnel destination ip-address

tunnel mode mpls

CONFIGURATION

INTERFACE TUNNEL

interface Tunnel 1 tunnel destination 100.10.10.2 tunnel mode mplsno shutdown


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.

5 Create a static route with the tunnel as the egress interface.

ip route ip-address/mask tunnel number CONFIGURATION

Force10#configure terminal Force10(conf)#ip route 55.0.0.0 /8 tunnel 1

6 Display the configured static routes.

show ip route static EXEC Privilege

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



Figure 21 IGP Autoroute Metrics

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 Destination Gateway Dist/Metric Last Change ----------- ------- ----------- ----------- 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


1 Make a tunnel available to OSPF for best-path selection.

tunnel mpls traffic-eng autoroute announce INTERFACE TUNNEL

2 Display the tunnels that are considered during IGP best-path calculations.

show mpls traffic-eng autoroute EXEC Privilege

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) Tu 2 destination 60.60.60.60 (load balancing metric 0, nexthop 60.60.60.60) (flags: Announce) Tu 1 destination 60.60.60.60 (load balancing metric 0, nexthop 60.60.60.60) (flags: Announce)

3 Assign a metric to the tunnel.

tunnel mpls traffic-eng autoroute metric {value | absolute absolute-metric | relative relative-metric}

INTERFACE TUNNEL

LSP LSP

Tail-end

Absolute / Relative / Metric

Head-enddestination topologicallybehind the tunnel destinationTransit

Absolute


Tunnel 1 is created from Router A to downstream Router C and announced.

Force10(conf)#int tun 1Force10(conf-if-tu-1)#tunnel mpls traffic-eng autoroute announceForce10(conf-if-tu-1)#show config!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 3.3.3.3 tunnel mode mpls tunnel mpls traffic-eng path-option 1 explicit name Tunnel1 tunnel mpls traffic-eng autoroute announceno shutdown

Destinations reachable through Router C now have Tunnel 1 as their egress interface.

Force10(conf-if-tu-1)#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 Destination Gateway Dist/Metric Last Change ----------- ------- ----------- ----------- 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.

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.

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.


• For OSPF, the tail-end must be in the same area.

Prior to enabling Forwarding Adjacenty the head-end route table contains the following routes:

Force10#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

Destination Gateway Dist/Metric Last Change ----------- ------- ----------- ----------- 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:

Force10#show run interface tunnel 1!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 tunnel mode mpls tunnel mpls traffic-eng path-option 10 dynamic tunnel mpls traffic-eng forwarding-adjacency no shutdown


1 Between two routers, create two tunnels, one in each direction.

2 Enable Forwarding Adjacency on each router. tunnel mpls traffic-eng forwarding-adjacency

INTERFACE TUNNEL

3 Optionally, configure a hold time. 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.

mpls traffic-eng forwarding-adjacency holdtime interval

INTERFACE TUNNEL


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 Tu 1 destination 100.1.1.3 (load balancing metric 0, nexthop 100.1.1.3) (flags: Forward-Adjacency, holdtime 0)

Force10#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

Destination Gateway Dist/Metric Last Change ----------- ------- ----------- ----------- 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

OSPF Router with ID (100.1.1.1) (Process ID 55)

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 Options: (No TOS-capability, No DC, E) LS type: Router Link State ID: 100.1.1.3 Advertising Router: 100.1.1.3 LS Seq Number: 0x8000000a Checksum: 0x2d39 Length: 60 Number of Links: 3

Link connected to: a Point-to-Point Network (Link ID) Neighbor Router ID: 100.1.1.1 (Link Data) Router Interface address: 66.6.192.2 Number of TOS metric: 0

The IGP cost of the tunnel interface is configurable:

Force10(conf-if-tu-1)#ip ospf cost 15Force10(conf-if-tu-1)#show conf!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 tunnel mode mpls tunnel mpls traffic-eng path-option 10 dynamic tunnel mpls traffic-eng forwarding-adjacency ip ospf cost 15 no shutdownForce10(conf-if-tu-1)#do show ip ospf database router adv-router 100.1.1.1


Router (Area 0)

LS age: 5 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: 0x80000017 Checksum: 0xd98d 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: 15


• MPLS ping and traceroute on page 95

• Disable TTL Propagation on page 104

Implementation Information• Neither MPLS nor LDP ping will be sucessful if the frame is framented at any transit router.

MPLS ping and tracerouteThe 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 pingFigure 22 MPLS ping and Extended MPLS ping

Chapter 9 MPLS System Management and Troubleshooting

Transit

Tail-end

Head-end

1.3.4.1

1.3.4.2

1.4.1.1

1.4.1.2

96 MPLS System Management and Troubleshooting

Tunnel must be operationally up and have a borrowed IP address, as shown below.

Force10#show running-config interface tunnel 1!interface Tunnel 1 ip unnumbered Loopback 0 tunnel destination 100.1.1.3 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#show mpls traffic-eng tunnels brief TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT 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 using extended MPLS ping options. When prompted for the protocol, enter the keyword mpls.

ping EXEC Privilege


Force10#ping Protocol [ip] : mplsType: Traffic engineering or ldpType [Traffic-eng]: Traffic-engTunnel Id: 1 Repeat Count [5]: 1Datagram size [100]: 200Timeout in secs [3]: Verbose [n]: Extended commands [n]: ySource IP address: 100.1.1.1Reply with Router-alert [n]: Exp bits: 4Time to live [255]: Padding data pattern [0xABCD]: Destination start address [127.0.0.1]: 127.0.0.1Destination end address [127.0.0.1]: 127.0.0.10Destination 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!Destination address 127.0.0.2!Destination address 127.0.0.3!Destination address 127.0.0.4!Destination address 127.0.0.5!Destination address 127.0.0.6!Destination address 127.0.0.7!Destination address 127.0.0.8!Destination address 127.0.0.9!Destination address 127.0.0.10!

Success rate is 100 percent (10/10), round-trip min/avg/max = 0/0/0 ms



traffic-eng tracerouteFigure 23 MPLS traceroute and Extended MPLS traceroute


Trace the route through a tunnel.

traceroute mpls traffic-eng tunnel number EXEC Privilege

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 tunnel using extended MPLS traceroute options. When prompted for the protocol enter the keyword mpls.

traceroute EXEC Privilege

Transit

Tail-end

Head-end

1.3.4.1

1.3.4.2

1.4.1.1

1.4.1.2


ldp pingFigure 24 LDP Ping and Extended LDP ping

Force10#tracerouteProtocol [ip] : mplsType: Traffic engineering or ldpType [Traffic-eng]: Traffic-engTunnel Id: 1 Timeout in secs [3]: Extended commands [n]: ySource IP address: 100.1.1.1Reply with Router-alert [n]: Exp bits: 4Time to live [255]:



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


Ping an LDP prefix. ping mpls ldp ip-address/mask EXEC Privilege


Transit

Tail-end

Head-end

192.168.20.1

192.168.20.2

192.168.30.3

192.168.30.3

R-ID: Lo 100.1.1.1./32

R-ID: Lo 100.1.1.2./32

R-ID: Lo 100.1.1.3./32

Force10#show mpls ldp bindings 192.168.20.0/24 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 Remote binding: lsr: 100.1.1.2, label: Implicit-Null 100.1.1.1/32 Local binding: label Implicit-Null Remote binding: None 100.1.1.2/32 Local binding: label Not-Assigned Remote binding: lsr: 100.1.1.2, label: Implicit-Null 100.1.1.3/32 Local binding: label Not-Assigned Remote binding: lsr: 100.1.1.2, label: 100004


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:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

Ping an LDP prefix using extended ldp ping options. When prompted for “Type,” enter the keyword ldp.

ping EXEC Privilege



Force10#ping Protocol [ip] : mplsType: Traffic engineering or ldpType [Traffic-eng]: ldpTarget FEC IPv4 address: 100.1.1.3Target FEC mask length: 32Repeat Count [5]: 1Datagram size [100]: 200Timeout in secs [3]: Verbose [n]: Extended commands [n]: ySource IP address: 100.1.1.1Reply with Router-alert [n]: Exp bits: 4Time to live [255]: Padding data pattern [0xABCD]: Destination start address [127.0.0.1]: 127.0.0.1Destination end address [127.0.0.1]: 127.0.0.10Destination 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:Destination address 127.0.0.1!Destination address 127.0.0.2!Destination address 127.0.0.3!Destination address 127.0.0.4!Destination address 127.0.0.5!Destination address 127.0.0.6!Destination address 127.0.0.7!Destination address 127.0.0.8!Destination address 127.0.0.9!Destination address 127.0.0.10!

Success rate is 100 percent (10/10), round-trip min/avg/max = 0/0/0 msForce10#



ldp tracerouteFigure 25 LDP traceroute and Extended LDP traceroute


Trace the route to an LDP prefix.

traceroute mpls ldp ip-address/mask EXEC Privilege

Force10#traceroute mpls ldp 100.1.1.3/32



LSP Traceroute: Tracing the route to 100.1.1.3/32, 255 hops max 0 Self MTU 0 [Labels: 100004 EXP: 0]S 1 192.168.20.2 MTU 1554 [Labels: implicit-null Exp: 0] 0 ms! 2 192.168.30.3 MTU 0 0 ms

Trace the route to an LDP prefix. When prompted for “Type,” enter the keyword ldp.

traceroute EXEC Privilege

Transit

Tail-end

Head-end

192.168.20.1

192.168.20.2

192.168.30.3

192.168.30.3

R-ID: Lo 100.1.1.1./32

R-ID: Lo 100.1.1.2./32

R-ID: Lo 100.1.1.3./32

Force10#show mpls ldp bindings 192.168.20.0/24 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 Remote binding: lsr: 100.1.1.2, label: Implicit-Null 100.1.1.1/32 Local binding: label Implicit-Null Remote binding: None 100.1.1.2/32 Local binding: label Not-Assigned Remote binding: lsr: 100.1.1.2, label: Implicit-Null 100.1.1.3/32 Local binding: label Not-Assigned Remote binding: lsr: 100.1.1.2, label: 100004


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.

Force10#tracerouteProtocol [ip] : mplsType: Traffic engineering or ldpType [Traffic-eng]: ldpTarget FEC IPv4 address: 100.1.1.3Target FEC mask length: 32Timeout in secs [3]: Extended commands [n]: ySource IP address: 100.1.1.1Reply with Router-alert [n]: Exp bits: 4Time to live [255]:



LSP Traceroute: Tracing the route to 100.1.1.3/32, 255 hops max 0 Self MTU 0 [Labels: 100004 EXP: 0]S 1 192.168.20.2 MTU 1554 [Labels: implicit-null Exp: 0] 0 ms! 2 192.168.30.3 MTU 0 0 ms

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 PropagationDisabling 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


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 MIBFTOS 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 MIBThe 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

Chapter 10 MPLS MIBs

Table 9 mplsLSRMIB Tables and OIDs

Object OID Description

mplsInterfaceLabelMinIn .1.3.6.1.2.1.10.166.2.1.1.1.2

The minimum value of an MPLS label that this LSR is willing to receive on this interface.Return Value: 16

106 MPLS MIBs

mplsInterfaceLabelMaxIn .1.3.6.1.2.1.10.166.2.1.1.1.3

The maximum value of an MPLS label that this LSR is willing to receive on this interface.Return Value: 1048575

mplsInterfaceTable—.1.3.6.1.2.1.10.166.2.1.1

mplsInterfaceLabelMinOut .1.3.6.1.2.1.10.166.2.1.1.1.4

The minimum value of an MPLS label that this LSR is willing to send on this interface.Return Value: 16

mplsInterfaceLabelMaxOut .1.3.6.1.2.1.10.166.2.1.1.1.5

The maximum value of an MPLS label that this LSR is willing to send on this interface.Return Value: 1048575

mplsInterfaceTotalBandwidth .1.3.6.1.2.1.10.166.2.1.1.1.6

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.Return Value: 0

mplsInterfaceAvailableBandwidth .1.3.6.1.2.1.10.166.2.1.1.1.7

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.Return Value: 0

mplsInterfaceLabelParticipationType .1.3.6.1.2.1.10.166.2.1.1.1.8

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.Return Value: 00

mplsInterfacePerfTable—.1.3.6.1.2.1.10.166.2.1.2

mplsInSegmentIndex .1.3.6.1.2.1.10.166.2.1.4.1.1The index for this in-segment. The string containing the single octet 0x00 MUST not be used as an index.

mplsInSegmentInterface .1.3.6.1.2.1.10.166.2.1.4.1.2

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.Return Value: 0

mplsInSegmentLabel .1.3.6.1.2.1.10.166.2.1.4.1.3

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 for the tunnels.



mplsInSegmentLabelPtr .1.3.6.1.2.1.10.166.2.1.4.1.4

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.Return Value: 0.0

mplsInSegmentTable—.1.3.6.1.2.1.10.166.2.1.4

mplsInSegmentNPop .1.3.6.1.2.1.10.166.2.1.4.1.5

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).Return Value: 1

mplsInSegmentAddrFamily .1.3.6.1.2.1.10.166.2.1.4.1.6

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).Return Value: 1

mplsInSegmentXCIndex .1.3.6.1.2.1.10.166.2.1.4.1.7

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.Return Value: mplsXCIndex of mplsXCTable

mplsInSegmentOwner .1.3.6.1.2.1.10.166.2.1.4.1.8

The entity that created and is responsible for managing this segment.Return Value: Returns a value of 6, which means RSVP-TE.

mplsInSegmentTrafficParamPtr .1.3.6.1.2.1.10.166.2.1.4.1.9

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.Return Value: 0.0

mplsInSegmentRowStatus .1.3.6.1.2.1.10.166.2.1.4.1.10

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.Return Value: 1


108 MPLS MIBs

mplsInSegmentStorageType .1.3.6.1.2.1.10.166.2.1.4.1.11

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.Return Value: 2

mplsInSegmentPerfTable—.1.3.6.1.2.1.10.166.2.1.5

mplsOutSegmentIndex .1.3.6.1.2.1.10.166.2.1.7.1.1

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 no out-segment exists or has been configured.

mplsOutSegmentInterface .1.3.6.1.2.1.10.166.2.1.7.1.2

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.Return Value: Interface index of the outgoing interface.

mplsOutSegmentPushTopLabel .1.3.6.1.2.1.10.166.2.1.7.1.3

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 mplsOutSegmentPushTopLabelis 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 if the FRR swap label is Implicit-Null.

mplsOutSegmentTopLabel .1.3.6.1.2.1.10.166.2.1.7.1.4

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 label is Implicit-Null.

mplsOutSegmentTopLabelPtr .1.3.6.1.2.1.10.166.2.1.7.1.5

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.Return Value: 0.0

mplsOutSegmentTable—.1.3.6.1.2.1.10.166.2.1.7

mplsOutSegmentNextHopAddrType .1.3.6.1.2.1.10.166.2.1.7.1.6

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.Return Value: Returns a value of 1, which maps to IPV4.



mplsOutSegmentNextHopAddr .1.3.6.1.2.1.10.166.2.1.7.1.7

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 tunnels which are originated from the PLR.

mplsOutSegmentXCIndex .1.3.6.1.2.1.10.166.2.1.7.1.8

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 of mplsxctable.

mplsOutSegmentOwner .1.3.6.1.2.1.10.166.2.1.7.1.9

The entity which created and is responsible for managing this segment.Return Value: Returns a value of 6 which means RSVP-TE.

mplsOutSegmentTrafficParamPtr .1.3.6.1.2.1.10.166.2.1.7.1.10

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.Return Value: 0.0

mplsOutSegmentRowStatus .1.3.6.1.2.1.10.166.2.1.7.1.11

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.Return Value: 1

mplsOutSegmentStorageType .1.3.6.1.2.1.10.166.2.1.7.1.12

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.Return Value: 2

mplsOutSegmentPerfTable—.1.3.6.1.2.1.10.166.2.1.8

mplsXCIndex .1.3.6.1.2.1.10.166.2.1.10.1.1

Primary index for the conceptual row identifying a group of cross-connect segments. The string containing a single octet 0x00 is an invalid index.

mplsXCInSegmentIndex .1.3.6.1.2.1.10.166.2.1.10.1.2

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 case no corresponding mplsInSegmentEntry shall exist.


110 MPLS MIBs

Traffic Engineering MIBThe 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

mplsXCOutSegmentIndex .1.3.6.1.2.1.10.166.2.1.10.1.3

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 corresponding mplsOutSegmentEntry shall exist.

mplsXCLspId .1.3.6.1.2.1.10.166.2.1.10.1.4

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 from transit router as well.

mplsXCTable—.1.3.6.1.2.1.10.166.2.1.10

mplsXCLabelStackIndex .1.3.6.1.2.1.10.166.2.1.10.1.5

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).Return Value: 0

mplsXCOwner .1.3.6.1.2.1.10.166.2.1.10.1.6

The entity that created and is responsible for managing this cross-connect.Return Value: Returns a value of 6, which means RSVP-TE.

mplsXCRowStatus .1.3.6.1.2.1.10.166.2.1.10.1.7

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. Return Value: 1

mplsXCStorageType .1.3.6.1.2.1.10.166.2.1.10.1.8

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.Return Value: 2

mplsXCAdminStatus .1.3.6.1.2.1.10.166.2.1.10.1.9

The desired operational status of this segment.Return Value: “Up” if there is a tunnel/segment present, and no value returned if no segment is present.

mplsXCOperStatus .1.3.6.1.2.1.10.166.2.1.10.1.10

The actual operational status of this cross-connect.Return Value: “Up” if there is a tunnel/segment present, and no value returned if no segment is present.



• 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

112 MPLS MIBs

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.




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.



114 MPLS MIBs

TE Scalars MIB TableTE 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.

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.

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.




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.

Table 11 TE Scalars MIB Table


116 MPLS MIBs


The FTOS implementation of MPLS is in accordance with the following RFCs:

Chapter 11 FTOS-supported RFCs

RFC TitleE-Series 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 Base (MIB)

8.3.1.0

3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)

8.3.1.0

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 & traceroute)

8.3.1.0

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

MPLS Configuration Guide for E-Series ExaScale › CSPortal20 › KnowledgeBase › D… · MPLS...

Documents

Transcript of MPLS Configuration Guide for E-Series ExaScale › CSPortal20 › KnowledgeBase › D… · MPLS...