2.16. MPLS/RSVP command reference

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.

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.

MPLS must be shut down before the MPLS instance can be deleted. If MPLS is not shut down, when the no mpls command is executed, a warning message on the console displays indicating that MPLS is still administratively up.

The no form of this command deletes this MPLS protocol instance, which removes all configuration parameters for this MPLS instance.

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.

Note: Implicit NULL must be enabled for the use of Manual Bypass or Dynamic Bypass (FRR facility) if the 7210 SAS is used as an egress LER or is a merge point.

This command specifies 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.

By default, the value is inherited by all LSPs.

This command configures the amount of time that the ingress node waits before programming its data plane and declaring to the service module that the LSP is up.

The no form of this command disables the hold timer.

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.

The 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 (in the config>router>mpls>lsp>pce-report context) overrides the global configuration for reporting an LSP to the PCE. The default configuration, which inherits the global MPLS-level configuration, is disabled (using the pce-report rsvp-te disable command).

The default configuration controls the introduction of a PCE into an existing network and allows the user to decide whether all RSVP-TE LSPs should be reported. If PCE reporting for an LSP is disabled, either because of the inheritance of the global MPLS configuration or because of LSP-level configuration, enabling the pce-control option for the LSP has no effect.

This command configures 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.

This command enables or disables 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 the system.

When this command 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 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 set up and the MPLS/RSVP task keeps retrying the request to CSPF. If a path exists that meets the other TE constraints, other than the SRLG one, the bypass or detour LSP is set up.

An FRR bypass or detour LSP 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 performs the following steps.

When 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 will not be considered by the MPLS/RSVP task at the PLR for 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 a make-before-break (MBB) operation. An MBB operation occurs as a result of a global revertive operation, a reoptimization of the LSP path (timer-based or manual), or a user change to any of the path constraints.

When the bypass or detour path is set up and is operationally up, subsequent changes to the SRLG group membership of an interface that the bypass or detour LSP path is using would not be considered by the MPLS/RSVP task at the PLR until the next opportunity that 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 the srlg-frr command takes effect only after LSP paths are resignaled, which is done by shutting down and reenabling MPLS. Another option is using the tools perform router mpls resignal command. While using the tools command might have less service impact, only originating LSPs can be resignaled using the tools command. If local transit and bypass LSPs must also be resignaled, the tools command must be executed on all ingress nodes in the network. The same might 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 when the detour or bypass LSP is in use.

An RSVP interface can belong to a maximum of 64 SRLG groups. Configure the SRLG groups using the config router mpls srlg-group command. Configure the SRLG groups that an RSVP interface belongs to using the srlg-group command in the config>router>mpls>interface context.

The no form of this command reverts to the default value.

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 was 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 then resumes queries into the TE database for SRLG membership information. The user SRLG database is maintained.

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 using the config router mpls user-srlg-db disable command.

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 assumes these interfaces have no SRLG membership association.

The no form of this command deletes all interface entries under the router ID.

This command enable the user to manually enter the SRLG membership information for any link in the network, including links on this node, into the user SRLG database.

An interface can be associated with up to five 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.

CSPF does 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.

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. An in-label can be associated with either a pop or 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.

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.

This command disables the label map definition. This drops all packets that match the in-label specified in the label-map command.

The no form of this command administratively enables the defined label map action.

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.

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 first in order 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.

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.

This command administratively disables the static LSP.

The no form of this command administratively enables the static LSP.

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.

This command configures the value used as the fast retry timer 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 functionality 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 reverts to the default value.

This command configures MPLS protocol support on an IP interface. No MPLS commands are 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 be shut down first 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.

This command associates admin groups with the interface.

The user can apply admin groups to an IES, VPRN, network IP, or MPLS interface. 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 added to a specific interface through multiple operations.

After an admin group is bound to one or more interfaces, its value cannot be changed until all bindings are removed. The configured admin-group membership is applied in all levels and areas the interface is participating in. The same interface cannot have different memberships in different levels or areas.

Only the admin groups bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.

The user can also delete all memberships of an interface by not specifying a group name.

The no form of this command deletes the association of this interface with one or more of the admin groups.

This command defines the association of RSVP interface to an SRLG group. 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.

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. 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. 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 the all SPF paths is 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 by entering the config router mpls lsp cspf use-te-metric 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 reverts to the default value.

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. Notre that 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.

This command configures the make-before-break (MBB) functionality for an LSP or LSP path. When enabled for the LSP, MBB is performed for the primary path and all the secondary paths of the LSP.

This command specifies that the advertised data (ADSPEC) object is 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 both primary paths that signal the ADSPEC object and primary paths that do not. The MTU of 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.

This command enables or disables RSVP-TE LSP to be used as a transport LSP for BGP tunnel routes.

This command configures Constrained Shortest Path First (CSPF) computation for constrained-path LSPs. Constrained-path LSPs are the ones that take configuration constraints into account. CSPF is also used to calculate the detour routes when the fast-reroute command is enabled.

Explicitly configured LSPs where each hop from ingress to egress is specified do not use CSPF. The LSP will be set up using RSVP signaling from ingress to egress.

If an LSP is configured with fast-reroute frr-method specified but does not enable CSPF, neither global revertive nor local revertive is available for the LSP to recover.

This command configures the admin groups to be excluded when an LSP is set up in the primary or secondary contexts.

Each single operation of the exclude command allows a maximum of five groups to be specified at a time. However, a maximum of 32 groups can be specified per LSP by using multiple operations. The admin groups are defined in the config>router>mpls>admin-group context.

The no form of this command removes the exclude command.

This command configures 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.

Fast reroute is available only for the primary path. No configuration is required on the transit hops of the LSP. The ingress router signals all intermediate routers using RSVP to set up their detours. TE must be enabled for fast-reroute to work.

CSPF must be enabled for fast rerouter to work. If an LSP is configured with fast-reroute frr-method specified but without CSPF enabled, neither global revertive nor local revertive is available for the LSP to recover.

The no form of this fast-reroute command removes the detour LSP from each node on the primary path. This command also removes 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.

This command configures reserved bandwidth on the detour path. When configuring an LSP, specify the traffic rate associated with the LSP.

When configuring the fast-reroute command, allocate bandwidth for the rerouted path. The bandwidth rate does not need to be the same as the bandwidth allocated for the LSP.

This command configures how many more routers a detour can traverse compared to the LSP itself on a fast reroute. 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.

The no form of this command reverts to the default value.

This command enables or disables node and link protection on the specified LSP. Node protection ensures that traffic from an LSP traversing a neighboring router reaches its destination even if the neighboring router fails.

This optional command specifies 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.

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.

The no form of this command reverts to the default value.

This command configures the admin groups to be included when an LSP is set up. Up to five groups per operation can be specified, up to 32 maximum.

The no form of this command deletes the specified groups in the specified context.

This command configures the metric for this LSP, which is used to select an LSP among a set of LSPs that are destined to the same egress router. The LSP with the lowest metric is selected.

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 for each 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.

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 is used in cases where the user wants to use the PCE-specific path computation algorithm instead of the local router CSPF algorithm.

The enabling of the pce-computation requires that the cspf option first be enabled; otherwise, 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.

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 only updates the path at the next network event or reoptimization.

The enabling of the pce-control command requires that the cspf option first be enabled; 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.

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.

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.

This optional command specifies the number of attempts software should make to re-establish the LSP after it has failed LSP. After each successful attempt, the counter is reset to zero.

When the specified number is reached, no more attempts are made, and the LSP path is put into the shutdown state.

Use the config router mpls lsp lsp-name no shutdown command to bring up the path after the retry limit is exceeded.

The no form of this command reverts to the default value.

This command configures the time, in seconds, for LSP re-establishment attempts after the LSP has failed.

The no form of this command reverts to the default value.

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.

This command disables the existing LSP including the primary 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.

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 first shut down to delete it.

The no form of this command results in no action except a warning message on the console indicating that the primary path is administratively up.

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, the 7210 SAS 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 7210 SAS software does not switch back between secondary paths.

The 7210 SAS software starts the signaling of all non-standby secondary paths at the same time. Retry counters are maintained for each unsuccessful attempt. When the retry limit is reached on a path, the 7210 SAS software does 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 shutdown first to delete it.

The no secondary path-name command results in no action except a warning message on the console indicating that the secondary path is administratively up.

This command enables the MBB functionality for an LSP or a primary or secondary LSP path. When enabled for the LSP, an MBB operation is performed for primary path and all the secondary paths of the LSP.

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 command specifies the admin groups to be excluded when an LSP is set up. Up to 5 groups per operation can be specified, up to 32 maximum. The admin groups are defined in the config>router>mpls>admin-group context.

The no form of this command removes the exclude command.

This command overrides the config router mpls lsp 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:

The no form of this command reverts to the values defined under the LSP definition using the config router mpls lsp lsp-name hop-limit command.

This command enables the use of path preference among configured standby secondary paths per 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 is not in use. Path preference can be configured on standby secondary path.

The no form of this command reverts to the default value.

This command enables recording of all the 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 path of the LSP. The increase in control traffic per LSP may impact scalability.

The no form of this command disables the recording of all the hops for the specified LSP. There are no restrictions as to when the no command can be used.

The no form of this command also disables the record-label command.

This command enables recording of all the 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 the hops that an LSP path traverses.

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 already be established and in the up state, because 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 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 set up. If CSPF does not find a path, MPLS/RSVP keeps retrying the requests to CSPF.

If CSPF is not enabled on the LSP, 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 command output.

At initial primary LSP path establishment, if primary does not come up or primary is not configured, SRLG secondary is not signaled and is put in the down state. A specific failure code indicates the exact reason for the failure in show router mpls lsp path detail command 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 use it.

As soon as the primary path is configured and successfully established, MPLS/RSVP moves the LSP to the primary and signals all SRLG secondary paths.

Any time the primary path is reoptimized, has undergone MBB, or has come back up after being down, the MPLS/RSVP task checks with CSPF if the SRLG secondary should be resignaled. If MPLS/RSVP finds that the current secondary path is no longer SRLG disjoint, for example, it became ineligible and puts it on a delayed MBB immediately after the expiry of the retry timer. If MBB fails at the first try, the secondary path is torn down and the path is put on retry.

At the next opportunity that the primary path goes down, the LSP uses the path of an eligible SRLG secondary if it is in the up state. If all secondary eligible SLRG paths are in the down state, MPLS/RSVP uses a non SRLG secondary if configured and in the up state. If while the LSP is using a non SRLG secondary, an eligible SRLG secondary came back up, MPLS/RSVP does not switch the path of the LSP to it. As soon as primary is resignaled and comes up with a new SLRG list, MPLS/RSVP resignals the secondary 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 has the ineligibility status removed when any of the following occurs.

When primary path of the LSP is set up and is operationally up, any subsequent changes to the SRLG group membership of an interface the primary path is using would not be considered until the next opportunity the primary path is resignaled. The primary path may be resignaled because of a failure or an MBB operation. MBB occurs as a result of a global revertive operation, a timer-based or manual reoptimization of the LSP path, or an operator change to any of the path constraints.

When an SRLG secondary path is set up and is operationally up, any subsequent changes to the SRLG group membership of an interface the secondary path is using would not be considered until the next opportunity the secondary path is resignaled. The secondary path is resignaled because of a failure, a resignaling of the primary path, or an MBB operation. MBB 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.

Also, the user-configured include or exclude admin group statements for this secondary path are also checked together with the SRLG constraints by CSPF.

The no form of this command reverts to the default value.

The secondary path LSP is normally signaled when the primary path LSP fails. The standby command 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.

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 the last hop. A hop list can include the ingress interface IP address, the system IP address, and the egress IP address of any of the hops being specified.

The no form of this command deletes hop list entries for the path. All the LSPs currently using this path are affected. Additionally, all services actively using these LSPs are affected. The path must be shut down first to delete the hop from the hop list. The no hop hop-index command results in no action except a warning message on the console indicating that the path is administratively up.

This command configures a global parameter to apply a shorter retry timer for the first try after an active LSP path went down because of a local failure or the receipt of a RESVTear. This timer is used only on the first try. Subsequent retries continue to be governed by the existing LSP level retry timer.

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 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 shut down, any LSP using the path becomes operationally down.

To create a strict path from the ingress to the egress router, the ingress and 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 are affected. All the services that are actively using these LSPs are also 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 results in no action except a warning message on the console indicating that the path may be in use.

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 as standby secondary are established or re-established.

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 LSP must be shut down first 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.

The no form of this command deletes this static LSP and associated information.

This command specifies the label to be pushed onto 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.

This command administratively disables the static LSP.

The no form of this command administratively enables the static LSP.

This command configures the system IP address of the egress router for the static LSP. This command is required when creating an LSP. For LSPs that are used as transport tunnels for services, the to IP address must be the system IP address.

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 the RSVP sessions are torn down. The existing configuration is retained.

The no form of this command administratively enables RSVP on the interface.

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.

This command enables the use of bi-directional 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.

Configure the BFD session parameters, such as transmit-interval, receive-interval, and multiplier, under the IP interface in the config>router>interface>bfd context.

It is possible that the BFD session on the interface was 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 at the time the neighbor gets its first session, which is when this node sends or receives a new Path message over the interface. However, if the session does not come up, because of not receiving 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 independent of whether an RSVP hello is enabled on the interface. However, hello timeout clears all sessions towards 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 registers with the BFD session running with each of those neighbors independently.

Similarly, the disabling of 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:

Note: For more information about the list of protocols that support BFD, refer to the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide.

The no form of this command removes BFD from the associated RSVP protocol adjacency.

This command initiates a graceful shutdown of the specified RSVP interface (maintenance interface) or all RSVP interfaces on the node (maintenance node), if applied at the RSVP level.

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 MBB 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 resignals 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 TE metric set to 0xffffffff and the unreserved bandwidth parameter set to zero.

A head-end LER node, upon receipt of the PathErr message, performs a single MBB 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:

The head-end LER node, upon receipt of the updates IPG TE LSA/LSP for the maintenance interfaces, updates the TE database. This information is used at the next scheduled CSPF computation for any LSP with a path that traverses any of the maintenance interfaces.

The no form of this command disables the graceful shutdown operation at the RSVP interface level or the RSVP level. The configured TE parameters of the maintenance links are restored and the maintenance node floods the links.

This command specifies 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.

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 command 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. The node will also not send Message-ID in RSVP messages. This effectively disables summary refresh.

This command configures the value of the rapid retransmission interval. This is used in the retransmission mechanism based on an exponential backoff timer to handle unacknowledged message_id objects.

The RSVP-TE message with the same message-id is retransmitted every 2 × rapid-retransmit-time interval.

The node stops the retransmission of unacknowledged RSVP messages in the following cases when the updated backoff interval exceeds the value of the regular refresh interval or when 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 using the config router rsvp refresh-time command.

The no form of this command reverts to the default value.

This command configures the value of the rapid retry limit. This is used in the retransmission mechanism based on an exponential backoff timer in order to handle unacknowledged message_id objects. The RSVP message with the same message_id is retransmitted every 2 × rapid-retransmit-time interval.

The node stops the 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 command, whichever comes first.

The no form of this command reverts to the default value.

This command configures the interval between the successive Path and Resv refresh messages. RSVP declares the session down after it misses the consecutive refresh messages value configured in the keep-multiplier command.

The no form of this command reverts to the default value.

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, that 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.

This command configures the authentication key 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:

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 that also contains a flags field, a key identifier field, and a sequence number field. The RSVP sender complies with 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.

The MD5 implementation does not support the authentication challenge procedures in RFC 2747.

The no form of this command disables authentication.

This command configures the time interval between RSVP hello messages.

RSVP hello packets detect loss of RSVP connectivity with the neighboring node. Hello packets detect the loss of the neighbor more quickly than it would take for the RSVP session to time out based on the refresh interval. After the loss of the of 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. To disable sending hello messages, set the value to zero.

This command enables the use of the implicit null label for all LSPs signaled by RSVP on the node.

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 signals the implicit null label. If the egress LER is also the merge-point (MP) node, the incoming interface for the path refresh message over the bypass dictates whether the packet uses the implicit null label. The same is true for a 1-to-1 detour LSP.

The RSVP interface must be shut down before changing the implicit-null-label command.

The no form of this command reverts the RSVP interface to using the RSVP level configuration value.

This command enables the use of the RSVP overhead refresh reduction capabilities on this RSVP interface.

The no form of this command reverts to the default value.

This command configures reliable delivery of RSVP messages over the RSVP interface. When the refresh-reduction command is enabled on an interface and the reliable-delivery command is disabled, the router sends a message_id and not set ACK desired in the RSVP messages over the interface. The router does not expect an ACK but accepts it if received. The node also accepts message IDs and replies with an ACK when requested. In this case, if the neighbor set 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 to this message from the neighbor.

Finally, when the reliable-delivery command is enabled on any interface, RSVP message pacing is disabled on all RSVP interfaces on 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. 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 also generated in the CLI after such an attempt.

The no form of this command reverts to the default value.

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 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 to the default value.

This command configures RSVP message pacing, in 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 are dropped because the output queue for the interface used for message pacing is full.

This command configures the maximum number of RSVP messages that are sent in the specified period under normal operating conditions.

This command configures the time interval, in milliseconds, during which the router can send the specified number of RSVP messages, as specified in the max-burst command.

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 that serves as a backup for a set of LSPs. Such an LSP tunnel is called a bypass tunnel.

This command displays MPLS interface information.

This command displays MPLS labels exchanged.

This command displays the MPLS label range.

This command displays LSP details.

This command displays MPLS SRLG database information.

This command displays MPLS paths.

This command displays MPLS static LSP information.

This command displays MPLS operation information.

This command shows RSVP interfaces.

This command shows neighbor information.

This command shows RSVP session information.

This command displays global statistics in the RSVP instance.

This command displays RSVP status.