MPLS and RSVP
This chapter provides information to configure MPLS and RSVP.
MPLS
Multiprotocol Label Switching (MPLS) is a label switching technology that provides the ability to set up connection-oriented paths over a connectionless IP network. MPLS facilitates network traffic flow and provides a mechanism to engineer network traffic patterns independently from routing tables. MPLS sets up a specific path for a sequence of packets. The packets are identified by a label inserted into each packet. MPLS is not enabled by default and must be explicitly enabled.
MPLS is independent of any routing protocol but is considered multiprotocol because it works with the Internet Protocol (IP) and frame relay network protocols.
The 7210 SAS routers enable service providers to deliver virtual private networks (VPNs) and Internet access using MPLS tunnels, with Ethernet interfaces.
MPLS label stack
MPLS requires a set of procedures to enhance network layer packets with label stacks, which turns them into labeled packets. Routers that support MPLS are called Label Switching Routers (LSRs). To transmit a labeled packet on a specific data link, an LSR must support the encoding technique which, when given a label stack and a network layer packet, produces a labeled packet.
In MPLS, packets can carry not just one label, but a set of labels in a stack. An LSR can swap the label at the top of the stack, pop the stack, or swap the label and push one or more labels into the stack. The processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been above it in the past, or that some number of other labels may be below it at present.
As described in RFC 3032, MPLS Label Stack Encoding, the label stack is represented as a sequence of label stack entries. Each label stack entry is represented by 4 octets. The following figure shows the label placement in a packet. Packet/label field description describes packet and label fields.
Field |
Description |
|---|---|
Label |
This 20-bit field carries the actual value (unstructured) of the label. |
Exp |
This 3-bit field is reserved for experimental use. It is currently used for Class of Service (CoS). |
S |
This bit is set to 1 for the last entry (bottom) in the label stack, and 0 for all other label stack entries. |
TTL |
This 8-bit field is used to encode a TTL value. |
A stack can carry several labels, organized in a last in/first out order. The top of the label stack appears first in the packet and the bottom of the stack appears last, as shown in the following figure.
The label value at the top of the stack is looked up when a labeled packet is received. A successful lookup reveals:
The next hop where the packet is to be forwarded.
The operation to be performed on the label stack before forwarding.
In addition, the lookup may reveal outgoing data link encapsulation and other information needed to properly forward the packet.
An empty label stack can be thought of as an unlabeled packet. An empty label stack has zero (0) depth. The label at the bottom of the stack is referred to as the Level 1 label. The label above it (if it exists) is the Level 2 label, and so on. The label at the top of the stack is referred to as the Level m label.
Labeled packet processing is independent of the level of hierarchy. Processing is always based on the top label in the stack which includes information about the operations to perform on the packet's label stack.
Label values
Packets traveling along an LSP (see Label Switching Routers) are identified by its label, the 20-bit, unsigned integer. The range is 0 through 1,048,575. Label values 0-15 are reserved and are defined below as follows:
A value of 0 represents the IPv4 Explicit NULL Label. This Label value is legal only at the bottom of the Label stack. It indicates that the Label stack must be popped, and the packet forwarding must be based on the IPv4 header.
A value of 1 represents the router alert Label. This Label value is legal anywhere in the Label stack except at the bottom. When a received packet contains this Label value at the top of the Label stack, it is delivered to a local software module for processing. The actual packet forwarding is determined by the Label beneath it in the stack. However, if the packet is further forwarded, the router alert Label should be pushed back onto the Label stack before forwarding. The use of this Label is analogous to the use of the router alert option in IP packets. Because this Label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol.
A value of 3 represents the Implicit NULL Label. This is a Label that a Label Switching Router (LSR) can assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the Label at the top of the stack with a new Label, but the new Label is Implicit NULL, the LSR pops the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the RSVP, so a value is reserved.
Values 4-15 are reserved for future use.
7210 SAS devices uses labels for MPLS, RSVP-TE, and LDP, as well as packet-based services such as VLL and VPLS.
Label values 16 through 1,048,575 are defined as follows:
Label values 16 through 31 are reserved for future use.
Label values 32 through 1,023 are available for static assignment.
Label values 1,024 through 2,047 are reserved for future use.
Label values 2,048 through 18,431 are statically assigned for services.
Label values 32768 through 131,071 are dynamically assigned for both MPLS and services.
Label values 131,072 through 1,048,575 are reserved for future use.
Label Switching Routers
LSRs perform the label switching function. LSRs perform different functions based on it's position in an LSP. Routers in an LSP do one of the following:
The router at the beginning of an LSP is the ingress label edge router (ILER). The ingress router can encapsulate packets with an MPLS header and forward it to the next router along the path. An LSP can only have one ingress router.
A Label Switching Router (LSR) can be any intermediate router in the LSP between the ingress and egress routers. An LSR swaps the incoming label with the outgoing MPLS label and forwards the MPLS packets it receives to the next router in the MPLS path (LSP). An LSP can have 0-253 transit routers.
The router at the end of an LSP is the egress label edge router (ELER). The egress router strips the MPLS encapsulation which changes it from an MPLS packet to a data packet, and then forwards the packet to its final destination using information in the forwarding table. Each LSP can have only one egress router. The ingress and egress routers in an LSP cannot be the same router.
A router in your network can act as an ingress, egress, or transit router for one or more LSPs, depending on your network design.
An LSP is confined to one IGP area for LSPs using constrained-path. They cannot cross an autonomous system (AS) boundary.
Static LSPs can cross AS boundaries. The intermediate hops are manually configured so the LSP has no dependence on the IGP topology or a local forwarding table.
LSP types
The following are LSP types:
static LSPs
A static LSP specifies a static path. All routers that the LSP traverses must be configured manually with labels. No signaling such as RSVP or LDP is required.
signaled LSP
LSPs are set up using a signaling protocol such as RSVP-TE or LDP. The 7210 SAS supports only RSVP-TE for setting up LSPs. The signaling protocol allows labels to be assigned from an ingress router to the egress router. Signaling is triggered by the ingress routers. Configuration is required only on the ingress router and is not required on intermediate routers. Signaling also facilitates path selection.
There are two signaled LSP types:
explicit-path LSPs
MPLS uses RSVP-TE to set up explicit path LSPs. The hops within the LSP are configured manually. The intermediate hops must be configured as either strict or loose meaning that the LSP must take either a direct path from the previous hop router to this router (strict) or can traverse through other routers (loose). You can control how the path is set up. They are similar to static LSPs but require less configuration. See RSVP.
constrained-path LSPs
The intermediate hops of the LSP are dynamically assigned. A constrained path LSP relies on the Constrained Shortest Path First (CSPF) routing algorithm to find a path which satisfies the constraints for the LSP. In turn, CSPF relies on the topology database provided by the extended IGP such as OSPF or IS-IS.
When the path is found by CSPF, RSVP uses the path to request the LSP set up. CSPF calculates the shortest path based on the constraints provided such as bandwidth, class of service, and specified hops.
If fast reroute is configured, the ingress router signals the routers downstream. Each downstream router sets up a detour for the LSP. If a downstream router does not support fast reroute, the request is ignored and the router continues to support the LSP. This can cause some of the detours to fail, but otherwise the LSP is not impacted.
No bandwidth is reserved for the rerouted path. If the user enters a value in the bandwidth parameter in the config>router>mpls>lsp>fast-reroute context, it will have no effect on the LSP backup LSP establishment.
Hop-limit parameters specifies the maximum number of hops that an LSP can traverse, including the ingress and egress routers. An LSP is not set up if the hop limit is exceeded. The hop count is set to 255 by default for the primary and secondary paths. It is set to 16 by default for a bypass or detour LSP path.
MPLS Fast Re-Route (FRR)
The MPLS facility bypass method of MPLS Fast Re-Route (FRR) functionality is extended to the ingress node.
The behavior of an LSP at an ingress LER with both fast reroute and a standby LSP path configured is as follows:
When a downstream detour becomes active at a point of local repair (PLR):
The ingress LER switches to the standby LSP path. If the primary LSP path is repaired subsequently at the PLR, the LSP will switch back to the primary path. If the standby goes down, the LSP is switched back to the primary, even though it is still on the detour at the PLR. If the primary goes down at the ingress while the LSP is on the standby, the detour at the ingress is cleaned up and for one-to-one detours a "path tear" is sent for the detour path. In other words, the detour at the ingress does not protect the standby. If and when the primary LSP is again successfully re-signaled, the ingress detour state machine will be restarted.
When the primary fails at the ingress:
The LSP switches to the detour path. If a standby is available then LSP would switch to standby on expiration of hold-timer. If hold-timer is disabled then switchover to standby would happen immediately. On successful global revert of primary path, the LSP would switch back to the primary path.
Admin groups are not taken into account when creating detours for LSPs.
Manual bypass LSP
The 7210 SAS supports Manual bypass tunnels, on implementation of the Manual bypass feature a LSP can be preconfigured from a PLR which is used exclusively for bypass protection. If a path message for a new LSP requests for bypass protection, the node checks if a manual bypass tunnel satisfying the path constraints exists. If a tunnel is found, it is selected. If no such tunnel exists by default, the 7210 SAS dynamically signals a bypass LSP.
Users can disable the dynamic bypass creation on a per node basis using the CLI.
A maximum of 1000 associations of primary LSP paths can be made with a single manual bypass at the PLR node. If dynamic bypass creation is disabled on the node, it is recommended to configure additional manual bypass LSPs to handle the required number of associations.
PLR bypass LSP selection rules
The following figure shows bypass tunnel nodes.
The PLR uses the following rules to select a bypass LSP among multiple manual and dynamic bypass LSPs at the time of establishment of the primary LSP path or when searching for a bypass for a protected LSP which does not have an association with a bypass tunnel:
The MPLS/RSVP task in the PLR node checks if an existing manual bypass satisfies the constraints. If the path message for the primary LSP path indicated node protection is needed, which is the default LSP FRR setting at the head end node, MPLS/RSVP task searches for a node-protect' bypass LSP. If the path message for the primary LSP path indicated link protection is needed, then it searches for a link-protect bypass LSP.
If multiple manual bypass LSPs satisfying the path constraints exist, it will prefer a manual-bypass terminating closer to the PLR over a manual bypass terminating further away. If multiple manual bypass LSPs satisfying the path constraints terminate on the same downstream node, it selects one with the lowest IGP path cost or if in a tie, picks the first one available.
If none satisfies the constraints and dynamic bypass tunnels have not been disabled on PLR node, then the MPLS/RSVP task in the PLR will check if any of the already established dynamic bypasses of the requested type satisfies the constraints.
If none do, then the MPLS/RSVP task will ask CSPF to check if a new dynamic bypass of the requested type, node-protect or link-protect, can be established.
If the path message for the primary LSP path indicated node protection is needed, and no manual bypass was found after Step 1, or no dynamic bypass LSP was found after 3 attempts of performing Step 3, the MPLS/RSVP task will repeat Steps 1-3 looking for a suitable link-protect bypass LSP. If none are found, the primary LSP will have no protection and the PLR node must clear the "local protection available" flag in the IPv4 address sub-object of the record route object (RRO) starting in the next Resv refresh message it sends upstream.
If the path message for the primary LSP path indicated link protection is needed, and no manual bypass was found after step 1, or no dynamic bypass LSP was found after performing Step 3, the primary LSP will have no protection and the PLR node must clear the "local protection available" flag in the IPv4 address sub-object of the RRO starting in the next RESV refresh message it sends upstream. The PLR will not search for a node-protect’ bypass LSP in this case.
If the PLR node successfully makes an association, it must set the "local protection available" flag in the IPv4 address sub-object of the RRO starting in the next RESV refresh message it sends upstream.
For all primary LSP that requested FRR protection but are not currently associated with a bypass tunnel, the PLR node on reception of RESV refresh on the primary LSP path repeats Steps 1-7.
If the user disables dynamic-bypass tunnels on a node while dynamic bypass tunnels were activated and were passing traffic, traffic loss will occur on the protected LSP. Furthermore, if no manual bypass exist that satisfy the constraints of the protected LSP, the LSP will remain without protection.
If the user configures a bypass tunnel on node B and dynamic bypass tunnels have been disabled, LSPs which have been previously signaled and which were not associated with any manual bypass tunnel, for example, none existed, will be associated with the manual bypass tunnel if suitable. The node checks for the availability of a suitable bypass tunnel for each of the outstanding LSPs every time a RESV message is received for these LSPs.
If the user configures a bypass tunnel on node B and dynamic bypass tunnels have not been disabled, LSPs which have been previously signaled over dynamic bypass tunnels will not automatically be switched into the manual bypass tunnel even if the manual bypass is a more optimized path. The user will have to perform a make before break at the head end of these LSPs.
If the manual bypass goes into the down state in node B and dynamic bypass tunnels have been disabled, node B (PLR) will clear the "protection available" flag in the RRO IPv4 sub-object in the next RESV refresh message for each affected LSP. It will then try to associate each of these LSPs with one of the manual bypass tunnels that are still up. If it finds one, it will make the association and set again the "protection available" flag in the next RESV refresh message for each of these LSPs. If it could not find one, it will keep checking for one every time a RESV message is received for each of the remaining LSPs. When the manual bypass tunnel is back UP, the LSPs which did not find a match will be associated back to this tunnel and the protection available flag is set starting in the next RESV refresh message.
If the manual bypass goes into the down state in node B and dynamic bypass tunnels have not been disabled, node B will automatically signal a dynamic bypass to protect the LSPs if a suitable one does not exist. Similarly, if an LSP is signaled while the manual bypass is in the down state, the node will only signal a dynamic bypass tunnel if the user has not disabled dynamic tunnels. When the manual bypass tunnel is back into the UP state, the node will not switch the protected LSPs from the dynamic bypass tunnel into the manual bypass tunnel.
FRR node-protection (facility)
The MPLS Fast Re-Route (FRR) functionality enables PLRs to be aware of the missing node protection and allows them to regularly probe for a node-bypass.
The following figure shows an LSP scenario.
Where:
LSP 1: between PE_1 to PE_2, with CSPF, FRR facility node-protect enabled.
P_1 protects P_2 with bypass-nodes P_1 -P_3 - P_4 - PE_4 -PE_2.
If P_4 fails, P_1 tries to establish the bypass-node three times.
When the bypass-node creation fails, P_1 will protect link P_1-P_2.
P_1 protects the link to P_2 through P_1 - P_5 - P_2.
P_4 returns online.
As LSP 1 had requested node protection, but because of a lack of any available path, it could only obtain link protection. Therefore, every 60 seconds the PLR for LSP 1 will search for a new path that may be able to provide node protection. When P_4 is back online and such a path is available, A new bypass tunnel will be signaled and LSP 1 will get associated with this new bypass tunnel.
Uniform FRR failover time
The failover time during FRR consists of a detection time and a switchover time. The detection time corresponds to the time it takes for the RSVP control plane protocol to detect that a network IP interface is down or that a neighbor/next-hop over a network IP interface is down. The control plane can be informed of an interface down event when the event is because of a failure in a lower layer such in the physical layer. The control plane can also detect the failure of a neighbor/next-hop on its own by running a protocol such as Hello, Keep-Alive, or BFD.
The switchover time is measured from the time the control plane detected the failure of the interface or neighbor/next-hop to the time the IOM completed the reprogramming of all the impacted ILM or service records in the datapath. This includes the time it takes for the control plane to send a down notification to all IOMs to request a switch to the backup NHLFE.
Uniform Fast-Reroute (FRR) failover enables the switchover of MPLS and service packets from the outgoing interface of the primary LSP path to that of the FRR backup LSP within the same amount of time regardless of the number of LSPs or service records. This is achieved by updating Ingress Label Map (ILM) records and service records to point to the backup Next-Hop Label to Forwarding Entry (NHLFE) in a single operation.
Configuration guidelines
Implicit NULL must be enabled for use of Manual Bypass or Dynamic Bypass (FRR facility) if the 7210 is used as a egress LER or is a Merge Point.
MPLS pseudowire hash label support
The MPLS pseudowire hash label allows LSR nodes in a network to load balance labeled packets in a much more granular fashion than allowed by simply hashing on the standard label stack. It also removes the need to have an LSR inspect the payload below the label stack to check for an IPv4 or IPv6 header.
An MPLS hash label, is inserted by the ingress LER at the bottom of the label stack in packets forwarded over an LSP. The value of the label is the result of the hash of the packet headers (the packet header fields used depends on the capability of the ingress LER node). Since the ingress LER hash routine maintains packet ordering within a conversation, this guarantees that the spraying of packets by an LSR hashing on the extended label stack, which includes the hash label, will also maintain packet ordering within a conversation. LSR hashing pertains to multiple LDP ECMP paths or multiple paths over a LAG network port.
-
On 7210 SAS devices, the ingress node does not use the pseudowire hash label for ECMP hashing and LAG hashing. It is only available for use by the transit MPLS LSR nodes. See the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for information about the fields used by the ingress LER for ECMP and LAG hashing.
The pseudowire hash label is supported for VLL with spoke SDP, and VPLS services with spoke SDP and mesh SDP.
This feature is only supported on the 7210 SAS-Mxp, 7210 SAS-Sx/S 1/10GE, 7210 SAS-R6 (IMMv2 cards), and 7210 SAS-R12 (IMMv2 cards).
- The pseudowire hash label is not accounted for the in the total number of MPLS transport and service labels that the node pushes and pops.
MPLS Transport Profile (MPLS-TP)
This feature is only supported on 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T.
MPLS can be used to provide a network layer to support packet transport services. In some operational environments, it is desirable that the operation and maintenance of such an MPLS based packet transport network follow operational models typical in traditional optical transport networks (For example, SONET/SDH), while providing additional OAM, survivability and other maintenance functions targeted at that environment.
MPLS-TP defines a profile of MPLS targeted at transport applications. This profile defines the specific MPLS characteristics and extensions required to meet transport requirements, while retaining compliance to the standard IETF MPLS architecture and label switching paradigm. The basic requirements are architecture for MPLS-TP are described by the IETF in RFC 5654, RFC 5921 and RFC 5960, to meet two objectives:
-
To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies.
-
To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks.
To meet these objectives, MPLS-TP has a number of high level characteristics:
It does not modify the MPLS forwarding architecture, which is based on existing pseudowire and LSP constructs. Point-to-point LSPs may be unidirectional or bidirectional. Bi-directional LSPs must be congruent (that is, co-routed and follow the same path in each direction). The 7210 SAS supports bidirectional co-routed MPLS-TP LSPs.
There is no LSP merging.
OAM, protection and forwarding of data packets can operate without IP forwarding support. When static provisioning is used, there is no dependency on dynamic routing or signaling.
LSP and pseudowire monitoring is only achieved through the use of OAM and does not rely on control plane or routing functions to determine the health of a path. For example, LDP hello failures, do not trigger protection.
MPLS-TP can operate in the absence of an IP control plane and IP forwarding of OAM traffic. In 7210 SAS releases, MPLS-TP is only supported on static LSPs and PWs.
The 7210 SAS supports MPLS-TP on LSPs and PWs with static labels. MPLS-TP is not supported on dynamically signaled LSPs and PWs. MPLS-TP is supported for Epipe, and Epipe Spoke SDP termination on VPLS. Static PWs may use SDPs that use either static MPLS-TP LSPs or RSVP-TE LSPs.
The following MPLS-TP OAM and protection mechanisms, defined by the IETF, are supported:
MPLS-TP Generic Associated Channel for LSPs and PWs (RFC 5586)
MPLS-TP Identifiers (RFC 6370)
Proactive CC, CV, and RDI using BFD for LSPs (RFC 6428)
BFD based CV is not supported in this release.
On-Demand CV for LSPs and PWs using LSP Ping and LSP Trace (RFC 6426)
1-for-1 Linear protection for LSPs (RFC 6378)
Static PW Status Signaling (RFC 6478)
The 7210 SAS can play the role of an LER and an LSR for static MPLS-TP LSPs, and a PE/T-PE for static MPLS-TP PWs. It can also act an MPLS network that supports both MPLS-TP and dynamic IP/MPLS.
MPLS-TP model
The following figure shows a high level functional model for MPLS-TP in 7210 SAS. LSP A and LSP B are the working and protect LSPs of an LSP tunnel. These are modeled as working and protect paths of an MPLS-TP LSP in 7210 SAS. MPLS-TP OAM runs in-band on each path. 1:1 linear protection coordinates the working and protect paths, using a protection switching coordination protocol (PSC) that runs in-band on each path over a Generic Associated Channel (G-ACh) on each path. Each path can use an IP numbered, IP unnumbered, or MPLS-TP unnumbered (that is, non-IP) interface.
For 7210 SAS platforms, all MPLS-TP LSPs are bidirectional co-routed as detailed in RFC 5654. That is, the forward and backward directions follow the same route (in terms of links and nodes) across the network. Both directions are setup, monitored and protected as a single entity. Therefore, both ingress and egress directions of the same LSP segment are associated at the LER and LSR and use the same interface (although this is not enforced by the system).
In the above model, an SDP can use one MPLS-TP LSP. This abstracts the underlying paths toward the overlying services, which are transported on pseudowires. Pseudowires are modeled as spoke SDPs and can also use MPLS-TP OAM. PWs with static labels may use SDPs that in-turn use either signaled RSVP-TE LSPs, or one static MPLS-TP LSP.
MPLS-TP provider edge and gateway
This section describes examples of roles for the 7210 SAS in an MPLS-TP network.
VLL services
The 7210 SAS may use MPLS TP LSPs, and PWs, to transport point to point virtual leased line services. The node plays the role of a terminating PE or switching PE for VLLs. Only T-PE functionality is supported on 7210 SAS-T (network mode). Both T-PE and S-PE (static only) functionality is supported on 7210 SAS-R6 and 7210 SAS-R12. Epipe is supported.
The following figures show the use of the 7210 SAS as a T-PE/S-PE for services in an MPLS-TP domain.
Spoke SDP termination on IES and VPRN services is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-R6 and 7210 SAS-R12. Is it also supported on 7210 SAS platforms operating in access-uplink mode.
MPLS-TP Epipe spoke SDP termination on VPLS is supported on all 7210 SAS platforms as described in this document, including those operating in access-uplink mode.
7210 SAS-R6 and 7210 SAS-R12 nodes can be used as T-PE nodes (LER nodes) that originate Epipe services, or as S-PE nodes acting as stitching points for MPLS-TP PWs.
Detailed descriptions of MPLS-TP
MPLS-TP LSPs
The 7210 SAS supports the configuration of MPLS-TP tunnels, which comprise a working and, optionally, a protect LSP. In 7210 SAS, a tunnel is referred to as an LSP, while an MPLS-TP LSP is referred to as a path. It is then possible to bind an MPLS-TP tunnel to an SDP.
MPLS-TP LSPs (that is, paths) with static labels are supported. MPLS-TP is not supported for signaled LSPs.
Both bidirectional associated (where the forward and reverse directions of a bidirectional LSP are associated at a specific LER, but may take different routes through the intervening network) and bidirectional co-routed (where the forward and reverse directions of the LSP are associated at each LSR, and take the same route through the network) are possible in MPLS-TP. However, only bidirectional co-routed LSPs are supported.
It is possible to configure MPLS-TP identifiers associated with the LSP, and MPLS-TP OAM parameters on each LSP of a tunnel. MPLS-TP protection is configured for a tunnel at the level of the protect path level. Both protection and OAM configuration is managed through templates to simplify provisioning for a large numbers of tunnels.
The 7210 SAS plays the role of either an LER or an LSR.
MPLS-TP on pseudowires
MPLS-TP is supported on PWs with static labels. The provisioning model supports RFC 6370-style PW path identifiers for MPLS-TP PWs.
MPLS-TP PWs reuse the static PW provisioning model of previous 7210 SAS releases. The primary distinguishing feature for an "MPLS-TP" PW is the ability to configure MPLS-TP PW path identifiers, and to support MPLS-TP OAM and static PW status signaling.
The 7210 SAS can perform the role of a T-PE for a PW with MPLS-TP. The 7210 SAS-R6 and 7210 SAS-R12 can perform the role of S-PE for MPLS-TP PW. The 7210 SAS-T does not support S-PE functionality.
A spoke-SDP with static PW labels and MPLS-TP identifiers and OAM capabilities can use an SDP that uses either an MPLS-TP tunnel, or that uses regular RSVP-TE LSPs. The control word is supported for all MPLS-TP PWs.
MPLS-TP maintenance identifiers
MPLS-TP is designed for use both with, and without, a control plane. MPLS-TP therefore specifies a set of identifiers that can be used for objects in either environment. This includes a path and maintenance identifier architecture comprising Node, Interface, PW and LSP identifiers, Maintenance Entity Groups (MEGs), Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs). These identifiers are specified in RFC 6370.
MPLS-TP OAM and protection switching operates within a framework that is designed to be similar to existing transport network maintenance architectures. MPLS-TP introduces concept of maintenance domains to be managed and monitored. In these, Maintenance Entity Group End Points (MEPs) are edges of a maintenance domain. OAM of a maintenance level must not leak beyond corresponding MEP and so MEPs typically reside at the end points of LSPs and PWs. Maintenance Intermediate Points (MIPS) define intermediate nodes to be monitored. Maintenance Entity Groups (MEGs) comprise all the MEPs and MIPs on an LSP or PW.
The following figure shows the MPLS-TP maintenance architecture.
Both IP-compatible and ICC (ITU-T carrier code) based identifiers for the above objects are specified in the IETF, but only the IP-compatible identifiers defined in RFC 6370 are supported.
The 7210 SAS supports the configuration of the following node and interface related identifiers:
Global_ID: In MPLS-TP, the Global_ID should be set to the AS# of the node. If not explicitly configured, then it assumes the default value of 0. In 7210 SAS, the source Global ID for an MPLS-TP Tunnel is taken to be the Global ID configured at the LER. The destination Global ID is optional in the tunnel configuration. If it is not configured, then it is taken as the same as the source Global ID.
Node_ID: This is a 32-bit value assigned by the operator within the scope of the Global_ID. The 7210 SAS supports the configuration of an IPv4 formatted address <a.b.c.d> or an unsigned 32-bit integer for the MPLS-TP Node ID at each node. The node ID must be unique within the scope of the global ID, but there is no requirement for it to be a valid IP address. Indeed, a node-id can represent a separate IP-compatible addressing space that may be separate from the IP addressing plan of the underlying network. If no node ID is configured, then the node ID is taken to be the system interface IPv4 address of the node. When configuring a tunnel at an LER, either an IPv4 or an unsigned integer Node ID can be configured as the source and destination identifiers, but both ends must be of the same type.
Statically configured LSPs are identified using GMPLS-compatible identifiers with the addition of a Tunnel_Num and LSP_Num. As in RSVP-TE, tunnels represent, for example, a set of working and protect LSPs. These are GMPLS-compatible because GMPLS chosen by the IETF as the control plane for MPLS-TP LSPs, although this is not supported in 7210 SAS 6.1R1 release. PWs are identified using a PW Path ID which has the same structure as FEC129 AII Type 2.
The 7210 SAS derives the identifiers for MEPs and MIPs on LSPs and PWs based on the configured identifiers for the MPLS-TP Tunnel, LSP or PW Path ID, for use in MPLS-TP OAM and protection switching, as per RFC 6370.
The information models for LSPs and PWs supported in 7210 SAS are shown in MPLS-TP LSP and tunnel information model and MPLS-TP PW information model. The figures use the terminology defined in RFC 6370.
The MPLS-TP Tunnel ID and LSP ID are not to be confused with the RSVP-TE tunnel ID implemented on the 7210 system. The following table describes how these map to the X and Y ends of the tunnel shown in the preceding figure for the case of co-routed bidirectional LSPs.
RSVP-TE Identifier |
MPLS-TP Maintenance Identifier |
|---|---|
Tunnel Endpoint Address |
Node ID (Y) |
Tunnel ID (X) |
Tunnel Num (X) |
Extended Tunnel ID |
Node ID (X) |
Tunnel Sender Address |
Node ID (X) |
LSP ID |
LSP Num |
In the PW information model shown in the preceding figure, the MS-PW is identified by the PW Path ID that is composed of the full AGI:SAII:TAII. The PW Path ID is also the MEP ID at the T-PEs, so a user does not have to explicitly configure a MEP ID, it is automatically derived by the system. For MPLS-TP PWs with static labels, although the PW is not signaled end-to-end, the directionality of the SAII and TAII is taken to be the same as for the equivalent label mapping message that is, from downstream to upstream. This is to maintain consistency with signaled pseudowires using FEC 129.
On the 7210 SAS, an S-PE for an MS-PW with static labels is configured as a pair of spoke SDPs bound together in an VLL service using the vc-switching command. Therefore, the PW Path ID configured at the spoke-sdp level at an S-PE must contain the Global-ID, Node-ID and AC-ID at the far end T-PEs, not the local S-PE. The ordering of the SAII:TAII in the PW Path ID where static PWs are used should be consistent with the direction of signaling of the egress label to a spoke-SDP forming that segment, if that label were signaled using T-LDP (in downstream unsolicited mode). VCCV Ping will check the PW ID in the VCCV Ping echo request message against the configured PW Path ID for the egress PW segment.
The following figure shows an example of how the PW Path IDs can be configured for a simple two-segment MS-PW.
Generic Associated Channel
MPLS-TP requires that all OAM traffic be carried in-band on both directions of an LSP or PW. This is to ensure that OAM traffic always shares fate with user data traffic. This is achieved by using an associated control channel on an LSP or PW, similar to that used today on PWs. This creates a channel, which is used for OAM, protection switching protocols (for example, LSP linear protection switching coordination), and other maintenance traffic, and is known as the Generic Associated Channel (G-ACh).
RFC 5586 specifies mechanisms for implementing the G-ACh, relying on the combination of a reserved MPLS label, the 'Generic-ACH Label (GAL)', as an alert mechanism (value=13) and Generic Associated Channel Header (G-ACH) for MPLS LSPs, and using the Generic Associated Channel Header, only, for MPLS PWs (although the GAL is allowed on PWs).
The purpose of the GAL is to indicate that a G-ACH resides at the bottom of the label stack, and is only visible when the bottom non-reserved label is popped. The G-ACH channel type is used to indicate the packet type carried on the G-ACh. Packets on a G-ACh are targeted to a node containing a MEP by ensuring that the GAL is pushed immediately below the label that is popped at the MEP (for example, LSP endpoint or PW endpoint), so that it can be inspected as soon as the label is popped. A G-ACh packet is targeted to a node containing a MIP by setting the TTL of the LSP or PW label, as applicable, so that it expires at that node, in a similar manner to the SR OS implementation of VCCV for MS-PWs.
The following figure shows labels for LSP and PW G-ACh packets.
The 7210 SAS supports the G-ACh on static pseudowires and static LSPs.
MPLS-TP Operations, Administration and Maintenance (OAM)
This section details the MPLS-TP OAM mechanisms that are supported.
On-demand connectivity verification (CV) using LSP-Ping
MPLS–TP supports mechanisms for on demand CC/CV as well as route tracing for LSPs and PWs. These are required to enable an operator to test the initial configuration of a transport path, or to assist with fault isolation and diagnosis. On demand CC/CV and route tracing for MPLS-TP is based on LSP-Ping and is described in RFC 6426. Three possible encapsulations are specified in that RFC:
IP encapsulation, using the same label stack as RFC 4379, or encapsulated in the IPv4 G-ACh channel with a GAL/ACH
A non-IP encapsulation with GAL/ACH for LSPs and ACH for PWs.
In IP-encapsulation, LSP-Ping packets are sent over the MPLS LSP for which OAM is being performed and contain an IP/UDP packet within them. The On-demand CV echo response message is sent on the reverse path of the LSP, and the reply contains IP/UDP headers followed by the On-demand CV payload.
In non-IP environments, LSP ping can be encapsulated with no IP/UDP headers in a G-ACh and use a source address TLV to identify the source node, using forward and reverse LSP or PW associated channels on the same LSP or PW for the echo request and reply packets. In this case, no IP/UDP headers are included in the LSP-Ping packets.
The 7210 SAS supports the following encapsulations:
IP encapsulation with ACH for PWs (as per VCCV type 1).
IP encapsulation without ACH for LSPs using labeled encapsulation
Non-IP encapsulation with ACH for both PWs and LSPs.
LSP Ping and VCCV Ping for MPLS-TP use two new FEC sub-types in the target FEC stack to identify the static LSP or static PW being checked. These are the Static LSP FEC sub-type, which has the same format as the LSP identifier described above, and the Static PW FEC sub-type,. These are used in-place of the currently defined target FEC stack sub-TLVs.
In addition, MPLS-TP uses a source/destination TLV to carry the MPLS-TP global-id and node-id of the target node for the LSP ping packet, and the source node of the LSP ping packet.
LSP Ping and VCCV-Ping for MPLS-TP can only be launched by the LER or T-PE. The replying node therefore sets the TTL of the LSP label or PW label in the reply packet to 255 to ensure that it reaches the node that launched the LSP ping or VCCV Ping request.
Downstream mapping support
The following table describes the four RFC 4379 specified address types for the downstream mapping TLV for use with IP numbered and unnumbered interfaces.
Type # |
Address type |
K octets |
Reference |
7210 SAS-R6 and 7210 SAS-R12 support |
7210 SAS-T support |
|---|---|---|---|---|---|
1 |
IPv4 Numbered |
16 |
RFC 4379 |
Yes |
Yes |
2 |
IPv4 Unnumbered |
16 |
RFC 4379 |
Yes |
Yes |
3 |
IPv6 Numbered |
40 |
RFC 4379 |
No |
No |
4 |
IPv6 Unnumbered |
28 |
RFC 4379 |
No |
No |
RFC 6426 adds address type 5 for use with Non IP interfaces, including MPLS-TP interfaces. In addition, this RFC specifies that type 5 must be used when non-IP ACH encapsulation is used for LSP Trace.
It is possible to send and respond to a DSMAP/DDMAP TLV in the LSP Trace packet for numbered IP interfaces as per RFC 4379. In this case, the echo request message contains a downstream mapping TLV with address type 1 (IPv4 address) and the IPv4 address in the DDMAP/DSMAP TLV is taken to be the IP address of the IP interface that the LSP uses. The LSP trace packet therefore contains a DSMAP TLV in addition to the MPLS-TP static LSP TLV in the target FEC stack.
DSMAP/DDMAP is not supported for pseudowires.
Proactive CC, CV and RDI
Proactive Continuity Check (CC) is used to detect a loss of continuity defect (LOC) between two MEPs in a MEG. Proactive Connectivity Verification (CV) is used to detect an unexpected connectivity defect between two MEPs (For example: mis-merging or disconnection), as well as unexpected connectivity within the MEG with an unexpected MEP. This feature implements both functions using proactive generation of OAM packets by the source MEP that are processed by the peer sink MEP. CC and CV packets are always sent in-band such that they fate share with user traffic, either on an LSP, PW or section and are used to trigger protection switching mechanisms.
Proactive CC/CV based on bidirectional forwarding detection (BFD) for MPLS-TP is described in RFC 6428. BFD packets are sent using operator configurable timers and encapsulated without UDP/IP headers on a standardized G-ACh channel on an LSP or PW.
CC packets simply consist of a BFD control packet, while CV packets also include an identifier for the source MEP in order that the sink MEP can detect if it is receiving packets from an incorrect peer MEP, therefore indicating a mis-connectivity defect. Other defect types (including period mis-configuration defect) should be supported. When a supported defect is detected, an appropriate alarm is generated (for example: log, SNMP trap) at the receiving MEP and all traffic on the associated transport path (LSP or PW) is blocked. This is achieved using linear protection for CC defects, and by blocking the ingress datapath for CV defects.
7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T only support BFD-based CC mode. BFD-based CC-CV mode is not supported in the current release.
When an LSP with CV is first configured, the LSP will be held in the CV defect state for 3.5 seconds after the first valid CV packet is received.
The following figures show an example of linear protection switching of LSPs triggered based on a CC or CV defect detected by BFD CC/CV.
Note that RFC 6428 defines two BFD session modes: Coordinated mode, in which the session state on both directions of the LSP is coordinated and constructed from a single, bidirectional BFD session, and independent mode, in which two independent sessions are bound together at a MEP. Coordinated mode is supported.
BFD is supported on MPLS-TP LSPs. When BFD_CV detects a mis-connectivity on an LSP, the system will drop all incoming non-OAM traffic with the LSP label (at the LSP termination point) instead of forwarding it to the associated SAP or PW segment.
The following G-ACh channel types are supported for the combined CC/CV mode:
0x22 for BFD CC with no IP encapsulation
0x23 for BFD CV
The 0x07 G-ACh channel type is used for the CC-only mode.
BFD-based RDI
RDI provides a mechanism whereby the source MEP can be informed of a downstream failure on an LSP, and can therefore either raise an alarm, or initiate a protection switching operation. In the case of BFD based CC/CV, RDI is communicated using the BFD diagnostic field in BFC CC/CV messages. The following diagnostic codes are supported:
1 - Control Detection Time Expired
9 - mis-connectivity defect
PW control channel status notifications (static pseudowire status signaling)
MPLS-TP introduces the ability to support a full range of OAM and protection / redundancy on PWs for which no dynamic T-LDP control plane exists. Static PW status signaling is used to advertise the status of a PW with statically configured labels by encapsulating the PW status TLV in a G-ACh on the PW. This mechanism enables OAM message mapping and PW redundancy for such PWs, as defined in RFC6478. This mechanism is known as control channel status signaling in SR OS.
PW control channel status notifications use a similar model to T-LDP status signaling. That is, in general, status is always sent to the nearest neighbor T-PE. To achieve this, the PW label TTL is set to 1 for the G-ACh packet containing the status message.
Control channel status notifications are disabled by default on a spoke-sdp. If they are enabled, then the default refresh interval is set to zero (although this value should be configurable in CLI). That is, when a status bit changes, three control channel status packets will be sent consecutively at one-second intervals, and then the transmitter will fall silent. If the refresh timer interval is non-zero, then status messages will continue to be sent at that interval. The system supports the configuration of a refresh timer of 0, or from 10-65535 seconds. The recommended value is 600 seconds.
In order to constrain the CPU resources consumed processing control channel status messages, the system implements a credit-based mechanism. If a user enables control channel status on a PW[n], then a certain number of credits c_n are consumed from a CPM-wide pool of max_credit credits. The number of credits consumed is inversely proportional to the configured refresh timer (the first three messages at 1 second interval do not count against the credit). If the current_credit <= 0, then control channel status signaling cannot be configured on a PW (but the PW can still be configured and no shutdown).
If a PE with a non-zero refresh timer configured does not receive control channel status refresh messages for 3.5 time the specified timer value, then by default it will time out and assume a PW status of zero.
A trap is generated if the refresh timer times out.
If PW redundancy is configured, the system will always consider the literal value of the PW status; a time-out of the refresh timer will not impact the choice of the active transit object for the VLL service. The result of this is that if the refresh timer times-out, and a given PW is currently the active PW, then the system will not fail-over to an alternative PW if the status is zero and some lower-layer OAM mechanism for example, BFD has not brought down the LSP due to a connectivity defect. It is recommended that the PW refresh timer be configured with a much longer interval than any proactive OAM on the LSP tunnel, so that the tunnel can be brought down before the refresh timer expires if there is a CC defect.
A unidirectional continuity fault on a RSVP TE LSP may not result in the LSP being brought down before the received PW status refresh timer expires. It is therefore recommended that either bidirectional static MPLS-TP LSPs with BFD CC, or additional protection mechanisms. For example, FRR be used on RSVP-TE LSPs carrying MPLS-TP PWs. This is particularly important in active/standby PW dual homing configurations, where the active / standby forwarding state or operational state of every PW in the redundancy set must be accurately reflected at the redundant PE side for the configuration.
A PW with a refresh timer value of zero is always treated as having not expired.
The 7210 SAS implements a hold-down timer for control-channel-status pw-status bits in order to suppress bouncing of the status of a PW. For a specific spoke-sdp, if the system receives 10 pw-status ‟change” events in 10 seconds, the system will ‟hold-down” the spoke-sdp on the local node with the last received non-zero pw-status bits for 20 seconds. It will update the local spoke with the most recently received pw-status. This hold down timer is not persistent across shutdown/no-shutdown events.
Pseudowire redundancy and active / standby dual-homing
PW redundancy is supported for static MPLS-TP pseudowires. However, instead of using T-LDP status signaling to signal the forwarding state of a PW, control channel status signaling is used.
The following PW redundancy scenarios are available:
MC-LAG with single and multi-segment PWs interconnecting the PEs.
The 7210 SAS-T can only act as T-PE when a multi-segment PW is used.
The 7210 SAS-R6 and 7210 SAS-R12 can act as T-PE or S-PE when a multi-segment PW is used.
Dual-homing of a VLL service into redundant IES or VPRN PEs (the IES and VPRN service is configured on the 7750 PEs), with active/standby PWs.
In this scenario, 7210 SAS originates the Epipe MPLS-TP PWs as a T-PE. 7210 SAS nodes cannot terminate a MPLS-TP PW in a IES or VPRN service.
Dual-homing of a VLL service into a VPLS with active/standby PWs.
In this scenario, 7210 SAS originates the Epipe MPLS-TP PWs as a T-PE. 7210 SAS-R6 and 7210 SAS-R12 nodes can terminate a MPLS-TP PW in a VPLS service.
Active/standby dual-homing into routed VPLS is not supported for MPLS-TP PWs.
It is possible to configure inter-chassis backup (ICB) PWs as static MPLS-TP PWs with MPLS-TP identifiers. Only MPLS-TP PWs are supported in the same endpoint. That is, PWs in an endpoint must either be all MPLS-TP, or none of them must be MPLS-TP. This implies that an ICB used in an endpoint for which other PWs are MPLS TP must also be configured as an MPLS-TP PW.
A fail over to a standby pseudowire is initiated based on the existing supported methods (For example, failure of the SDP).
MPLS-TP LSP protection
Linear 1-for-1 protection of MPLS-TP LSPs is supported, as defined in RFC 6378. This applies only to LSPs (not PWs).
This is supported edge-to-edge on an LSP, between two LERs, where normal traffic is transported either on the working LSP or on the protection LSP using a logical selector bridge at the source of the protected LSP.
At the sink LER of the protected LSP, the LSP that carries the normal traffic is selected, and that LSP becomes the working LSP. A protection switching coordination (PSC) protocol coordinates between the source and sink bridge, which LSP will be used, as working path and protection path. The PSC protocol is always carried on a G-ACh on the protection LSP.
The 7210 SAS supports single-phased coordination between the LSP endpoints, in which the initiating LER performs the protection switch over to the alternate path and informs the far-end LER of the switch.
Bidirectional protection switching is achieved by the PSC protocol coordinating between the two end points to determine which of the two possible paths (that is, the working or protect path), transmits user traffic at any given time.
It is possible to configure non-revertive or revertive behavior. For non-revertive, the LSP will not switch back to the working path when the PSC switch over requests end, while for revertive configurations, the LSP always returns back to the working path when the switch over requests end.
The following figures show the behavior of linear protection in more detail.
In normal condition, user data packets are sent on the working path on both directions, from A to Z and Z to A.
A defect in the direction of transmission from node Z to node A impacts the working connection Z-to-A, and initiates the detection of a defect at the node A.
The unidirectional PSC protocol initiates protection switching: the selector bridge at node A is switched to protection connection A-to-Z and the selector at node A switches to protection connection Z to-A. The PSC packet, sent from node A to node Z, requests a protection switch to node Z.
After node Z validates the priority of the protection switch request, the selector at node Z is switched to protection connection A-to-Z and the selector bridge at the node Z is switched to protection connection Z-to-A. The PSC packet, sent from node Z to node A, is used as acknowledge, informing node A about the switching.
If BFD CC or CC/CV OAM packets are used to detect defects on the working and protection path, they are inserted on both working and protection paths, and are sent regardless of whether the selected path is the currently active path.
The 7210 SAS supports the following operator commands:
Forced Switch
Manual Switch
Clear
Lockout of protection
Configuring MPLS-TP
This section describes the steps required to configured MPLS-TP.
Configuration overview
The following steps must be performed to configure MPLS-TP LSPs or PWs.
At the 7210 SAS LER and LSR:
- Create an MPLS-TP context, containing nodal MPLS-TP identifiers. This is configured under config>router>mpls>mpls-tp.
- Ensure that a sufficient range of labels is reserved for static LSPs and PWs. This is configured under config>router>mpls-labels>static-labels.
- Ensure that a range of tunnel identifiers is reserved for MPLS-TP LSPs under config>router>mpls-mpls-tp>tp-tunnel-id-range.
- A user may optionally configure MPLS-TP interfaces, which are interfaces that no not use IP addressing or ARP for next hop resolution. These can only be used by MPLS-TP LSPs.
At the 7210 SAS LER, configure:
OAM Templates. These contain generic parameters for MPLS-TP proactive OAM. An OAM template is configured under config>router>mpls>mpls-tp>oam-template.
BFD templates. These contain generic parameters for BFD used for MPLS-TP LSPs. A BFD template is configured under config>router>bfd>bfd-template.
Protection templates. These contain generic parameters for MPLS-TP 1-for-1 linear protection. A protection template is configured under config>router>mpls>mpls-tp>protection-template.
MPLS-TP LSPs are configured under config>router>mpls>lsp mpls-tp
Pseudowires using MPLS-TP are configured as spoke SDPs with static PW labels.
At an LSR, the user must configure an LSP transit-path under config>router>mpls>mpls-tp>transit-path.
The following sections describe these configuration steps in more detail.
Node-wide MPLS-TP parameter configuration
Generic MPLS-TP parameters are configured under config>router>mpls>mpls-tp. If a user configures no mpls, normally the entire mpls configuration is deleted. However, in the case of mpls-tp a check that there is no other mpls-tp configuration for example, services or tunnels using mpls-tp on the node, will be performed.
The mpls-tp context is configured as follows.
config
router
mpls
mpls-tp
global-id <global-id>
node-id {<ipv4address> | | <1.. .4,294,967,295>}
[no] shutdown
exit
MPLS-TP LSPs may be configured if the mpls-tp context is administratively down (shutdown), but they will remain down until the mpls-tp context is configured as administratively up. No programming of the datapath for an MPLS-TP Path occurs until the following are all true:
MPLS-TP context is no shutdown
MPLS-TP LSP context is no shutdown
MPLS-TP Path context is no shutdown
A shutdown of mpls-tp will therefore bring down all MPLS-TP LSPs on the system.
The mpls-tp context cannot be deleted if MPLS-TP LSPs or SDPs exist on the system.
Node-wide MPLS-TP identifier configuration
MPLS-TP identifiers are configured for a node under the following CLI tree.
config
router
mpls
mpls-tp
global-id <global-id>
node-id <node-id>
[no] shutdown
exit
The default value for the global-id is 0. This is used if the global-id is not explicitly configured. If a user expects that inter domain LSPs will be configured, then it is recommended that the global ID should be set to the local ASN of the node. as configured under config>router. If two-byte ASNs are used, then the most significant two bytes of the global-id are padded with zeros.
The default value of the node-id is the system interface IPv4 address. The MPLS-TP context cannot be administratively enabled unless at least a system interface IPv4 address is configured because MPLS requires that this value is configured.
These values are used unless overridden at the LSP or PW end-points, and apply only to static MPLS-TP LSPs and PWs.
To change the values, config>router>mpls>mpls-tp must be in the shutdown state. This will bring down all of the MPLS-TP LSPs on the node. New values are propagated to the system when a no shutdown is performed.
Static LSP and pseudowire (VC) label and tunnel ranges
SR OS reserves a range of labels for use by static LSPs and a range of labels for use by static pseudowires (SVCs); that is, LSPs and pseudowires with no dynamic signaling of the label mapping. These are configured as follows.
config
router
mpls-labels
static-labels max-lsp-labels 991 max-svc-labels 16384
The minimum label value for the static LSP label starts at 32 and expands all the way to the maximum number specified. The static VC label range is contiguous with this. The dynamic label range exists above the static VC label range (the label ranges for the respective label type are contiguous). This prevents fragmentation of the label range.
The MPLS-TP tunnel ID range is configured as follows.
config
router
mpls
mpls-tp
[no] tp-tunnel-id-range 1 10
The tunnel ID range referred to here is a contiguous range of RSVP-TE Tunnel IDs is reserved for use by MPLS TP, and these IDs map to the MPLS-TP Tunnel Numbers. There are some cases where the dynamic LSPs may have caused fragmentation to the number space such that contiguous range {max-min} is not available. In these cases, the command will fail.
There is no default value for the tunnel ID range, and it must be configured to enable MPLS-TP.
If a configuration of the tunnel ID range fails, then the system will give a reason. This could be that the initially requested range, or the change to the allocated range, is not available, that is, the tunnel IDs in that range have already been allocated by RSVP-TE. Allocated Tunnel IDs are visible using a show command.
Changing the LSP or static VC label ranges does not require a reboot.
The static label ranges for LSPs, above, apply only to static LSPs configured using the CLI tree for MPLS-TP specified in this section. Different scalability constraints apply to static LSPs configured using the following CLI introduced in earlier SAS OS releases:
config>router>mpls>static-lsp
config>router>mpls>interface>label-map
The scalability applying to labels configured using this CLI is enforced as follows:
A maximum of 1000 static LSP names may be configured with a PUSH operation.
A maximum of 1000 LSPs with a POP or SWAP operation may be configured.
These two limits are independent of one another, giving a combined limit of 1000 PUSH and 1000 POP/SAP operations configured on a node.
The static LSP and VC label spaces are contiguous. Therefore, the dimensioning of these label spaces requires careful planning by an operator as increasing the static LSP label space impacts the start of the static VC label space, which may already-deployed
Interface configuration for MPLS-TP
It is possible for MPLS-TP paths to use both numbered IP numbered interfaces that use ARP/static ARP, or IP unnumbered interfaces. MPLS-TP requires no changes to these interfaces. It is also possible to use a new type of interface that does not require any IP addressing or next-hop resolution.
Draft-ietf-mpls-tp-next-hop-addressing provides guidelines for the usage of various Layer 2 next-hop resolution mechanisms with MPLS-TP. If protocols such as ARP are supported, then they should be used. However, in the case where no dynamic next hop resolution protocol is used, it should be possible to configure a unicast, multicast or broadcast next-hop MAC address. The rationale is to minimize the amount of configuration required for upstream nodes when downstream interfaces are changes. A default multicast MAC address for use by MPLS-TP point-to-point LSPs has been assigned by IANA (Value: 01-00-5e-90-00-00). This value is configurable on the 7210 to support interoperability with 3rd party implementations that do not default to this value, and this no default value is implemented on the 7210.
To support these requirements, a new interface type known as an unnumbered MPLS-TP interface is introduced. This is an unnumbered interface that allows a broadcast or multicast destination MAC address to be configured. An unnumbered MPLS-TP interface is configured using the unnumbered-mpls-tp keyword, as follows.
config
router
interface <if-name> [unnumbered-mpls-tp]
port <port-id>[:encap-val]
mac <local-mac-address>
static-arp <remote-mac-addr>
//ieee-address needs to support mcast and bcast
exit
The remote-mac-address may be any unicast, broadcast of multicast address. However, a broadcast or multicast remote-mac-address is only allowed in the static-arp command on Ethernet unnumbered interfaces when the unnumbered-mpls-tp keyword has been configured. This also allows the interface to accept packets on a broadcast or any multicast MAC address. If a packet is received with a unicast destination MAC address, then it will be checked against the configured <local-mac-address> for the interface, and dropped if it does not match. When an interface is of type unnumbered-mpls-tp, only MPLS-TP LSPs are allowed on that interface; other protocols are blocked from using the interface.
An unnumbered MPLS-TP interface is assumed to be point-to-point, and therefore users must ensure that the associated link is not broadcast or multicast in nature if a multicast or broadcast remote MAC address is configured.
The following is a summary of the constraints of an unnumbered MPLS-TP interface:
It is unnumbered and may borrow/use the system interface address
It prevents explicit configuration of a borrowed address
It prevents IP address configuration
It prevents all protocols except MPLS
It prevents Deletion if an MPLS-TP LSP is bound to the Interface
It is allowed only in network chassis mode D
MPLS-TP is only supported over Ethernet ports. The system will block the association of an MPLS-TP LSP to an interface whose port is non-Ethernet.
LER configuration for MPLS-TP
This section describes the LER configurations for MPLS-TP.
LSP and path configuration
MPLS-TP tunnels are configured using the mpls-tp LSP type at an LER under the LSP configuration, using the following CLI tree.
config
router
mpls
lsp <xyz> [bypass-only|mpls-tp <src-tunnel-num>]
to node-id {<a.b.c.d> | <1.. .4,294,967,295>}
dest-global-id <global-id>
dest-tunnel-number <tunnel-num>
[no] working-tp-path
lsp-num <lsp-num>
in-label <in-label>
out-label <out-label> out-link <if-name>
[next-hop <ipv4-address>]
[no] mep
[no] oam-template <name>
[no] bfd-enable [cc | cc_cv] // defaults to cc
[no] shutdown
exit
[no] shutdown
exit
[no] protect-tp-path
lsp-num <lsp-num>
in-label <in-label>
out-label <out-label> out-link <if-name>
[next-hop <ipv4-address> ]
[no] mep
[no] protection-template <name>
[no] oam-template <name>
[no] bfd-enable [cc | cc_cv] //defaults to cc
[no] shutdown
exit
[no] shutdown
exit
<if-name> could be numbered or unnumbered interface using an Ethernet port.
<src-tunnel-num> is a mandatory create time parameter for mpls-tp tunnels, and has to be assigned by the user based on the configured range of tunnel ids. The src-global-id used for the LSP ID is derived from the node-wide global-id value configured under config>router>mpls>mpls-tp. A tunnel cannot be put in the no shutdown state unless the global-id is configured.
The from address of an LSP to be used in the tunnel identifier is taken to be the local node’s node-id/global-id, as configured under config>router>mpls>mpls-tp. If that is not explicitly configured, the default value of the system interface IPv4 address is used
The to node-id address may be entered in 4-octet IPv4 address format or unsigned 32-bit format. This is the far-end node-id for the LSP, and does do need to be IP addresses.
The from and to addresses are used as the from and to node-id in the MPLS-TP Tunnel Identifier used for the MEP ID.
Each LSP consists of a working-tp-path and, optionally, a protect-tp-path. The protect-tp-path provides protection for the working-tp-path is 1:1 linear protection is configured (see below). Proactive OAM, such as BFD, is configured under the MEP context of each path. Protection for the LSP is configured under the protect-tp-path mep context.
The ‛to’ global-id is an optional parameter. If it is not entered, then the dest global ID takes the default value of 0. Global ID values of 0 are allowed and indicate that the node’s configured Global ID should be used. If the local global ID value is 0, then the remote ‛to’ global ID must also be 0. The ‛to’ global ID value cannot be changed if an LSP is in use by an SDP.
The ‛to’ tunnel number is an optional parameter. If it is not entered, then it is taken to be the same value as the source tunnel number.
LSPs are assumed to be bidirectional and co-routed. Therefore, the system will assume that the incoming interface is the same as the out-link.
The next-hop <ip-address> can only be configured if the out-link if-name refers to a numbered IP interface. In this case, the system will determine the interface to use to reach the configured next-hop, but will check that the user-entered value for the out-link corresponds to the link returned by the system. If they do not correspond, then the path will not come up. Note that if a user changes the physical port referred to in the interface configuration, then BFD, if configured on the LSP, will go down. Users should therefore ensure that an LSP is moved to a different interface with a different port configuration to change the port that it uses. This is enforced by blocking the next-hop configuration for an unnumbered interface.
There is no check made that a valid ARP entry exists before allowing a path to come up. Therefore, a path will only be held down if BFD is down. If static ARP is not configured for the interface, then it is assumed that dynamic ARP is used. The result is that if BFD is not configured, a path can come up before ARP resolution has completed for an interface. If BFD is not used, then it is recommended that the connectivity of the path is explicitly checked using on-demand CC/CV before sending user traffic on it.
The following is a list of additional considerations for the configuration of MPLS-TP LSPs and paths:
The working-tp-path must be configured before the protect-tp-path.
Likewise, the protect-tp-path has to be deleted first before the working-tp-path.
The lsp-num parameter is optional. Its default value is ‛1’ for the working-tp-path and ‛2’ for protect-tp-path.
The mep context must be deleted before a path can be deleted.
An MPLS interface needs to be created under config>router>mpls>interface before using/specifying the out-label/out-link in the Forward path for an MPLS-TP LSP. Creation of the LSP will fail if the corresponding MPLS interface does not exist even though the specified router interface may be valid.
The system will program the MPLS-TP LSP information upon a 'no shutdown' of the TP-Path only on the very first no shutdown. The Working TP-Path is programmed as the Primary and the Protection TP-Path is programmed as the 'backup'.
The system will not deprogram the IOM on an 'admin shutdown' of the MPLS-TP path. Traffic will gracefully move to the other TP-Path if valid, as determined by the proactive MPLS-TP OAM. This should not result in traffic loss. However it is recommended that the user does moves traffic to the other TP-Path through a tools command before doing 'admin shut' of an Active TP-Path.
Deletion of the out-label/out-link sub-command under the MPLS-TP Path is not allowed after being configured. These can only be modified.
MPLS will allow the deletion of an 'admin shutdown' TP-Path. This will cause MPLS to deprogram the corresponding TP-Path forwarding information from IOM. This can cause traffic loss for users that are bound to the MPLS-TP LSP.
MPLS will not deprogram the IOM on a specific interface admin shut/clear unless the interface is a System Interface. However, if MPLS informs the TP-OAM module that the MPLS interface has gone down, then it triggers a switch to the standby tp-path if the associated interface went down and if it is valid.
If a MEP is defined and shut down, then the corresponding path is also operationally down. The MEP administrative state is applicable only when a MEP is created from an MPLS-TP path.
It is not mandatory to configure BFD or protection on an MPLS-TP path to bring the LSP up.
If bfd-enable cc is configured, then CC-only mode using ACh channel 0x07 is used. If bfd-enable cc_v is configured, then BFD CC packets use channel 0x22 and CV packets use channel 0x23.
The protection template is associated with a LSP as a part of the MEP on the protect path. If only a working path is configured, then the protection template is not configured.
BFD cannot be enabled under the MEP context unless a named BFD template is configured.
Proactive CC/CV (using BFD) configuration
Generally applicable proactive OAM parameters are configured using templates.
7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T only support BFD-based CC mode. BFD-based CC-CV mode is not supported in the current release.
Proactive CC and CV uses BFD parameters such as Tx/Rx timer intervals, multiplier and other session/fault management parameters which are specific to BFD. These are configured using a BFD Template. The BFD Template may be used for non-MPLS-TP applications of BFD, and therefore contains the full set of possible configuration parameters for BFD. Only a sub-set of these may be used for any specific application.
Generic MPLS-TP OAM and fault management parameters are configured in the OAM Template.
Named templates are referenced from the MPLS-TP Path MEP configuration, so different parameter values are possible for the working and protect paths of a tunnel.
The BFD Template is configured as follows.
config
router
bfd
[no] bfd-template <name>
[no] transmit-interval <transmit-interval>
[no] receive-interval <receive-interval>
[no] echo-receive <echo-interval>
[no] multiplier <multiplier>
[no] type <cpm-np>
exit
The parameters are as follows:
transmit-interval transmit-interval and the rx receive-interval: These are the transmit and receive timers for BFD packets. If the template is used for MPLS-TP, then these are the timers used by CC packets. Values are in milliseconds: 10ms to 100,000ms, with 1ms granularity. Default 10ms for CPM3 or better, 1 sec for other hardware.
Note:For MPLS-TP CV packets, a transmit interval of 1 sec is always used.
multiplier multiplier: Integer 3 – 20. Default: 3. This parameter is ignored for MPLS-TP combined cc-v BFD sessions, and the default of 3 used, as per RFC6428.
echo-receive echo-interval: Sets the minimum echo receive interval, in milliseconds, for a session. Values: 100ms – 100,000ms. Default: 100. This parameter is not used by a BFD session for MPLS-TP.
type iom-hw type: This parameter controls the system to use the IOM based hardware BFD session for the local termination point. Hardware based BFD session is enabled by default, when BFD is configured for use with MPLS-TP LSPs.
If the above BFD timer values are changed in a template, any BFD sessions on MEPs to which that template is bound will try to renegotiate their timers to the new values. BFD implementations in some MPLS-TP peer nodes may not be able handle this renegotiation, as allowed by Section 3.7.1 of RFC6428, and may take down the BFD session. This could result in unwanted behavior, for example an unexpected protection switching event. It is therefore recommended that in these circumstances, the user of 7210 SAS exercises care in modifying the BFD timer values after a BFD session is UP.
Commands within the BFD-template use a begin-commit model. To edit any value within the BFD template, a <begin> needs to be executed after the template context has been entered. However, a value will still be stored temporarily until the commit is issued. After the commit is issued, values will actually be used by other modules like the mpls-tp module and bfd module.
A BFD template is referenced from the OAM template. The OAM Template is configured as follows.
config
router
mpls
mpls-tp
oam-template "state-machine-oam-template-prot"
bfd-template "state-machine-bfd-template-prot"
hold-time-down 0
hold-time-up 20
exit
hold-time-down interval: 0-5000 deciseconds, 10ms steps, default 0. This is equivalent to the standardized hold-off timer.
hold-time-up interval: 0-500 centiseconds in 100ms steps, default 2 seconds This is an additional timer that can be used to reduce BFD bouncing.
bfd-template name: This is the named BFD template to use for any BFD sessions enabled under a MEP for which the OAM template is configured.
An OAM template is then applied to a MEP as described above.
Protection templates and linear protection configuration
Protection templates defines the generally applicable protection parameters for an MPLS-TP tunnel. Only linear protection is supported, and so the application of a named template to an MPLS-TP tunnel implies that linear protection is used.
A template is configured as follows.
config
router
mpls
mpls-tp
protection-template <name>
[no] revertive
[no] wait-to-restore <interval>
rapid-psc-timer <interval>
slow-psc-timer <interval>
exit
The allowed values are as follows:
wait-to-restore interval: 0-720 seconds, 1 sec steps, default 300 seconds. This is applicable to revertive mode only.
rapid-psc-timer interval: [10, 100, 1000ms]. Default 100ms
slow-psc-timer interval: 5s-60s. Default: 5s
revertive: Selects revertive behavior. Default: no revertive.
LSP Linear Protection operations are enacted using the following tools>perform commands.
tools>perform>router>mpls
tp-tunnel
clear {<lsp-name> | id <tunnel-id>}
force {<lsp-name> | id <tunnel-id>}
lockout {<lsp-name> | id <tunnel-id>}
manual {<lsp-name> | id <tunnel-id>}
exit
exit
To minimize outage times, users should use the ‟mpls-tp protection command” (for example, force/manual) to switch all the relevant MPLS-TP paths before executing the following commands:
clear router mpls interface <>
config router mpls interface <> shut
Intermediate LSR configuration for MPLS-TP LSPs
The forward and reverse directions of the MPLS-TP LSP Path at a transit LSR are configured using the following CLI tree.
config
router
mpls
mpls-tp
transit-path <path-name>
[no] path-id {lsp-num <lsp-num>|working-path|protect-path
[src-global-id <global-id>]
src-node-id {<ipv4address> | <1.. .4,294,967,295>}
src-tunnel-num <tunnel-num>
[dest-global-id <global-id>]
dest-node-id {<ipv4address> | <1.. .4,294,967,295>}
[dest-tunnel-num <tunnel-num>]}
forward-path
in-label <in-label> out-label <out-label>
out-link <if-name> [next-hop <ipv4-next-hop>]
reverse-path
in-label <in-label> out-label <out-label>
[out-link <if-name> [next-hop <ipv4-next-hop>]
[no] shutdown
Ensure that the src-tunnel-num and dest-tunnel-num are consistent with the source and destination of a label mapping message for a signaled LSP.
If dest-tunnel-num is not entered in CLI, the dest-tunnel-num value is taken to be the same as the src-tunnel-num value.
If any of the global-id values are not entered, the value is taken to be 0.
If the src-global-id value is entered, but the dest-global-id value is not entered, dest-global-id value is the same as the src-global-id value.
The lsp-num must match the value configured in the LER for a specified path. If no explicit lsp-num is configured, then working-path or protect-path must be specified (equating to 1 or 2 in the system).
The forward path must be configured before the reverse path. The configuration of the reverse path is optional.
The LSP-ID (path-id) parameters apply with respect to the downstream direction of the forward LSP path, and are used to populate the MIP ID for the path at this LSR.
The reverse path configuration must be deleted before the forward path.
The forward-path (and reverse-path if applicable) parameters can be configured with or without the path-id, but they must be configured if MPLS-TP OAM is to be able to identify the LSR MIP.
The transit-path can be no shutdown (as long as the forward-path/reverse-path parameters have been configured properly) with or without identifiers.
The path-id and path-name must be unique on the node. There is a one to one mapping between a specified path-name and path-id.
Traffic cannot pass through the transit-path if the transit-path is in the shutdown state.
RSVP
The Resource Reservation Protocol (RSVP) is a network control protocol used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality of service (QoS) requests to all nodes along the paths of the flows and to establish and maintain state to provide the requested service. RSVP requests generally result in resources reserved in each node along the datapath. MPLS leverages this RSVP mechanism to set up traffic engineered LSPs. RSVP is not enabled by default and must be explicitly enabled.
RSVP requests resources for simplex flows. It requests resources only in one direction (unidirectional). Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. Duplex flows require two LSPs, to carry traffic in each direction.
RSVP is not a routing protocol. RSVP operates with unicast and multicast routing protocols. Routing protocols determine where packets are forwarded. RSVP consults local routing tables to relay RSVP messages.
RSVP uses two message types to set up LSPs, PATH and RESV. Establishing LSPs shows the process to establish an LSP.
The sender (the ingress LER (ILER)), sends PATH messages toward the receiver, (the egress LER (ELER)) to indicate the FEC for which label bindings are wanted. PATH messages are used to signal and request label bindings required to establish the LSP from ingress to egress. Each router along the path observes the traffic type.
PATH messages facilitate the routers along the path to make the necessary bandwidth reservations and distribute the label binding to the router upstream.
The ELER sends label binding information in the RESV messages in response to PATH messages received.
The LSP is considered operational when the ILER receives the label binding information.
Figure 20. Establishing LSPs 
The following figure shows an example of an LSP path set up using RSVP. The ingress label edge router (ILER 1) transmits an RSVP path message (path: 30.30.30.1) downstream to the egress label edge router (ELER 4). The path message contains a label request object that requests intermediate LSRs and the ELER to provide a label binding for this path.
Figure 21. LSP using RSVP path set up 
In addition to the label request object, an RSVP PATH message can also contain a number of optional objects:
Explicit route object (ERO) — When the ERO is present, the RSVP path message is forced to follow the path specified by the ERO (independent of the IGP shortest path).
Record route object (RRO) — Allows the ILER to receive a listing of the LSRs that the LSP tunnel actually traverses.
A session attribute object controls the path set up priority, holding priority, and local-rerouting features.
Upon receiving a path message containing a label request object, the ELER transmits a RESV message that contains a label object. The label object contains the label binding that the downstream LSR communicates to its upstream neighbor. The RESV message is sent upstream toward the ILER, in a direction opposite to that followed by the path message. Each LSR that processes the RESV message carrying a label object uses the received label for outgoing traffic associated with the specific LSP. When the RESV message arrives at the ingress LSR, the LSP is established.
Using RSVP for MPLS
Hosts and routers that support both MPLS and RSVP can associate labels with RSVP flows. When MPLS and RSVP are combined, the definition of a flow can be made more flexible. After an LSP is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic can be accomplished using a variety of criteria. The set of packets that are assigned the same label value by a specific node are considered to belong to the same FEC which defines the RSVP flow.
For use with MPLS, RSVP already has the resource reservation component built-in which makes it ideal to reserve resources for LSPs.
RSVP Traffic Engineering extensions for MPLS
RSVP has been extended for MPLS to support automatic signaling of LSPs. To enhance the scalability, latency, and reliability of RSVP signaling, several extensions have been defined. Refresh messages are still transmitted but the volume of traffic, the amount of CPU utilization, and response latency are reduced while reliability is supported. None of these extensions result in backward compatibility problems with traditional RSVP implementations.
Hello protocol
The Hello protocol detects the loss of a neighbor node or the reset of a neighbor’s RSVP state information. In standard RSVP, neighbor monitoring occurs as part of the RSVP soft-state model. The reservation state is maintained as cached information that is first installed and then periodically refreshed by the ingress and egress LSRs. If the state is not refreshed within a specified time interval, the LSR discards the state because it assumes that either the neighbor node has been lost or its RSVP state information has been reset.
The Hello protocol extension is composed of a hello message, a hello request object and a hello ACK object. Hello processing between two neighbors supports independent selection of failure detection intervals. Each neighbor can automatically issue hello request objects. Each hello request object is answered by a hello ACK object.
MD5 authentication of RSVP interface
When enabled on an RSVP interface, authentication of RSVP messages operates in both directions of the interface.
A node maintains a security association with its neighbors for each authentication key. The following items are stored in the context of this security association:
The HMAC-MD5 authentication algorithm.
Key used with the authentication algorithm.
Lifetime of the key. A key is user-generated key using a third party software/hardware and enters the value as static string into CLI configuration of the RSVP interface. The key will continue to be valid until it is removed from that RSVP interface.
Source Address of the sending system.
Latest sending sequence number used with this key identifier.
The RSVP sender transmits an authenticating digest of the RSVP message, computed using the shared authentication key and a keyed-hash algorithm. The message digest is included in an Integrity object which also contains a Flags field, a Key Identifier field, and a Sequence Number field. The RSVP sender complies to the procedures for RSVP message generation in RFC 2747, RSVP Cryptographic Authentication.
An RSVP receiver uses the key together with the authentication algorithm to process received RSVP messages.
When a PLR node switches the path of the LSP to a bypass LSP, it does not send the Integrity object in the RSVP messages over the bypass tunnel. If an integrity object is received from the MP node, then the message is discarded because there is no security association with the next-next-hop MP node.
The 7210 SAS MD5 implementation does not support the authentication challenge procedures in RFC 2747.
Reservation styles
LSPs can be signaled with explicit reservation styles. A reservation style is a set of control options that specify a number of supported parameters. The style information is part of the LSP configuration. The 7210 SAS supports two reservation styles.
If FRR is enabled for the LSP and selects the facility FRR method at the head-end node, only the SE reservation style is allowed. Furthermore, if a 7210 SAS PLR node receives a path message with fast-reroute requested with facility method and the FF reservation style, it will reject the reservation. The one-to-one detour method supports both FF and SE styles.
RSVP message pacing
When a flood of signaling messages arrive because of topology changes in the network, signaling messages can be dropped which results in longer set up times for LSPs. RSVP message pacing controls the transmission rate for RSVP messages, allowing the messages to be sent in timed intervals. Pacing reduces the number of dropped messages that can occur from bursts of signaling messages in large networks.
RSVP overhead refresh reduction
The RSVP refresh reduction feature consists of the following capabilities implemented in accordance to RFC 2961, RSVP Refresh Overhead Reduction Extensions:
RSVP message bundling
This capability is intended to reduce overall message handling load. The 7210 SAS supports receipt and processing of bundled message only, but no transmission of bundled messages.
Reliable message delivery
This capability consists of sending a message-id and returning a message-ack for each RSVP message. It can be used to detect message loss and support reliable RSVP message delivery on a per hop basis. It also helps reduce the refresh rate because the delivery becomes more reliable.
Summary refresh
This capability consists of refreshing multiples states with a single message-id list and sending negative ACKs (NACKs) for a message_id which could not be matched. The summary refresh capability reduce the amount of messaging exchanged and the corresponding message processing between peers. It does not however reduce the amount of soft state to be stored in the node.
These capabilities can be enabled on a per-RSVP-interface basis are referred to collectively as ‟refresh overhead reduction extensions”. When the refresh-reduction is enabled on a 7210 SAS RSVP interface, the node indicates this to its peer by setting a refresh-reduction- capable bit in the flags field of the common RSVP header. If both peers of an RSVP interface set this bit, all the above three capabilities can be used. Furthermore, the node monitors the settings of this bit in received RSVP messages from the peer on the interface. As soon as this bit is cleared, the node stops sending summary refresh messages. If a peer did not set the ‟refresh-reduction-capable” bit, a 7210 SAS node does not attempt to send summary refresh messages.
Configuring implicit null
The implicit null label option allows a 7210 SAS egress LER to receive MPLS packets from the previous hop without the outer LSP label. The operation of the previous hop is referred to as penultimate hop popping (PHP). This option is signaled by the egress LER to the previous hop during the FEC signaling by the LDP control protocol.
The router can be configured to signal the implicit null label value over all RSVP interfaces and for all RSVP LSPs which have this node as the egress LER. In addition, the egress LER can be configured to receive MPLS packet with the implicit null label on a static LSP.
The following CLI command is used to configure the router:
config>router>ldp>implicit-null-label
RSVP must be shut down before changing the implicit null configuration option.
Using unnumbered Point-to-Point interface in RSVP
This feature is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.
This feature introduces the use of unnumbered IP interface as a Traffic Engineering (TE) link for the signaling of RSVP P2P LSP and P2MP LSP.
An unnumbered IP interface is identified uniquely on a router in the network by the tuple {router-id, ifIndex}. Each side of the link assigns a system-wide unique interface index to the unnumbered interface. IS-IS, OSPF, RSVP, and OAM modules will use this tuple to advertise the link information, signal LSP paths over this unnumbered interface, or send and respond to an MPLS echo request message over an unnumbered interface.
The interface borrowed IP address is used exclusively as the source address for IP packets which are originated from the interface and needs to be configured to an address different from system interface for the FRR bypass LSP to come up at the ingress LER.
The borrowed IP address for an unnumbered interface is configured using the following CLI command with a default value set to the system interface address:
configure>router>interface>unnumbered [ip-int-name | ip-address].
The support of unnumbered TE link in IS-IS consists of adding a new sub-TLV of the extended IS reachability TLV, which encodes the Link Local and Link Remote Identifiers as defined in RFC 5307.
The support of unnumbered TE link in OSPF consists of adding a new sub-TLV, which encodes the same Link Local and Link Remote Identifiers in the Link TLV of the TE area opaque LSA and sends the local Identifier in the Link Local Identifier TLV in the TE link local opaque LSA as per RFC 4203.
The support of unnumbered TE link in RSVP implements the signaling of unnumbered interfaces in ERO/RRO as per RFC 3477 and the support of IF_ID RSVP_HOP object with a new Ctype as per Section 8.1.1 of RFC 3473. The IPv4 Next/Previous Hop Address field is set to the borrowed IP interface address.
The unnumbered IP is advertised by IS-IS TE and OSPF TE, and CSPF can include them in the computation of a path for a P2P LSP or for the S2L of a P2MP LSP. This feature does not, however, support defining an unnumbered interface as a hop in the path definition of an LSP.
A router creates an RSVP neighbor over an unnumbered interface using the tuple {router-id, ifIndex}. The router-id of the router which advertised a specified unnumbered interface index is obtained from the TE database. As as result, if traffic engineering is disabled in IS-IS or OSPF, a non-CSPF LSP with the next-hop for its path is over an unnumbered interface will not come up at the ingress LER because the router-id of the neighbor which has the next-hop of the path message cannot be looked up.
In this case, the LSP path will remain in operationally down state with a reason 'noRouteToDestination'. If a PATH message was received at the LSR in which traffic engineering was disabled and the next-hop for the LSP path is over an unnumbered interface, a PathErr message will be sent back to the ingress LER with the Routing Problem error code of 24 and an error value of 5 ‟No route available toward destination”.
This feature supports all of the MPLS features available for numbered IP interfaces, with the following exceptions:
Configuring a router-id with a value other than system.
Signaling of an LSP path with an ERO based a loose/strict hop using an unnumbered TE link in the path hop definition.
Signaling of one-to-one detour LSP over unnumbered interface.
Soft preemption of LSP path using unnumbered interface.
Inter-area LSP.
Unnumbered RSVP interface registration with BFD.
RSVP Hello and all Hello related capabilities such as Graceful-restart helper.
The user SRLG database feature. The user-srlg-db option under MPLS allows the user to manually enter the SRLG membership of any link in the network in a local database at the ingress LER. The user cannot enter an unnumbered interface into this database and therefore all unnumbered interfaces will be considered as having no SRLG membership if the user enabled the user-srlg-db option.
This feature also extends the support of lsp-ping, p2mp-lsp-ping, lsp-trace, and p2mp-lsptrace to P2P and P2MP LSPs that have unnumbered TE links in their path.
Operation of RSVP FRR facility backup over unnumbered interface
When the Point-of-Local Repair (PLR) node activates the bypass LSP by sending a PATH message to refresh the path state of protected LSP at the Merge-Point (MP) node, it must use an IPv4 tunnel sender address in the sender template object which is different than the one used by the ingress LER in the PATH message. These are the procedures specified in RFC 4090 and which are followed in the node implementation.
The node uses the address of the outgoing interface of the bypass LSP as the IPv4 tunnel sender address in the sender template object. This address will be different from the system interface address used in the sender template of the protected LSP by the ingress LER and therefore does not cause conflicts when the ingress LER acts as a PLR.
When the PLR is the ingress LER node and the outgoing interface of the bypass LSP is unnumbered, it is required that the user assigns to the interface a borrowed IP address which is different from the system interface. If not, the bypass LSP will not come up.
In addition, the PLR node will include the IPv4 RSVP_HOP object (C-Type=1) or the IF_ID RSVP_HOP object (C-Type=3) in the PATH message if the outgoing interface of the bypass LSP is numbered or unnumbered respectively.
When the MP node receives the PATH message over the bypass LSP, it will create the merge-point context for the protected LSP and associate it with the existing state if any of the following is satisfied:
Change in C-Type of the RSVP_HOP object
C-Type is IF_ID RSVP_HOP and did not change but IF_ID TLV is different
Change in IPv4 Next/Previous Hop Address in RSVP_HOP object regardless of the C-Type value
These procedures at PLR and MP nodes are followed in both link-protect and node-protect FRR.
If the MP node is running a pre-R9.0 R4 implementation, it will reject the new IF_ID C-Type and drop the PATH over bypass. This will result in the protected LSP state expiring at the MP node, which will tear down the path. This would be the case in general when node-protect FRR is enabled and the MP node does not support unnumbered RSVP interface.
PCEP support for RSVP-TE LSPs
PCEP is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.
The Path Computation Element Communication Protocol (PCEP) is one of several protocols used for communication between a wide area network (WAN) software-defined network (SDN) controller and network elements.
The 7210 SAS operates as a PCE Client (PCC) only, supporting PCC capabilities for RSVP-TE LSPs.
The following MPLS-level and LSP-level CLI commands are used to configure RSVP-TE LSPs in a router acting as a PCC.
-
config>router>mpls> pce-report rsvp-te {enable | disable} -
config>router>mpls>lsp> path-profile profile-id [path-group group-id] pce-computation pce-control pce-report {enable | disable | inherit}
Traffic Engineering
Without traffic engineering, routers route traffic according to the SPF algorithm, disregarding congestion or packet types.
With traffic engineering, network traffic is routed efficiently to maximize throughput and minimize delay. Traffic engineering facilitates the mapping of traffic flows to the destination through a different (less congested) path other than the one selected by the SPF algorithm.
MPLS directs a flow of IP packets along a label switched path (LSP). LSPs are simplex, meaning that the traffic flows in one direction (unidirectional) from an ingress router to an egress router. Two LSPs are required for duplex traffic. Each LSP carries traffic in a specific direction, forwarding packets from one router to the next across the MPLS domain.
When an ingress router receives a packet, it adds an MPLS header to the packet and forwards it to the next hop in the LSP. The labeled packet is forwarded along the LSP path until it reaches the destination point. The MPLS header is removed and the packet is forwarded based on Layer 3 information such as the IP destination address. The physical path of the LSP is not constrained to the shortest path that the IGP would choose to reach the destination IP address.
TE metric (IS-IS and OSPF)
When the use of the TE metric is selected for an LSP, the shortest path computation after the TE constraints are applied will select an LSP path based on the TE metric instead of the IGP metric. The user configures the TE metric under the MPLS interface. Both the TE and IGP metrics are advertised by OSPF and IS-IS for each link in the network. The TE metric is part of the traffic engineering extensions of both IGP protocols.
A typical application of the TE metric is to allow CSPF to represent a dual TE topology for the purpose of computing LSP paths.
An LSP dedicated for real-time and delay sensitive user and control traffic has its path computed by CSPF using the TE metric. The user configures the TE metric to represent the delay figure, or a combined delay/jitter figure, of the link. In this case, the shortest path satisfying the constraints of the LSP path will effectively represent the shortest delay path.
An LSP dedicated for non delay sensitive user and control traffic has its path computed by CSPF using the IGP metric. The IGP metric could represent the link bandwidth or some other figure as required.
When the use of the TE metric is enabled for an LSP, CSPF will first prune all links in the network topology that do not meet the constraints specified for the LSP path. These constraints include bandwidth, admin-groups, and hop limit. CSPF will then run an SPF on the remaining links. The shortest path among the all SPF paths will be selected based on the TE metric instead of the IGP metric which is used by default. The TE metric is only used in CSPF computations for MPLS paths and not in the regular SPF computation for IP reachability.
Maintenance of TE links and nodes
Graceful shutdown is used to maintain selective links and nodes in a TE network. Before a shutdown, head-end LER nodes are notified of the imminent shutdown of the links or nodes for the purpose of maintenance, so the head-end nodes can move the paths of the LSPs away from the affected resources. Modified TE parameters for the affected links are flooded so all other nodes in the network avoid them in the CSPF calculations.
When the maintenance is over, the operator disables graceful shutdown, which reinstates and floods the user-configured TE parameters. The restored links are available for LSP path establishment.
Admin-group support on facility bypass backup LSP
This feature is supported only on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.
This includes of the LSP primary path admin-group constraints in the computation of a fast reroute (FRR) facility bypass backup LSP so that all nodes in the LSP path protect the primary LSP path.
This feature is supported with the primary path of an RSVP P2P LSP in both intra-area and inter-area TE.
Procedures at head-end node
The user enables the signaling of the primary LSP path admin-group constraints in the FRR object at the ingress LER with the following CLI command:
config>router>mpls>lsp>fast-reroute>propagate-admin-group
When this command is enabled at the ingress LER, the admin-group constraints configured in the context of the P2P LSP primary path, or the constraints configured in the context of the LSP and inherited by the primary path, are copied into the FAST_REROUTE object. The admin-group constraints are copied into the ‟include-any” or ‟exclude-any” fields.
During LSP signaling to the downstream node, the ingress LER also propagates the admin-group constraints, which allows the node to include these constraints in the selection of the FRR backup LSP for LSP primary path protection.
The ingress LER inserts the FAST_REROUTE object, by default, in a primary LSP path message. If the user disables the object using the config>router>mpls>no frr-object command, the admin-group constraints are not propagated.
The same admin-group constraints can be copied into the Session Attribute object for use by LSR, typically an ABR, to expand the ERO of an inter-area LSP path. The constraints are also used by any LSR node in the path of a CSPF or non-CSPF LSP to check the admin-group constraints against the ERO, regardless of whether the hop is strict or loose. These constraints are governed strictly by the config>router>mpls>lsp>propagate-admin-group command.
That is, the user can copy the primary path admin-group constraints into only the FAST_REROUTE object, or only the Session Attribute object, or both.
The point-of-local repair (PLR) rules for admin-group constraint processing can use either FAST_REROUTE or Session Attribute object admin-group constraints.
Procedures at PLR node
The global config>router>mpls>admin-group-frr command is used to enable admin-group constraints when associating a manual or dynamic bypass LSP with the primary LSP path at a PLR node.
When the user enables this command, each PLR node reads the admin-group constraints in the FAST_REROUTE object included in the Path message of the LSP primary path. If the object is not included, the PLR reads the admin-group constraints from the Session Attribute object in the Path message.
If the PLR is also the ingress LER for the LSP primary path, the PLR uses the admin-group constraint from the LSP or path level configurations.
Whether the PLR node is also the ingress LER or just an LSR for the protected LSP primary path, the outcome of the ingress LER configuration dictates the behavior of the PLR node. The following table summarizes the bypass LSP admin-group behavior.
Ingress LER configuration |
Session attribute |
FRR object |
Bypass LSP at PLR (LER/LSF) follows admin-group constraints |
|
|---|---|---|---|---|
1 |
frr-object lsp>no propagate-admin-group lsp>frr>propagate-admin-group |
Admin color constraints not sent |
Admin color constraints sent |
Yes |
2 |
frr-object lsp>propagate-admin-group lsp>frr>propagate-admin-group |
Admin color constraints sent |
Admin color constraints sent |
Yes |
3 |
frr-object lsp>propagate-admin-group lsp>frr>no propagate-admin-group |
Admin color constraints sent |
Admin color constraints not sent |
No |
4 |
no frr-object lsp>propagate-admin-group lsp>frr>propagate-admin-group |
Admin color constraints sent |
Not present |
Yes |
5 |
no frr-object lsp>no propagate-admin-group lsp>frr>propagate-admin-group |
Admin color constraints not sent |
Not present |
No |
6 |
no frr-object lsp>propagate-admin-group lsp>frr>no propagate-admin-group |
Admin color constraints sent |
Not present |
Yes |
Next, the PLR node uses the admin-group constraints and other constraints, such as hop-limit and SRLG, to select a manual or dynamic bypass among those that are already in use.
If none of the manual or dynamic bypass LSPs satisfy the admin-group constraints and other constraints, the PLR node requests the CSPF for the path that merges closest to the protected link or node and includes or excludes the specified admin-group IDs.
Modifying the configuration of the config>router>mpls>admin-group-frr command does not affect existing bypass associations. The change only applies to new attempts to find a valid bypass.
Manual and timer resignal of RSVP-TE bypass LSP
This feature is supported only on the 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.
The config>router>mpls>bypass-resignal-timer command triggers the periodic global reoptimization of all dynamic bypass LSP paths associated with an RSVP P2P LSP. The operation is performed at each expiry of the user-configurable bypass LSP resignal timer.
When this command is enabled, MPLS requests the CSPF for the best path for each dynamic bypass LSP originated on this node. The constraints, hop limit, SRLG, and admin-group constraints of the first associated LSP primary path that originally triggered the signaling of the bypass LSP must be satisfied. To do this, MPLS saves the original Path State Block (PSB) of that LSP primary path, even if the latter is torn down.
If CSPF returns no path or returns a new path with a cost that is higher than the current path, MPLS does not signal the new bypass path. If CSPF returns a new path with a cost that is lower than the current path, MPLS signals it. Also, if the new bypass path is SRLG strict disjoint with the primary path of the original PSB while the current path is SRLG loose disjoint, the manual bypass path is resignaled, regardless of cost comparison.
After the new path is successfully signaled, MPLS evaluates each PSB of each PLR (that is, each unique avoid-node or avoid-link constraint) associated with the current bypass LSP path to check if the corresponding LSP primary path constraints are still satisfied by the new bypass LSP path. If so, the PSB association is moved to the new bypass LSP.
Each PSB for which the constraints are not satisfied remains associated with the PLR on the current bypass LSP and is checked at the next background PSB re-evaluation, or at the next timer or manual bypass reoptimization. Additionally, if SRLG FRR loose disjointness is configured using the configure>router>mpls srlg-frr command, and the current bypass LSP is SRLG disjoint with a primary path while the new bypass LSP is not SRLG disjoint, the PSB association is not moved.
If a specific PLR associated with a bypass LSP is active, the corresponding PSBs remain associated with the current PLR until the global revertive Make-Before-Break (MBB) tears down all corresponding primary paths, which also causes the current PLR to be removed.
While it is in the preceding state, the older PLR does not get any new PSB association until the PLR is removed. When the last PLR is removed, the older bypass LSP is torn down.
Additionally, PSBs that have not been moved by the dynamic or manual reoptimization of a bypass LSP as a result of the PSB constraints not being met by the new signaled bypass LSP path are re-evaluated by the FRR background task, which handles cases where the PSB has requested node protection, but its current PLR is a link-protect.
This feature is not supported with an inter-area dynamic bypass LSP and bypass LSP protecting S2L paths of a P2MP LSP.
The tools>perform>router>mpls>resignal-bypass command performs a manual reoptimization of a specific dynamic or manual bypass LSP, or of all dynamic bypass LSPs.
The user must configure the manual bypass LSP name. The dynamic bypass LSP name is displayed in the output of show>router>mpls>bypass-tunnel dynamic detail.
The delay option triggers the global reoptimization of all dynamic bypass LSPs at the expiry of the specified delay. This option forces the global bypass resignal timer to expire after an amount of time equal to the value of the delay parameter. This option has no effect on a manual bypass LSP.
However, when the bypass LSP name is specified, the named dynamic or manual bypass LSP is signaled and the associations are moved only if the new bypass LSP path has a lower cost than the current one. This behavior is different from that of the tools>perform>router>mpls>resignal command for the primary or secondary active path of an LSP, which signals and switches to the new path, regardless of the cost comparison. This handling is required because a bypass LSP can have a large number of PSB associations and the associated processing churn is much higher.
In the specific case where the name corresponds to a manual bypass LSP, the LSP is torn down and resignaled using the new path provided by CSPF if no PSB associations exist. If one or more PSB associations exist but no PLR is active, the tools>perform>router>mpls>resignal-bypass bypass-lsp-name configuration fails and the user is prompted to explicitly enter the force option. In this case, the manual bypass LSP is torn down and resignaled, temporarily leaving the associated LSP primary paths unprotected. If one or more PLRs associated with the manual bypass LSP is active, the command fails.
Finally, and as with the timer-based resignal, the PSB associations are checked for the SRLG and admin-group constraints using the updated information provided by CSPF for the current path and new path of the bypass LSP. See RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB and RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB for more information.
RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB
This feature enhances procedures of the timer and manual resignal (both delay and lsp options) of the RSVP-TE bypass LSP path by updating the SRLG information of the links of the current path and checking for SRLG disjointness constraint. The following sequence describes the timer and manual resignal enhancements.
CSPF updates the SRLG membership of the current bypass LSP path and checks if the path violates the SRLG constraint of the first primary path that was associated with a PLR of this bypass LSP. This is referred to as the initial PSB.
CSPF attempts a new path computation for the bypass LSP using the initial PSB constraints.
-
MPLS uses the information returned by CSPF to determine if the new bypass path is more optimal.
-
If SRLG FRR strict disjointness is configured using the configure>router>mpls> srlg-frr strict option and CSPF indicates that the updated SRLG information of the current path violated the SRLG constraint of the PLR of the initial PSB, the new path is more optimal.
-
Otherwise, MPLS performs additional checks using the PLR of the initial PSB to determine if the new path is more optimal. The following table summarizes the possible cases of bypass path optimality determination.
Table 5. Determination of bypass LSP path optimality PLR SRLG constraint check1
SRLG FRR configuration (strict/loose)
Path cumulative cost comparison1
More optimal path
Current path
New path
Disjoint
Disjoint
—
New cost < current cost
New
Disjoint
Disjoint
—
New cost ≥ current cost
Current
Disjoint
Not disjoint
—
—
Current
Not disjoint
Disjoint
—
—
New
Not disjoint
Not disjoint
Strict
—
Current
Not disjoint
Not disjoint
Loose
New cost < current cost
New
Not disjoint
Not disjoint
Loose
New cost ≥ current cost
Current
-
If the path returned by CSPF is found to be a more optimal bypass path with respect to the PLR of the initial PSB, the following sequence of actions occurs.
MPLS signals and programs the new path.
MPLS moves to the new bypass path the PSB associations of all PLRs for which evaluation against the preceding table results in the new bypass path being more optimal.
Among the remaining PLRs, if the updated SRLG information of the current bypass path changed and SRLG FRR loose disjointness is configured (configure>router>mpls>srlg-frr), MPLS keeps this PLR PSB association with the current bypass path.
Among the remaining PLRs, if the updated SRLG information of the current bypass path changed and SRLG strict disjointness is configured (configure>router>mpls>srlg-frr strict), MPLS evaluates the SRLG constraint of each PLR and performs the following actions.
MPLS keeps with the current bypass path the PSB associations of all PLRs where the SRLG constraint is not violated by the updated SRLG information of the current bypass path.
These PSBs are re-evaluated at the next timer or manual resignal MBB following the procedure described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.
MPLS detaches from the current bypass path the PSB associations of all PLRs where the SRLG constraint is violated by the updated SRLG information of the current bypass path.
These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis following the procedure described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.
If the path returned by CSPF is found to be less optimal than the current bypass path, or if CSPF does not return a new path, the following actions are performed.
If the updated SRLG information of the current bypass path did not change, MPLS keeps the current bypass path and the PSB associations of all PLRs.
If the updated SRLG information of the current bypass path changed and SRLG FRR loose disjointness is configured using the configure>router>mpls>srlg-frr command, MPLS keeps the current bypass path and the PSB associations of all PLRs.
If the updated SRLG information of the current bypass path has changed and SRLG strict disjointness is configured (configure>router>mpls>srlg-frr strict), MPLS evaluates the SRLG constraint of each PLR and performs the following actions.
MPLS keeps with the current bypass path the PSB associations of all PLRs where the SRLG constraint is not violated by the updated SRLG information of the current bypass path.
These PSBs are re-evaluated at the next timer or manual resignal MBB following the procedure described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.
MPLS detaches from the current bypass path the PSB associations of all PLRs where the SRLG constraint is violated by the updated SRLG information of the current bypass path.
These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis following the procedure described in RSVP-TE bypass LSP path SRLG information update in manual and timer resignal MBB.
RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB
This feature enhances procedures of the timer and manual resignal (both delay and lsp options) of a RSVP-TE bypass LSP path by updating the administrative group information of the current path links and checking for administrative group constraints. The following sequence describes the timer and manual resignal enhancements.
CSPF updates the administrative group membership of the current bypass LSP path and checks if the path violates the administrative group constraints of the first primary path associated with this bypass LSP. This is referred to as the initial PSB.
CSPF attempts a new path computation for the bypass LSP using the PLR constraints of the initial PSB.
MPLS uses the information returned by CSPF and determines if the new bypass path is more optimal.
If CSPF indicates the updated administrative group information of the current path violates the administrative group constraint of the initial PSB, the new path is more optimal.
Otherwise, the new path is more optimal only if its metric is lower than the updated metric of the current bypass path.
If the path returned by CSPF is found to be a more optimal bypass path, the following sequence of actions is performed.
MPLS signals and programs the new path.
Because the administrative group constraint is not part of the PLR definition, MPLS evaluates the PSBs of all PLRs associated with the current bypass, and takes the following actions.
MPLS moves to the new bypass path the PSB associations in which the administrative group constraints are not violated by the new bypass path.
Among the remaining PSBs, MPLS keeps with the current bypass path the PSB associations in which the administrative group constraints are not violated by the updated administrative group information of the current bypass path.
These PSBs are re-evaluated at the next timer or manual resignal MBB following the procedure described in RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB.
Among the remaining PSBs, MPLS detaches from the current bypass path the PSB associations in which the administrative group constraints are violated by the updated administrative group information of the current bypass path.
These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis following the procedure described in RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB.
If the path returned by CSPF is found to be less optimal than the current bypass path or if CSPF did not return a new path, the following actions are performed.
If the updated administrative group information of the current bypass path did not change, MPLS keeps the current bypass path and all PSB associations.
If the updated administrative group information of the current bypass path has changed, MPLS evaluates the PSBs of all PLRs associated with the current bypass, and performs the following actions.
MPLS keeps with the current bypass path the PSB associations in which the administrative group constraints are not violated by the updated administrative group information of the current bypass path.
MPLS detaches from the current bypass path the PSB associations in which the administrative group constraints are violated by the updated administrative group information of the current bypass path.
These orphaned PSBs are re-evaluated by the FRR background task, which checks unprotected PSBs on a regular basis following the procedure described in RSVP-TE bypass LSP path administrative group information update in manual and timer resignal MBB.
Advanced MPLS/RSVP features
This section describes the advanced MPLS and RSVP features.
Shared Risk Link Groups
Shared Risk Link Groups (SRLGs) is a feature that allows the user to establish a backup secondary LSP path or a FRR LSP path which is disjoint from the path of the primary LSP. Links that are members of the same SRLG represent resources sharing the same risk, for example, fiber links sharing the same conduit or multiple wavelengths sharing the same fiber.
When the SRLG option is enabled on a secondary path, CSPF includes the SRLG constraint in the computation of the secondary LSP path. This requires that the primary LSP already be established and up since the head-end LER needs the most current ERO computed by CSPF for the primary path. CSPF would return the list of SRLG groups along with the ERO during primary path CSPF computation. At a subsequent establishment of a secondary path with the SRLG constraint, the MPLS/RSVP task will query again CSPF providing the list of SLRG group numbers to be avoided. CSPF prunes all links with interfaces which belong to the same SRLGs as the interfaces included in the ERO of the primary path. If CSPF finds a path, the secondary is setup. If not, MPLS/RSVP will keep retrying the requests to CSPF.
When the SRLG option is enabled on FRR, CSPF includes the SRLG constraint in the computation of a FRR detour or bypass for protecting the primary LSP path. CSPF prunes all links with interfaces which belong to the same SRLG as the interface which is being protected, for example, the outgoing interface at the PLR the primary path is using. If one or more paths are found, the MPLS/RSVP task will select one based on best cost and will signal the bypass/detour. If not and the user included the strict option, the bypass/detour is not setup and the MPLS/RSVP task will keep retrying the request to CSPF. Otherwise, if a path exists which meets the other TE constraints, other than the SRLG one, the bypass/detour is setup.
A bypass or a detour LSP path is not guaranteed to be SRLG disjoint from the primary path. This is because only the SRLG constraint of the outgoing interface at the PLR that the primary path is using is avoided.
Enabling disjoint backup paths
The following details the steps necessary to create shared risk link groups:
For primary/standby SRLG disjoint configuration:
Create an SRLG-group similar to admin groups.
Link the SRLG-group to MPLS interfaces.
Configure primary and secondary LSP paths and enable SRLG on the secondary LSP path.
Note:The SRLG secondary LSP paths will always perform a strict CSPF query; the srlg-frr command is irrelevant in this case. For more information, see srlg-frr.
For FRR detours/bypass SRLG disjoint configuration:
Create an SRLG group, similar to admin groups.
Link the SRLG group to MPLS interfaces.
Enable the srlg-frr (strict/non-strict) option, which is a system-wide parameter, and it force every LSP path CSPF calculation, to take the configured SRLG memberships (and propagated through the IGP opaque-te-database) into account.
Configure primary FRR (one-to-one/facility) LSP paths. Consider that each PLR will create a detour/bypass that will only avoid the SRLG memberships configured on the primary LSP path egress interface. In a one-to-one case, detour-detour merging is out of the control of the PLR, therefore the latter will not ensure that its detour will be prohibited to merge with a colliding one. For facility bypass, with the presence of several bypass type to bind to, the following priority rules will be followed:
Manual bypass disjoint
Manual bypass non-disjoint (eligible only if srlg-frr is non-strict)
Dynamic disjoint
Dynamic non-disjoint (eligible only if srlg-frr is non-strict)
Non-CSPF manual bypass is not considered.
The following figure shows a typical application of the SRLG feature is to provide for an automatic placement of secondary backup LSPs or FRR bypass/detour LSPs that minimizes the probability of fate sharing with the path of the primary LSP.
Figure 22. Shared Risk Link Groups 
This feature is supported on OSPF and IS-IS interfaces on which RSVP is enabled.
Static configurations of SRLG memberships
This feature provides operations with the ability to enter manually the link members of SRLG groups for the entire network at any 7210 SAS node which will need to signal LSP paths (for example, a head-end node).
The operator may explicitly enables the use by CSPF of the SRLG database. In that case, CSPF will not query the TE database for IGP advertised interface SRLG information.
The SRLG secondary path computation and FRR bypass/detour path computation remains unchanged.
There are deployments where the 7210 SAS will interpret with routers that do not implement the SRLG membership advertisement through IGP SRLG TLV or sub-TLV.
In these situations, the user is provided with the ability to enter manually the link members of SRLG groups for the entire network at any 7210 SAS node which will need to signal LSP paths, for example, a head-end node.
The user enters the SRLG membership information for any link in the network by using the interface ip-int-name srlg-group group-name command in the config>router>mpls> srlg-database>router-id context. An interface can be associated with up to 5 SRLG groups for each execution of this command. The user can associate an interface with up to 64 SRLG groups by executing the command multiple times. The user must also use this command to enter the local interface SRLG membership into the user SRLG database. The user deletes a specific interface entry in this database by executing the no form of this command.
The group-name must have been previously defined in the SRLG srlg-group group-name value group-value command in the config>router>mpls. The maximum number of distinct SRLG groups the user can configure on the system is 1024.
The parameter value for router-id must correspond to the router ID configured under the base router instance, the base OSPF instance or the base IS-IS instance of a specific node. A single user SLRG database is maintained per node regardless if the listed interfaces participate in static routing, OSPF, IS-IS, or both routing protocols. The user can temporarily disable the use by CSPF of all interface membership information of a specific router ID by executing the shutdown command in the config>router>mpls>srlg-database>router-id context. In this case, CSPF will assume these interfaces have no SRLG membership association. The operator can delete all interface entries of a specific router ID entry in this database by executing the no router-id router-address command in the config>router>mpls>srlg-database context.
CSPF will not use entered SRLG membership if an interface is not listed as part of a router ID in the TE database. If an interface was not entered into the user SRLG database, it will be assumed that it does not have any SRLG membership. CSPF will not query the TE database for IGP advertised interface SRLG information.
The operator enables the use by CSPF of the user SRLG database by entering the user-srlg-db enable command in the config>router>mpls context. When the MPLS module makes a request to CSPF for the computation of an SRLG secondary path, CSPF will query the local SRLG and computes a path after pruning links which are members of the SRLG IDs of the associated primary path. Similarly, when MPLS makes a request to CSPF for a FRR bypass or detour path to associate with the primary path, CSPF queries the user SRLG database and computes a path after pruning links which are members of the SRLG IDs of the PLR outgoing interface.
The operator can disable the use of the user SRLG database by entering the user-srlg-db disable in command in the config>router>mpls context. CSPF will then resumes queries into the TE database for SRLG membership information. However, the user SRLG database is maintained
The operator can delete the entire SRLG database by entering the no srlg-database command in the config>router>mpls context. In this case, CSPF will assume all interfaces have no SRLG membership association if the user has not disabled the use of this database.
TE graceful shutdown
Graceful shutdown provides a method to bulk re-route transit LSPs away from the node during software upgrade of a node. A solution is described in RFC 5817, Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks. This is achieved in this draft by using a PathErr message with a specific error code Local Maintenance on TE link required flag. When a LER gets this message, it performs a make-before-break on the LSP path to move the LSP away from the links/nodes which IP addresses were indicated in the PathErr message.
Graceful shutdown can flag the affected link/node resources in the TE database so other routers will signal LSPs using the affected resources only as a last resort. This is achieved by flooding an IGP TE LSA/LSP containing link TLV for the links under graceful shutdown with the traffic engineering metric set to 0xffffffff and 0 as unreserved bandwidth.
Inter-area TE LSP (ERO expansion method)
This feature is only supported on the 7210 SAS-Mxp. Only P2P LSPs are supported; P2MP LSPs are not supported.
The inter-area contiguous LSP functionality provides an end-to-end TE path. Each transit node in an area can set up a TE path LSP that is based on TE information available within its local area.
A PE node that initiates an inter-area contiguous TE LSP does a partial CSPF calculation to include its local area border router (ABR) as a loose node.
An ABR that receives a Path message with loose hop ERO does a partial CSPF calculation to the next domain border router as a loose hop or CSPF to reach the final destination.
Automatic ABR node selection for inter-area LSP
The ingress LER automatically selects the ABR when setting up an inter-area RSVP P2P LSP. The user does not need to include the ABR as a loose hop in the LSP path definition.
CSPF adds the capability to compute all segments of a multi-segment intra-area or inter-area LSP path in one operation.
The following figure shows the role of each node in the signaling of an inter-area LSP with automatic ABR node selection.
CSPF for an inter-area LSP operates as follows:
CSPF in the ingress LER node determines that an LSP is an inter-area LSP by doing a route lookup using the destination address of a P2P LSP (that is, the address in the to field of the LSP configuration). If there is no intra-area route to the destination address, the LSP is considered an inter-area LSP.
When the path of the LSP is empty, CSPF computes a single-segment intra-area path to an ABR node that advertised a prefix matching with the destination address of the LSP.
When the path of the LSP contains one or more hops, CSPF computes a multi-segment intra-area path that includes the hops that are in the area of the ingress LER node.
When all hops are in the area of the ingress LER node, the calculated path ends on an ABR node that advertised a prefix matching the destination address of the LSP.
When there are one or more hops that are not in the area of the ingress LER node, the calculated path ends on an ABR node that advertised a prefix matching with the first hop address that is not in the area of the ingress LER node.
In the case of a multi-segment inter-area LSP, if CSPF finds a hop that can be reached through an intra-area path but that resides on an ABR, CSPF calculates a path only up to that ABR. This is because there is a better chance to reach the destination of the LSP by first signaling the LSP up to that ABR and continuing the path calculation from there by having the ABR expand the remaining hops in the ERO.
The following figure shows this behavior. The TE link between ABR nodes D and E is in area 0. When node C computes the path for the LSP from C to B, in which the path specifies nodes D and E as loose hops, it fails the path computation if CSPF attempts a path all the way to the last hop in the local area, node E. Instead, CSPF stops the path at node D, which further expands the ERO by including link D to E as part of the path in area 0.
Figure 24. CSPF for an inter-area LSP 
If there is more than one ABR that advertises a prefix, CSPF calculates a path for all ABRs. Only the shortest path is withheld. If more than one path has the shortest path, CSPF chooses a path randomly.
The path for an intra-area LSP cannot exit and re-enter the local area of the ingress LER.
Rerouting of inter-area LSP
The automatic selection of the ABR allows the ingress LER to reroute an inter-area LSP primary path through a different ABR in the following situations:
When the local exit ABR node fails, there are two possibilities to consider:
The primary path is not protected at the ABR and is therefore torn down by the previous hop in the path. In this case, the ingress LER retries the LSP primary path through the ABR that has the best path for the destination prefix of the LSP.
The primary path is protected at the ABR with a manual or dynamic bypass LSP. In this case, the ingress LER receives a Path Error message with a notification of a protection becoming active downstream and a RESV message with a Local-Protection-In-Use flag set. At the receipt of the first of these two messages, the ingress LER performs a global revertive make-before-break (MBB) to re-optimize the LSP primary path through the ABR that has the best path for the destination prefix of the LSP.
When the local exit ABR node goes into IS-IS overload or is put into node TE graceful shutdown, the ingress LER performs an MBB to re-optimize the LSP primary path through the ABR that has the best path for the destination prefix of the LSP. The MBB is performed at the receipt of the PathErr message for the node TE shutdown or manual re-optimization of the LSP path in the case of the receipt of the IS-IS overload bit.
Behavior of MPLS options in inter-area LSP
Automatic ABR selection provides the following functionality:
Path bandwidth reservation and admin-groups operate within the scope of all areas because they rely on propagating the parameter information in the Path message across the area boundary.
The TE graceful shutdown and soft preemption functionality support MBB of the LSP path to avoid the link or node that originated the PathErr message, provided the link or node is in the local area of the ingress LER. If the PathErr originated in a remote area, the ingress LER cannot avoid the link or node when it performs the MBB because it computes the path to the local ABR exit router only. There is, however, an exception to this for the TE graceful shutdown case only: the upstream ABR nodes in the current path of the LSP record the link or node to avoid and use it in subsequent ERO expansions. This means that if the ingress LER computes a new MBB path that goes through the same exit ABR router as the current path, and all ABR upstream nodes of the node or link that originated the PathErr message are also selected in the new MBB path when the ERO is expanded, the new path avoids this link or node.
MBB avoids the ABR node when the node is put into TE graceful shutdown.
The use-te-metric option in CSPF cannot be propagated across the area boundary and operates within the scope of the local area of the ingress LER node.
The srlg option on bypass LSP operates locally at each PLR within each area. The PLR node protecting the ABR checks the SRLG constraint for the path of the bypass within the local area.
The srlg option on the secondary path is allowed to operate within the scope of the local area of the ingress LER node.
The PLR node must indicate to CSPF that a request to a one-to-one detour LSP path must remain within the local area. If the destination for the detour, which is the same as that of the LSP, is outside the area, CSPF must not return a path.
The propagate-admin-group option under the LSP must be enabled on the inter-area LSP if the user wants to have admin-groups propagated across the areas.
Using automatic ABR selection, timer-based resignal of the inter-area LSP path is supported and resignals the path if the cost of the path segment to the local exit ABR changes. The cost shown for the inter-area LSP at ingress LER is the cost of the path segments to the ABR node.
Inter-area LSP support of OSPF virtual links
The OSPF virtual link extends area 0 for a router that is not connected to area 0. As a result, it makes all prefixes in area 0 reachable through an intra-area path; they are not, however, reachable because the path crosses the transit area through which the virtual link is set up to reach the area 0 remote nodes.
The TE database in a router learns all the remote TE links in area 0 from the ABR connected to the transit area, but an intra-area LSP path using these TE links cannot be signaled within area 0 because none of these links are directly connected to this node.
This inter-area LSP feature can identify when the destination of an LSP is reachable using a virtual link. In this case, CSPF automatically computes and signals an inter-area LSP through the ABR nodes that are connected to the transit area.
However, when the ingress LER for the LSP is the ABR connected to the transit area, and the destination of the LSP is the address corresponding to another ABR router ID in that same transit area, CSPF computes and signals an intra-area LSP using the transit area TE links, even when the destination router ID is only part of area 0.
Area border node FRR protection for inter-area LSP
For protection of the area border router, the upstream node of the area border router acts as a point-of-local-repair (PLR), and the next-hop node to the protected domain border routers is the merge-point (MP). Both manual and dynamic bypass are available to protect the area border node.
Manual bypass protection works only when a completely strict path is provisioned that avoids the area border node.
Dynamic bypass protection provides the automatic computation, signaling, and association with the primary path of an inter-area P2P LSP to provide ABR node protection. The following figure shows the role of each node in ABR node protection using a dynamic bypass LSP.
For a PLR node within the local area of the ingress LER to provide ABR node protection, the node must dynamically signal a bypass LSP and associate it with the primary path of the inter-area LSP using the following:
The PLR must inspect the record route object (RRO) node ID of the LSP primary path to determine the address of the node immediately downstream of the ABR in the other area.
The PLR signals an inter-area bypass LSP with a destination address set to the address downstream of the ABR and with the exclude router object (XRO) set to exclude the node ID of the protected ABR.
The request to CSPF is for a path to the merge-point (that is, the next-next-hop in the RRO received in the RESV for the primary path) along with the constraint to exclude the protected ABR. If CSPF returns a path that can only go to an intermediate hop, the PLR node signals the dynamic bypass and automatically includes the XRO with the address of the protected ABR. Otherwise, the PLR signals the dynamic bypass directly to the merge-point node with no XRO object in the Path message.
If a node-protect dynamic bypass cannot be found or signaled, the PLR node attempts a link-protect dynamic bypass LSP. As in existing implementation of dynamic bypass within the same area, the PLR attempts in the background to signal a node-protect bypass at the receipt of every third RESV refresh message for the primary path.
Refresh reduction over dynamic bypass works only if the RRO node ID also contains the interface address. Otherwise, the neighbor is not created when the bypass is activated by the PLR. The Path state times out after three refreshes following the activation of the bypass backup LSP.
A one-to-one detour backup LSP cannot be used at the PLR for the protection of the ABR. As a result, a PLR node does not signal a one-to-one detour LSP for ABR protection. In addition, an ABR rejects a Path message that is received from a third party implementation with a detour object and with the ERO having the next-hop loose. This is performed regardless of whether the cspf-on-loose-hop command is enabled on the node. That is, the router as a transit ABR for the detour path rejects the signaling of an inter-area detour backup LSP.
Point-to-Multipoint (P2MP) LSP
This feature is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-Sx 1/10GE and 7210 SAS-Sx 10/100GE, and platforms operating in access-uplink mode.
P2MP LSPs signaled using RSVP or mLDP is only supported on 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12.
Inter-area RSVP-TE P2MP LSPs are not supported.
The following is a generic description of the P2MP LSPs functionality.
Point-to-multipoint (P2MP) LSP allows the source of multicast traffic to forward packets to one or many multicast receivers over a network without requiring a multicast protocol, such as PIM, to be configured in the network core routers. A P2MP LSP tree is established in the control plane which path consists of a head-end node, one or many branch nodes, and the leaf nodes. Packets injected by the head-end node are replicated in the data plane at the branching nodes before they are delivered to the leaf nodes.
Application in video broadcast
The following figure shows the use of the SR product family in triple play application (TPSDA). 7210 SAS devices could be attached to the BSA device as part of the access network.
A PIM-free core network can be achieved by deploying P2MP LSPs using other core routers. The router can act as the ingress LER receiving the multicast packets from the multicast source and forwarding them over the P2MP LSP.A router can act as a leaf for the P2MP LSP tree initiated from the head-end router co-located with the video source. The router can also act as a branch node serving other leaf nodes and supports the replication of multicast packets over P2MP LSPs.
P2MP LSP data plane
A P2MP LSP is a unidirectional label switched path (LSP) which inserts packets at the root (ingress LER) and forwards the exact same replication of the packet to one or more leaf nodes (egress LER). The packet can be replicated at the root of P2MP LSP tree and, or at a transit LSR which acts as a branch node for the P2MP LSP tree.
The data link layer code-point, for example Ethertype when Ethernet is the network port, continues to use the unicast codepoint defined in RFC 3032, MPLS Label Stack Encoding, and which is used on P2P LSP. This change is specified in draft-ietf-mpls-multicast-encaps, MPLS Multicast Encapsulations.
Procedures at ingress LER node
The following procedures occur at the root of the P2MP LSP (head-end or ingress LER node):
First, the P2MP LSP state is established via the control plane. Each leaf of the P2MP LSP will have a next-hop label forwarding entry (NHLFE) configured in the forwarding plane for each outgoing interface.
The user maps a specific multicast destination group address to the P2MP LSP in the base router instance by configuring a static multicast group under a tunnel interface representing the P2MP LSP.
An FTN entry is programmed at the ingress of the head-end node that maps the FEC of a received user IP multicast packet to a list of outgoing interfaces (OIF) and corresponding NHLFEs.
The head-end node replicates the received IP multicast packet to each NHLFE. Replication is performed at ingress toward the fabric or at egress forwarding engine depending on the location of the OIF.
At ingress, the head-end node performs a PUSH operation on each of the replicated packets.
Procedures at LSR node
The following procedures occur at an LSR node that is not a branch node:
The LSR performs a label swapping operation on a leaf of the P2MP LSP. This is a conventional operation of an LSR in a P2P LSP. An ILM entry is programmed at the ingress of the LSR to map an incoming label to a NHLFE. The following is an exception handling procedure for control packets received on an ILM in an LSR.
Packets that arrive with the TTL in the outer label expiring are sent to the CPM for further processing and are not forwarded to the egress NHLFE.
Procedures at branch LSR node
The following procedures occur at an LSR node that is a branch node:
-
The LSR performs a replication and a label swapping for each leaf of the P2MP LSP. An ILM entry is programmed at the ingress of the LSR to map an incoming label to a list of OIF and corresponding NHLFEs.
-
There is a system defined limit on the number of OIF/NHLFEs per ILM entry.
For control packets received on an ILM in a branch LSR, packets that arrive with the TTL in the outer label expiring are sent to the CPM for further processing and not copied to the LSP branches.
Procedures at egress LER node
At the leaf node of the P2MP LSP (egress LER), the egress LER performs a pop operation. An ILM entry is programmed at the ingress of the egress LER to map an incoming label to a list of next-hop/OIF.
For control packets received on an ILM in an egress LER, the packet is sent to the CPM for further processing if there is any of the IP header exception handling conditions set after the label is popped: 127/8 destination address, router alert option set, or any other options set.
Procedures at BUD LSR node
At an LSR node which is both a branch node and an egress leaf node (bud node), the bud LSR performs a pop operation on one or many replications of the received packet and a swap operation of the remaining replications. An ILM entry is programmed at ingress of the LSR to map the incoming label to list of NHLFE/OIF and next-hop/OIF. The exact same packets are replicated to an LSP leaf and to a local interface.
The following are the exception handling procedures for control packets received on an ILM in a bud LSR:
Packets which arrive with the TTL in the outer label expiring are sent to the CPM and are not copied to the LSP branches.
Packets whose TTL does not expire are copied to all branches of the LSP. The local copy of the packet is sent to the CPM for further processing if there is any of the IP header exception handling conditions set after the label is popped: 127/8 destination address, router alert option set, or any other options set.
RSVP control plane in a P2MP LSP
P2MP RSVP LSP is specified in RFC 4875, Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).
A P2MP LSP is modeled as a set of root-to-leaf (S2L) sub-LSPs. The root, for example the head-end node, triggers signaling using one or multiple path messages. A path message can contain the signaling information for one or more S2L sub-LSPs. The leaf sub-LSP paths are merged at branching points.
A P2MP LSP is identified by the combination of <P2MP ID, tunnel ID, extended tunnel ID> part of the P2MP session object, and <tunnel sender address, LSP ID> fields in the P2MP sender_template object.
A specific sub-LSP is identified by the <S2L sub-LSP destination address> part of the S2L_SUB_LSP object and an ERO and secondary ERO (SERO) objects.
The following are characteristics of this feature:
Supports the deaggregated method for signaling the P2MP RSVP LSP. Each root to leaf is modeled as a P2P LSP in the RSVP control plane. Only data plane merges the paths of the packets.
Each S2L sub-LSP is signaled in a separate path message. Each leaf node responds with its own resv message. A branch LSR node will forward the path message of each S2L sub-LSP to the downstream LSR without replicating it. It will also forward the resv message of each S2L sub-LSP to the upstream LSR without merging it with the resv messages of other S2L sub-LSPs of the same P2MP LSP. The same is done for subsequent refreshes of the path and resv states.
The node will drop aggregated RSVP messages on the receive side if originated by another vendor’s implementation.
The user configures a P2MP LSP by specifying the optional create-time parameter p2mp-lsp following the LSP name. Next, the user creates a primary P2MP instance using the keyword primary-p2mp-instance. Then a path name of each S2L sub-LSP must added to the P2MP instance using the keyword s2l-path. The paths can be empty paths or can specify a list of explicit hops. The path name must exist and must have been defined in the config>router>mpls>path context.
The same path name can be re-used by more than one S2L of the primary P2MP instance. However the to keyword must have a unique argument per S2L as it corresponds to the address of the egress LER node.
The user can configure a secondary instance of the P2MP LSP to backup the primary one. In this case, the user enters the name of the secondary P2MP LSP instance under the same LSP name. One or more secondary instances can be created. The trigger for the head-end node to switch the path of the LSP from the primary P2MP instance to the secondary P2MP instance is to be determined. This could be based on the number of leaf LSPs which went down at a specified time.
The following parameters can be used with a P2MP LSP: adaptive, cspf, exclude, fast-reroute, from, hop-limit, include, metric, retry-limit, retry-timer, resignal-timer.
The following parameters cannot be used with a P2MP LSP: adspec, primary, secondary, to.
The to parameter is not available at the LSP level but at the path level of each S2L sub-LSP of the primary or secondary instance of this P2MP LSP.
The node ingress LER will not inset an adspec object in the path message of an S2L sub-LSP. If received in the resv message, it will be dropped. The operational MTU of an S2L path is derived from the MTU of the outgoing interface of that S2L path.
The hold-timer configured in the config>router>mpls>hold-timer context applies when signaling or re-signaling an individual S2L sub-LSP path. It does not apply when the entire tree is signaled or re-signaled.
The head-end node can add or remove a S2L sub-LSP of a specific leaf node without impacting forwarding over the already established S2L sub-LSPs of this P2MP LSP and without re-signaling them.
The head-end node performs a make-before break (MBB) on an individual S2L path of a primary P2MP instance whenever it applies the FRR global revertive procedures to this path. If CSPF finds a new path, RSVP signals this S2L path with the same LSP-ID as the existing path.
All other configuration changes, such as adaptive/no-adaptive (when an MBB is in progress), use-te-metric, no-frr, cspf/no-cspf, result in the tear-down and re-try of all affected S2L paths.
MPLS requests CSPF to re-compute the whole set of S2L paths of a specified active P2MP instance each time the P2MP re-signal timer expires. The P2MP re-signal timer is configured separately from the P2P LSP. MPLS performs a global MBB and moves each S2L sub-LSP in the instance into its new path using a new P2MP LSP ID if the global MBB is successful. This is regardless of the cost of the new S2L path.
MPLS will request CSPF to re-compute the whole set of S2L paths of a specified active P2MP instance each time the user performs a manual re-signal of the P2MP instance. MPLS then always performs a global MBB and moves each S2L sub-LSP in the instance into its new path using a new P2MP LSP ID if the global MBB is successful. This is regardless of the cost of the new S2L path. The user executes a manual re-signal of the P2MP LSP instance using the command: tools>perform>router>mpls>resignal p2mp-lsp lsp-name p2mp-instance instance-name.
When performing global MBB, MPLS runs a separate MBB on each S2L in the P2MP LSP instance. If an S2L MBB does not succeed the first time, MPLS will re-try the S2L using the re-try timer and re-try count values inherited from P2MP LSP configuration. However, there will be a global MBB timer set to 600 seconds and which is not configurable. If the global MBB succeeds, for example, all S2L MBBs have succeeded, before the global timer expires, MPLS moves the all S2L sub-LSPs into their new path. Otherwise when this timer expires, MPLS checks if all S2L paths have at least tried once. If so, it then aborts the global MBB. If not, it will continue until all S2Ls have re-tried once and then aborts the global MBB. Once global MBB is aborted, MPLS will move all S2L sub-LSPs into the new paths only if the set of S2Ls with a new path found is a superset of the S2Ls which have a current path which is up.
While make-before break is being performed on individual S2L sub-LSP paths, the P2MP LSP will continue forwarding packets on S2L sub-LSP paths which are not being re-optimized and on the older S2L sub-LSP paths for which make-before-break operation was not successful. MBB will therefore result in duplication of packets until the old path is torn down.
The MPLS datapath of an LSR node, branch LSR node, and bud LSR node will be able to re-merge S2L sub-LSP paths of the same P2MP LSP in case their ILM is on different incoming interfaces and their NHLFE is on the same or different outgoing interfaces. This could occur anytime there are equal cost paths through this node for the S2L sub-LSPs of this P2MP LSP.
Link-protect FRR bypass using P2P LSPs is supported. In link protect, the PLR protecting an interface to a branch LSR will only make use of a single P2P bypass LSP to protect all S2L sub-LSPs traversing the protected interface.
Refresh reduction on RSVP interface and on P2P bypass LSP protecting one or more S2L sub-LSPs.
A manual bypass LSP cannot be used for protecting S2L paths of a P2MP LSP.
The following MPLS features do operate with P2MP LSP:
BFD on RSVP interface
MD5 on RSVP interface
IGP metric and TE metric for computing the path of the P2MP LSP with CSPF
SRLG constraint for computing the path of the P2MP LSP with CSPF. SRLG is supported on FRR backup path only.
TE graceful shutdown
Admin group constraint
The following MPLS features are not operable with P2MP LSP:
Class based forwarding over P2MP RSVP LSP
LDP-over-RSVP where the RSVP LSP is a P2MP LSP
Diff-Serv TE
Soft preemption of RSVP P2MP LSP
Forwarding multicast packets over RSVP P2MP LSP in the base router
Multicast packets are forwarded over the P2MP LSP at the ingress LER based on a static join configuration of the multicast group against the tunnel interface associated with the originating P2MP LSP. At the egress LER, packets of a multicast group are received from the P2MP LSP via a static assignment of the specific <S,G> to the tunnel interface associated with a terminating LSP.
Procedures at ingress LER node
To forward multicast packets over a P2MP LSP, perform the following steps:
Create a tunnel interface associated with the P2MP LSP: config>router>tunnel-interface rsvp-p2mp lsp-name. (The config>router>pim>tunnel-interface command has been discontinued.)
Add static multicast group joins to the PIM interface, either as a specific <S,G> or as a <*,G>: config>router>igmp>tunnel-if>static>group>source ip-address and config>router>igmp>tunnel-if>static>group>starg.
The tunnel interface identifier consists of a string of characters representing the LSP name for the RSVP P2MP LSP. MPLS will pass a more structured tunnel interface identifier to PIM. The structure will follow the one BGP uses to distribute the PMSI tunnel information in BGP multicast VPN as specified in draft-ietf-l3vpn-2547bis-mcast-bgp, Multicast in MPLS/BGP IP VPNs.The format is: <extended tunnel ID, reserved, tunnel ID, P2MP ID> as encoded in the RSVP-TE P2MP LSP session_attribute object in RFC 4875.
The user can create one or more tunnel interfaces in PIM and associate each to a different RSVP P2MP LSP. The user can then assign static multicast group joins to each tunnel interface. A specific <*,G> or <S,G> can only be associated with a single tunnel interface.
A multicast packet which is received on an interface and which succeeds the RPF check for the source address will be replicated and forwarded to all OIFs which correspond to the branches of the P2MP LSP. The packet is sent on each OIF with the label stack indicated in the NHLFE of this OIF. The packets will also be replicated and forwarded natively on all OIFs which have received IGMP or PIM joins for this <S,G>.
The multicast packet can be received over a PIM or IGMP interface which can be an IES interface, a spoke SDP-terminated IES interface, or a network interface.
To duplicate a packet for a multicast group over the OIF of both P2MP LSP branches and the regular PIM or IGMP interfaces, the tap mask for the P2MP LSP and that of the PIM based interfaces will need to be combined into a superset MCID.
Procedures with a primary tunnel at egress LER node
The user configures a tunnel interface and associates it with a terminating P2MP LSP leaf using the command: config>router>tunnel-interface rsvp-p2mp lsp-name sender sender-address. (The config>router>pim>tunnel-interface command has been discontinued).
The tunnel interface identifier consists of strings of characters representing the LSP name for the RSVP P2MP LSP followed by the system address of the ingress LER. The LSP name must correspond to a P2MP LSP name configured by the user at the ingress LER and must not contain the special character ‟:” MPLS will pass a more structured tunnel interface identifier to PIM. The structure will follow the one BGP uses to distribute the PMSI tunnel information in BGP multicast VPN as specified in draft-ietf-l3vpn-2547bis-mcast-bgp. The format is: <extended tunnel ID, reserved, tunnel ID, P2MP ID> as encoded in the RSVP-TE P2MP LSP session_attribute object in RFC 4875.
The egress LER accepts multicast packets using the following methods:
The regular RPF check on unlabeled IP multicast packets, which is based on routing table lookup.
The static assignment which specifies the receiving of a multicast group <*,G> or a specific <S,G> from a primary tunnel-interface associated with an RSVP P2MP LSP.
One or more primary tunnel interfaces in the base router instance can be configured. In other words, the user will be able to receive different multicast groups, <*,G> or specific <S,G>, from different P2MP LSPs. This assumes that the user configured static joins for the same multicast groups at the ingress LER to forward over a tunnel interface associated with the same P2MP LSP.
A multicast info policy CLI option allows the user to define a bundle and specify channels in the bundle that must be received from the primary tunnel interface. The user can apply the defined multicast info policy to the base router instance.
At any specified time, packets of the same multicast group can be accepted from either the primary tunnel interface associated with a P2MP LSP or from a PIM interface. These are mutually exclusive options. As soon as a multicast group is configured against a primary tunnel interface in the multicast info policy, it is blocked from other PIM interfaces.
However, if the user configured a multicast group to be received from a specified primary tunnel interface, there is nothing preventing packets of the same multicast group from being received and accepted from another primary tunnel interface. However, an ingress LER will not allow the same multicast group to be forwarded over two different P2MP LSPs. The only possible case is that of two ingress LERs forwarding the same multicast group over two P2MP LSPs toward the same egress LER.
A multicast packet received on a tunnel interface associated with a P2MP LSP can be forwarded over a PIM or IGMP interface which can be an IES interface, a spoke SDP-terminated IES interface, or a network interface.
Packets received from a primary tunnel-interface associated with a terminating P2MP LSP cannot be forwarded over a tunnel interface associated with an originating P2MP LSP.
Configuration guidelines for RSVP P2MP LSPs
Before using P2MP LSPs with NG-MVPN, resources must be allocated from the sf-ingress-internal-tcam resource pool using the configure>system>global-res-profile>sf-ingress-internal-tcam>mpls-p2mp command. In addition, if the 7210 SAS-R6 is deployed as a bud router, the configure>system> loopback-no-svc-port p2mpbud p2mpbud-port-id command must be used to configure one of the front-panel ports as a loopback port.
Ingress FC classification is available for packets received on a P2MP LSP on a network port IP interface that needs to be replicated to IP receivers. Ingress FC classification allows users to prioritize multicast traffic to IP receivers in the service. Also available is the capability to mark the packet with IP DSCP values while sending the multicast stream out of the IP interface. To enable ingress FC classification, use the loopback-no-svc-port [p2mpbud p2mpbud-port-id [classification]] command. Before using the command, users must ensure that sufficient resources are available in the network port ingress CAM resource pool and MPLS EXP ingress profile map resource pool. The tools>dump>system-resources command can be used to check resource availability.
MPLS/RSVP configuration process overview
The following figure shows the process to configure MPLS and RSVP parameters.
Configuration notes
This section describes MPLS and RSVP restrictions.
Interfaces must already be configured in the config>router>interface context before they can be specified in MPLS and RSVP.
A router interface must be specified in the config>router>mpls context to apply it or modify parameters in the config>router>rsvp context.
A system interface must be configured and specified in the config>router>mpls context.
Paths must be created before they can be applied to an LSP.
Configuring MPLS and RSVP with CLI
This section provides information to configure MPLS and RSVP using the command line interface.
MPLS configuration overview
Multiprotocol Label Switching (MPLS) enables routers to forward traffic based on a simple label embedded into the packet header. A router examines the label to determine the next hop for the packet, saving time for router address lookups to the next node when forwarding packets. MPLS is not enabled by default and must be explicitly enabled.
LSPs
To configure MPLS-signaled label switched paths (LSPs), an LSP must run from an ingress router to an egress router. Configure only the ingress router and configure LSPs to allow the software to make the forwarding decisions or statically configure some or all routers in the path. The LSP is set up by Resource Reservation Protocol (RSVP), through RSVP signaling messages. The 7210 SAS automatically manages label values. Labels that are automatically assigned have values ranging from 1,024 through 1,048,575 (see Label values).
A static LSP is a manually set up LSP where the next-hop IP address and the outgoing label are explicitly specified.
Paths
To configure signaled LSPs, you must first create one or more named paths on the ingress router. For each path, the transit routers (hops) in the path are specified.
Router interface
At least one router interface and one system interface must be defined in the config>router>interface context to configure MPLS on an interface.
Choosing the signaling protocol
If only static label switched paths are used in your configurations, then you must manually define the paths through the MPLS network. Label mappings and actions configured at each hop must be specified. You do not need to enable RSVP if you are configuring static LSPs.
If dynamic LSP signaling is implemented in your network, then RSVP must be specified. Enable signaling protocols only on the links where the functionality is required.
To implement MPLS, the following entities must be enabled:
MPLS must be enabled on all routers that are part of an LSP.
RSVP must be enabled on the same routers.
When MPLS is enabled and either RSVP is also enabled, MPLS uses RSVP to set up the configured LSPs. For example, when you configure an LSP with both MPLS and RSVP running, RSVP initiates a session for the LSP. RSVP uses the local router as the RSVP session sender and the LSP destination as the RSVP session receiver. When the RSVP session is created, the LSP is set up on the path created by the session. If the session is not successfully created, RSVP notifies MPLS, MPLS can then either initiate backup paths or retry the initial path.
Basic MPLS configuration
This section provides information to configure MPLS and provides configuration examples of common configuration tasks. To enable MPLS on the 7210 SAS, you must configure at least one MPLS interface. The other MPLS configuration parameters are optional. The following is an example of an MPLS configuration.
The admin-group is configured in the config>router>if-attribute context and associated with the MPLS interface in the config>router>mpls>interface context.
ALA-1>config>router>if-attr# info
----------------------------------------------
admin-group "green" value 15
admin-group "yellow" value 20
admin-group "red" value 25
----------------------------------------------
A:ALA-1>config>router>mpls# info
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
if-attribute
admin-group "green" 15
admin-group "yellow" 20
admin-group "red" 25
interface "system"
exit
interface "StaticLabelPop"
admin-group "green"
label-map 50
pop
no shutdown
exit
exit
interface "StaticLabelPop"
label-map 35
swap 36 nexthop 10.10.10.91
no shutdown
exit
exit
path "secondary-path"
no shutdown
exit
path "to-NYC"
hop 1 10.10.10.104 strict
no shutdown
exit
lsp "lsp-to-eastcoast"
to 10.10.10.104
from 10.10.10.103
fast-reroute one-to-one
exit
primary "to-NYC"
exit
secondary "secondary-path"
exit
no shutdown
exit
static-lsp "StaticLabelPush"
to 10.10.11.105
push 60 nexthop 10.10.11.105
no shutdown
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>mpls#
Common configuration tasks
This section provides a brief overview of the tasks to configure MPLS and provides the CLI commands.
The following protocols must be enabled on each participating router:
MPLS
RSVP (for RSVP-signaled MPLS only)
LDP
In order for MPLS to run, you must configure at least one MPLS interface in the config>router>mpls context.
An interface must be created in the config>router>interface context before it can be applied to MPLS.
In the config>router>mpls context, configure path parameters for configuring LSP parameters. A path specifies some or all hops from ingress to egress. A path can be used by multiple LSPs.
When an LSP is created, the egress router must be specified in the to command and at least one primary or secondary path must be specified. All other statements under the LSP hierarchy are optional.
Configuring global MPLS parameters
Admin groups signify link colors, such as red, yellow, or green. MPLS interfaces advertise the link colors that they support. CSPF uses the information when paths are computed for constraint-based LSPs. CSPF must be enabled in order for admin groups to be relevant.
Use the following syntax to configure MPLS admin-group parameters.
Config>router>if-attribute
admin-group group-name value group-value
mpls
frr-object
resignal-timer minutes
Admin group configuration output
ALA-1>config>router>if-attr# info
----------------------------------------------
admin-group "green" value 15
admin-group "yellow" value 20
admin-group "red" value 25
----------------------------------------------
A:ALA-1>config>router>mpls# info
----------------------------------------------
resignal-timer 500
...
----------------------------------------------
A:ALA-1>config>router>mpls#
Configuring an MPLS interface
Configure the label-map parameters if the interface is used in a static LSP. Use the following syntax to configure an MPLS interface on a router.
config>router>mpls
interface
no shutdown
admin-group group-name [group-name...(up to 32 max)]
label-map
pop
swap
no shutdown
srlg-group group-name [group-name...(up to 5 max)]
te-metric value
Interface configuration output
A:ALA-1>config>router>mpls# info
----------------------------------------------
...
interface "to-104"
admin-group "green"
admin-group "red"
admin-group "yellow"
label-map 35
swap 36 nexthop 10.10.10.91
no shutdown
exit
exit
no shutdown
...
----------------------------------------------
A:ALA-1>config>router>mpls#
Configuring MPLS paths
Configure an LSP path to use in MPLS. When configuring an LSP, the IP address of the hops that the LSP should traverse on its way to the egress router must be specified. The intermediate hops must be configured as either strict or loose meaning that the LSP must take either a direct path from the previous hop router to this router (strict) or can traverse through other routers (loose).
Use the following syntax to configure a path.
config>router> mpls
path path-name
hop hop-index ip-address {strict|loose}
no shutdown
Path configuration output
A:ALA-1>config>router>mpls# info
------------------------------------------
interface "system"
exit
path "secondary-path"
hop 1 10.10.0.121 strict
hop 2 10.10.0.145 strict
hop 3 10.10.0.1 strict
no shutdown
exit
path "to-NYC"
hop 1 10.10.10.103 strict
hop 2 10.10.0.210 strict
hop 3 10.10.0.215 loose
exit
------------------------------------------
A:ALA-1>config>router>mpls#
Configuring an MPLS LSP
Configure an LSP path for MPLS. When configuring an LSP, you must specify the IP address of the egress router in the to statement. Specify the primary path to be used. Secondary paths can be explicitly configured or signaled upon the failure of the primary path. All other statements are optional.
MPLS LSP configuration output
A:ALA-1>config>router>mplp# info
----------------------------------------------
...
lsp "lsp-to-eastcoast"
to 192.168.200.41
rsvp-resv-style ff
cspf
include "red"
exclude "green"
adspec
fast-reroute one-to-one
exit
primary "to-NYC"
hop-limit 10
exit
secondary "secondary-path"
bandwidth 50000
exit
no shutdown
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>mpls#
Configuring a static LSP
An LSP can be explicitly (statically) configured. Static LSPs are configured on every node along the path. The label’s forwarding information includes the address of the next hop router.
Use the following syntax to configure a static LSP.
config>router>mpls
static-lsp lsp-name
to ip-address
push out-label nexthop ip-addr
no shutdown
Static LSP configuration output
A:ALA-1>config>router>mpls# info
----------------------------------------------
...
static-lsp "static-LSP"
to 10.10.10.124
push 60 nexthop 10.10.42.3
no shutdown
exit
...
----------------------------------------------
A:ALA-1>config>router>mpls#
Configuring manual bypass tunnels
Consider the network setup in the following figure that shows nodes A through F.
-
The user first configures the option to disable the dynamic
bypass tunnels.
Listed below are the steps to configure the manual bypass tunnels:
- Configure the option to disable the dynamic bypass tunnels on the 7210 SAS node B (if required). The CLI for this configuration is: config>router>mpls>dynamic-bypass [disable | enable] The dynamic bypass tunnels are enabled by default.
- Configure an LSP on node B, such as B-E-F-C which is used only as bypass. The user specifies each hop in the path, for example, the bypass LSP has a strict path.
Including the bypass-only keyword disables the following options under the LSP configuration:
-
bandwidth
-
fast-reroute
-
secondary
The following LSP configuration options are allowed:
-
adaptive
-
adspec
-
cspf
-
exclude
-
hop-limit
-
include
-
metric
Bypass tunnel configuration outputA:7210 SAS>config>router>mpls>path# info ------------------------------------------- ... path "BEFC" hop 10 10.10.10.11 strict hop 20 10.10.10.12 strict hop 30 10.10.10.13 strict no shutdown exit lsp "bypass-BC" to 10.10.10.15 primary "BEFC" exit no shutdown ... ------------------------------------------- A:7210 SAS >config>router>mpls>path# -
Configure an LSP from A to D and indicate fast-reroute bypass
protection, select the facility as ‟FRR
method”
(config>router>mpls>lsp>fast-reroute
facility).
Observe if the following criteria apply:
-
If the LSP passes through B
-
A bypass is requested
-
The next hop is C
-
A manually configured bypass-only tunnel exists from B to C (excluding link B to C)
-
Configuring RSVP parameters
RSVP is used to set up LSPs. RSVP must be enabled on the router interfaces that are participating in signaled LSPs. The keep-multiplier and refresh-time default values can be modified in the RSVP context.
Initially, interfaces are configured in the config>router>mpls>interface context. Only these existing (MPLS) interfaces are available to modify in the config>router> rsvp context. Interfaces cannot be directly added in the RSVP context.
RSVP configuration output
A:ALA-1>config>router>rsvp# info
----------------------------------------------
interface "system"
no shutdown
exit
interface to-104
hello-interval 4000
no shutdown
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>rsvp#
Configuring RSVP message pacing parameters
RSVP message pacing maintains a count of the messages that were dropped because the output queue for the egress interface was full.
Use the following syntax to configure RSVP parameters.
config>router>rsvp
no shutdown
msg-pacing
period milli-seconds
max-burst number
RSVP message pacing configuration output
A:ALA-1>config>router>rsvp# info
----------------------------------------------
keep-multiplier 5
refresh-time 60
msg-pacing
period 400
max-burst 400
exit
interface "system"
no shutdown
exit
interface to-104
hello-interval 4000
no shutdown
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>rsvp#
Configuring graceful shutdown
Enable TE graceful shutdown on the maintenance interface using the config>router>rsvp>interface>graceful-shutdown command.
Disable graceful shutdown by executing the no form of the command at the RSVP interface level or at the RSVP level. This restores the user-configured TE parameters of the maintenance links, and the 7210 SAS maintenance node floods them.
MPLS configuration management tasks
This section describes the MPLS configuration management tasks.
Modifying MPLS parameters
You must shut down MPLS entities to modify parameters. Re-enable (no shutdown) the entity for the change to take effect.
Modifying an MPLS LSP
Some MPLS LSP parameters such as primary and secondary, must be shut down before they can be edited or deleted from the configuration.
MPLS LSP configuration output
A:ALA-1>>config>router>mpls>lsp# info
----------------------------------------------
shutdown
to 10.10.10.104
from 10.10.10.103
rsvp-resv-style ff
include "red"
exclude "green"
fast-reroute one-to-one
exit
primary "to-NYC"
hop-limit 50
exit
secondary "secondary-path"
exit
----------------------------------------------
A:ALA-1>config>router>mpls#
Modifying MPLS path parameters
To modify path parameters, the config>router>mpls>path context must be shut down first.
Path configuration output
A:ALA-1>config>router>mpls# info
#------------------------------------------
echo "MPLS"
#------------------------------------------
...
path "secondary-path"
hop 1 10.10.0.111 strict
hop 2 10.10.0.222 strict
hop 3 10.10.0.123 strict
no shutdown
exit
path "to-NYC"
hop 1 10.10.10.104 strict
hop 2 10.10.0.210 strict
no shutdown
exit
...
----------------------------------------------
A:ALA-1>config>router>mpls#
Modifying MPLS static LSP parameters
To modify static LSP parameters, the config>router>mpls>path context must be shut down first.
Static LSP configuration output
A:ALA-1>config>router>mpls# info
----------------------------------------------
...
static-lsp "static-LSP"
to 10.10.10.234
push 102704 nexthop 10.10.8.114
no shutdown
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>mpls#
Deleting an MPLS interface
To delete an interface from the MPLS configuration, the interface must be shut down first.
Use the following syntax to delete an interface from the MPLS configuration.
mpls
[no] interface ip-int-name
shutdown
A:ALA-1>config>router>mpls# info
----------------------------------------------
...
admin-group "green" 15
admin-group "red" 25
admin-group "yellow" 20
interface "system"
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>mpls#
RSVP configuration management tasks
This section describes the RSVP configuration management tasks.
Modifying RSVP parameters
Only interfaces configured in the MPLS context can be modified in the RSVP context.
The no rsvp command deletes this RSVP protocol instance and removes all configuration parameters for this RSVP instance. The shutdown command suspends the execution and maintains the existing configuration.
The following example displays a modified RSVP configuration example.
A:ALA-1>config>router>rsvp# info
----------------------------------------------
keep-multiplier 5
refresh-time 60
msg-pacing
period 400
max-burst 400
exit
interface "system"
exit
interface "test1"
hello-interval 5000
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>rsvp#
Modifying RSVP message pacing parameters
RSVP message pacing maintains a count of the messages that were dropped because the output queue for the egress interface was full.
The following is a sample modified RSVP message pacing configuration output.
A:ALA-1>config>router>rsvp# info
----------------------------------------------
keep-multiplier 5
refresh-time 60
msg-pacing
period 200
max-burst 200
exit
interface "system"
exit
interface "to-104"
exit
no shutdown
----------------------------------------------
A:ALA-1>config>router>rsvp#
Deleting an interface from RSVP
Interfaces cannot be deleted directly from the RSVP configuration. An interface must have been configured in the MPLS context and then the RSVP context. The interface must first be deleted from the MPLS context. This removes the association from RSVP.
See Deleting an MPLS interface for information about deleting an MPLS interface.
MPLS/RSVP command reference
Command hierarchies
MPLS commands
config
- router
- [no] mpls
- [no] admin-group-frr
- bypass-resignal-timer minutes
- no bypass-resignal-timer
- [no] cspf-on-loose-hop
- dynamic-bypass [enable | disable]
- [no] frr-object
- hold-timer seconds
- no hold-timer
- [no] interface ip-int-name
- [no] admin-group group-name [group-name...(up to 5 max)]
- label-map in-label
- no label-map in-label
- no pop
- pop
- no shutdown
- shutdown
- swap out-label nexthop ip-address
- swap implicit-null-label nexthop ip-address
- no swap
- no shutdown
- shutdown
- [no] srlg-group group-name [group-name...(up to 5 max)]
- te-metric metric
- no te-metric
- [no] p2mp-resignal-timer minutes
- pce-report rsvp-te {enable | disable}
- resignal-timer minutes
- no resignal-timer
- [no] shutdown
- [no] srlg-database
- [no] router-id router-addr
- [no] interface ip-addr srlg-group group-name [group-name..(up to 5 max)]
- [no] shutdown
- [no] srlg-frr [strict]
- [no] static-lsp lsp-name
- no push label
- push label nexthop ip-address
- [no] shutdown
- to ip-address
- [no] static-lsp-fast-retry seconds
- user-srlg-db [enable | disable]
- mpls-labels
- static-label-range static range
- no static-label-range
MPLS-TP commands
MPLS-TP commands are only supported on 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T (network mode).
config
- router
- [no] mpls
- [no] mpls-tp
- global-id global-id
- no global-id
- node-id node-id
- no node-id
- [no] oam-template name
- bfd-template name
- no bfd-template
- hold-time-down timer
- no hold-time-down
- hold-time-up timer
- no hold-time-up
- protection-template name
- no protection-template
- rapid-psc-timer interval
- no rapid-psc-timer
- [no] revertive
- slow-psc-timer interval
- no slow-psc-timer
- wait-to-restore interval
- no wait-to-restore
- [no] shutdown
- tp-tunnel-id-range start-id end-id
- no tp-tunnel-id-range
- transit-path path-name
- no transit-path
- [no] forward-path in-label out-label out-label out-link interface name [next-hop ip-address]
- in-label in-label out-label out-label out-link if-name [next-hop next-hop]
- path-id {lsp-num lsp-num | working-path | protect-path [src-global-id src-global-id] src-node-id src-node-id src-tunnel-num src-tunnel-num [dest-global-id dest-global-id] dest-node-id dest-node-id [dest-tunnel-num dest-tunnel-num]}
- no path-id
- [no] reverse-path in-label out-label out-label out-link interface name [next-hop ip-address]
- in-label in-label out-label out-label out-link if-name [next-hop next-hop]
- [no] shutdown
MPLS LSP commands
config
- router
- [no] mpls
- [no] lsp lsp-name [bypass-only | p2mp-lsp | mpls-tp src-tunnel-num]
- [no] adaptive
- [no] adspec
- bgp-transport-tunnel {include | exclude}
- [no] cspf [use-te-metric]
- [no] exclude group-name [group-name...(up to 5 max)]
- fast-reroute frr-method
- no fast-reroute
- hop-limit number
- no hop-limit
- [no] node-protect
- [no] propagate-admin-group
- from ip-address
- hop-limit number
- no hop-limit
- [no] include group-name [group-name...(up to 5 max)]
- [no] ldp-over-rsvp [include | exclude]
- metric metric
- path-profile profile-id [path-group group-id]
- no path-profile profile-id
- [no] pce-computation
- [no] pce-control
- pce-report {enable | disable | inherit}
- [no] propagate-admin-group
- [no] to id
- [no] primary path-name
- [no] adaptive
- bandwidth rate-in-mpbs
- no bandwidth
- [no] exclude group-name [group-name...(up to 5 max)]
- hop-limit number
- no hop-limit
- [no] include group-name [group-name...(up to 5 max)]
- [no] record
- [no] record-label
- [no] shutdown
- retry-limit number
- no retry-limit
- retry-timer seconds
- no retry-timer
- rsvp-resv-style [se | ff]
- [no] secondary path-name
- [no] adaptive
- bandwidth rate-in-mbps
- no bandwidth
- [no] exclude group-name [group-name...(up to 5 max)]
- hop-limit number
- no hop-limit
- [no] include group-name [group-name...(up to 5 max)]
- [no] path-preference
- [no] record
- [no] record-label
- [no] shutdown
- [no] srlg
- [no] standby
- [no] shutdown
- to ip-address
- vprn-auto-bind [include | exclude]
- lsp-template template-name p2mp
- no lsp-template template-name
- cspf [use-te-metric]
- no cspf
- default-path path-name
- exclude group-name [group-name...(up to 5 max)]
- no exclude [group-name [group-name...(up to 5 max)]]
- include group-name [group-name...(up to 5 max)]
- no include [group-name [group-name...(up to 5 max)]]
- [no] propagate-admin-group
- [no] record
- [no] record-label
- retry-limit number
- no retry-limit
- retry-timer seconds
- no retry-timer
- [no] shutdown
MPLS-TP LSP commands
MPLS-TP LSP commands are only supported on 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T (network mode).
config
- router
- [no] mpls
- [no] lsp lsp-name [bypass-only | mpls-tp src-tunnel-num]
- [no] protect-tp-path
- in-label in-label
- lsp-num lsp-number
- no lsp-num
- [no] mep
- bfd-enable [bfd-mode]
- no bfd-enable
- oam-template [32 chars max]
- no oam-template
- protection-template [256 chars max]
- no protection-template
- [no] shutdown
- out-label out-label out-link if-name [next-hop ip-address]
- no out-label
- [no] shutdown
- [no] working-tp-path
- in-label in-label
- lsp-num lsp-number
- no lsp-num
- [no] mep
- bfd-enable [bfd-mode]
- no bfd-enable
- oam-template name
- no oam-template
- [no] shutdown
- out-label out-label out-link if-name [next-hop ip-address]
- no out-label
- [no] shutdown
MPLS path commands
RSVP commands
config
- router
- [no] rsvp
- [no] graceful-shutdown
- [no] implicit-null-label
- [no] interface ip-int-name
- authentication-key [authentication-key | hash-key] [hash | hash2]
- no authentication-key
- [no] bfd-enable
- [no] graceful-shutdown
- hello-interval milli-seconds
- no hello-interval
- [no] refresh-reduction
- [no] reliable-delivery
- [no] shutdown
- subscription percentage
- no subscription
- keep-multiplier number
- no keep-multiplier
- node-id-in-rro {include | exclude}
- [no] msg-pacing
- max-burst number
- no max-burst
- period milli-seconds
- no period
- rapid-retransmit-time hundred-milliseconds
- no rapid-retransmit-time
- rapid-retry-limit number
- no rapid-retry-limit
- refresh-time seconds
- no refresh-time
- [no] shutdown
Show commands
show
- router
- mpls
- admin-group group-name
- bypass-tunnel [to ip-address] [protected-lsp name] [dynamic | manual | p2mp] [detail]
- interface [ip-int-name | ip-address] [label-map label]
- interface [ip-int-name | ip-address]
- lsp [lsp-name] [status {up | down}] [from ip-address | to ip-address] [detail]
- lsp {transit | terminate} [status {up | down}] [from ip-address | to ip-address | lsp-name name] [detail]
- lsp count
- lsp lsp-name activepath
- lsp [lsp-name] path [path-name] [status {up | down}] [detail]
- mpls-labels
- label start-label [end-label | in-use | label-owner]
- label-range
- mpls-tp
- oam-template [template-name] [associations]
- protection-template [template-name] [associations]
- status
- transit-path [path-name] [detail]
- path [path-name] [lsp-binding]
- srlg-database [router-id ip-address] [interface ip-address]
- srlg-group [group-name]
- static-lsp [lsp-name]
- static-lsp {transit | terminate}
- static-lsp count
- status
show
- router
- rsvp
- interface [interface [ip-int-name]] statistics [detail]
- neighbor [ip-address] [detail]
- session [session-type] [from ip-address| to ip-address| lsp-name name] [status {up | down}] [detail]
- statistics
- status
Tools commands
- perform
- router
- mpls
- cspf to ip-addr [from ip-addr] [bandwidth bandwidth] [include-bitmap bitmap] [exclude-bitmap bitmap] [hop-limit limit] [exclude-address excl-addr [excl-addr...(up to 8 max)]] [use-te-metric] [strict-srlg] [srlggroup
grp-id...(up to 8 max)] [skip-interface interface-name]
- resignal {lsp lsp-name path path-name | delay minutes}
- resignal-bypass {lsp bypass-lsp-name [force] | delay minutes}
- tp-tunnel
- clear id tunnel-id
- clear lsp-name
- force id tunnel-id
- force lsp-name
- lockout id tunnel-id
- lockout lsp-name
- manual id tunnel-id
- manual lsp-name
- trap-suppress number-of-traps time-interval
Clear commands
clear
- router
- mpls
- interface [ip-int-name]
- lsp lsp-name
- rsvp
- interface [ip-int-name] [statistics]
- statistics
Debug commands
debug
- router
- mpls [lsp lsp-name] [sender source-address] [endpoint endpoint-address] [tunnel-id tunnel-id] [lsp-id lsp-id]
- no mpls
- [no] event
- all [detail]
- no all
- frr [detail]
- no frr
- iom [detail]
- no iom
- lsp-setup [detail]
- no lsp-setup
- mbb [detail]
- no mbb
- misc [detail]
- no misc
- xc [detail]
- no xc
- rsvp [lsp lsp-name] [sender source-address] [endpoint endpoint-address] [tunnel-id tunnel-id] [lsp-id lsp-id] [interface ip-int-name]
- no rsvp
- [no] event
- all [detail]
- no all
- auth
- no auth
- misc [detail]
- no misc
- nbr [detail]
- no nbr
- path [detail]
- no path
- resv [detail]
- no resv
- rr
- no rr
- [no] packet
- all [detail]
- no all
- ack
- bundle [detail]
- no bundle
- hello [detail]
- no hello
- path [detail]
- no path
- patherr [detail]
- no patherr
- pathtear [detail]
- no pathtear
- resv [detail]
- no resv
- resverr [detail]
- no resverr
- resvtear [detail]
- no resvtear
- srefresh [detail]
- no srefresh
Command descriptions
MPLS configuration commands
Generic commands
shutdown
Syntax
[no] shutdown
Context
config>router>mpls
config>router>mpls>interface
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.
MPLS is not enabled by default and must be explicitly enabled (no shutdown).
The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.
The no form of this command places the entity into an administratively enabled state.
Default
no shutdown
MPLS commands
mpls
Syntax
[no] mpls
Context
config>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure MPLS parameters. MPLS is not enabled by default and must be explicitly enabled (no shutdown). The shutdown command administratively disables MPLS.
The no form of this command deletes this MPLS protocol instance; this will remove all configuration parameters for this MPLS instance.
MPLS must be shutdown before the MPLS instance can be deleted. If MPLS is not shutdown, when the no mpls command is executed, a warning message is displayed on the console indicating that MPLS is still administratively up.
admin-group-frr
Syntax
[no] admin-group-frr
Context
config>router>mpls
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the use of admin-group constraints when a manual or dynamic bypass LSP is associated with the primary LSP path at a Point-of-Local Repair (PLR) node.
When this command is enabled, each PLR node reads the admin-group constraints in the FAST_REROUTE object included in the Path message of the LSP primary path. If the object is not included, the PLR reads the Session Attribute object in the Path message.
If the PLR is also the ingress LER for the LSP primary path, only the admin-group constraints from the LSP or path level configurations are used.
Next, the PLR node uses the admin-group and other constraints, such as hop-limit and SRLG, to select a manual or dynamic bypass LSP among the bypass LSPs that are already in use.
If none of the manual or dynamic bypass LSPs satisfy the admin-group and other constraints, the PLR node requests the CSPF for a path that merges the closest to the protected link or node and that includes or excludes the specified admin-group IDs.
Modifying the configuration of this command does not affect existing bypass associations. The change only applies to new attempts to find a valid bypass.
The no form of this command disables the use of administrative group constraints on an FRR backup LSP at a PLR node.
Default
no admin-group-frr
bypass-resignal-timer
Syntax
bypass-resignal-timer minutes
no bypass-resignal-timer
Context
config>router>mpls
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command triggers the periodic global reoptimization of all dynamic bypass LSP paths associated with RSVP P2P LSP. The operation is performed at each expiry of the user-configurable bypass LSP resignal timer.
When this command is enabled, MPLS requests the CSPF for the best path for each dynamic bypass LSP originated on this node. The constraints of the first associated LSP primary path that originally triggered the signaling of the bypass LSP must be satisfied. To do this, MPLS saves the original Path State Block (PSB) of that LSP primary path, even if the latter is torn down.
If CSPF returns no path or returns a new path with a cost that is higher than the current path, MPLS does not signal the new bypass path. If CSPF returns a new path with a cost that is lower than the current path, MPLS signals it. Also, if the new bypass path is SRLG strict disjoint with the primary path of the original PSB while the current path is SLRG loose disjoint, the manual bypass path is resignaled, regardless of cost comparison.
After the new path is successfully signaled, MPLS evaluates each PSB of each PLR (that is, each unique avoid-node or avoid-link constraint) associated with the older bypass LSP path to check if the corresponding LSP primary path constraints are still satisfied by the new bypass LSP path. If so, the PSB association is moved to the new bypass LSP.
Each PSB for which constraints are not satisfied remains associated with the older bypass LSP and is checked at the next background PSB re-evaluation, or at the next timer or manual bypass reoptimization. If the older bypass LSP is SRLG disjoint with a primary path that has the non-strict SRLG constraint while the new bypass LSP is not SRLG disjoint, the PSB association is not moved.
If a specific PLR associated with a bypass LSP is active, the corresponding PSBs remain associated with the older bypass LSP until the global revertive Make-Before-Break (MBB) tears down all corresponding primary paths, which will also cause the older bypass LSP to be torn down.
This periodic bypass reoptimization feature also implements a background PSB re-evaluation task that audits in the background each RSVP session and determines if an existing manual or dynamic bypass is more optimal for that session. If so, it moves the PSB association to this existing bypass. If the PLR for this session is active, no action is taken and the PSB is re-examined at the next re-evaluation.
The periodic bypass reoptimization feature evaluates only the PSBs of the PLRs associated with that bypass LSP and only against the new bypass LSP path. The background re-evaluation task, however, audits all PSBs on the system against all existing manual and dynamic bypass LSPs.
PSBs that have not been moved by the dynamic or manual reoptimization of a bypass LSP because the PSB constraints have not been met by the new signaled bypass LSP path are re-evaluated by the background task against all existing manual and dynamic bypass LSPs.
Finally, the background re-evaluation task checks for PSBs that have requested node-protect bypass LSP but are currently associated with a link-protect bypass LSP, and PSBs that requested FRR protection but have no association. This is in addition to the attempt made at the receipt of a Resv message on the protected LSP path to accelerate the association.
This feature is not supported with inter-area dynamic bypass LSP and bypass LSP protecting S2L paths of a P2MP LSP.
The no form of this command disables the periodic global reoptimization of dynamic bypass LSP paths.
Default
no bypass-resignal timer
Parameters
- minutes
Specifies the time, in minutes, that MPLS waits before attempting to resignal dynamic bypass LSP paths originated on the system.
cspf-on-loose-hop
Syntax
[no] cspf-on-loose-hop
Context
config>router>mpls
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the option to perform CSPF calculations until the next loose hop or the final destination of the LSP on LSR. On receiving a PATH message on the LSR and processing all local hops in the received ERO, if the next hop is loose, the LSR node does a CSPF calculation until the next loose hop. On successful completion of the CSPF calculation, the ERO in the PATH message is modified to include newly calculated intermediate hops and the message is propagated forward to the next hop. This allows for the setting up of inter-area LSPs based on the ERO expansion method.
The LSP may fail to set up if this command is enabled on an LSR that is not an area border router and that receives a PATH message without a proper next loose hop in the ERO. The cspf-on-loose-hop command can change dynamically and is applied to the new LSP setup after changes are made.
The no form of this command reverts to the default value.
Default
no cspf-on-loose-hop
dynamic-bypass
Syntax
dynamic-bypass [enable | disable]
no dynamic-bypass
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command disables the creation of dynamic bypass LSPs in FRR. One or more manual bypass LSPs must be configured to protect the primary LSP path at the PLR nodes.
If the 7210 SAS is used as an egress LER and is a merge point, implicit null must be enabled for use of manual bypass or dynamic bypass (FRR facility).
Default
dynamic-bypass enable
frr-object
Syntax
[no] frr-object
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures whether fast reroute for LSPs using the facility bypass method is signaled with or without the fast reroute object using the one-to-one keyword. The value is ignored if fast reroute is disabled for the LSP or if the LSP is using one-to-one backup.
Default
frr-object
hold-timer
Syntax
hold-timer seconds
no hold-timer
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the amount of time that the ingress node waits before programming its data plane and declaring to the service module that the LSP state is up.
The no form of this command disables the hold timer.
Default
hold-timer 1
Parameters
- seconds
Specifies the hold time, in seconds.
p2mp-resignal-timer
Syntax
p2mp-resignal-timer minutes
no p2mp-resignal-timer
Context
config>router>mpls
Platforms
7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the resignal timer for a P2MP LSP instance.
MPLS requests CSPF to recompute the whole set of S2L paths of a specific active P2MP instance each time the P2MP resignal timer expires. The P2MP resignal timer is configured separately from the P2P LSP parameter. MPLS performs a global MBB and moves each S2L sub-LSP in the instance into its new path using a new P2MP LSP ID if the global MBB is successful, regardless of the cost of the new S2L path.
The no form of this command disables the timer-based resignaling of P2MP LSPs on this system.
Default
no resignal-timer
Parameters
- minutes
Specifies the time, in minutes, that MPLS waits before attempting to resignal the P2MP LSP instance.
pce-report
Syntax
pce-report rsvp-te {enable | disable}
Context
config>router>mpls
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the reporting mode for RSVP-TE LSPs.
The PCC LSP database is synchronized with the PCE LSP database using the PCEP PCRpt (PCE Report) message for PCC-controlled, PCE-computed, and PCE-controlled LSPs.
This global MPLS-level pce-report command enables or disables PCE reporting for all RSVP-TE LSPs during PCE LSP database synchronization. The PCC reports both CSPF and non-CSPF LSPs.
The LSP-level pce-report command (config>router>mpls>lsp>pce-report) overrides the global configuration for reporting an LSP to the PCE. The default configuration, which inherits the global MPLS-level configuration, is disabled (pce-report rsvp-te disable).
The default configuration controls the introduction of a PCE into an existing network and allows the operator to decide whether all RSVP-TE LSPs should be reported. If PCE reporting for an LSP is disabled, either because of inheritance of the global MPLS configuration or because of LSP-level configuration, enabling the pce-control option for the LSP has no effect.
Default
pce-report rsvp-te disable
Parameters
- rsvp-te {enable | disable}
Enables or disables PCE reporting for all RSVP-TE LSPs.
resignal-timer
Syntax
resignal-timer minutes
no resignal-timer
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the value for the LSP resignal timer. The resignal timer is the wait time, in minutes, before the software attempts to resignal the LSPs.
When the resignal timer expires, if the new computed path for an LSP has a better metric than the current recorded hop list, an attempt is made to resignal that LSP using the make-before-break mechanism. If the attempt to resignal an LSP fails, the LSP continues to use the existing path and a resignal is attempted the next time the timer expires.
The no form of this command disables timer-based LSP resignaling.
Default
no resignal-timer
Parameters
- minutes
Specifies the time, in minutes, that the software waits before attempting to resignal the LSPs.
srlg-frr
Syntax
srlg-frr [strict]
no srlg-frr
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of the Shared Risk Link Group (SRLG) constraint in the computation of an FRR bypass or detour LSP for any primary LSP path on this system.
When this option is enabled, CSPF includes the SRLG constraint in the computation of an FRR detour or bypass for protecting the primary LSP path.
CSPF prunes all links with interfaces that belong to the same SRLG as the interface that is being protected, where the interface being protected is the outgoing interface at the PLR used by the primary path.
If one or more paths are found, the MPLS/RSVP task selects one path based on best cost and signals the setup of the FRR bypass or detour LSP. If no path is found and the user included the strict option, the FRR bypass or detour LSP is not setup and the MPLS/RSVP task will keep retrying the request to CSPF. If no path is found and the strict option is disabled, if a path exists that meets all the TE constraints except the SRLG constraint, the FRR bypass or detour LSP is set up.
An FRR bypass or detour LSP path is not guaranteed to be SRLG disjoint from the primary path. This is because only the SRLG constraint of the outgoing interface at the PLR that the primary path is using is checked.
When the MPLS/RSVP task is searching for a SRLG bypass tunnel to associate with the primary path of the protected LSP, the task first checks if any configured manual bypass LSP with CSPF enabled satisfies the SLRG constraints. The MPLS/RSVP skips any non-CSPF bypass LSP in the search as there is no ERO returned to check the SLRG constraint. If no path is found, the task checks if an existing dynamic bypass LSP satisfies the SLRG and other primary path constraints. If not, it will make a request to CSPF.
After the primary path of the LSP is set up and is operationally up, any subsequent changes to the SRLG group membership of an interface that the primary path is using is not be considered by the MPLS/RSVP task at the PLR for FRR bypass or detour LSP association until the next opportunity that the primary path is resignaled. The path may be resignaled because of a failure or to a make-before-break operation. Make-before-break occurs as a result of a global revertive operation, a timer based or manual reoptimization of the LSP path, or a user change to any of the path constraints.
After the FRR bypass or detour LSP path is setup and is operationally up, any subsequent changes to the SRLG group membership of an interface that the FRR bypass or detour LSP path is using would not be considered by the MPLS/RSVP task at the PLR until the next opportunity the association with the primary LSP path is rechecked. The association is rechecked if the bypass path is reoptimized. Detour paths are not reoptimized and are resignaled if the primary path is down.
Enabling or disabling srlg-frr only takes effect after LSP paths are resignaled. This can be achieved by shutting down and re-enabling MPLS. Another option is using the tools>perform>router>mpls>resignal command. Though the latter has less impact on service, only originating LSPs can be resignaled with the tools command. If local transit and bypass LSPs are also to be resignaled, the tools command must be executed on all ingress nodes in the network. The same can be locally achieved by disabling and enabling using the configure>router>mpls>dynamic-bypass command, but this can trigger the LSP to go down and traffic loss to occur in case detour or bypass LSP is in use.
An RSVP interface can belong to a maximum of 64 SRLG groups. The user configures the SRLG groups using the config>router>mpls>srlg-group command. The user associates the SRLG with an RSVP interface using the srlg-group command in the config>router>mpls>interface context.
The no form of this command reverts to the default value.
Default
no srlg-frr
Parameters
- strict
Specifies the name of the SRLG group within a virtual router instance.
user-srlg-db
Syntax
user-srlg-db [enable | disable]
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of CSPF by the user SRLG database. When the MPLS module makes a request to CSPF for the computation of an SRLG secondary path, CSPF queries the local SRLG and computes a path after pruning links that are members of the SRLG IDs of the associated primary path. When MPLS makes a request to CSPF for an FRR bypass or detour path to associate with the primary path, CSPF queries the user SRLG database and computes a path after pruning links that are members of the SRLG IDs of the PLR outgoing interface.
If an interface is not entered into the user SRLG database, it is assumed that it does not have any SRLG membership. CSPF will not query the TE database for IGP advertised interface SRLG information.
The disable keyword disables the use of the user SRLG database. CSPF resumes queries into the TE database for SRLG membership information. The user SRLG database is maintained.
Default
user-srlg-db disable
Parameters
- enable
Keyword to enable the use of the user SRLG database.
- disable
Keyword to disable the use of the user SRLG database.
srlg-database
Syntax
[no] srlg-database
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context manually enter the link members of SRLG groups for the entire network at any node that needs to signal LSP paths (for example, a head-end node).
The no form of this command deletes the entire SRLG database. CSPF assumes all interfaces have no SRLG membership association if the database was not disabled with the command config>router>mpls>user-srlg-db disable.
router-id
Syntax
[no] router-id ip-address
Context
config>router>mpls>srlg-database
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command manually enters the link members of SRLG groups for a specific router in the network. The user must also use this command to enter the local interface SRLG membership into the user SRLG database. Use by CSPF of all interface SRLG membership information of a specific router ID may be temporarily disabled by shutting down the node. If this occurs, CSPF will assume these interfaces have no SRLG membership association.
The no form of this command deletes all interface entries under the router ID.
Parameters
- ip-address
Specifies the router ID for this system. This value must be the router ID configured under the base router instance, the base OSPF instance, or the base IS-IS instance.
interface
Syntax
interface ip-address srlg-group group-name [group-name...(up to 5 max)]
no interface ip-address [srlg-group group-name...(up to 5 max)]
Context
config>router>mpls>srlg-database>router-id
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures SRLG membership information for any link in the network, including links on this node, in the user SRLG database.
An interface can be associated with up to five SRLG groups for each execution of this command. The operator can associate an interface with up to 64 SRLG groups by executing the command multiple times.
CSPF will not use entered SRLG membership if an interface is not validated as part of a router ID in the routing table.
The no form of this command deletes a specific interface entry in this user SRLG database. The group name must already exist in the config>router>mpls>srlg-group context.
Parameters
- ip-int-name
Specifies the name of the network IP interface. An interface name cannot be in the form of an IP address.
- srlg-group group-name
Specifies the SRLG group name, up to 32 characters. Up to 1024 group names can be defined in the config>router>mpls context. The SRLG group names must be identical across all routers in a single domain.
label-map
Syntax
[no] label-map in-label
Context
config>router>mpls>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command is used on transit routers when a static LSP is defined. The static LSP on the ingress router is initiated using the config>router>mpls>static-lsp lsp-name command. The in-label is associated with either a pop or a swap action, but not both. If both actions are specified, the last action specified takes effect.
The no form of this command deletes the static LSP configuration associated with the in-label.
Parameters
- in-label
Specifies the incoming MPLS label on which to match.
pop
Syntax
[no] pop
Context
config>router>mpls>if>label-map
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies that the incoming label must be popped (removed). No label stacking is supported for a static LSP. The service header follows the top label. After the label is popped, the packet is forwarded based on the service header.
The no form of this command removes the pop action for the in-label.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>if>label-map
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command disables the label map definition. This drops all packets that match the in-label specified in the label-map in-label command.
The no form of this command administratively enables the defined label map action.
Default
no shutdown
swap
Syntax
swap {out-label | implicit-null-label} nexthop ip-address
no swap {out-label | implicit-null-label}
Context
config>router>mpls>interface>label-map
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command swaps the incoming label and specifies the outgoing label and next hop IP address on an LSR for a static LSP.
The no form of this command removes the swap action associated with the in-label.
Parameters
- implicit-null-label
Keyword to specify the use of the implicit label value for the outgoing label of the swap operation.
- out-label
Specifies the label value to be swapped with the in-label. Label values 16 through 1,048,575 are defined as follows.
Label values 16 through 31 are reserved.
Label values 32 through 1,023 are available for static assignment.
Label values 1,024 through 2,047 are reserved for future use.
Label values 2,048 through 18,431 are statically assigned for services.
Label values 28,672 through 131,071 are dynamically assigned for both MPLS and services.
Label values 131,072 through 1,048,575 are reserved for future use.
- nexthop ip-address
Specifies the IP address to forward to. If an ARP entry for the next hop exists, the static LSP is marked operational. If an ARP entry does not exist, the software sets the operational status of the static LSP to down and continues to the ARP for the configured next hop. Software will continue to the ARP for the configured next hop at a fixed interval.
static-lsp
Syntax
[no] static-lsp lsp-name
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures a static LSP on the ingress router. The static LSP is a manually setup LSP where the next-hop IP address and the outgoing label (push) must be specified.
The LSP must first be shut down to delete it. If the LSP is not shut down, the no static-lsp lsp-name command generates a warning message on the console indicating that the LSP is administratively up.
The no form of this command deletes this static LSP and associated information.
Parameters
- lsp-name
Specifies the LSP name, up to 32 characters.
push
Syntax
no push label
push label nexthop ip-address
Context
config>router>mpls>static-lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the label to be pushed on the label stack and the next hop IP address for the static LSP.
The no form of this command removes the association of the label to push for the static LSP.
Parameters
- label
Specifies the label to push on the label stack. Label values 16 through 1,048,575 are defined as follows.
Label values 16 through 31 are reserved.
Label values 32 through 1,023 are available for static assignment.
Label values 1,024 through 2,047 are reserved for future use.
Label values 2,048 through 18,431 are statically assigned for services.
Label values 28,672 through 131,071 are dynamically assigned for both MPLS and services.
Label values 131,072 through 1,048,575 are reserved for future use.
- nexthop ip-address
Specifies the IP address of the next hop toward the LSP egress router. If an ARP entry for the next hop exists, the static LSP is marked operational.
If an ARP entry does not exist, software sets the operational status of the static LSP to down and continues to ARP for the configured next hop. Software continuously tries to ARP for the configured next hop at a fixed interval.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>static-lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command administratively disables the static LSP.
The no form of this command administratively enables the static LSP.
Default
shutdown
to
Syntax
to ip-address
Context
config>router>mpls>static-lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the system IP address of the egress router for the static LSP. This command is required while creating an LSP. For LSPs that are used as transport tunnels for services, the to IP address must be the system IP address. If the to address does not match the SDP address, the LSP is not included in the SDP definition.
Parameters
- ip-address
Specifies the system IP address of the egress router.
static-lsp-fast-retry
Syntax
static-lsp-fast-retry seconds
[no] static-lsp-fast-retry
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the fast retry timer value for a static LSP.
When a static LSP is trying to come up, the MPLS request for the ARP entry of the LSP next hop may fail when it is made while the next hop is still down or unavailable. In that case, MPLS starts a retry timer before making the next request. This enhancement allows the user to configure the retry timer so that the LSP comes up as soon as the next hop is up.
The no form of this command removes the configuration.
Default
no static-fast-retry-timer
Parameters
- seconds
Specifies the value, in seconds, used as the fast retry timer for a static LSP.
MPLS label commands
mpls-labels
Syntax
mpls-labels
Context
config>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure MPLS labels on the ingress router.
static-label-range
Syntax
static-label-range static-range
no static-label-range
Context
config>router>mpls-labels
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the static label range on the ingress router.
The no form of this command reverts to the default value.
Default
static-label-range 18400
Parameters
- static-range
Specifies the static label range.
MPLS interface commands
interface
Syntax
[no] interface ip-int-name
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies MPLS protocol support on an IP interface. MPLS commands are not executed on an IP interface where MPLS is not enabled. An MPLS interface must be explicitly enabled (no shutdown).
The no form of this command deletes all MPLS commands, such as label-map, that are defined under the interface. The MPLS interface must first be shut down to delete the interface definition. If the interface is not shut down, the no interface ip-int-name command does nothing except issue a warning message on the console indicating that the interface is administratively up.
Default
shutdown
Parameters
- ip-int-name
Specifies the name of the network IP interface, up to 32 characters. An interface name cannot be in the form of an IP address. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
admin-group
Syntax
[no] admin-group group-name [group-name...(up to 5 max)]
Context
config>router>mpls>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures administrative groups that this interface supports.
This information is advertised as part of OSPF and IS-IS to help CSPF compute constrained LSPs that must include or exclude specific administrative groups. An MPLS interface is assumed to belong to all the administrative groups unless the admin-group command is issued under the interface configuration. When the admin-group command is issued, the interface is assumed to belong to only the specifically listed groups for that command.
Each single operation of the admin-group command allows a maximum of five groups to be specified at a time. However, a maximum of 32 groups can be specified per interface through multiple operations.
Default
no admin-group
Parameters
- group-name
Specifies the name of the group, up to 32 characters. The group names should be the same across all routers in the MPLS domain.
srlg-group
Syntax
[no] srlg-group group-name [group-name...(up to 5 max)]
Context
config>router>mpls>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command associates an RSVP interface to SRLG groups. An interface can belong to up to 64 SRLG groups. However, each single operation of the srlg-group command allows a maximum of five groups to be specified at a time.
The no form of this command deletes the association of the interface to the SRLG group.
Parameters
- group-name
Specifies the name of the SRLG group, up to 32 characters, within a virtual router instance.
te-metric
Syntax
te-metric value
no te-metric
Context
config>router>mpls>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the traffic engineering metric used on the interface. This metric is in addition to the interface metric used by IGP for the shortest path computation.
This metric is flooded as part of the TE parameters for the interface using an opaque LSA or an LSP. The IS-IS TE metric is encoded as sub-TLV 18 as part of the extended IS reachability TLV, and the metric value is encoded as a 24-bit unsigned integer. The OSPF TE metric is encoded as a sub-TLV Type 5 in the Link TLV, and the metric value is encoded as a 32-bit unsigned integer.
When the use of the TE metric is enabled for an LSP, CSPF first prunes all links in the network topology that do not meet the constraints specified for the LSP path. Such constraints include bandwidth, admin-groups, and hop limit. Then, CSPF runs an SPF on the remaining links. The shortest path among all the SPF paths will be selected based on the TE metric instead of the IGP metric, which is used by default.
The TE metric in CSPF LSP path computation can be configured using the config>router>mpls>lsp>cspf>use-te-metric CLI command.
The TE metric is only used in CSPF computations for MPLS paths and not in the regular SPF computation for IP reachability. The value of the IGP metric is advertised in the TE metric sub-TLV by IS-IS and OSPF.
The no form of this command removes the configuration.
Default
no te-metric
Parameters
- value
Specifies the metric value.
MPLS-TP commands
mpls-tp
Syntax
[no] mpls-tp
Context
config>router>mpls
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
Commands in this context configure generic MPLS-TP parameters and MPLS-TP transit paths. If a user configures no mpls, normally the entire MPLS configuration is deleted. However, in the case of mpls-tp, a check is made that there is no other mpls-tp configuration (for example, services or LSPs using MPLS TP on the node). The mpls-tp context cannot be deleted if MPLS-TP LSPs or SDPs exist on the system.
A shutdown of mpls-tp will bring down all MPLS-TP LSPs on the system.
Default
no mpls-tp
tp-tunnel-id-range
Syntax
tp-tunnel-id-range start-id end-id
no tp-tunnel-id-range
Context
config>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the range of MPLS tunnel IDs reserved for MPLS-TP LSPs. The maximum difference between the start-id and end-id is 4000.
The tunnel ID is the RSVP-TE tunnel ID. This maps to the MPLS-TP tunnel number. In some cases, dynamic LSPs may cause fragmentation to the number space such that the contiguous range [end-id – start-id] is not available. In these cases, the command fails.
There are no default values for the start-id and end-id of the tunnel ID range, and they must be configured to enable MPLS-TP.
Default
no tunnel-id-range
Parameters
- start-id
Specifies the start ID.
- end-id
Specifies the end ID.
oam-template
Syntax
[no] oam-template name
Context
config>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables or edits an OAM template context. Generally, applicable proactive OAM parameters are configured using templates. The top-level template is the OAM template.
Generic MPLS-TP OAM and fault management parameters are configured in the OAM template.
Proactive CC/CV uses BFD and parameters such as Tx/Rx timer intervals, multiplier, and other session or fault management parameters specific to BFD that are configured using a BFD template, which is referenced from the OAM template.
Default
no oam-template
Parameters
- name
Specifies a text string name for the template of up to 32 characters in printable 7-bit ASCII, enclosed in double quotes. Named OAM templates are referenced from the MPLS-TP path MEP configuration.
hold-time-down
Syntax
hold-time-down timer
no hold-time-down
Context
config>router>mpls>mpls-tp>oam-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the hold-down dampening timer. It is equivalent to a hold-off timer.
Default
no hold-time-down
Parameters
- interval
Specifies the hold-down dampening timer interval.
hold-time-up
Syntax
hold-time-up timer
no hold-time-up
Context
config>router>mpls>mpls-tp>oam-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the hold-up dampening timer. This can be used to provide additional dampening to the state of proactive CC BFD sessions.
Default
no hold-time-up
Parameters
- interval
Specifies the hold-up dampening timer interval.
bfd-template
Syntax
bfd-template name
no bfd-template
Context
config>router>mpls>mpls-tp>oam-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures a named BFD template to be referenced by an OAM template.
Default
no bfd-template
Parameters
- name
Specifies the BFD template name as a text string up to 32 characters in printable 7-bit ASCII, enclosed in double quotes.
protection-template
Syntax
protection-template name
no protection-template
Context
config>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command creates or edits a named protection template context. Protection templates are used to define generally applicable protection parameters for MPLS-TP tunnels. Only linear protection is supported; the application of a named template to an MPLS-TP LSP implies that linear protection is used. A protection template is applied under the MEP context of the protect-path of an MPLS-TP LSP.
Default
no protection-template
Parameters
- name
Specifies the protection template name as a text string of up to 32 characters in printable 7-bit ASCII, enclosed in double quotes.
revertive
Syntax
[no] revertive
Context
config>router>mpls>mpls-tp>protection-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures revertive behavior for MPLS-TP linear protection. The protect-tp-path MEP must be in the shutdown state for the MPLS-TP LSPs referencing this protection template to change the revertive parameter.
Default
revertive
wait-to-restore
Syntax
wait-to-restore interval
no wait-to-restore
Context
config>router>mpls>mpls-tp>protection-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the WTR timer. It determines how long to wait until the active path of an MPLS-TP LSP is restored to the working path following the clearing of a defect on the working path. It is applicable only for revertive mode.
Default
no wait-to-restore
Parameters
- interval
Specifies the WTR timer interval.
rapid-psc-timer
Syntax
rapid-psc-timer interval
no rapid-psc-timer
Context
config>router>mpls>mpls-tp>protection-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the rapid timer value used for protection switching coordination (PSC) packets for MPLS-TP linear protection, in accordance with RFC 6378.
Default
no rapid-psc-timer
Parameters
- interval
Specifies the rapid timer interval, in milliseconds.
slow-psc-timer
Syntax
slow-psc-timer interval
no slow-psc-timer
Context
config>router>mpls>mpls-tp>protection-template
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the slow timer value used for PSC packets for MPLS-TP linear protection, in accordance with RFC 6378.
Default
no rapid-psc-timer
Parameters
- interval
Specifies the slow timer interval, in milliseconds.
global-id
Syntax
global-id global-id
no global-id
Context
config>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the MPLS-TP global ID for the node. The MPLS-TP LSPs originating at this node use this ID as the ‛from’ global ID. If the global-id value is not configured, a value of zero is used.
If an operator expects that inter domain LSPs will be configured, Nokia recommends that the global ID should be set to the local ASN of the node, as configured under config>system. If two-byte ASNs are used, the most significant two bytes of the global ID are padded with zeros.
To change the global-id value, the config>router>mpls>mpls-tp CLI command must be in the shutdown state. This state brings down all of the MPLS-TP LSPs on the node. New values a propagated to the system when a no shutdown is performed.
Default
no global-id
Parameters
- global-id
Specifies the global ID for the node.
node-id
Syntax
node-id node-id
no node-id
Context
config>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the MPLS-TP node ID. The MPLS-TP LSPs originating at this node use this ID as the ‛from’ node ID. The default value of the node ID is the system interface IPv4 address. The node ID may be entered in the 4-octet IPv4 address format, <a.b.c.d>, or as an unsigned 32-bit integer.
The node ID is not treated as a routable IP address from the perspective of IP routing, and is not advertised in any IP routing protocols.
The MPLS-TP context cannot be administratively enabled unless at least a system interface IPv4 address is configured because MPLS requires that this value is configured.
Default
no node-id
Parameters
- node-id
Specifies the MPLS-TP node ID for the node.
transit-path
Syntax
transit-path path-name
no transit-path
Context
config>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the configuration or editing of an MPLS-TP transit path at an LSR.
Default
no transit-path
Parameters
- path-name
Specifies the template of up to 32 characters in printable 7-bit ASCII, enclosed in double quotes.
path-id
Syntax
path-id {lsp-num lsp-num | working-path | protect-path [src-global-id src-global-id] src-node-id src-node-id src-tunnel-num src-tunnel-num [dest-global-id dest-global-id] dest-node-id dest-node-id [dest-tunnel-num dest-tunnel-num]}
no path-id
Context
config>router>mpls>mpls-tp>transit-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the path ID for an MPLS-TP transit path at an LSR. The path ID is equivalent to the MPLS-TP LSP ID and is used to generate the maintenance entity group intermediate point (MIP) identifier for the LSP at the LSR. A path ID must be configured for on-demand OAM to verify an LSP at the LSR.
The path ID must contain at least the following parameters: lsp-num, src-node-id, src-global-id, src-tunnel-num, and dest-node-id.
The path ID must be unique on a node. Nokia recommends that this the configured value is also globally unique.
The no form of this command removes the path ID from the configuration.
Default
no path-id
Parameters
- lsp-num
Specifies the LSP number.
- src-global-id
Specifies the source global ID.
- src-node-id
Specifies the source node ID.
- src-tunnel-num
Specifies the source tunnel number.
- dest-global-id
Specifies the destination global ID. If the destination global ID is not entered, it is set to the same value as the source global ID.
- dest-node-id
Specifies the destination node ID.
- dest-tunnel-num
Specifies the destination tunnel number. If the destination tunnel number is not entered, it is set to the same value as the source tunnel number.
forward-path
Syntax
[no] forward-path
Context
config>router>mpls>mpls-tp>transit-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the forward path of an MPLS-TP transit path to be created or edited.
The forward path must be created before the reverse path.
The no form of this command removes the forward path. The forward path cannot be removed if a reverse exists.
Default
no forward-path
reverse-path
Syntax
[no] reverse-path
Context
config>router>mpls>mpls-tp>transit-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the reverse path of an MPLS-TP reverse path to be configured or edited.
The reverse path must be created after the forward path. The reverse path must be removed before the forward path.
The no form of this command removes the reverse path.
Default
no reverse-path
in-label
Syntax
in-label in-label out-label out-label out-link interface-name [next-hop next-hop]
no in-label
Context
config>router>mpls>mpls-tp>transit-path>forward-path
config>router>mpls>mpls-tp>transit-path>reverse-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the label mapping associated with a forward path or reverse path of an MPLS-TP transit path to be configured.
The incoming label, outgoing label, and outgoing interface must be configured using the in-label, out-label, and out-link parameters. If the out-link refers to a numbered IP interface, the user may optionally configure the next-hop parameter and the system will determine the interface to use to reach the configured next hop, but will check that the user-entered value for the out-link corresponds to the link returned by the system. If they do not correspond, the path will not come up.
Default
no in-label
Parameters
- in-label
Specifies the incoming label.
- out-label
Specifies the outgoing label.
- interface-name
Specifies the name of the outgoing interface, up to 32 characters, used for the path.
- next-hop
Specifies the next hop.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>mpls-tp>transit-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command administratively enables or disables an MPLS-TP transit path.
Default
no shutdown
LSP commands
lsp
Syntax
[no] lsp lsp-name [bypass-only | mpls-tp src-tunnel-num]
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command creates an LSP that is signaled dynamically by the 7210 SAS.
When the LSP is created, the egress router must be specified using the to command and at least one primary or secondary path must be specified. All other statements under the LSP hierarchy are optional. The maximum number of static configurable LSPs is 4.
LSPs are created in the administratively down (shutdown) state.
The no form of this command deletes the LSP. All configuration information associated with this LSP is lost. The LSP must be administratively shutdown before it can be deleted.
Parameters
- lsp-name
Specifies the name that identifies the LSP. The LSP name can be up to 32 characters long and must be unique.
- bypass-only
Keyword to define an LSP as a manual bypass LSP exclusively. When a path message for a new LSP requests bypass protection, the PLR first checks if a manual bypass tunnel satisfying the path constraints exists. If one if found, the 7210 SAS selects it. By default, if no manual bypass tunnel is found, the 7210 SAS dynamically signals a bypass LSP. The CLI for this feature includes a knob that provides the user with the option to disable dynamic bypass creation on a per-node basis.
- mpls-tp
Keyword to define an LSP as an MPLS-TP LSP. The following parameters can only be used with an MPLS-TP LSP: to, dest-global-id, dest-tunnel-number, working-tp-path, protect-tp-path. Other parameters defined for the above LSP types cannot be used. This is supported on 7210 SAS-T network mode, 7210 SAS-R6 and 7210 SAS-R12 devices only.
- src-tunnel-num
Specifies the source tunnel number. This is a mandatory time parameter for MPLS-TP LSPs, and has to be assigned by the user based on the configured range of tunnel IDs.
adaptive
Syntax
[no] adaptive
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the make-before-break functionality for an LSP or LSP path. When enabled for the LSP, make-before-break is performed for the primary path and all secondary paths of the LSP.
Default
adaptive
adspec
Syntax
[no] adspec
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
When enabled, the ADSPEC object will be included in RSVP messages for this LSP. The ADSPEC object is used by the ingress LER to discover the minimum value of the MTU for links in the path of the LSP. By default, the ingress LER derives the LSP MTU from that of the outgoing interface of the LSP path.
A bypass LSP always signals the ADSPEC object because it protects primary paths that signal the ADSPEC object and primary paths that do not. This means that MTU of the LSP at ingress LER may change to a different value from that derived from the outgoing interface even if the primary path has ADSPEC disabled.
Default
no adspec
bgp-transport-tunnel
Syntax
bgp-transport-tunnel include | exclude
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command controls whether RSVP-TE LSP can be used as a transport LSP for BGP tunnel routes.
Default
bgp-transport-tunnel exclude
Parameters
- include
Keyword to enable RSVP-TE LSP to be used as transport LSP from the ASBR to local PE router, from ingress PE to ASBR in the local AS, or between multi-hop eBGP peers with ASBR to ASBR adjacency.
- exclude
Disables RSVP-TE LSP from being used as transport LSP from the ASBR to local PE router, from ingress PE to ASBR in the local AS, or between multi-hop eBGP peers with ASBR to ASBR adjacency.
cspf
Syntax
[no] cspf [use-te-metric]
Context
config>router>mpls>lsp
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command enables constrained shortest path first (CSPF) computation for constrained-path LSPs. Constrained-path LSPs take configuration constraints into account. CSPF is also used to calculate the detour routes when the fast-reroute command is enabled.
Explicitly configured LSPs for which each hop from ingress to egress is specified do not use CSPF. The LSP is set up using RSVP signaling from ingress to egress.
If an LSP is configured with the fast-reroute frr-method option specified but does not enable CSPF, neither global revertive nor local revertive will be available for the LSP to recover.
The no form of this command disables CSPF computation for constrained-path LSPs.
Default
no cspf
Parameters
- use-te-metric
Keyword to use the TE metric for the CSPF computation of the LSP path.
exclude
Syntax
[no] exclude group-name [group-name...(up to 5 max)]
Context
config>router>mpls>lsp
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command specifies the admin groups to be excluded when an LSP is set up in the primary or secondary contexts. A maximum of 5 groups can be specified per single operation of the exclude command. However, a maximum of 32 groups can be specified per LSP through multiple operations. The admin groups are defined in the config>router>if-attribute context.
The no form of this command removes the admin groups configured for exclusion.
Default
no exclude
Parameters
- group-name
Specifies the existing group name, up to 32 characters, to be excluded when an LSP is set up.
fast-reroute
Syntax
fast-reroute [frr-method]
no fast-reroute
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables a precomputed detour LSP from each node in the path of the LSP. In case of failure of a link or LSP between two nodes, traffic is immediately rerouted on the precomputed detour LSP, which avoids packet loss.
When the fast-reroute command is enabled, each node along the path of the LSP tries to establish a detour LSP as follows.
Each upstream node sets up a detour LSP that avoids only the immediate downstream node, and merges back on to the main path of the LSP as soon as possible.
If it is not possible to set up a detour LSP that avoids the immediate downstream node, a detour can be set up to the downstream node on a different interface.
The detour LSP may take one or more hops (see hop-limit) before merging back on to the main LSP path.
When the upstream node detects a downstream link or node failure, the ingress router switches traffic to a standby path if one was set up for the LSP.
Fast reroute is available only for the primary path. No configuration is required on the transit hops of the LSP. The ingress router will signal all intermediate routers using RSVP to set up their detours. TE must be enabled for fast-reroute to work.
If an LSP is configured with the fast-reroute frr-method option specified but does not enable CSPF, neither global revertive nor local revertive will be available for the LSP to recover.
The no form of this command removes the detour LSP from each node on the primary path. This command will also remove configuration information about the hop-limit and the bandwidth for the detour routes.
The no form of fast-reroute hop-limit command reverts to the default value.
Default
no fast-reroute
Parameters
- frr-method
Specifies the fast reroute method.
hop-limit
Syntax
hop-limit limit
no hop-limit
Context
config>router>mpls>lsp>fast-reroute
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the fast reroute context to set how many more routers a detour is allowed to traverse compared to the LSP itself. For example, if an LSP traverses four routers, any detour for the LSP can be no more than ten router hops, including the ingress and egress routers.
Default
hop-limit 16
Parameters
- limit
Specifies the maximum number of hops.
node-protect
Syntax
[no] node-protect
Context
config>router>mpls>lsp>fast-reroute
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables node and link protection on the specified LSP. Node protection ensures that traffic from an LSP traversing a neighboring router will reach its destination even if the neighboring router fails.
The no form of this command disables node and link protection on the specified LSP.
Default
node-protect
propagate-admin-group
Syntax
[no] propagate-admin-group
Context
config>router>mpls>lsp>fast-reroute
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
The command enables the signaling of the primary LSP path admin-group constraints in the FRR object at ingress.
When this command is executed, the admin-group constraints configured in the context of the P2P LSP primary path, or the constraints configured in the context of the LSP and inherited by the primary path, are copied into the FAST_REROUTE object. The admin-group constraints are copied into the ‟include-any” or ‟exclude-any” fields.
During LSP signaling to the downstream node, the ingress LER also propagates the admin-group constraints, which allows the node to include these constraints in the selection of the FRR backup LSP for LSP primary path protection.
The ingress LER inserts the FAST_REROUTE object, by default, in a primary LSP path message. If the user disables the object using config>router>mpls>no frr-object command, the admin-group constraints are not propagated.
The same admin-group constraints can be copied into the Session Attribute object for use by an LSR, typically an ABR, to expand the ERO of an inter-area LSP path. The constraints are also used by any LSR node in the path of a CSPF or non-CSPF LSP to check the admin-group constraints against the ERO regardless if the hop is strict or loose. These constraints are governed strictly by the config>router>mpls>lsp>propagate-admin-group command.
That is, the user can copy the primary path admin-group constraints into only the FAST_REROUTE object only, or only the Session Attribute object only, or both. However, the PLR rules for processing the admin-group constraints can make use of either of the two object admin-group constraints.
This feature is supported with the primary path of an RSVP P2P LSP in both intra-area and inter-area TE.
The no form of this command disables administrative group constraint signaling in the FRR object.
Default
no propagate-admin-group
from
Syntax
from ip-address
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This optional command configures the IP address of the ingress router for the LSP. When this command is not specified, the system IP address is used. IP addresses that are not defined in the system are allowed. If an invalid IP address is entered, LSP bring-up fails and an error is logged.
If an interface IP address is specified as the from address, and the egress interface of the next-hop IP address is a different interface, the LSP is not signaled. As the egress interface changes because of changes in the routing topology, an LSP recovers if the from IP address is the system IP address and not a specific interface IP address.
Only one from address can be configured.
Parameters
- ip-address
Specifies the IP address of the ingress router. This can be either the interface or the system IP address. If the IP address is local, the LSP must egress through that local interface which ensures local strictness.
hop-limit
Syntax
hop-limit number
no hop-limit
Context
config>router>mpls>lsp
config>router>mpls>lsp>fast-reroute
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the maximum number of hops that an LSP can traverse, including the ingress and egress routers. An LSP is not set up if the hop limit is exceeded. This value can be changed dynamically for an LSP that is already set up with the following implications.
If the new value is less than the current number of hops of the established LSP, the LSP is brought down. Software then tries to re-establish the LSP within the new hop-limit number. If the new value is equal to or greater than the current number hops of the established LSP, the LSP is not affected.
The no form of this command returns the parameter to the default value.
Default
hop-limit 255
Parameters
- number
Specifies the number of hops the LSP can traverse, expressed as an integer.
include
Syntax
[no] include group-name [group-name...(up to 5max)]
Context
config>router>mpls>lsp
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command configures the admin groups to be included when an LSP is set up. Up to 5 groups per operation can be specified, up to 32 maximum.
The no form of this command deletes the specified groups in the specified context.
Default
no include
Parameters
- group-name
Specifies admin groups, up to 32 characters, to be included when an LSP is set up.
ldp-over-rsvp
Syntax
[no] ldp-over-rsvp [include | exclude]
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures if this LSP will be included in LDP over RSVP.
The no form of this command reverts to default operation.
Default
no ldp-over-rsvp
Parameters
- include
Specifies that this LSP will be included in LDP over RSVP.
- exclude
Specifies that this LSP will be excluded from LDP over RSVP.
metric
Syntax
metric metric
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the metric for this LSP, which is used to select an LSP among a set of LSPs that are destined for the same egress router. The LSP with the lowest metric is selected.
In LDP-over-RSVP, LDP performs a lookup in the Routing Table Manager (RTM), which provides the next hop to the destination PE and the advertising router (ABR or destination PE). If the advertising router matches the targeted LDP peer, LDP performs a second lookup for the advertising router in the Tunnel Table Manager (TTM). This lookup returns the best RSVP LSP to use to forward packets for an LDP FEC learned through the targeted LDP session. The lookup returns the LSP with the lowest metric. If multiple LSPs have the same metric, the result of the lookup is to select the first available LSP in the TTM.
Default
metric 1
Parameters
- metric
Specifies the metric for this LSP, which is used to select an LSP among a set of LSPs that are destined for the same egress router.
path-profile
Syntax
path-profile profile-id [path-group group-id]
no path-profile profile-id
Context
config>router>mpls>lsp
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the PCE path profile and path group ID.
The PCE supports the computation of disjoint paths for two LSPs originating or terminating on the same or different PE routers. To indicate this constraint to the PCE, the user configures the PCE path profile ID and path group ID to which the PCE-computed or PCE-controlled LSP belongs. Because the PCC passes these parameters transparently to the PCE, the parameters are opaque data to the router.
The association of the optional path group ID allows the PCE to determine the profile ID to use with this path group ID. Although one path group ID is allowed per profile ID, you can execute the path-profile command multiple times and enter the same path group ID with multiple profile IDs. A maximum of five path-profile profile-id [path-group group-id] entries can be associated with the same LSP.
Parameters
- profile-id
Specifies the profile ID.
- group-id
Specifies the path group ID.
pce-computation
Syntax
[no] pce-computation
Context
config>router>mpls>lsp
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the PCE-computed LSP mode of operation for an RSVP-TE LSP.
The user can grant only path computation requests (PCE-computed) or both path computation requests and path updates (PCE-controlled) to a PCE for a specific LSP.
The pce-computation command sends the path computation request to the PCE instead of the local CSPF. Enabling this option allows the PCE to perform path computations for the LSP at the request of the PCC router only. This feature is used in cases where the operator wants to use the PCE-specific path computation algorithm instead of the local router CSPF algorithm.
The default configuration is no pce-computation. To enable the pce-computation command or pce-control command, you must first enable the cspf option, or this configuration is rejected. Conversely, an attempt to disable the cspf option on an RSVP-TE LSP that has the pce-computation command or pce-control command enabled is rejected.
Default
no pce-computation
pce-control
Syntax
[no] pce-control
Context
config>router>mpls>lsp
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command enables the PCE-controlled LSP mode of operation for an RSVP-TE LSP.
Using the pce-control command, the PCC router delegates full control of the LSP to the PCE (PCE-controlled). As a result, PCE acts in an active stateful mode for this LSP. The PCE can reroute the path following a failure or reoptimize the path and update the router without an update request from the PCC router.
The user can delegate CSPF and non-CSPF LSPs, or LSPs that have the pce-computation option enabled or disabled. The LSP maintains the latest active path computed by the PCE or the PCC router at the time it is delegated. The PCE will only update the path at the next network event or reoptimization.
The default configuration is no pce-control. To enable the pce-control command or pce-computation command, you must first enable the cspf option; otherwise, this configuration is rejected. Conversely, an attempt to disable the cspf option on an RSVP-TE LSP that has the pce-control command or pce-computation command enabled is rejected.
If PCE reporting is disabled for the LSP, either because of inheritance from the MPLS-level configuration or because of LSP-level configuration, enabling the pce-control option for the LSP has no effect.
Default
no pce-control
pce-report
Syntax
pce-report {enable | disable | inherit}
Context
config>router>mpls>lsp
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the reporting mode to a PCE for an RSVP-TE LSP.
The PCC LSP database is synchronized with the PCE LSP database using the PCEP PCRpt (PCE Report) message for PCC-controlled, PCE-computed, and PCE-controlled LSPs.
Use the global MPLS-level pce-report command (config>router>mpls>pce-report) to enable or disable PCE reporting for all RSVP-TE LSPs during PCE LSP database synchronization.
The LSP-level pce-report command overrides the global configuration for reporting an LSP to the PCE. The default configuration is to inherit the global MPLS-level configuration. The inherit option reconfigures the LSP to inherit the global configuration.
Default
pce-report inherit
Parameters
- enable
Keyword to enable PCE reporting.
- disable
Keyword to disable PCE reporting.
- inherit
Keyword to inherit the global configuration for PCE reporting.
propagate-admin-group
Syntax
[no] propagate-admin-group
Context
config>router>mpls>lsp
config>router>mpls>lsp-template
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12 (for config>router>mpls>lsp context)
7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (network mode), and 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode) (for config>router>mpls>lsp-template context)
Description
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command enables the propagation of session attribute objects with resource affinity (C-type 1) in a Path message. If a session attribute with resource affinity is received at an LSR, the LSR checks the compatibility of admin-groups received in the Path message with configured admin-groups on the egress interface of the LSP.
To support admin-groups for inter-area LSPs, the ingress node must configure the propagation of admin-groups within the SESSION_ATTRIBUTE object. If a Path message is received by an LSR node that has the cspf-on-loose-hop command configured and the message includes admin-groups, the ERO expansion by CSPF to calculate the path to the next loose hop will include the admin-group constraints received from the ingress node.
If the cspf-on-loose-hop command is disabled, the SESSION_ATTRIBUTE object without resource affinity (C-Type 7) is propagated in the Path message, and CSPF at the LSR node will not include admin group constraints.
Admin-group propagation is supported with P2P LSPs.
The user can change the value of the propagate-admin-group option on the fly. An RSVP P2P LSP performs a make-before-break (MBB) when changing the configuration.
The no form of this command removes the configuration.
Default
no propagate-admin-group
retry-limit
Syntax
retry-limit number
no retry-limit
Context
config>router>mpls>lsp
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command configures the number of attempts the software should make to re-establish the LSP after the LSP has failed. After each successful attempt, the counter is reset to zero.
When the configured retry limit is reached, no more attempts are made and the LSP path is set to the shutdown state.
Use the config>router>mpls>lsp>no shutdown command to bring up the path after the retry limit is exceeded.
The no form of this command reverts the parameter to the default value.
Default
retry-limit 0
Parameters
- number
Specifies the number of software attempts to re-establish the LSP after it has failed. A value of 0 indicates to retry forever.
retry-timer
Syntax
retry-timer seconds
no retry-timer
Context
config>router>mpls>lsp
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command configures the time, in seconds, between LSP re-establishment attempts after the LSP has failed.
The no form of this command reverts to the default value.
Default
retry-timer 30
Parameters
- seconds
Specifies the amount of time, in seconds, between attempts to re-establish the LSP after it has failed.
rsvp-resv-style
Syntax
rsvp-resv-style [se | ff]
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the RSVP reservation style, shared explicit (se) or fixed filter (ff). A reservation style is a set of control options that specify a number of supported parameters. The style information is part of the LSP configuration.
Default
rsvp-resv-style se
Parameters
- ff
Keyword to configure fixed filter reservation style, which is a single reservation with an explicit scope. This reservation style specifies an explicit list of senders and a distinct reservation for each of them. A specific reservation request is created for data packets from a particular sender. The reservation scope is determined by an explicit list of senders.
- se
Keyword to configure shared explicit reservation style, which is a shared reservation with a limited scope. This reservation style specifies a shared reservation environment with an explicit reservation scope. This reservation style creates a single reservation over a link that is shared by an explicit list of senders. Because each sender is explicitly listed in the RESV message, different labels can be assigned to different sender-receiver pairs, thereby creating separate LSPs.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command disables the existing LSP, including the primary path and any standby secondary paths.
To shut down only the primary path, enter the config>router>mpls>lsp>primary> shutdown command.
To shut down a specific standby secondary path, enter the config>router>mpls>lsp> secondary>shutdown command. The existing configuration of the LSP is preserved.
Use the no form of this command to restart the LSP. LSPs are created in a shutdown state. Use this command to administratively bring up the LSP.
Default
shutdown
to
Syntax
to ip-address
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the system IP address of the egress router for the LSP. This command is mandatory to create an LSP.
An IP address for which a route does not exist is allowed in the configuration. If the LSP signaling fails because the destination is not reachable, an error is logged and the LSP operational status is set to down.
Parameters
- ip-address
Specifies the system IP address of the egress router.
vprn-auto-bind
Syntax
vprn-auto-bind [include | exclude]
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures whether the associated LSP can be used as part of the auto-bind feature for VPRN services. By default, a named LSP is allowed to be used for the auto-bind feature.
When the vprn-auto-bind command is set to exclude, the associated LSP is not used by the auto-bind feature within VPRN services.
The no form of this command reverts to the default value.
Default
vprn-auto-bind include
Parameters
- include
Keyword to allow an associated LSP to be used by auto-bind for VPRN services.
- exclude
Keyword to prevent the associated LSP from being used with the auto-bind feature for VPRN services.
lsp-template
Syntax
lsp-template template-name p2mp
no lsp-template template-name
Context
config>router>mpls
Platforms
7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (network mode), and 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode)
Description
This command creates a template that can be referenced by a client application where dynamic LSP creation is required. The LSP template type p2mp is mandatory.
The lsp-template command is only supported with NG-MVPN. This command is not supported for other applications.
The no form of this command deletes the LSP template. An LSP template cannot be deleted if a client application is using it.
Parameters
- template-name
Specifies the name of the LSP template, up to 32 characters. An LSP template name and LSP name must not be the same.
- p2mp
Mandatory keyword to configure P2MP as the LSP type that this template will signal.
default-path
Syntax
default-path path-name
Context
config>router>mpls>lsp-template
Platforms
7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (network mode), and 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC mode)
Description
A default path binding must be provided before the LSP template can be used for signaling LSP. The LSP template must be shut down to modify default-path binding.
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
Parameters
- path-name
Specifies the default path binding, up to 32 characters.
Primary and secondary path commands
primary
Syntax
primary path-name
no primary
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures a preferred path for the LSP. This command is optional only if the secondary path name is included in the LSP definition. Only one primary path can be defined for an LSP.
Some of the attributes of the LSP, such as the bandwidth and hop limit, can be optionally specified as the attributes of the primary path. The attributes specified in the primary path-name command override the LSP attributes.
The no form of this command deletes the association of this path-name from the lsp lsp-name. All configurations specific to this primary path, such as record, bandwidth, and hop limit, are deleted. The primary path must be shut down to delete it. The no primary command will not result in any action except a warning message on the console indicating that the primary path is administratively up.
Parameters
- path-name
Specifies the case-sensitive alphanumeric name label for the LSP path, up to 32 characters in length.
secondary
Syntax
[no] secondary path-name
Context
config>router>mpls>lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures an alternative path that the LSP uses if the primary path is not available. This command is optional and is not required if the config router mpls lsp lsp-name primary path-name command is specified. After the switch over from the primary to the secondary path, the software continuously tries to revert to the primary path. The switch back to the primary path is based on the retry-timer interval.
Up to eight secondary paths can be specified. All the secondary paths are considered equal and the first available path is used. The software will not switch back among secondary paths.
Software starts the signaling of all non-standby secondary paths at the same time. Retry counters are maintained for each unsuccessful attempt. Once the retry limit is reached on a path, software will not attempt to signal the path and administratively shuts down the path. The first successfully established path is made the active path for the LSP.
The no form of this command removes the association between this path-name and lsp-name. All specific configurations for this association are deleted. The secondary path must be shut down first to delete it. The no secondary path-name command will not result in any action except a warning message on the console indicating that the secondary path is administratively up.
Parameters
- path-name
Specifies the case-sensitive alphanumeric name label for the LSP path, up to 32 characters in length.
adaptive
Syntax
[no] adaptive
Context
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the make-before-break functionality for an LSP or a primary or secondary LSP path. When enabled for the LSP, make-before-break is performed for the primary path and all the secondary paths of the LSP.
Default
adaptive
working-tp-path
Syntax
[no] working-tp-path
Context
config>router>mpls>lsp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures or edits the working path for an MPLS-TP LSP. At least one working path (but not more than one working path) must be created for an MPLS-TP LSP. If MPLS-TP linear protection is also configured, this is the path that is used as the default working path for the LSP, and it must be created before the protect path. The working-tp-path can only be deleted if no protect-tp-path exists for the LSP.
The following commands are applicable to the working-tp-path: lsp-num, in-label, out-label, mep, shutdown.
Default
no working-tp-path
protect-tp-path
Syntax
[no] protect-tp-path
Context
config>router>mpls>lsp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures or edits the protect path for an MPLS-TP LSP. At least one working path must exist before a protect path can be created for an MPLS-TP LSP. If MPLS-TP linear protection is also configured, this is the path that is used as the default protect path for the LSP. The protect path must be deleted before the working path. Only one protect path can be created for each MPLS-TP LSP.
The following commands are applicable to the working-tp-path: lsp-num, in-label, out-label, mep, and shutdown.
lsp-num
Syntax
lsp-num lsp-num
no lsp-num
Context
config>router>mpls>lsp>working-tp-path
config>router>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the MPLS-TP LSP number for the working TP path or the protect TP path.
Default
no lsp-num
Parameters
- lsp-num
Specifies the LSP number.
in-label
Syntax
in-label in-label
Context
config>router>mpls>lsp>working-tp-path
config>router>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the incoming label for the reverse path, working path, or protect path of an MPLS-TP LSP. MPLS-TP LSPs are bidirectional, and so an incoming label value must be specified for each path.
Default
no in-label
Parameters
- in-label
Specifies the in label.
out-label
Syntax
out-label out-label out-link if-name [next-hop ip-address]
no out-label
Context
config>router>mpls>lsp>working-tp-path
config>router>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command configures the outgoing label value to use for an MPLS-TP working or protect path. The out-link is the outgoing interface on the node that this path will use, and must be specified. If the out-link refers to a numbered IP interface, the user may optionally configure the next-hop parameter and the system will determine the interface to use to reach the configured next-hop, but will check that the user-entered value for the out-link corresponds to the link returned by the system. If they do not correspond, the path will not come up.
Default
no out-label
Parameters
- out-label
Specifies the out label.
- if-name
Specifies the interface name.
- ip-address
Specifies the IPv4 address in a.b.c.d.
mep
Syntax
[no] mep
Context
config>router>mpls>lsp>working-tp-path
config>router>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command creates or edits an MPLS-TP maintenance entity group (MEG) endpoint (MEP) on an MPLS-TP path. MEPs represent the termination point for OAM flowing on the path, as well as linear protection for the LSP. Only one MEP can be configured at each end of the path.
The following commands are applicable to a MEP on an MPLS-TP working or protect path: oam-template, bfd-enable, and shutdown. In addition, a protection-template may be configured on a protect path.
The no form of this command removes a MEP from an MPLS-TP path.
oam-template
Syntax
oam-template name
no oam-template
Context
config>router>mpls>lsp>working-tp-path
config>router>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command applies an OAM template to an MPLS-TP working or protect path. It contains configuration parameters for proactive OAM mechanisms that can be enabled on the path, for example, BFD. Configuration of an OAM template is optional.
The no form of this command removes the OAM template from the path.
Default
no oam-template
Parameters
- name
Specifies a text string name for the template up to 32 characters in printable 7-bit ASCII, enclosed in double quotes.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>lsp>working-tp-path>mep
config>router>mpls>lsp>protect-tp-path>mep config>router>mpls>lsp>working-tp-path
config>router>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command disables the existing LSP, including the primary path and any standby secondary paths.
To shut down only the primary path, enter the config router mpls lsp lsp-name primary path-name shutdown command.
To shut down a specific standby secondary path, enter the config router mpls lsp lsp-name secondary path-name shutdown command. The existing configuration of the LSP is preserved.
The no form of this command restarts the LSP. LSPs are created in a shutdown state. Use this command to administratively bring up the LSP.
Default
shutdown
bfd-enable
Syntax
bfd-enable bfd-mode
no bfd-enable
Context
config>router>mpls>lsp>working-tp-path>mep
config>router>mpls>lsp>protect-tp-path>mep
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command associates the operational state of an MPLS-TP path with a BFD session for which control packets flow on the path. The BFD packets are encapsulated in a generic associated channel (G-ACh) on the path. The timer parameters of the BFD session are taken from the OAM template of the MEP.
A value of cc means that the BFD session is only used for continuity check of the MPLS-TP path. In this case, the cc timer parameters of the OAM template apply. A value of cc_cv means that the BFD session is used for both continuity checking and connectivity verification, and the cc_cv timers of the OAM template apply.
This form of this bfd-enable command is only applicable when it is configured under a MEP used on an MPLS-TP working or protect path.
Default
no bfd-enable
Parameters
- bfd-mode
Specifies the BFD mode.
protection-template
Syntax
protection-template name
no protection-template
Context
config>mpls>lsp>protect-tp-path
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command applies a protection template name to an MPLS-TP LSP under which the protect path is configured. If the template is applied, MPLS-TP 1:1 linear protection is enabled on the LSP using the parameters specified in the named template.
A named protection template can only be applied to the protect path context of an MPLS-TP LSP.
The no form of this command removes the template and disables MPLS-TP linear protection on the LSP.
Default
no protection-template
Parameters
- name
Specifies at text string for the template, up to 32 characters in printable 7-bit ASCII, enclosed in double quotes.
bandwidth
Syntax
bandwidth rate-in-mbps
no bandwidth
Context
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the amount of bandwidth to be reserved for the LSP path.
The no form of this command resets bandwidth parameters (no bandwidth is reserved). This is the bandwidth setting in the global LSP configuration.
Default
no bandwidth
Parameters
- rate-in-mbps
Specifies the amount of bandwidth reserved for the LSP path in Mbps.
exclude
Syntax
[no] exclude group-name [group-name...(up to 5 max)]
Context
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the admin groups to be excluded when an LSP is set up. Up to five groups per operation can be specified, up to 32 maximum. The admin groups are defined in the config>router>if-attribute context.
The no form of this command removes the exclude command.
Default
no exclude
Parameters
- group-name
Specifies the existing group name to be excluded when an LSP is set up.
hop-limit
Syntax
hop-limit number
no hop-limit
Context
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This optional command overrides the config router mpls lsp lsp-name hop-limit command. This command specifies the total number of hops that an LSP traverses, including the ingress and egress routers.
This value can be changed dynamically for an LSP that is already set up with the following implications.
If the new value is less than the current hops of the established LSP, the LSP is brought down. MPLS then tries to re-establish the LSP within the new hop limit number. If the new value is equal to or more than the current hops of the established LSP, the LSP will be unaffected.
The no form of this command reverts to the default values defined using the config router mpls lsp lsp-name hop-limit command.
Default
no hop-limit
Parameters
- number
Specifies the number of hops the LSP can traverse, expressed as an integer.
path-preference
Syntax
[no] path-preference value
Context
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of path preference among configured standby secondary paths for each LSP. If all standby secondary paths have a default path preference value, a non-standby secondary path remains an active path, while a standby secondary is available. A standby secondary path configured with highest priority (lowest path preference value) must be made the active path when the primary path is not in use. Path preference can be configured on standby secondary path.
The no form of this command resets the path preference to the default value.
Default
path-preference 255
Parameters
- value
Specifies an alternate path for the LSP if the primary path is not available.
record
Syntax
[no] record
Context
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command enables recording of all hops that an LSP path traverses. Enabling record increases the size of the PATH and RESV refresh messages for the LSP because this information is carried end-to-end along the LSP path. The increase in control traffic for each LSP may impact scalability.
The no form of this command disables the recording of all hops for a specific LSP. There are no restrictions for the no command usage.
The no form of this command also disables the record-label command.
Default
record
record-label
Syntax
[no] record-label
Context
config>router>mpls>lsp>primary
config>router>mpls>lsp>secondary
config>router>mpls>lsp-template
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The config>router>mpls>lsp-template context is only supported on the 7210 SAS-Mxp, 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-T (operating in network mode), and 7210 SAS-Sx/S 1/10GE (operating in standalone and standalone-VC mode).
In the lsp-template context, this command is only supported with NG-MVPN. It is not supported with other applications.
This command enables recording of all labels at each node that an LSP path traverses. Enabling the record-label command also enables the record command if it is not already enabled.
The no form of this command disables the recording of hops that an LSP path traverses.
Default
record-label
srlg
Syntax
[no] srlg
Context
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of the SRLG constraint in the computation of a secondary path for an LSP at the head-end LER. When this feature is enabled, CSPF includes the SRLG constraint in the computation of the secondary LSP path.
CSPF requires that the primary LSP be established already and in the up state, because the head-end LER needs the most current ERO computed by CSPF for the primary path and CSPF includes the list of SRLGs in the ERO during the CSPF computation of the primary path. At a subsequent establishment of a secondary path with the SRLG constraint, the MPLS/RSVP task queries CSPF again, which provides the list of SLRG group numbers to be avoided. CSPF prunes all links with interfaces that belong to the same SRLGs as the interfaces included in the ERO of the primary path. If CSPF finds a path, the secondary is setup. If CSPF does not find a path, MPLS/RSVP keeps retrying the requests to CSPF.
If CSPF is not enabled on the LSP (using the lsp lsp-name cspf command), a secondary path of that LSP that includes the SRLG constraint is shut down and a specific failure code indicates the exact reason for the failure in the show>router>mpls>lsp path detail output.
At initial primary LSP path establishment, if primary does not come up or is not configured, the SRLG secondary is not signaled and is put in the down state. A specific failure code indicates the exact reason for the failure in the show>router>mpls>lsp path detail output. However, if a non-SRLG secondary path was configured, such as a secondary path with the SRLG option disabled, the MPLS/RSVP task signals it and the LSP uses it.
As soon as the primary path is configured and successfully established, MPLS/RSVP moves the LSP to the primary path and signals all SRLG secondary paths.
Any time the primary path is reoptimized, has undergone MBB operation, or has come back up after being down, the MPLS/RSVP task checks with CSPF to determine if the SRLG secondary path should be resignaled. If the MPLS/RSVP task finds that the current secondary path is no longer SRLG disjoint — for example, the path became ineligible — it puts the path on a delayed MBB immediately after the expiry of the retry timer. If MBB fails on the first try, the secondary path is torn down and the path is put on retry.
At the next opportunity that the primary goes down, the LSP uses an eligible SRLG secondary path if the path is in the up state. If all secondary eligible SLRG paths are in the down state, MPLS/RSVP uses a non-SRLG secondary path if the path is configured and in the up state. If, while the LSP is using a non-SRLG secondary path, an eligible SRLG secondary path comes back up, MPLS/RSVP will not switch the path of the LSP to it. As soon as the primary path is resignaled and comes up with a new SLRG list, MPLS/RSVP resignals the secondary path using the new SRLG list.
A secondary path that becomes ineligible as a result of an update to the SRLG membership list of the primary path will have the ineligibility status removed when any of the following events occur.
A successful MBB operation of the standby SRLG path occurs, making the path eligible again.
The standby path goes down, in which case MPLS/RSVP puts the standby on retry when the retry timer expires. If successful, it becomes eligible. If not successful after the retry-timer expires or the number of retries reaches the number configured under the retry-limit parameter, it is left down.
The primary path goes down, in which case the ineligible secondary path is immediately torn down and will only be resignaled when the primary path comes back up with a new SRLG list.
After the primary path of the LSP is set up and is operationally up, any subsequent changes to the SRLG group membership of an interface that the primary path is using is not considered until the next opportunity that the primary path is resignaled. The primary path may be resignaled because of a failure or to a make-before-break operation. A make-before-break operation occurs as a result of a global revertive operation, a timer-based or manual re-optimization of the LSP path, or a change by a user to any of the path constraints.
After an SRLG secondary path is setup and is operationally up, any subsequent changes to the SRLG group membership of an interface that the secondary path is using is not considered until the next opportunity that the secondary path is resignaled. The secondary path is resignaled because of a failure, to a resignaling of the primary path, or to a make-before-break operation. A make-before break operation occurs as a result of a timer-based or manual reoptimization of the secondary path, or an operator change to any of the path constraints of the secondary path, including enabling or disabling the SRLG constraint itself.
In addition, the user-configured include or exclude admin group statements for this secondary path are also checked along with the SRLG constraints by CSPF.
The no form of this command reverts to the default value.
Default
no srlg
standby
Syntax
[no] standby
Context
config>router>mpls>lsp>secondary
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
The secondary path LSP is normally signaled when the primary path LSP fails. The standby keyword ensures that the secondary path LSP is signaled and maintained indefinitely in a hot-standby state. When the primary path is re-established, the traffic is switched back to the primary path LSP.
The no form of this command specifies that the secondary LSP is signaled when the primary path LSP fails.
LSP path commands
hop
Syntax
hop hop-index ip-address {strict | loose}
no hop hop-index
Context
config>router>mpls>path
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the IP address of the hops that the LSP should traverse on its way to the egress router. The IP address can be the interface IP address or the system IP address. If the system IP address is specified, the LSP can choose the best available interface.
Optionally, the LSP ingress and egress IP address can be included as the first and last hop. A hop list can include the ingress interface IP address, system IP address, and egress IP address of any of the hops being specified.
The no form of this command deletes hop list entries for the path. All LSPs currently using this path are affected. Additionally, all services actively using these LSPs are affected. The path must be shut down to delete the hop from the hop list. The no hop hop-index command will not result in any action except a warning message on the console indicating that the path is administratively up.
Parameters
- hop-index
Specifies the hop index used to order the hops specified. The LSP always traverses from the lowest hop index to the highest. The hop index does not need to be sequential.
- ip-address
Specifies the system or network interface IP address of the transit router. The IP address can be the interface IP address or the system IP address. If the system IP address is specified, the LSP can choose the best available interface. A hop list can also include the ingress interface IP address, system IP address, and egress IP address of any of the specified hops.
- loose
Keyword to specify that the route taken by the LSP from the previous hop to this hop can traverse through other routers. Multiple hop entries with the same IP address are flagged as errors. Either the loose or strict keyword must be specified.
- strict
Keyword to specify that the LSP must take a direct path from the previous hop router to this router. No transit routers between the previous router and this router are allowed. If the IP address specified is the interface address, that is the interface the LSP must use. If there are direct parallel links between the previous router and this router and if the system IP address is specified, any one of the available interfaces can be used by the LSP. The user must ensure that the previous router and this router have a direct link. Multiple hop entries with the same IP address are flagged as errors. Either the loose or strict keyword must be specified.
path
Syntax
[no] path path-name
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the path to be used for an LSP. A path can be used by multiple LSPs. A path can specify some or all hops from ingress to egress, and they can be either strict or loose. A path can also be empty (no path-name specified), in which case the LSP is set up based on the IGP (best effort) calculated shortest path to the egress router. Paths are created in a shutdown state. A path must be shut down before making any changes (adding or deleting hops) to the path. When a path is in the shutdown state, any LSP using the path becomes operationally down.
To create a strict path from the ingress to the egress router, the ingress and the egress routers must be included in the path statement.
The no form of this command deletes the path and all its associated configuration information. All the LSPs that are currently using this path will be affected. Additionally, all services that are actively using these LSPs will be affected. A path must be shutdown and unbound from all LSPs using the path before it can be deleted. The no path path-name command will not result in any action except a warning message on the console indicating that the path may be in use.
Parameters
- path-name
Specifies a unique case-sensitive alphanumeric name label for the LSP path up to 32 characters in length.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>path
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command disables the existing LSPs using this path. All services using these LSPs are affected. Binding information, however, is retained in those LSPs. Paths are created in the shutdown state.
The no form of this command administratively enables the path. All LSPs, where this path is defined as primary or defined as standby secondary, are established or re-established.
Default
shutdown
Static LSP commands
static-lsp
Syntax
[no] static-lsp lsp-name
Context
config>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures a static LSP on the ingress router. The static LSP is a manually set up LSP where the next-hop IP address and the outgoing label (push) must be specified.
The no form of this command deletes this static LSP and associated information.
The LSP must be shut down to delete it. If the LSP is not shut down, the no static-lsp lsp-name command does nothing except generate a warning message on the console indicating that the LSP is administratively up.
Parameters
- lsp-name
Specifies the name that identifies the LSP, up to 32 characters.
push
Syntax
push label nexthop ip-address
no push label
Context
config>router>mpls>static-lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the label to be pushed on the label stack and the next-hop IP address for the static LSP.
The no form of this command removes the association of the label to push for the static LSP.
Parameters
- label
Specifies the label to push on the label stack. Label values 16 through 1,048,575 are defined as follows:
Label values 16 through 31 are reserved for the system.
Label values 32 through 1,023 are available for static assignment.
Label values 1,024 through 2,047 are reserved for future use.
Label values 2,048 through 18,431 are statically assigned for services.
Label values 28,672 through 131,071 are dynamically assigned for both MPLS and services.
Label values 131,072 through 1,048,575 are reserved for future use.
- nexthop ip-address
Specifies the IP address of the next hop toward the LSP egress router. If an ARP entry for the next hop exists, the static LSP is marked operational. If an ARP entry does not exist, the software sets the operational status of the static LSP to down and continues the ARP for the configured next hop. The Software continuously tries the ARP for the configured next hop at a fixed interval.
shutdown
Syntax
[no] shutdown
Context
config>router>mpls>static-lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command administratively disables the static LSP.
The no form of this command administratively enables the static LSP.
Default
shutdown
to
Syntax
to ip-address
Context
config>router>mpls>static-lsp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the system IP address of the egress router for the static LSP. When creating an LSP, this command is required. For LSPs that are used as transport tunnels for services, the to IP address must be the system IP address.
Parameters
- ip-address
Specifies the system IP address of the egress router.
RSVP configuration commands
Generic commands
shutdown
Syntax
[no] shutdown
Context
config>router>rsvp
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command disables the RSVP protocol instance or the RSVP-related functions for the interface. The RSVP configuration information associated with this interface is retained. When RSVP is administratively disabled, all RSVP sessions are torn down. The existing configuration is retained.
The no form of this command administratively enables RSVP on the interface.
Default
shutdown
Special Cases
- RSVP Protocol Handling on the 7210 SAS-Mxp
When the no shutdown command is issued in the configure>router>rsvp context, resources are allocated to enable the node to process the protocol. When the configure>router>rsvp>shutdown command is issued, the resources are deallocated.
RSVP commands
rsvp
Syntax
[no] rsvp
Context
config>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
Commands in this context configure RSVP protocol parameters. RSVP is not enabled by default and must be explicitly enabled (no shutdown).
RSVP is used to set up LSPs. RSVP should be enabled on all router interfaces that participate in signaled LSPs.
The no form of this command deletes this RSVP protocol instance and removes all configuration parameters for this RSVP instance. To suspend the execution and maintain the existing configuration, use the shutdown command. RSVP must be shut down before the RSVP instance can be deleted. If RSVP is not shut down, the no rsvp command does nothing except issue a warning message on the console indicating that RSVP is still administratively enabled.
Default
no shutdown
graceful-shutdown
Syntax
[no] graceful-shutdown
Context
config>router>rsvp
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command initiates a graceful shutdown of the specified RSVP interface or all RSVP interfaces on the node if applied at the RSVP level. These are referred to as maintenance interface and maintenance node, respectively.
To initiate a graceful shutdown the maintenance node generates a PathErr message with a specific error sub-code of Local Maintenance on TE Link required for each LSP that is exiting the maintenance interface.
The node performs a single make-before-break attempt for all adaptive CSPF LSPs it originates and LSP paths using the maintenance interfaces. If an alternative path for an affected LSP is not found, the LSP is maintained on its current path. The maintenance node also tears down and re-signals any detour LSP path using listed maintenance interfaces as soon as they are not active.
The maintenance node floods an IGP TE LSA/LSP containing Link TLV for the links under graceful shutdown with the traffic engineering metric set to 0xffffffff and unreserved bandwidth parameter set to zero (0).
After receiving the PathErr message, ahead-end LER node performs a single make-before-break attempt on the affected adaptive CSPF LSP. If an alternative path is not found, the LSP is maintained on its current path.
A node does not take any action on the paths of the following originating LSPs after receiving the PathErr message:
an adaptive CSPF LSP for which the PathErr indicates a node address in the address list and the node corresponds to the destination of the LSP; in this case, no alternative paths can be found
an adaptive CSPF LSP for which the path has explicit hops defined using the listed maintenance interfaces or nodes
a CSPF LSP with the adaptive option disabled and for which the current path is over the listed maintenance interfaces in the PathErr message; these are not subject to make-before-break
a non-CSPF LSP for which the current path is over the listed maintenance interfaces in the PathErr message
After receiving the updated IPG TE LSA/LSP for the maintenance interfaces, the head-end LER node updates the TE database. This information is used at the next scheduled CSPF computation for any LSP for which the path may traverse any of the maintenance interfaces.
The no form of this command disables the graceful shutdown operation at the RSVP interface level or at the RSVP level. The configured TE parameters of the maintenance links are restored and the maintenance node floods the links.
keep-multiplier
Syntax
keep-multiplier number
no keep-multiplier
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the keep multiplier number. The keep-multiplier number is an integer used by RSVP to declare that a reservation is down or the neighbor is down.
The no form of this command reverts to the default value.
Default
keep-multiplier 3
Parameters
- number
Specifies the keep multiplier value.
node-id-in-rro
Syntax
node-id-in-rro [include | exclude]
Context
config>router>rsvp
Platforms
7210 SAS-Mxp
Description
This command enables the option to include the node ID sub-object in the RRO. Propagation of the node ID sub-object is required to provide fast reroute protection for an LSP that spans multiple area domains.
If this option is disabled, the node ID is not included in the RRO object.
Default
node-id-in-rro exclude
Parameters
- include
Keyword to include the node ID sub-object in the RRO.
- exclude
Keyword to exclude the node ID sub-object in the RRO.
refresh-reduction-over-bypass
Syntax
refresh-reduction-over-bypass [enable | disable]
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the refresh reduction capabilities over all bypass tunnels originating on this 7210 SAS PLR node or terminating on this 7210 SAS Merge Point (MP) node.
By default, this is disabled. Because a bypass tunnel may merge with the primary LSP path in a node downstream of the next hop, there is no direct interface between the PLR and the MP node, and it is possible the latter will not accept summary refresh messages received over the bypass.
When disabled, the node as a PLR or MP will not set the ‟Refresh-Reduction-Capable” bit on RSVP messages pertaining to LSP paths tunneled over the bypass. It will also not send the Message-ID in RSVP messages. This disables summary refresh.
Default
disable
Parameters
- enable
Keyword to enable refresh reduction capabilities.
- disable
Keyword to disable refresh reduction capabilities.
rapid-retransmit-time
Syntax
rapid-retransmit-time hundred-milliseconds
no rapid-retransmit-time
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command is used to define the value of the rapid retransmission interval. This is used in the retransmission mechanism based on the exponential back-off timer to handle unacknowledged message_id objects.
The RSVP message with the same message ID is retransmitted every 2 ✕ rapid-retransmit-interval.
The node stops re transmission of unacknowledged RSVP messages whenever the updated back-off interval exceeds the value of the regular refresh interval or the number of retransmissions reaches the value of the rapid-retry-limit parameter, whichever comes first.
The rapid retransmission interval must be smaller than the regular refresh interval configured in config>router>rsvp>refresh-time.
The no form of this command reverts to the default value.
Default
rapid-retransmit-time 5
Parameters
- hundred-milliseconds
Specifies the rapid retransmission interval, in units of 100 milliseconds.
rapid-retry-limit
Syntax
rapid-retry-limit limit
no rapid-retry-limit
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the value of the rapid retry limit. This is used in the retransmission mechanism based on an exponential backoff timer to handle unacknowledged message_id objects. The RSVP message with the same message_id is retransmitted every 2 ✕ rapid-retransmit-time interval of time. The node stops retransmission of unacknowledged RSVP messages whenever the updated backoff interval exceeds the value of the regular refresh interval or the number of retransmissions reaches the value of the rapid-retry-limit parameter, whichever comes first.
The no form of this command reverts to the default value.
Default
rapid-retry-limit 3
Parameters
- limit
Specifies the value of the rapid retry limit, expressed as an integer value.
refresh-time
Syntax
refresh-time seconds
no refresh-time
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command controls the interval, in seconds, between the successive Path and Resv refresh messages. RSVP declares the session down after it misses keep-multiplier number consecutive refresh messages.
The no form of this command reverts to the default value.
Default
refresh-time 30
Parameters
- seconds
Specifies the refresh time in seconds.
Interface commands
interface
Syntax
[no] interface ip-int-name
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables RSVP protocol support on an IP interface. No RSVP commands are executed on an IP interface where RSVP is not enabled.
The no form of this command deletes all RSVP commands such as hello-interval and subscription, which are defined for the interface. The RSVP interface must be shutdown before it can be deleted. If the interface is not shut down, the no interface ip-int-name command does nothing except issue a warning message on the console indicating that the interface is administratively up.
Default
shutdown
Parameters
- ip-int-name
Specifies the name of the network IP interface, up to 32 characters. An interface name cannot be in the form of an IP address. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
authentication-key
Syntax
authentication-key [authentication-key | hash-key] [hash | hash2]
no authentication-key
Context
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command specifies the authentication key to be used between RSVP neighbors to authenticate RSVP messages. Authentication uses the MD-5 message-based digest.
When enabled on an RSVP interface, authentication of RSVP messages operates in both directions of the interface.
A node maintains a security association using one authentication key for each interface to a neighbor. The following items are stored in the context of this security association:
HMAC-MD5 authentication algorithm
key used with the authentication algorithm
lifetime of the key (the user-entered key is valid until the user deletes it from the interface)
source address of the sending system
latest sending sequence number used with this key identifier
An RSVP sender transmits an authenticating digest of the RSVP message, computed using the shared authentication key and a keyed-hash algorithm. The message digest is included in an integrity object, which also contains a flags field, a key identifier field, and a sequence number field. The RSVP sender complies to the procedures for RSVP message generation as described in RFC 2747, RSVP Cryptographic Authentication.
An RSVP receiver uses the key together with the authentication algorithm to process received RSVP messages.
The MD5 implementation does not support the authentication challenge procedures as described in RFC 2747.
The no form of this command disables authentication.
Default
no authentication-key
Parameters
- authentication-key
Specifies the authentication key. The key can be any combination of ASCII characters up to 16 characters in length (unencrypted). If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- hash-key
Specifies the hash key. The key can be any combination of up 33 alphanumeric characters. If spaces are used in the string, enclose the entire string in quotation marks (‟ ”).
This is useful when a user must configure the parameter, but for security purposes, the actual unencrypted key value is not provided.
- hash
Keyword to specify that the key is entered in an encrypted form. If the hash parameter is not used, the key is assumed to be in a non-encrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash parameter specified.
- hash2
Keyword to specify that the key is entered in a more complex encrypted form. If the hash2 parameter is not used, the less encrypted hash form is assumed.
bfd-enable
Syntax
[no] bfd-enable
Context
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of bidirectional forwarding (BFD) to control the state of the associated RSVP interface. This causes RSVP to register the interface with the BFD session on that interface.
The user configures the BFD session parameters, such as transmit-interval, receive-interval, and multiplier, under the IP interface in the config>router>interface>bfd context.
The BFD session on the interface might already have been started because of a prior registration with another protocol; for example, OSPF or IS-IS.
The registration of an RSVP interface with BFD is performed when a neighbor gets its first session, which means registration occurs when this node sends or receives a new Path message over the interface. However, if the session did not come up because the session did not recieve a RESV for a new Path message sent after the maximum number of retries, the LSP is shut down and the node deregisters with BFD. In general, the registration of RSVP with BFD is removed as soon as the last RSVP session is cleared.
The registration of an RSVP interface with BFD is performed independently of whether RSVP hello is enabled on the interface or not. However, hello timeout clears all sessions toward the neighbor and RSVP deregisters with BFD at the clearing of the last session.
An RSVP session is associated with a neighbor based on the interface address the Path message is sent to. If multiple interfaces exist to the same node, each interface is treated as a separate RSVP neighbor. The user must enable BFD on each interface, and RSVP will register with the BFD session running with each of those neighbors independently.
Similarly, disabling BFD on the interface results in removing registration of the interface with BFD.
When a BFD session transitions to the down state, the following actions are triggered. For RSVP signaled LSPs, this triggers activation of FRR bypass or detour backup LSPs (PLR role), global revertive (head-end role), and switchover to secondary (if any) (head-end role) for affected LSPs with FRR enabled. It triggers a switchover to secondary (if any) and scheduling of retries for signaling the primary path of the non-FRR affected LSPs (head-end role).
The no form of this command removes BFD from the associated RSVP protocol adjacency.
Default
no bfd-enable
hello-interval
Syntax
hello-interval milli-seconds
no hello-interval
Context
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the time interval between RSVP hello messages.
RSVP hello packets are used to detect loss of RSVP connectivity with the neighboring node. Hello packets detect the loss of a neighbor more quickly than it would take for the RSVP session to time out based on the refresh interval. After the loss of the keep-multiplier number consecutive hello packets, the neighbor is declared to be in a down state.
The no form of this command reverts to the default value of the hello-interval. To disable sending hello messages, set the value to zero.
Default
hello-interval 3000
Parameters
- milli-seconds
Specifies the RSVP hello interval in milliseconds, in multiples of 1000. A value of 0 (zero) disables the sending of RSVP hello messages.
implicit-null-label
Syntax
implicit-null-label [enable | disable]
no implicit-null-label
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables or disables the use of the implicit null label for all LSPs.
All LSPs for which this node is the egress LER and for which the path message is received from the previous hop node over this RSVP interface will signal the implicit null label. This means that if the egress LER is also the merge-point (MP) node, the incoming interface for the path refresh message over the bypass dictates if the packet uses the implicit null label or not. The same applies for a 1-to-1 detour LSP.
The user must shut down the RSVP interface before being able to change the implicit null configuration option.
The no form of this command resets the interface to the RSVP level configuration.
Default
implicit-null disable
Parameters
- enable
Keyword to enable the implicit null label.
- disable
Keyword to disable the implicit null label.
refresh-reduction
Syntax
[no] refresh-reduction
Context
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables the use of the RSVP overhead refresh reduction capabilities on this RSVP interface.
The 7210 SAS node accepts bundle RSVP messages from its peer over the interface, performs reliable RSVP message delivery to its peer, and uses summary refresh messages to refresh the path and resv states. Reliable message delivery must be explicitly enabled by the user after refresh reduction is enabled.
The other two capabilities are immediately enabled.
A bundle message reduces the overall message handling load; it consists of a bundle header followed by one or more bundle sub-messages. A bundle sub-message is any RSVP message other than a bundle message. A 7210 SAS node only processes the bundled RSVP messages received and does not generate them.
When reliable message delivery is supported by both the node and its peer over the RSVP interface, an RSVP message is sent with a message_id object. A message_id object can be added to any RSVP message, or it can be a sub-message of a bundled message.
If a node sets the ack_desired flag in the message_id object, the receiver acknowledges the receipt of the RSVP message by piggy-backing a message_ack object in the next RSVP message it sends to the node. Alternatively, an ACK message can also be used to send the message_ack object. In both cases, more than one message_ack object can be included in the same message.
The 7210 SAS supports only the use of ACK messages to send a message_ack object, but it can also process the received message_ack objects piggy-backed to hop-by-hop RSVP messages, such as Path and RESV.
The 7210 SAS sets the ack_desired flag only in non-refresh RSVP messages and in refresh messages that contain new state information.
A retransmission mechanism based on an exponential backoff timer is supported to handle unacknowledged message_id objects. An RSVP message with the same message_id is re-transmitted every 2✕ rapid-retransmit-time interval. The rapid-retransmit-time is referred to as the rapid retransmission interval because it must be smaller than the regular refresh interval configured in the config>router>rsvp>refresh-time context.
The rapid retry limit indicates the maximum number of retransmissions allowed for unacknowledged RSVP messages. The node stops the retransmission of unacknowledged RSVP messages when:
the updated backoff interval exceeds the regular refresh interval
the number of retransmissions reaches the value of the rapid-retry-limit parameter, whichever comes first
These two parameters can be configured on a system in the config>router>rsvp context.
Summary refresh consists of sending a summary refresh messages containing message_id list objects. The fields of the message_id list object are populated with the values from the message_identifier field in the message_id object of a previously sent individual Path or RESV message. The summary refresh message is sent per refresh regular interval. The interval is configured by the user using the refresh-time command in the config>router>rsvp context. The receiver checks each message_id object against the saved Path and RESV states. If a match is found the state is updated. If any message_identifier field does not match, the node sends a message_id_nack object to the originator of the message.
The preceding capabilities are collectively referred to as ‟refresh overhead reduction extensions”. When refresh-reduction is enabled on an RSVP interface, the node sets a ‟refresh-reduction-capable” bit in the flag field of the common RSVP header. If both peers on a RSVP interface set the ‟refresh-reduction-capable” bit, all the refresh overhead reduction extensions can be implemented. The node monitors the bit in all the RSVP messages received from the peer. The router stops sending summary refresh messages after the bit is cleared. the node does not send summary refresh messages if the bit is not set by the peer.
A node (with refresh reduction and reliable message delivery enabled) attempts to perform reliable message delivery even if the ‟refresh-reduction-capable” bit is not set by the peer. If the peer does not support the message_id object, it returns the ‟unknown object class” error message. The node retransmits the RSVP message without the message_id object and adopts the same message handling method for all future messages sent to the peer.
The no form of this command reverts to the default value.
Default
no refresh-reduction
reliable-delivery
Syntax
[no] reliable-delivery
Context
config>router>rsvp>interface>refresh-reduction
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables reliable delivery of RSVP messages over the RSVP interface. When refresh-reduction is enabled on an interface and reliable-delivery is disabled, the router sends a message_id and not set ACK desired in the RSVP messages over the interface. Consequently, the 7210 SAS does not expect an ACK, but will accept it if received. The node also accepts message ID and reply with an ACK when requested. In this case, if the neighbor sets the ‟refresh-reduction-capable” bit in the flags field of the common RSVP header, the node enters summary refresh for a specific message_id it sent regardless of whether it received an ACK or not to this message from the neighbor.
When the reliable-delivery option is enabled on any interface, RSVP message pacing is disabled on all RSVP interfaces of the system, for example, the user cannot enable the msg-pacing option in the config>router>rsvp context, and an error message is returned in the CLI. Conversely, when the msg-pacing option is enabled, the user cannot enable the reliable-delivery option on any interface on this system. An error message is generated in the CLI after such an attempt.
The no form of this command reverts to the default value.
Default
no reliable-delivery
subscription
Syntax
subscription percentage
no subscription
Context
config>router>rsvp>interface
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the percentage of the link bandwidth that RSVP can use for reservation and sets a limit for the amount of over-subscription or under-subscription allowed on the interface.
When the subscription command is set to zero, no new sessions are permitted on this interface. If the percentage value is exceeded, the reservation is rejected and a log message is generated.
The no form of this command reverts the percentage to the default value.
Default
subscription 100
Parameters
- percentage
Specifies the percentage of the interface bandwidth that RSVP allows to be used for reservations.
Message pacing commands
msg-pacing
Syntax
[no] msg-pacing
Context
config>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables RSVP message pacing for which the specified number of RSVP messages, specified in the max-burst command, are sent in a configured interval, specified in the period command. A count is kept of the messages that were dropped because the output queue for the interface used for message pacing was full.
Default
no msg-pacing
max-burst
Syntax
max-burst number
no max-burst
Context
config>router>rsvp>msg-pacing
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the maximum number of RSVP messages that are sent in the specified period under normal operating conditions.
The no form of this command reverts to the default value.
Default
max-burst 650
Parameters
- number
Specifies the maximum number of RSVP messages sent within the specified period.
period
Syntax
period milli-seconds
no period
Context
config>router>rsvp>msg-pacing
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command configures the time interval, in milliseconds, during which the router can send RSVP messages, as specified in the max-burst command.
The no form of this command reverts to the default value.
Default
period 100
Parameters
- milli-seconds
Specifies the time interval for sending RSVP messages.
Show commands
Show MPLS commands
admin-group
Syntax
admin-group group-name
Context
show>router>if-attribute
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS administrative group information.
Parameters
- group-name
Specifies a group name, up to 32 characters.
Output
The following output is an example of MPLS administrative group information, and Output fields: If-attribute admin group describes the output fields.
Sample outputA:ALA-1# show router if-attribute admin-group
=================================================
MPLS Administrative Groups
=================================================
Group Name Group Value
-------------------------------------------------
green 15
red 25
yellow 20
-------------------------------------------------
No. of Groups: 3
=================================================
A:ALA-1#
Label |
Description |
|---|---|
Group Name |
Displays the name of the group; the name identifies the administrative group within a virtual router instance |
Group Value |
Displays the unique group value associated with the administrative group. If the value displays -1, then the group value for this entry has not been set. |
No. of Groups |
Displays the total number of configured admin groups within the virtual router instance |
bypass-tunnel
Syntax
bypass-tunnel [to ip-address] [protected-lsp [lsp-name]] [dynamic | manual | p2mp] [detail]
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays information about bypass tunnels.
If fast reroute is enabled on an LSP and the facility method is selected, instead of creating a separate LSP for every LSP that is to be backed up, a single LSP is created which serves as a backup for a set of LSPs. Such an LSP tunnel is called a bypass tunnel.
Parameters
- ip-address
Specifies the IP address of the egress router.
- lsp-name
Specifies the name of the LSP protected by the bypass tunnel.
- dynamic
Keyword to display dynamically assigned labels for bypass protection.
- manual
Keyword to display manually assigned labels for bypass protection.
- p2mp
Keyword to display P2MP bypass tunnel information.
- detail
Keyword to display detailed information.
Output
The following output is an example of MPLS bypass tunnel information, and Output fields: MPLS bypass-tunnel describes the output fields.
Sample output*A:Dut-A>config>router>mpls# show>router>mpls# bypass-tunnel
*A:SRU4>show>router>mpls# bypass-tunnel
===============================================================================
MPLS Bypass Tunnels
===============================================================================
Legend : m - Manual d - Dynamic p - P2mp
===============================================================================
To State Out I/F Out Label Reserved Protected Type
BW (Kbps) LSP Count
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:SRU4>show>router>mpls#*A:Dut-A>show>router>mpls#
*A:Dut-A>config>router>mpls# show>router>mpls# bypass-tunnel detail
=======================================================================
MPLS Bypass Tunnels (Detail)
=======================================================================
-----------------------------------------------------------------------
bypass-node10.20.1.2
-----------------------------------------------------------------------
To : 10.20.1.4 State : Up
Out I/F : 1/1/2 Out Label : 131070
Up Time : 0d 00:00:18 Active Time : n/a
Reserved BW : 0 Kbps Protected LSP Count : 1
Type : Dynamic
Setup Priority : 7 Hold Priority : 0
Class Type : 0
Exclude Node : None Inter-Area : False
ComputedHops:
10.20.1.1, If Index : 2(S)
-> 10.20.1.2, If Index : 2(S)
-> 10.20.1.4, If Index : 2(S)
-> 10.20.1.6, If Index : 2(S)
Actual Hops :
10.20.1.1, If Index: 2 @ n Record Label : N/A
-> 10.20.1.2, If Index : 2 @ n Record Label : 131071
-> 10.20.1.4, If Index : 2 Record Label : 131071
-> 10.20.1.6, If Index : 2 Record Label : 131071
=======================================================================
*A:Dut-A>show>router>mpls#
Label |
Description |
|---|---|
To |
Displays the system IP address of the egress router |
State |
Dispalys the LSP administrative state |
Out I/F |
Displays the name of the network IP interface |
Out Label |
Displays the incoming MPLS label on which to match |
Reserved BW (Kbps) |
Displays the amount of bandwidth in megabits per second (Mbps) reserved for the LSP |
interface
Syntax
interface [ip-int-name | ip-address] [label-map label]
interface [ip-int-name | ip-address]
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS interface information.
Parameters
- ip-int-name
Specifies the name of the network IP interface. An interface name cannot be in the form of an IP address. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- ip-address
Displays the system or network interface IP address.
- label-map label
Displays the MPLS label on which to match.
Output
The following output is an example of MPLS interface information, and Output fields: MPLS interface describes the output fields.
Sample outputA:7210SAS# config>router>mpls# show router mpls interface
===============================================================================
MPLS Interfaces
===============================================================================
Interface Port-id Adm Opr TE-metric
-------------------------------------------------------------------------------
system system Up Up None
Admin Groups None
Srlg Groups None
ip-10.10.2.3 1/1/15 Up Up None
Admin Groups None
Srlg Groups None
ip-10.10.5.3 1/1/1 Up Up None
Admin Groups None
Srlg Groups None
ip-10.10.11.3 1/1/3 Up Up None
Admin Groups None
Srlg Groups None
ip-10.10.12.3 lag-1 Up Up None
Admin Groups None
Srlg Groups None
-------------------------------------------------------------------------------
Interfaces : 5
===============================================================================
*A:7210SAS#
Label |
Description |
|---|---|
Interface |
Displays the interface name |
Port-id |
Displays the port ID displayed in the slot/mda/port format |
Adm |
Displays the administrative state of the interface |
Opr |
Displays the operational state of the interface |
Srlg Groups |
Displays the shared risk link group (SRLG) names |
Te-metric |
Displays the traffic engineering metric used on the interface |
Interfaces |
Displays the total number of interfaces |
Transmitted |
Displays the number of packets and octets transmitted from the interface |
Received |
Displays the number of packets and octets received |
In Label |
Displays the ingress label |
In I/F |
Displays the ingress interface |
Out Label |
Displays the egress label |
Out I/F |
Displays the egress interface |
Next Hop |
Displays the next hop IP address for the static LSP |
Type |
Displays whether the label value is statically or dynamically assigned |
label
Syntax
label start-label [end-label | in-use | label-owner]
Context
show>router>mpls-labels
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays information about MPLS labels exchanged by signaling protocols.
Parameters
- start-label
Specifies the label value assigned at the ingress router.
- end-label
Specifies the label value assigned for the egress router.
- in-use
Specifies the number of in-use labels displayed.
- label-owner
Specifies the owner of the label.
Output
The following output is an example of MPLS label information, and Output fields: MPLS label describes the output fields.
Sample output*A:SRU4>config>router>mpls-labels# show router mpls-labels label 202
=================================================================
MPLS Label 202
=================================================================
Label Label Type Label Owner
-----------------------------------------------------------------
202 static-lsp STATIC
-----------------------------------------------------------------
In-use labels in entire range : 5057
=================================================================
*A:SRU4>config>router>mpls-labels#
Label |
Description |
|---|---|
Label |
Displays the label value |
Label Type |
Displays whether the label value is statically or dynamically assigned |
Label Owner |
Displays the label owner |
In-use labels in entire range |
Displays the total number of labels being used by RSVP |
label-range
Syntax
label-range
Context
show>router>mpls-labels
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays the MPLS label range.
Output
The following output is an example of MPLS label range information, and Output fields: MPLS label-range describes the output fields.
Sample output
*A:Dut-A# show router mpls-labels label-range
==============================================================================
Label Ranges
==============================================================================
Label Type Start Label End Label Aging Total Available
------------------------------------------------------------------------------
static-lsp 32 1023 - 992
static-svc 2048 18431 - 16384
dynamic 32768 131071 0 102400
==============================================================================
*A:Dut-A#
Label |
Description |
|---|---|
Label Type |
Displays information about the static-lsp, static-svc, and dynamic label types. |
Start Label |
Displays the label value assigned at the ingress router |
End Label |
Displays the label value assigned for the egress router |
Aging |
Displays the number of labels released from a service that are transitioning back to the label pool; labels are aged 15 seconds |
Total Available |
Displays the number of label values available |
lsp
Syntax
lsp lsp-name [status {up|down}] [from ip-address | to ip-address] [detail]
lsp {transit | terminate} [status {up | down}] [from ip-address | to ip-address | lsp-name name] [detail]
lsp count
lsp lsp-name activepath
lsp lsp-name path [path-name] [status {up |down}] [detail]
lsp [lsp-name] path [path-name] mbb
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays LSP details.
Parameters
- lsp lsp-name
The name of the LSP used in the path.
- status up
Keyword to display an LSP that is operationally up.
- status down
Keyword to display an LSP that is operationally down.
- from ip-address
Displays the IP address of the ingress router for the LSP.
- to ip-address
Displays the IP address of the egress router for the LSP.
- transit
Displays the number of static LSPs that transit through the router.
- terminate
Displays the number of static LSPs that terminate at the router.
- lsp count
Displays the total number of LSPs.
- activepath
Displays the present path being used to forward traffic.
- mbb
Displays make-before-break (MBB) information.
- detail
Displays detailed information.
Output
The following output is an example of MPLS LSP information, and Output fields: MPLS LSP describes the output fields.
Sample output*A:SRU4>config>router>mpls# show router mpls lsp "to_110_20_1_1_cspf"
===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name To Fastfail Adm Opr
Config
-------------------------------------------------------------------------------
to_110_20_1_1_cspf 110.20.1.1 No Up Up
-------------------------------------------------------------------------------
LSPs : 1
===============================================================================
*A:SRU4>config>router>mpls#
*A:Dut-A# show router mpls lsp transit detail
===============================================================================
MPLS LSPs (Transit) (Detail)
===============================================================================
-------------------------------------------------------------------------------
LSP D_B_1::D_B_1
-------------------------------------------------------------------------------
From : 10.20.1.4 To : 10.20.1.2
State : Up
In Interface : lag-1:10 In Label : 130668
Out Interface : lag-2 Out Label : 131065
Previous Hop : 10.10.14.4 Next Hop : 10.10.12.2
Reserved BW : 0 Kbps
-------------------------------------------------------------------------------
*A:Dut-A#
*===============================================================================
*A:7210-SAS>show>router>mpls# lsp A detail
===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
-------------------------------------------------------------------------------
Type : Originating
-------------------------------------------------------------------------------
LSP Name : A LSP Tunnel ID : 1
From : 10.2.2.2 To : 10.100.100.100
Adm State : Up Oper State : Down
LSP Up Time : 0d 00:00:00 LSP Down Time : 0d 00:05:42
Transitions : 2 Path Changes : 2
Retry Limit : 0 Retry Timer : 30 sec
Signaling : RSVP Resv. Style : SE
Hop Limit : 255 Negotiated MTU : 0
Adaptive : Enabled ClassType : 0
FastReroute : Disabled Oper FR : Disabled
CSPF : Disabled ADSPEC : Disabled
Metric : 0
Include Grps: Exclude Grps :
None None
Type : RegularLsp Least Fill : Disabled
LdpOverRsvp : Enabled VprnAutoBind : Enabled
Oper Metric : 65535
Primary : A Down Time : 0d 00:05:42
Bandwidth : 0 Mbps
===============================================================================
*A:7210-SAS>show>router>mpls# lsp 2 detail
*A:Dut-A# config>router>mpls# show router mpls lsp ‟1” path detail
=======================================================================
MPLS LSP 1 Path (Detail)
=======================================================================
Legend :
@ - Detour Available # - Detour In Use
b - Bandwidth Protected n - Node Protected
s - Soft Preemption
S - Strict L - Loose
A - ABR
=======================================================================
-----------------------------------------------------------------------
LSP 1 Path 1
-----------------------------------------------------------------------
LSP Name : 1 Path LSP ID : 30208
From : 10.20.1.1 To : 10.20.1.6
Adm State : Up Oper State : Up
Path Name : 1 Path Type : Primary
Path Admin : Up Path Oper : Up
OutInterface: 1/1/1 Out Label : 131071
Path Up Time: 0d 00:00:05 Path Dn Time: 0d 00:00:00
Retry Limit : 0 Retry Timer : 30 sec
RetryAttempt: 0 NextRetryIn : 0 sec
Adspec : Disabled Oper Adspec : Disabled
CSPF : Enabled Oper CSPF : Enabled
Least Fill : Disabled Oper LeastF*: Disabled
FRR : Enabled Oper FRR : Enabled
FRR NodePro*: Enabled Oper FRR NP : Enabled
FR Hop Limit: 16 Oper FRHopL*: 16
FR Prop Adm*: Disabled Oper FRProp*: Disabled
Prop Adm Grp: Disabled Oper PropAG : Disabled
Inter-area : False
Neg MTU : 1496 Oper MTU : 1496
Bandwidth : No Reservation Oper Bw : 0 Mbps
Hop Limit : 255 Oper HopLim*: 255
Record Route: Record Oper RecRou*: Record
Record Label: Record Oper RecLab*: Record
SetupPriori*: 7 Oper SetupP*: 7
Hold Priori*: 0 Oper HoldPr*: 0
Class Type : 0 Oper CT : 0
Backup CT : None
MainCT Retry: n/a
Rem :
MainCT Retry: 0
Limit :
Include Grps: Oper InclGr*:
None None
Exclude Grps: Oper ExclGr*:
None None
Adaptive : Enabled Oper Metric : 3000
Preference : n/a
Path Trans : 1 CSPF Queries: 1
Failure Code: noError Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
10.20.1.1, If Index : 2 @ n Record Label :
N/A
-> 10.20.1.2, If Index : 2 @ n Record Label :
131071
-> 10.20.1.4, If Index : 2 Record Label :
131071
-> 10.20.1.6, If Index : 2 Record Label :
131071
ComputedHops:
10.20.1.1, If Index : 2(S)
-> 10.20.1.2, If Index : 2(S)
-> 10.20.1.4, If Index : 2(S)
-> 10.20.1.6, If Index : 2(S)
ResigEligib*: False
LastResignal: n/a CSPF Metric : 3000
=======================================================================
* indicates that the corresponding row element may have been truncated.
Label |
Description |
|---|---|
LSP Name |
Displays the name of the LSP used in the path |
To |
Displays the system IP address of the egress router for the LSP |
Adm State |
|
Oper State |
|
Oper State |
|
LSPs |
Displays the total number of LSPs configured |
From |
Displays the IP address of the ingress router for the LSP |
LSP Up Time |
Displays the length of time the LSP has been operational |
Transitions |
Displays the number of transitions that have occurred for the LSP |
Retry Limit |
Displays the number of attempts that the software should make to re-establish the LSP after it has failed |
Signaling |
Displays the signaling style |
Hop Limit |
Displays the maximum number of hops that an LSP can traverse, including the ingress and egress routers |
Fast Reroute/FastFail Config |
enabled — Fast reroute is enabled. In the event of a failure, traffic is immediately rerouted on the precomputed detour LSP, thus minimizing packet loss. disabled — there is no detour LSP from each node on the primary path |
ADSPEC |
enabled — the LSP will include advertising data (ADSPEC) objects in RSVP messages disabled — the LSP will not include advertising data (ADSPEC) objects in RSVP messages |
Primary |
Displays the preferred path for the LSP |
Secondary |
Displays the alternate path that the LSP uses if the primary path is not available. |
Bandwidth |
Displays the amount of bandwidth in megabits per second (Mbps) reserved for the LSP path |
LSP Up Time |
Displays the total time in increments that the LSP path has been operational |
LSP Tunnel ID |
Displays the value that identifies the label switched path that is signaled for this entry |
To |
Displays the IP address of the egress router for the LSP |
LSP Down Time |
Displays the total time in increments that the LSP path has not been operational |
Path Changes |
Displays the number of path changes this LSP has had. For every path change (path down, path up, path change), a corresponding syslog/trap (if enabled) is generated. |
Retry Timer |
Displays the time, in seconds, for LSP re-establishment attempts after an LSP failure |
Resv Style |
se — Specifies a shared reservation environment with a limited reservation scope. This reservation style creates a single reservation over a link that is shared by an explicit list of senders. ff — Specifies a shared reservation environment with an explicit reservation scope. Specifies an explicit list of senders and a distinct reservation for each of them. |
Negotiated MTU |
Displays the size of the maximum transmission unit (MTU) that is negotiated during establishment of the LSP |
FR Hop Limit |
Displays the total number of hops a detour LSP can take before merging back onto the main LSP path |
LastResignalAttempt |
Displays the system up time when the last attempt to resignal this LSP was made |
VprnAutoBind |
Displays the status on VPRN auto-bind feature as enabled or disabled |
oam-template
Syntax
oam-template [template-name] [associations]
Context
show>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command displays MPLS-TP OAM template information.
Output
The following output is an example of MPLS-TP OAM template information.
Sample output
*A:7210SAS>show>router>mpls>tp# oam-template
===============================================================================
MPLS-TP OAM Templates
===============================================================================
Template Name : temp1 Router ID : 1
BFD Template : temp1 Hold-Down Time: 0 centiseconds
Hold-Up Time : 0 deciseconds
-------------------------------------------------------------------------------
Template Name : temp2 Router ID : 1
BFD Template : temp2 Hold-Down Time: 0 centiseconds
Hold-Up Time : 0 deciseconds
-------------------------------------------------------------------------------
Template Name : temp3 Router ID : 1
BFD Template : temp3 Hold-Down Time: 0 centiseconds
Hold-Up Time : 0 deciseconds
===============================================================================
*A:7210SAS>show>router>mpls>tp#
protection-template
Syntax
protection-template [template-name] [associations]
Context
show>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command displays MPLS-TP protection template information.
Output
The following output is an example of MPLS-TP protection template information.
Sample output
*A:7210SAS>show>router>mpls>tp# protection-template
===============================================================================
MPLS-TP Protection Templates
===============================================================================
Template Name : temp1 Router ID : 1
Protection Mode: one2one Direction : bidirectional
Revertive : revertive Wait-to-Restore : 1sec
Rapid-PSC-Timer: 10ms Slow-PSC-Timer : 5sec
-------------------------------------------------------------------------------
Template Name : temp2 Router ID : 1
Protection Mode: one2one Direction : bidirectional
Revertive : revertive Wait-to-Restore : 1sec
Rapid-PSC-Timer: 10ms Slow-PSC-Timer : 5sec
-------------------------------------------------------------------------------
Template Name : temp3 Router ID : 1
Protection Mode: one2one Direction : bidirectional
Revertive : revertive Wait-to-Restore : 1sec
Rapid-PSC-Timer: 10ms Slow-PSC-Timer : 5sec
-------------------------------------------------------------------------------
===============================================================================
*A:7210SAS>show>router>mpls>tp#
status
Syntax
status
Context
show>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command displays MPLS-TP system configuration information.
Output
The following output is an example of MPLS-TP system configuration information.
Sample output*A:mlstp-dutA# show router mpls mpls-tp status
===============================================================================
MPLS-TP Status
===============================================================================
Admin Status : Up
Global ID : 42 Node ID : 0.0.3.233
Tunnel Id Min : 1 Tunnel Id Max : 4096
===============================================================================
transit-path
Syntax
transit-path [path-name] [detail]
Context
show>router>mpls>mpls-tp
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
This command displays MPLS-TP tunnel information.
Parameters
- path-name
Specifies the path name, up to 32 characters max.
- detail
Keyword to displays detailed information.
Output
The following output is an example of MPLS-TP tunnel information.
Sample outputA:mplstp-dutC# show router mpls mpls-tp transit-path
<path-name>
"tp-32" "tp-33" "tp-34" "tp-35" "tp-36" "tp-37" "tp-38" "tp-39"
"tp-40" "tp-41"
detail
A:mplstp-dutC# show router mpls mpls-tp transit-path "tp-32"
===============================================================================
MPLS-TP Transit tp-32 Path Information
===============================================================================
Path Name : tp-32
Admin State : Up Oper State : Up
------------------------------------------------------------------
Path NextHop InLabel OutLabel Out I/F
------------------------------------------------------------------
FP 2080 2081 CtoB_1
RP 2081 2080 CtoA_1
===============================================================================
A:mplstp-dutC# show router mpls mpls-tp transit-path "tp-32" detail
===============================================================================
MPLS-TP Transit tp-32 Path Information (Detail)
===============================================================================
Path Name : tp-32
Admin State : Up Oper State : Up
-------------------------------------------------------------------------------
Path ID configuration
Src Global ID : 42 Dst Global ID : 42
Src Node ID : 0.0.3.234 Dst Node ID : 0.0.3.233
LSP Number : 2 Dst Tunnel Num: 32
Forward Path configuration
In Label : 2080 Out Label : 2081
Out Interface : CtoB_1 Next Hop Addr : n/a
Reverse Path configuration
In Label : 2081 Out Label : 2080
Out Interface : CtoA_1 Next Hop Addr : n/a
===============================================================================
A:mplstp-dutC#
srlg-database
Syntax
srlg-database [router-id ip-address] [interface ip-address]
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS SRLG database information.
Parameters
- router-id ip-address
Specifies a 32-bit integer uniquely identifying the router in the autonomous system. By convention, to ensure uniqueness, this may default to the value of one of the router IPv4 host addresses, represented as a 32-bit unsigned integer, if IPv4 is configured on the router. The router-id can be either the local one or a remote router.
- interface ip-address
Specifies the IP address of the interface.
path
Syntax
path [path-name] [lsp-binding]
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS paths.
Parameters
- path-name
Specifies the unique name label for the LSP path, up to 32 characters.
- lsp-binding
Keyword to display binding information.
Output
The following output is an example of MPLS path information, and Output fields: MPLS path describes the output fields.
Sample output*A:SRU4>config>router>mpls# show router mpls path
===============================================================================
MPLS Path:
===============================================================================
Path Name Adm Hop Index IP Address Strict/Loose
-------------------------------------------------------------------------------
to_110_20_1_1 Up no hops n/a n/a
to_110_20_1_2 Up no hops n/a n/a
to_110_20_1_3 Up no hops n/a n/a
to_110_20_1_4 Up no hops n/a n/a
to_110_20_1_5 Up no hops n/a n/a
to_110_20_1_6 Up no hops n/a n/a
to_110_20_1_110 Up no hops n/a n/a
to_10_8_100_15 Up no hops n/a n/a
to_10_20_1_20 Up no hops n/a n/a
to_10_20_1_22 Up no hops n/a n/a
to_10_100_1_1 Up no hops n/a n/a
------------------------------------------------------------------------------
Paths : 11
===============================================================================
*A:SRU4>config>router>mpls#
Label |
Description |
|---|---|
Path Name |
Displays the unique name label for the LSP path |
Adm |
Down — the path is administratively disabled Up — the path is administratively enabled |
Hop Index |
Displays the value used to order the hops in a path |
IP Address |
Displays the IP address of the hop that the LSP should traverse on the way to the egress router |
Strict/Loose |
Strict — the LSP must take a direct path from the previous hop router to the next router Loose — the route taken by the LSP from the previous hop to the next hop can traverse through other routers |
LSP Name |
Displays the name of the LSP used in the path |
Binding |
Primary — the preferred path for the LSP Secondary — the standby path for the LSP |
Paths |
Displays the total number of paths configured |
srlg-group
Syntax
srlg-group [group-name]
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS SRLG group information.
Parameters
- group-name
Specifies the name of the SRLG group within a virtual router instance.
Output
The following output is an example of MPLS SRLG group information, and Output fields: MPLS SRLG-group describes the output fields.
Sample output*A:SRU4>config>router>mpls# show router mpls srlg-group
===============================================================================
MPLS Srlg Groups
===============================================================================
Group Name Group Value Interfaces
-------------------------------------------------------------------------------
1432 1432 srl-1
1433 1433 srl-3
1434 1434 aps-8
1435 1435 aps-9
2410 2410 srr-1
2411 2411 srr-2
2412 2412 srr-3
3410 3410 aps-1
3420 3420 aps-2
3430 3430 aps-3
3440 3440 sr4-1
41.80 4180 g7600
41104 41104 germ-1
415.70 41570 gsr1
420.40 42040 m160
422.60 42260 gsr2
44.200 44200 hubA
45100 45100 ess-7-1
45110 45110 ess-7-2
45120 45120 ess-7-3
4651 4651 src-1.1
4652 4652 src-1.2
4653 4653 src-1.3
4654 4654 src-1.4
4655 4655 src-1.5
4656 4656 src-1.6
4657 4657 src-1.7
4658 4658 src-1.8
4659 4659 src-1.9
4660 4660 src-1.10
-------------------------------------------------------------------------------
No. of Groups: 30
===============================================================================
*A:SRU4>config>router>mpls#
*A:SRU4>config>router>mpls# show router mpls srlg-group "1432"
===============================================================================
MPLS Srlg Groups
===============================================================================
Group Name Group Value Interfaces
-------------------------------------------------------------------------------
1432 1432 srl-1
-------------------------------------------------------------------------------
No. of Groups: 1
===============================================================================
*A:SRU4>config>router>mpls#
Label |
Description |
|---|---|
Group Name |
Displays the name of the SRLG group within a virtual router instance |
Group Value |
Displays the group value associated with this SRLG group |
Interface |
Displays the interface where the SRLG group is associated |
No. of Groups |
Displays the total number of SRLG groups associated with the output |
static-lsp
Syntax
static-lsp [lsp-name]
static-lsp {transit | terminate}
static-lsp count
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS static LSP information.
Output
The following output is an example of MPLS static LSP information, and Output fields: MPLS static-LSP describes the output fields.
Sample outputA:ALA-12# show router mpls static-lsp
===============================================================================
MPLS Static LSPs (Originating)
===============================================================================
Lsp Name To Next Hop Out Label Out I/F Adm Opr
-------------------------------------------------------------------------------
NYC_SJC_customer2 10.20.1.10 10.10.1.4 1020 1/1/1 Up Up
-------------------------------------------------------------------------------
LSPs : 1
===============================================================================
A:ALA-12#
*A:SRU4>config>router>mpls# show router mpls static-lsp transit
===============================================================================
MPLS Static LSPs (Transit)
===============================================================================
In Label In Port Out Label Out Port Next Hop Adm Opr
-------------------------------------------------------------------------------
240 aps-1 440 1/1/10 10.22.11.3 Up Up
241 aps-1 441 1/1/10 10.22.11.3 Up Up
242 aps-1 442 1/1/10 10.22.11.3 Up Up
243 aps-1 443 1/1/10 10.22.11.3 Up Up
244 aps-1 444 1/1/10 10.22.11.3 Up Up
245 aps-1 445 1/1/10 10.22.11.3 Up Up
246 aps-1 446 1/1/10 10.22.11.3 Up Up
247 aps-1 447 1/1/10 10.22.11.3 Up Up
248 aps-1 448 1/1/10 10.22.11.3 Up Up
249 aps-1 449 1/1/10 10.22.11.3 Up Up
250 aps-1 450 1/1/10 10.22.11.3 Up Up
251 aps-1 451 1/1/10 10.22.11.3 Up Up
252 aps-1 452 1/1/10 10.22.11.3 Up Up
253 aps-1 453 1/1/10 10.22.11.3 Up Up
...
207 3/2/8 407 1/1/9 10.22.10.3 Up Up
208 3/2/8 408 1/1/9 10.22.10.3 Up Up
209 3/2/8 409 1/1/9 10.22.10.3 Up Up
-------------------------------------------------------------------------------
LSPs : 256
===============================================================================
*A:SRU4>config>router>mpls#
A:ALA-12# show router mpls static-lsp terminate
===============================================================================
MPLS Static LSPs (Terminate)
===============================================================================
In Label In I/F Out Label Out I/F Next Hop Adm Opr
-------------------------------------------------------------------------------
1021 1/1/1 n/a n/a n/a Up Up
-------------------------------------------------------------------------------
LSPs : 1
===============================================================================
A:ALA-12#
Label |
Description |
|---|---|
Lsp Name |
Displays the name of the LSP used in the path |
To |
Displays the system IP address of the egress router for the LSP |
Next Hop |
Displays the system IP address of the next hop in the LSP path |
In I/F |
Displays the ingress interface |
Out Label |
Displays the egress label |
Out I/F |
Displays the egress interface |
Adm |
Down — the path is administratively disabled Up — the path is administratively enabled |
Opr |
Down — the path is operationally down Up — the path is operationally up |
LSPs |
Displays the total number of static LSPs |
status
Syntax
status
Context
show>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays MPLS operation information.
Output
The following output is an example of MPLS status information, and Output fields: MPLS status describes the output fields.
Sample output*A:7210SAS# show router mpls status
===============================================================================
MPLS Status
===============================================================================
Admin Status : Up Oper Status : Up
Oper Down Reason : n/a
FR Object : Enabled Resignal Timer : Disabled
Hold Timer : 1 seconds Next Resignal : N/A
Srlg Frr : Disabled Srlg Frr Strict : Disabled
Dynamic Bypass : Enabled User Srlg Database : Disabled
Least Fill Min Thd.: 5 percent LeastFill ReoptiThd: 10 percent
Short. TTL Prop Lo*: Enabled Short. TTL Prop Tr*: Enabled
AB Sample Multipli*: 1 AB Adjust Multipli*: 288
Exp Backoff Retry : Disabled CSPF On Loose Hop : Disabled
Lsp Init RetryTime*: 30 seconds
Logger Event Bundl*: Disabled
P2mp Resignal Timer: Disabled P2mp Next Resignal : N/A
Sec FastRetryTimer : Disabled Static LSP FR Timer: 30 seconds
P2P Max Bypass Ass*: 1000
P2PActPathFastRetry: Disabled
In Maintenance Mode: No
LSP Counts Originate Transit Terminate
-------------------------------------------------------------------------------
Static LSPs 0 0 0
Dynamic LSPs 0 0 1
Detour LSPs 0 0 0
S2l LSPs 0 0 0
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:7210SAS#
Label |
Description |
|---|---|
Admin Status |
Down — MPLS is administratively disabled Up — MPLS is administratively enabled |
Oper Status |
Down — MPLS is operationally down Up — MPLS is operationally up |
LSP Counts |
Static LSPs — Displays the count of static LSPs that originate, transit, and terminate on or through the router Dynamic LSPs — Displays the count of dynamic LSPs that originate, transit, and terminate on or through the router Detour LSPs — Displays the count of detour LSPs that originate, transit, and terminate on or through the router |
FR Object |
Enabled — Specifies that Fast reroute object is signaled for the LSP Disabled — Specifies that Fast reroute object is not signaled for the LSP |
Resignal Timer |
Enabled — Specifies that the resignal timer is enabled for the LSP Disabled — Specifies that the resignal timer is disabled for the LSP |
Hold Timer |
Displays the amount of time that the ingress node holds before programming its data plane and declaring the LSP up to the service module |
Show RSVP commands
interface
Syntax
interface [ip-int-name | ip-address] statistics [detail]
Context
show>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command shows RSVP interfaces.
Parameters
- ip-int-name
Specifies the name of the network IP interface, up to 32 characters. An interface name cannot be in the form of an IP address. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- ip-address
Specifies the system or network interface IP address.
- statistics
Keyword to display the IP address and number of packets sent and received on an interface-basis.
- detail
Keyword to display detailed information.
Output
The following output is an example of RSVP interface information, and Output fields: RSVP interface describes the output fields.
Sample output*A:7210-SAS>show>router>rsvp# interface detail
===============================================================================
RSVP Interfaces (Detailed)
===============================================================================
-------------------------------------------------------------------------------
Interface : system
-------------------------------------------------------------------------------
Interface : system
Port ID : system
Admin State : Up Oper State : Up
Active Sessions : 0 Active Resvs : 0
Total Sessions : 0
Subscription : 100 % Port Speed : 0 Mbps
Total BW : 0 Mbps Aggregate : Dsabl
Hello Interval : n/a Hello Timeouts : n/a
Authentication : Disabled
Auth Rx Seq Num : n/a Auth Key Id : n/a
Auth Tx Seq Num : n/a Auth Win Size : n/a
Refresh Reduc. : Disabled Reliable Deli. : Disabled
Bfd Enabled : n/a Graceful Shut. : Disabled
ImplicitNullLabel : Disabled* GR helper : n/a
Percent Link Bandwidth for Class Types
Link Bw CT0 : 100 Link Bw CT4 : 0
Link Bw CT1 : 0 Link Bw CT5 : 0
Link Bw CT2 : 0 Link Bw CT6 : 0
Link Bw CT3 : 0 Link Bw CT7 : 0
Bandwidth Constraints for Class Types (Kbps)
BC0 : 0 BC4 : 0
BC1 : 0 BC5 : 0
BC2 : 0 BC6 : 0
BC3 : 0 BC7 : 0
Bandwidth for TE Class Types (Kbps)
TE0-> Resv. Bw : 0 Unresv. Bw : 0
TE1-> Resv. Bw : 0 Unresv. Bw : 0
TE2-> Resv. Bw : 0 Unresv. Bw : 0
TE3-> Resv. Bw : 0 Unresv. Bw : 0
TE4-> Resv. Bw : 0 Unresv. Bw : 0
TE5-> Resv. Bw : 0 Unresv. Bw : 0
TE6-> Resv. Bw : 0 Unresv. Bw : 0
TE7-> Resv. Bw : 0 Unresv. Bw : 0
No Neighbors.
-------------------------------------------------------------------------------
Interface : ip-10.10.12.3
-------------------------------------------------------------------------------
Interface : ip-10.10.12.3
Port ID : 1/1/9
Admin State : Up Oper State : Up
Active Sessions : 1 Active Resvs : 0
Total Sessions : 1
Subscription : 100 % Port Speed : 1000 Mbps
Total BW : 1000 Mbps Aggregate : Dsabl
Hello Interval : 3000 ms Hello Timeouts : 0
Authentication : Disabled
Auth Rx Seq Num : n/a Auth Key Id : n/a
Auth Tx Seq Num : n/a Auth Win Size : n/a
Refresh Reduc. : Disabled Reliable Deli. : Disabled
Bfd Enabled : No Graceful Shut. : Disabled
Percent Link Bandwidth for Class Types
Link Bw CT0 : 100 Link Bw CT4 : 0
Link Bw CT1 : 0 Link Bw CT5 : 0
Link Bw CT2 : 0 Link Bw CT6 : 0
Link Bw CT3 : 0 Link Bw CT7 : 0
Bandwidth Constraints for Class Types (Kbps)
BC0 : 1000000 BC4 : 0
BC1 : 0 BC5 : 0
BC2 : 0 BC6 : 0
BC3 : 0 BC7 : 0
Bandwidth for TE Class Types (Kbps)
TE0-> Resv. Bw : 0 Unresv. Bw : 1000000
TE1-> Resv. Bw : 0 Unresv. Bw : 1000000
TE2-> Resv. Bw : 0 Unresv. Bw : 1000000
TE3-> Resv. Bw : 0 Unresv. Bw : 1000000
TE4-> Resv. Bw : 0 Unresv. Bw : 1000000
TE5-> Resv. Bw : 0 Unresv. Bw : 1000000
TE6-> Resv. Bw : 0 Unresv. Bw : 1000000
TE7-> Resv. Bw : 0 Unresv. Bw : 1000000
Neighbors : 10.10.12.2
-------------------------------------------------------------------------------
Interface : ip-10.10.4.3
-------------------------------------------------------------------------------
Interface : ip-10.10.4.3
Port ID : 1/1/8
Admin State : Up Oper State : Up
Active Sessions : 1 Active Resvs : 0
Total Sessions : 1
Subscription : 100 % Port Speed : 1000 Mbps
Total BW : 1000 Mbps Aggregate : Dsabl
Hello Interval : 3000 ms Hello Timeouts : 0
Authentication : Disabled
Auth Rx Seq Num : n/a Auth Key Id : n/a
Auth Tx Seq Num : n/a Auth Win Size : n/a
Refresh Reduc. : Disabled Reliable Deli. : Disabled
Bfd Enabled : No Graceful Shut. : Disabled
Percent Link Bandwidth for Class Types
Link Bw CT0 : 100 Link Bw CT4 : 0
Link Bw CT1 : 0 Link Bw CT5 : 0
Link Bw CT2 : 0 Link Bw CT6 : 0
Link Bw CT3 : 0 Link Bw CT7 : 0
Bandwidth Constraints for Class Types (Kbps)
BC0 : 1000000 BC4 : 0
BC1 : 0 BC5 : 0
BC2 : 0 BC6 : 0
BC3 : 0 BC7 : 0
Bandwidth for TE Class Types (Kbps)
TE0-> Resv. Bw : 0 Unresv. Bw : 1000000
TE1-> Resv. Bw : 0 Unresv. Bw : 1000000
TE2-> Resv. Bw : 0 Unresv. Bw : 1000000
TE3-> Resv. Bw : 0 Unresv. Bw : 1000000
TE4-> Resv. Bw : 0 Unresv. Bw : 1000000
TE5-> Resv. Bw : 0 Unresv. Bw : 1000000
TE6-> Resv. Bw : 0 Unresv. Bw : 1000000
TE7-> Resv. Bw : 0 Unresv. Bw : 1000000
Neighbors : 10.10.4.2
-------------------------------------------------------------------------------
Interface : ip-10.10.2.3
-------------------------------------------------------------------------------
Interface : ip-10.10.2.3
Port ID : 1/1/4
Admin State : Up Oper State : Down
Active Sessions : 0 Active Resvs : 0
Total Sessions : 0
Subscription : 100 % Port Speed : 0 Mbps
Total BW : 0 Mbps Aggregate : Dsabl
Hello Interval : 3000 ms Hello Timeouts : 0
Authentication : Disabled
Auth Rx Seq Num : n/a Auth Key Id : n/a
Auth Tx Seq Num : n/a Auth Win Size : n/a
Refresh Reduc. : Disabled Reliable Deli. : Disabled
Bfd Enabled : No Graceful Shut. : Disabled
Percent Link Bandwidth for Class Types
Link Bw CT0 : 100 Link Bw CT4 : 0
Link Bw CT1 : 0 Link Bw CT5 : 0
Link Bw CT2 : 0 Link Bw CT6 : 0
Link Bw CT3 : 0 Link Bw CT7 : 0
Bandwidth Constraints for Class Types (Kbps)
BC0 : 0 BC4 : 0
BC1 : 0 BC5 : 0
BC2 : 0 BC6 : 0
BC3 : 0 BC7 : 0
Bandwidth for TE Class Types (Kbps)
TE0-> Resv. Bw : 0 Unresv. Bw : 0
TE1-> Resv. Bw : 0 Unresv. Bw : 0
TE2-> Resv. Bw : 0 Unresv. Bw : 0
TE3-> Resv. Bw : 0 Unresv. Bw : 0
TE4-> Resv. Bw : 0 Unresv. Bw : 0
TE5-> Resv. Bw : 0 Unresv. Bw : 0
TE6-> Resv. Bw : 0 Unresv. Bw : 0
TE7-> Resv. Bw : 0 Unresv. Bw : 0
No Neighbors.
===============================================================================
Label |
Description |
|---|---|
Interface |
Displays the name of the IP interface |
Total Sessions |
Displays the total number of RSVP sessions on this interface, including sessions that are active and sessions that have been signaled but a response has not yet been received |
Active Sessions |
Displays the total number of active RSVP sessions on this interface |
Total BW (Mbps) |
Displays the amount of bandwidth in megabits per second (Mbps) available to be reserved for the RSVP protocol on the interface |
Resv BW (Mbps) |
Displays the amount of bandwidth in mega-bits per seconds (Mbps) reserved on this interface. A value of zero (0) indicates that no bandwidth is reserved. |
Adm |
Down — the RSVP interface is administratively disabled Up — the RSVP interface is administratively enabled |
Opr |
Down — the RSVP interface is operationally down Up — the RSVP interface is operationally up |
Port ID |
Displays the physical port bound to the interface |
Active Resvs |
Displays the total number of active RSVP sessions that have reserved bandwidth |
Subscription |
Displays the percentage of the link bandwidth that RSVP can use for reservation. When the value is zero (0), no new sessions are permitted on this interface. |
Port Speed |
Displays the speed for the interface |
Unreserved BW |
Displays the amount of unreserved bandwidth |
Reserved BW |
Displays the amount of bandwidth, in megabits per second (Mbps), reserved by the RSVP session on this interface. A value of zero (0) indicates that no bandwidth is reserved. |
Total BW |
Displays the amount of bandwidth, in megabits per second (Mbps), available to be reserved for the RSVP protocol on this interface |
Hello Interval |
Displays the length of time, in seconds, between the hello packets that the router sends on the interface. This value must be the same for all routers attached to a common network. When the value is zero (0), the sending of hello messages is disabled. |
Refresh Time |
Displays the interval between the successive Path and Resv refresh messages. RSVP declares the session down after it misses ((keep-multiplier + 0.5) * 1.5 * refresh-time)) consecutive refresh messages. |
Hello Timeouts |
Displays the total number of hello messages that timed out on this RSVP interface |
Neighbors |
Displays the IP address of the RSVP neighbor |
Sent |
Displays the total number of error free RSVP packets that have been transmitted on the RSVP interface |
Recd |
Displays the total number of error free RSVP packets received on the RSVP interface |
Total Packets |
Displays the total number of RSVP packets, including errors, received on the RSVP interface |
Bad Packets |
Displays the total number of RSVP packets with errors transmitted on the RSVP interface |
Paths |
Displays the total number of RSVP PATH messages received on the RSVP interface |
Path Errors |
Displays the total number of RSVP PATH ERROR messages transmitted on the RSVP interface |
Path Tears |
Displays the total number of RSVP PATH TEAR messages received on the RSVP interface |
Resvs |
Displays the total number of RSVP RESV messages received on the RSVP interface |
Resv Confirms |
Displays the total number of RSVP RESV CONFIRM messages received on the RSVP interface |
Resv Errors |
Displays the total number of RSVP RESV ERROR messages received on the RSVP interface |
Resv Tears |
Displays the total number of RSVP RESV TEAR messages received on the RSVP interface |
Refresh Summaries |
Displays the total number of RSVP RESV summary refresh messages received on the interface |
Refresh Acks |
Displays the total number of RSVP RESV acknowledgment messages received when refresh reduction is enabled on the RSVP interface |
Hellos |
Displays the total number of RSVP RESV HELLO REQ messages received on the interface |
Bfd Enabled |
Yes — BFD is enabled on the RSVP interface No — BFD is disabled on the RSVP interface |
neighbor
Syntax
neighbor [ip-address] [detail]
Context
show>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays neighbor information.
Parameters
- ip-address
Displays RSVP information about the specified IP address.
- detail
Keyword to display detailed information.
Output
The following output is an example of RSVP neighbor information, and Output fields: RSVP neighbor describes the output fields.
Sample output*A:Dut>config>router>mpls# show router rsvp neighbor
=======================================================================
RSVP Neighbors
=======================================================================
Legend :
LR - Local Refresh Reduction RR - Remote Refresh Reduction
LD - Local Reliable Delivery RM - Remote Node supports
Message ID
LG - Local Graceful Restart RG - Remote Graceful Restart
=======================================================================
Neighbor Interface Hello Last Oper
Flags
Change
=======================================================================
10.20.1.2 ip-10.10.1.1 N/A 0d 00:00:44
10.20.1.3 ip-10.10.2.1 N/A 0d 00:00:44
-----------------------------------------------------------------------
Neighbors : 2
-----------------------------------------------------------------------
*A:Dut>config>router>mpls#
Label |
Description |
|---|---|
Neighbor |
Displays the IP address of the RSVP neighbor |
Interface |
Displays the interface ID of the RSVP neighbor |
Hello |
Displays the status of the Hello message |
Last Oper Change |
Displays the time of the last operational change to the connection |
Flags |
Displays the flags that are associated with the connection to the neighbor |
session
Syntax
session session-type [from ip-address | to ip-address| lsp-name name] [status {up | down}] [detail]
Context
show>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command shows RSVP session information.
Parameters
- session session-type
Specifies the session type.
- from ip-address
Specifies the IP address of the originating router.
- to ip-address
Specifies the IP address of the egress router.
- lsp-name name
Specifies the name of the LSP used in the path.
- up
Keyword to display a session that is operationally up.
- down
Keyword to display a session that is operationally down.
- detail
Keyword to display detailed information.
Output
The following output is an example of RSVP session information, and Output fields: RSVP session describes the output fields.
Sample output*A:SRU4>show>router>rsvp# session
===============================================================================
RSVP Sessions
===============================================================================
From To Tunnel LSP Name State
ID ID
-------------------------------------------------------------------------------
10.20.1.5 10.20.1.4 18 27648 b4-1::b4-1 Up
10.20.1.5 10.20.1.4 1 37902 gsr::gsr Up
10.20.1.5 10.20.1.22 11 53760 to_10_20_1_22_cspf::to_10_2* Up
10.20.1.4 10.20.1.20 146 17920 to_10_20_1_20_cspf_3::to_10* Up
10.20.1.4 10.20.1.20 145 34816 to_10_20_1_20_cspf_2::to_10* Up
10.20.1.4 10.20.1.20 147 45056 to_10_20_1_20_cspf_4::to_10* Up
10.20.1.4 10.20.1.20 148 6656 to_10_20_1_20_cspf_5::to_10* Up
10.20.1.4 10.20.1.20 149 58880 to_10_20_1_20_cspf_6::to_10* Up
10.20.1.4 10.20.1.20 150 13312 to_10_20_1_20_cspf_7::to_10* Up
10.20.1.4 10.20.1.20 152 40448 to_10_20_1_20_cspf_9::to_10* Up
10.20.1.4 10.20.1.20 154 27648 to_10_20_1_20_cspf_11::to_1* Up
10.20.1.4 10.20.1.20 155 12288 to_10_20_1_20_cspf_12::to_1* Up
10.20.1.4 10.20.1.20 151 46080 to_10_20_1_20_cspf_8::to_10* Up
10.20.1.4 10.20.1.20 153 512 to_10_20_1_20_cspf_10::to_1* Up
10.20.1.4 10.20.1.22 164 62464 to_10_20_1_22_cspf_2::to_10* Up
10.20.1.4 10.20.1.20 156 37888 to_10_20_1_20_cspf_13::to_1* Up
10.20.1.4 10.20.1.20 157 24064 to_10_20_1_20_cspf_14::to_1* Up
10.20.1.4 10.20.1.20 158 19968 to_10_20_1_20_cspf_15::to_1* Up
10.20.1.4 10.20.1.20 161 59904 to_10_20_1_20_cspf_18::to_1* Up
...
10.20.1.3 10.20.1.4 54 23088 to_110_20_1_4_cspf_4::to_11* Up
-------------------------------------------------------------------------------
Sessions : 1976
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:SRU4>show>router>rsvp#
A:ALA-12# show router rsvp session lsp-name A_C_2::A_C_2 status up
===============================================================================
RSVP Sessions
===============================================================================
From To Tunnel LSP Name State
ID ID
-------------------------------------------------------------------------------
10.20.1.1 10.20.1.3 2 40 A_C_2::A_C_2 Up
-------------------------------------------------------------------------------
Sessions : 1
===============================================================================
A:ALA-12#
|
Label |
Description |
|---|---|
|
From |
Displays the IP address of the originating router |
|
To |
Displays the IP address of the egress router |
|
Tunnel ID |
Displays the IP address of the tunnel ingress node supporting this RSVP session |
|
LSP ID |
Displays the ID assigned by the agent to this RSVP session |
|
Name |
Displays the administrative name assigned to the RSVP session by the agent |
|
State |
|
|
|
statistics
Syntax
statistics
Context
show>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays global statistics in the RSVP instance.
Output
The following output is an example of RSVP statistics information, and Output fields: RSVP statistics describes the output fields.
Sample output*A:SRU4>show>router>rsvp# statistics
===============================================================================
RSVP Global Statistics
===============================================================================
PATH Timeouts : 1026 RESV Timeouts : 182
===============================================================================
*A:SRU4>show>router>rsvp#
Label |
Description |
|---|---|
PATH Timeouts |
Displays the total number of path timeouts |
RESV Timeouts |
Displays the total number of RESV timeouts |
status
Syntax
rsvp status
Context
show>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command displays RSVP status.
Output
The following output is an example of RSVP status information, and Output fields: RSVP status describes the output fields.
Sample output*A:SRU4>show>router>rsvp# status
===============================================================================
RSVP Status
===============================================================================
Admin Status : Up Oper Status : Up
Keep Multiplier : 3 Refresh Time : 30 sec
Message Pacing : Disabled Pacing Period : 100 msec
Max Packet Burst : 650 msgs Refresh Bypass : Disabled
===============================================================================
*A:SRU4>show>router>rsvp#
Label |
Description |
|---|---|
Admin Status |
|
Oper Status |
|
Keep Multiplier |
Displays the keep-multiplier number used by RSVP to declare that a reservation is down or the neighbor is down. |
Refresh Time |
Displays the refresh-time interval, in seconds, between the successive Path and Resv refresh messages |
Message Pacing |
Enabled — RSVP messages, specified in the max-burst command, are sent in a configured interval, specified in the period command Disabled — Message pacing is disabled; RSVP message transmission is not regulated |
Pacing Period |
Displays the time interval, in milliseconds, when the router can send the specified number of RSVP messages specified in the rsvp max-burst command |
Max Packet Burst |
Displays the maximum number of RSVP messages that are sent in the specified period under normal operating conditions |
Tools commands
cspf
Syntax
cspf to ip-addr [from ip-addr] [bandwidth bandwidth] [include-bitmap bitmap] [exclude-bitmap bitmap] [hop-limit limit] [exclude-address excl-addr [excl-addr...(up to 8 max)]] [use-te-metric] [strict-srlg] [srlggroup grp-id...(up to 8 max)] [skip-interface interface-name]
Context
tools>perform>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command computes a CSPF path with specified user constraints.
Parameters
- to ip-addr
Specifies the destination IP address.
- from ip-addr
Specifies the originating IP address.
- bandwidth bandwidth
Specifies the amount of bandwidth in mega-bits per second (Mbps) to be reserved.
- include-bitmap bitmap
Specifies to include a bit-map that specifies a list of admin groups that should be included during setup.
- exclude-bitmap bitmap
Specifies to exclude a bit-map that specifies a list of admin groups that should be included during setup.
- hop-limit limit
Specifies the total number of hops a detour LSP can take before merging back onto the main LSP path.
- exclude-address ip-addr
Specifies IP addresses, up to 8, that should be included during setup.
- use-te-metric
Keyword to specify the use of the traffic engineering metric used on the interface.
- strict-srlg
Keyword to specify whether to associate the LSP with a bypass or signal a detour if a bypass or detour satisfies all other constraints except the SRLG constraints.
- srlg-group grp-id
Specifies up to 8 Shared Risk Link Groups (SRLGs). An SRLG group represents a set of interfaces which could be subject to the same failures or defects and therefore, share the same risk of failing.
- skip-interface interface-name
Specifies an interface name that should be skipped during setup.
Output
Sample output*A:Dut-C# tools perform router mpls cspf to 10.20.1.6
Req CSPF for all ECMP paths
from: this node to: 10.20.1.6 w/
(no Diffserv) class: 0 , setup Priority 7, Hold Priority 0 TE Class: 7
CSPF Path
To : 10.20.1.6
Path 1 : (cost 2000)
Src: 10.20.1.3 (= Rtr)
Egr: unnumbered lnkId 4 -
> Ingr: unnumbered lnkId 2 Rtr: 10.20.1.5 (met 1000)
Egr: unnumbered lnkId 3 -
> Ingr: unnumbered lnkId 3 Rtr: 10.20.1.6 (met 1000)
Dst: 10.20.1.6 (= Rtr)
Path 2 : (cost 2000)
Src: 10.20.1.3 (= Rtr)
Egr: unnumbered lnkId 5 -
> Ingr: unnumbered lnkId 5 Rtr: 10.20.1.4 (met 1000)
Egr: unnumbered lnkId 3 -
> Ingr: unnumbered lnkId 2 Rtr: 10.20.1.6 (met 1000)
Dst: 10.20.1.6 (= Rtr)
*A:Dut-C#
resignal
Syntax
resignal {lsp lsp-name path path-name | delay minutes}
Context
tools>perform>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command resignals specified LSP paths. The minutes parameter configures the global timer to resignal all LSPs. If only lsp-name and path-name are provided, the specified LSP is resignaled immediately.
Parameters
- lsp-name
Specifies a unique LSP name, up to 32 characters.
- path-name
Specifies the name for the LSP path, up to 32 characters.
- minutes
Specifies the delay interval, in minutes, before all LSPs are resignaled. If the value 0 is entered, all LSPs are resignaled immediately.
resignal-bypass
Syntax
resignal-bypass {lsp bypass-lsp-name [force] | delay minutes}
Context
tools>perform>router>mpls
Platforms
7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12
Description
This command performs a manual re-optimization of a specific dynamic or manual bypass LSP, or of all dynamic bypass LSPs.
The user must configure the manual bypass LSP name. The dynamic bypass LSP name is shown in the output of show>router>mpls>bypass-tunnel dynamic detail.
The delay option triggers the global reoptimization of all dynamic bypass LSPs at the expiry of the specified delay. This option forces the global bypass resignal timer to expire after an amount of time equal to the value of the delay parameter. This option has no effect on a manual bypass LSP.
However, when bypass-lsp-name is specified, the named dynamic or manual bypass LSP is signaled, and the associations are moved only if the new bypass LSP path has a lower cost than the current path. This behavior is different from that of the tools>perform>router>mpls>resignal command for the primary or secondary active path of an LSP, which signals and switches to the new path, regardless of the cost comparison. This handling is required because a bypass LSP may have a large number of PSB associations and the processing churn is much higher.
In the specific case where the name corresponds to a manual bypass LSP, the LSP is torn down and resignaled using the new path provided by CSPF if no PSB associations exist. If one or more PSB associations exist but no PLR is active, the command fails and the user is required to explicitly enter the force option. In this case, the manual bypass LSP is torn down and resignaled, temporarily leaving the associated LSP primary paths unprotected. If one or more PLRs associated with the manual bypass LSP is active, the command fails.
Finally, and as with the timer-based resignal, the PSB associations are checked for the SRLG and admin-group constraints using the updated information provided by CSPF for the current path and new path of the bypass LSP.
Parameters
- lsp bypass-lsp-name [force]
Specifies the name, up to 160 characters, of the dynamic or manual bypass LSP. The force option is required when the name corresponds to a manual bypass LSP and the LSP has PSB associations.
- delay minutes
Specifies the time, in minutes, that MPLS waits before attempting to resignal dynamic bypass LSP paths originated on the system.
tp-tunnel
Syntax
tp-tunnel
Context
tools>perform>router>mpls
Platforms
7210 SAS-T, 7210 SAS-R6, and 7210 SAS-R12
Description
Commands in this context perform linear protection operations on an MPLS-TP LSP.
clear
Syntax
clear id tunnel-id lsp-name
Context
tools>perform>router>mpls>tp-tunnel
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command clears all MPLS-TP linear protection operational commands for the specified LSPs that are currently active.
Parameters
- tunnel-id
Specifies the tunnel number of the MPLS-TP LSP, up to 32 characters.
- lsp-name
Specifies the name of the MPLS-TP LSP.
force
Syntax
force id tunnel-id lsp-name
Context
tools>perform>router>mpls>tp-tunnel
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command performs a force switchover of the MPLS-TP LSP from the active path to the protect path.
Parameters
- tunnel-id
Specifies the tunnel number of the MPLS-TP LSP, up to 32 characters.
- lsp-name
Specifies the name of the MPLS-TP LSP.
lockout
Syntax
lockout tunnel-id lsp-name
Context
tools>perform>router>mpls>tp-tunnel
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command performs a lockout of protection for an MPLS-TP LSP. This prevents a switchover to the protect path.
Parameters
- tunnel-id
Specifies the tunnel number of the MPLS-TP LSP, up to 32 characters.
- lsp-name
Specifies the name of the MPLS-TP LSP.
manual
Syntax
manual tunnel-id lsp-name
Context
tools>perform>router>mpls>tp-tunnel
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command performs a manual switchover of the MPLS-TP LSP from the active path to the protect path.
Parameters
- tunnel-id
Specifies the tunnel number of the MPLS-TP LSP, up to 32 characters.
- lsp-name
Specifies the name of the MPLS-TP LSP.
trap-suppress
Syntax
trap-suppress number-of-traps time-interval
Context
tools>perform>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command modifies thresholds for trap suppression. The command is used to suppress traps after a specified number of traps has been raised within the specified period of time.
Parameters
- number-of-traps
Specifies the number of traps, in multiples of 100.
- time-interval
Specifies the time interval, in seconds.
Clear commands
fec-egress-statistics
Syntax
fec-egress-statistics [ip-prefix/mask]
Context
clear>router>ldp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command resets or clears LDP FEC egress statistics.
Parameters
- ip-prefix
Specifies information for the specified IP prefix and mask length. Host bits must be "0".
- mask
Specifies the 32-bit address mask used to indicate the bits of an IP address that are being used for the subnet address.
interface
Syntax
interface ip-int-name
Context
clear>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command resets or clears statistics for MPLS interfaces.
Parameters
- ip-int-name
Specifies the name of an existing IP interface. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
lsp
Syntax
lsp lsp-name
Context
clear>router>mpls
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command resets and restarts an LSP.
Parameters
- lsp-name
Specifies the name of the LSP to clear, up to 64 characters.
interface
Syntax
interface ip-int-name statistics
Context
clear>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command resets or clears statistics for an RSVP interface.
Parameters
- ip-int-name
Specifies the name of the IP interface to clear. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- statistics
Keyword to clear only statistics.
statistics
Syntax
statistics
Context
clear>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command clears global statistics for the RSVP instance, for example, clears path and resv timeout counters.
Debug commands
mpls
Syntax
mpls [lsp lsp-name] [sender source-address] [endpoint endpoint-address] [tunnel-id tunnel-id] [lsp-id lsp-id]
no mpls
Context
debug>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables and configures debugging for MPLS.
Parameters
- lsp-name
Specifies the name that identifies the LSP, up to 32 characters.
- source-address
Specifies the system IP address of the sender.
- endpoint-address
Specifies the far-end system IP address.
- tunnel-id
Specifies the MPLS SDP ID.
- lsp-id
Specifies the LSP ID.
event
Syntax
[no] event
Context
debug>router>mpls
debug>router>rsvp
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for specific events.
The no form of this command disables the debugging.
all
Syntax
all [detail]
no all
Context
debug>router>mpls>event
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs all events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about all events.
auth
Syntax
auth
no auth
Context
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs authentication events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about authentication events.
frr
Syntax
frr [detail]
no frr
Context
debug>router>mpls>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs fast re-route events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about re-route events.
iom
Syntax
iom [detail]
no iom
Context
debug>router>mpls>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs MPLS IOM events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about MPLS IOM events.
lsp-setup
Syntax
lsp-setup [detail]
no lsp-setup
Context
debug>router>mpls>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs LSP setup events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about LSP setup events.
mbb
Syntax
mbb [detail]
no mbb
Context
debug>router>mpls>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs the state of the most recent invocation of the make-before-break (MBB) functionality.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about MBB events.
misc
Syntax
misc [detail]
no misc
Context
debug>router>mpls>event
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs miscellaneous events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about miscellaneous events.
xc
Syntax
xc [detail]
no xc
Context
debug>router>mpls>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs cross connect events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about cross connect events.
rsvp
Syntax
[lsp lsp-name] [sender source-address] [endpoint endpoint-address] [tunnel-id tunnel-id] [lsp-id lsp-id] [interface ip-int-name]
no rsvp
Context
debug>router
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables and configures debugging for RSVP.
Parameters
- lsp-name
Specifies the name that identifies the LSP, up to 32 characters.
- sender source-address
Displays the system IP address of the sender.
- endpoint-address
Displays the far-end system IP address.
- tunnel-id
Displays the RSVP tunnel ID.
- lsp-id
Displays the LSP ID.
- ip-int-name
Displays the interface name. The interface name can be up to 32 characters long and must be unique. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
nbr
Syntax
nbr [detail]
no nbr
Context
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs neighbor events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about neighbor events.
path
Syntax
path [detail]
no path
Context
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs path-related events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about path-related events.
resv
Syntax
resv [detail]
no resv
Context
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs RSVP reservation events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about RSVP reservation events.
rr
Syntax
rr
no rr
Context
debug>router>rsvp>event
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs refresh reduction events.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about refresh reduction events.
packet
Syntax
[no] packet
Context
debug>router>rsvp>
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enable the context to debug packets.
ack
Syntax
ack [detail]
no ack
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs ACK packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about RSVP-TE ACK packets.
bundle
Syntax
bundle [detail]
no bundle
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs bundle packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about RSVP-TE bundle packets.
all
Syntax
all [detail]
no all
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs all packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about all RSVP packets.
hello
Syntax
hello [detail]
no hello
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs hello packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about hello packets.
path
Syntax
path [detail]
no path
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for RSVP path packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about path-related events.
patherr
Syntax
patherr [detail]
no patherr
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs path error packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about path error packets.
pathtear
Syntax
pathtear [detail]
no pathtear
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs path tear packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about path tear packets.
resv
Syntax
resv [detail]
no resv
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command enables debugging for RSVP resv packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about RSVP Resv events.
resverr
Syntax
resverr [detail]
no resverr
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs ResvErr packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about ResvErr packets.
resvtear
Syntax
resvtear [detail]
no resvtear
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs ResvTear packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about ResvTear packets.
srefresh
Syntax
srefresh [detail]
no srefresh
Context
debug>router>rsvp>packet
Platforms
Supported on all 7210 SAS platforms as described in this document.
Description
This command debugs srefresh packets.
The no form of this command disables the debugging.
Parameters
- detail
Keyword to display detailed information about RSVP-TE srefresh packets.