mpls configuration guide for e-series exascale › csportal20 › knowledgebase › d… · mpls...
TRANSCRIPT
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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 5
• 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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 7
• 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 Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 9
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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 11
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 13
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
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Implementation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 15
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 Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 17
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
18 Multiprotocol Label Switching
• 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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 19
• 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
20 Multiprotocol Label Switching
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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 21
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
22 Multiprotocol Label Switching
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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 23
• 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.
24 Multiprotocol Label Switching
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 Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 25
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 27
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 29
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.
Step Task Command Syntax Command Mode
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
30 Constrained Shortest Path First
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
Step Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 31
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
Step Task Command Syntax Command Mode
32 Constrained Shortest Path First
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
Task Command Syntax Command Mode
Enable ingress affinity verification. mpls traffic-eng affinity ingress-check INTERFACE TUNNEL
Task Command Syntax Command Mode
Send RSVP messages without the affinity attribute.
mpls traffic-eng affinity send-non-ra INTERFACE TUNNEL
Step Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 33
• 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.
Task Command Syntax Command Mode
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
Task Command Syntax Command Mode
Chose the criterion for selecting one of multiple equal cost paths to a particular node.
mpls traffic-eng path-selection hop-count
CONFIGURATION
Task Command Syntax Command Mode
Configure a TE metric for an interface for use when the interface is advertised as part of IGP TE extensions.
administrative-weight weight CONFIGURATION
34 Constrained Shortest Path First
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.
Task Command Syntax Command Mode
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 Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 35
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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 37
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
Task Command Syntax Command Mode
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
38 MPLS High Availability
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.
Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 39
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.
Task Command Syntax Command Mode
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
40 MPLS High Availability
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
ip unnumbered loopback 0
tunnel destination 100.1.1.3
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 41
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
Step Task Command Syntax
42 MPLS High Availability
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)#
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] 17 Gi 0/18:17 Tu 2:17 Ready
Protect an LSP from Node Failure
In the following example, the Head LSR in Figure 10 is the PLR.
Figure 10 Protecting LSPs from Node Failure
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 43
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]. Borrow an 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/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
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_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
44 MPLS High Availability
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 ---------------- -------- -------------- -------------- ------
LSP midpoint item frr information: LSP identifier In-label Out intf/label FRR intf/label Status ---------------- -------- -------------- -------------- ------ 100.1.1.1 1 [7] 17 Gi 0/66:17 Tu 2:3 Ready
Force10#show mpls traffic-eng fast-reroute database Tunnel head end item frr information: Protected tunnel In-label Out intf/label FRR intf/label Status ---------------- -------- -------------- -------------- ------
LSP midpoint item frr information: LSP identifier In-label Out intf/label FRR intf/label Status ---------------- -------- -------------- -------------- ------ 100.1.1.1 1 [3] 16 Gi 0/66:16 Tu 2:3 Ready
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
Step Task Command Syntax
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 45
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.
Step Task Command Syntax Command Mode
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
46 MPLS High Availability
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
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 47
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.
Step Task Command Syntax Command Mode
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
48 MPLS High Availability
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
Task Command Syntax Command Mode
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
Step Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 49
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.
Task Command Syntax Command Mode
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
50 MPLS High Availability
Figure 11 Path Protection
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 51
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
Task Command Syntax Command Mode
Configure the retry interval for establishing LSPs.
tunnel mpls traffic-eng retries INTERFACE TUNNEL
Step Task Command Syntax Command Mode
52 MPLS High Availability
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 53
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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 55
• 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
56 Label Distribution Protocol
• 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.
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 57
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
58 Label Distribution Protocol
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 59
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
Type Parameter Description
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)
PDU Length LDP Identifier Message Type (0x0200)
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
60 Label Distribution Protocol
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
Type Parameter Description
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)
PDU Length LDP Identifier Message Type (0x0001)
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 61
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)
PDU Length LDP Identifier Message Type (0x0300)
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
62 Label Distribution Protocol
Figure 18 Label Mapping Message
Table 5 Label MappingTLVs
Type Parameter Description
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)
PDU Length LDP Identifier Message Type (0x0400)
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 63
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
Type Parameter Description
Version (1)
PDU Length LDP Identifier Message Type (0x0401)
Msg ID FEC TLV U(0)
Label Request Message
Msg Length
Optional Parameters
Hop Count TLVPath Vector TLV
64 Label Distribution Protocol
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 65
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.
Step Task Command Syntax Command Mode
1 Start the LDP process. mpls ldp enable CONFIGURATION
2 Enable LDP on an interface mpls ldp enable INTERFACE
Task Command Syntax Command Mode
Change the LSR router ID. mpls ldp router-id interface CONFIGURATION
66 Label Distribution Protocol
• 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.
Task Command Syntax Command Mode
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.
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 67
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.
Task Command Syntax Command Mode
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
Task Command Syntax Command Mode
Choose the labels that an LSR will accept from a neighbor.
mpls ldp neighbor ip-address labels accept prefix-list
CONFIGURATION
Task Command Syntax Command Mode
Enable neighbor authentication using an MD5 password.
[no] mpls ldp neighbor ip-address password [ 7 encrypted-pass | clear-pass]
CONFIGURATION
68 Label Distribution Protocol
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
Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 69
Log Neighbor Changes
The LDP session initialization state machine consists of five possible states. The system reaches operational state when a TCP connection is established, LDP parameters have been negotiated, and keepalives are being periodically transmitted. FTOS logs a state change whenever a neighbor transitsions to or from operational state.
Clear Sessions and Counters
LDP show and debug Commands
Task Command Syntax Command Mode
Enable or disable logging of LDP neighbor state changes. Logging is enabled by default.
mpls ldp log-neighbor-changes EXEC Privilege
Task Command Syntax Command Mode
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
Task Command Syntax Command Mode
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
70 Label Distribution Protocol
Display LDP neighbor information. show mpls ldp neighbor [ip-address [detail] | brief]
EXEC Privilege
Display LDP configuration parameters.
show mpls ldp parameters EXEC Privilege
Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 71
MPLS Quality of Service is supported only on platform ex
This chapter contains the following sections:
• 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:
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 73
• When EXP is 0, DSCP is 0
• When EXP is 1, DSCP is AF11 (001010)
• When EXP is 2, DSCP is AF21 (010010)
• When EXP is 3, DSCP is AF31 (011010)
• When EXP is 4, DSCP is AF41 (100010)
• 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
Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 75
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.
Task Command Syntax Command Mode
Enable the protocol globally. mpls rsvp enable CONFIGURATION
Task Command Syntax Command Mode
Make a specific amount of interface bandwidth reservable.
mpls rsvp bandwidth global-pool [bandwidth]
INTERFACE
Task Command Syntax Command Mode
Enable bandwidth logging. mpls rsvp bandwidth logging INTERFACE
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 77
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.
Task Command Syntax Command Mode
Enable graceful shutdown. mpls rsvp graceful-shutdown CONFIGURATION
Task Command Syntax Command Mode
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.
Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 79
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.
Task Command Syntax Command Mode
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
Task Command Syntax Command Mode
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.
Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 81
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.
Task Command Syntax Command Mode
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
Task Command Syntax Command Mode
Enable TTL checking. mpls rsvp signalling ttl-check CONFIGURATION
82 RSVP-TE
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 83
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
Step Task Command Syntax Command Mode
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.
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 85
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.
Step Task Command Syntax Command Mode
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
Type Name Description
86 MPLS Traffic Engineering
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.
Task Command Syntax Command Mode
Set bandwidth usage threshold values, that when crossed, trigger an IGP TE advertisement.
mpls traffic-eng flooding thresholds {up | down} {value} [[value] …]
INTERFACE
Task Command Syntax Command Mode
Set the flooding interval for bandwidth usage triggered TE advertisements.
mpls traffic-eng link-management timers periodic-flooding CONFIGURATION
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 87
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
Type Name Description
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.
Step Task Command Syntax Command Mode
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
88 MPLS Traffic Engineering
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.
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 89
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
Step Task Command Syntax Command Mode
90 MPLS Traffic Engineering
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
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 91
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.
92 MPLS Traffic Engineering
• 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
Step Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 93
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
94 MPLS Traffic Engineering
The the tailend router in the reverse direction:
Force10#show ip ospf database router adv-router 100.1.1.3
OSPF Router with ID (100.1.1.1) (Process ID 55)
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
OSPF Router with ID (100.1.1.1) (Process ID 55)
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 Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 95
• 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
Task Command Syntax Command Mode
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 97
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]:
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: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
Task Command Syntax Command Mode
98 MPLS System Management and Troubleshooting
traffic-eng tracerouteFigure 23 MPLS traceroute and Extended MPLS traceroute
Task Command Syntax Command Mode
Trace the route through a tunnel.
traceroute mpls traffic-eng tunnel number EXEC Privilege
Force10#traceroute 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 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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 99
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]:
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 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
Task Command Syntax Command Mode
Ping an LDP prefix. ping mpls ldp ip-address/mask EXEC Privilege
Task Command Syntax Command Mode
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
100 MPLS System Management and Troubleshooting
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
Type Ctrl-C to abort.
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
Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 101
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]:
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
Type Ctrl-C to abort.
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#
Task Command Syntax Command Mode
102 MPLS System Management and Troubleshooting
ldp tracerouteFigure 25 LDP traceroute and Extended LDP traceroute
Task Command Syntax Command Mode
Trace the route to an LDP prefix.
traceroute mpls ldp ip-address/mask EXEC Privilege
Force10#traceroute 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
Type Ctrl-C to abort.
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
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 103
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]:
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
Type Ctrl-C to abort.
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
Task Command Syntax Command Mode
104 MPLS System Management and Troubleshooting
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.
Task Command Syntax Command Mode
Disable TTL propagation. no mpls ip propagate-ttl CONFIGURATION
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 105
MPLS MIBs is supported only on platform ex
This chapter contains the following sections:
• 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.
Table 9 mplsLSRMIB Tables and OIDs
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 107
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
Table 9 mplsLSRMIB Tables and OIDs
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.
Table 9 mplsLSRMIB Tables and OIDs
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 109
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.
Table 9 mplsLSRMIB Tables and OIDs
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.
Table 9 mplsLSRMIB Tables and OIDs
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 111
• 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
Task Command Syntax Command Mode
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.
Table 10 mplsTunnelTable MIB Objects
Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 113
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.
Table 10 mplsTunnelTable MIB Objects
Task Command Syntax Command Mode
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
Task Command Syntax Command Mode
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.
Table 10 mplsTunnelTable MIB Objects
Task Command Syntax Command Mode
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 115
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
Task Command Syntax Command Mode
116 MPLS MIBs
MPLS Configuration Guide for FTOS version 8.3.1.0 Publication Date: December 21,2009 117
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