[no] interface ip-int-name
config>router>rsvp
This command enables RSVP-TE protocol support on an IP interface. No RSVP-TE commands are executed on an IP interface where RSVP-TE is not enabled.
The no form of this command deletes all RSVP-TE commands such as hello-interval and subscription, which are defined for the interface. The RSVP-TE interface must be shut down 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.
specifies the network IP interface. The interface name cannot be in the form of an IP address. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes.
auth-keychain name
no auth-keychain
config>router>rsvp>interface
This command associates an authentication keychain with the RSVP-TE interface. The keychain is a collection of keys used to authenticate RSVP-TE messages from remote peers. The keychain allows the rollover of authentication keys during the lifetime of a session and also supports stronger authentication algorithms than clear text and MD5.
The keychain must already be defined in the config>system>security>keychain context.
Either the authentication-key command or the auth-keychain command can be used by RSVP-TE, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.
By default, authentication is not enabled.
no auth-keychain
the name of an existing keychain, up to 32 characters
authentication-key {authentication-key|hash-key}[hash | hash2]
no authentication-key
config>router>rsvp>interface
This command specifies the authentication key to be used between RSVP-TE neighbors to authenticate RSVP-TE messages. Authentication uses the MD5 message-based digest.
When enabled on an RSVP-TE interface, authentication of RSVP-TE messages operates in both directions of the interface.
A 7705 SAR 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:
the HMAC-MD5 authentication algorithm
the key used with the authentication algorithm
the lifetime of the key; the user-entered key is valid until the user deletes it from the interface
the source address of the sending system
the latest sending sequence number used with this key identifier
A 7705 SAR RSVP-TE sender transmits an authenticating digest of the RSVP-TE 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 7705 SAR RSVP-TE sender complies with the procedures for RSVP-TE message generation in RFC 2747, RSVP Cryptographic Authentication.
A 7705 SAR RSVP-TE receiver uses the key together with the authentication algorithm to process received RSVP-TE 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-TE messages sent over the bypass tunnel. If the PLR receives an RSVP-TE message with an integrity object, it will perform the digest verification for the key of the interface over which the packet was received. If this fails, the packet is dropped. If the received RSVP-TE message is an RESV message and does not have an integrity object, then the PLR node will accept it only if it originated from the MP node.
A 7705 SAR MP node will accept RSVP-TE messages received over the bypass tunnel with and without the integrity object. If an integrity object is present, the proper digest verification for the key of the interface over which the packet was received is performed. If this fails, the packet is dropped.
The 7705 SAR MD5 implementation does not support the authentication challenge procedures in RFC 2747.
Either the authentication-key command or the auth-keychain command can be used by RSVP-TE, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.
The no form of this command disables authentication.
no authentication-key — the authentication key value is the null string
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, etc.), the entire string must be enclosed within double quotes.
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.
specifies the key is entered in an encrypted form. If the hash keyword 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.
specifies the key is entered in a more complex encrypted form. If the hash2 keyword is not used, the less-encrypted hash form is assumed.
[no] bfd-enable
config>router>rsvp>interface
This command enables the use of bidirectional forwarding (BFD) to control the state of the associated RSVP-TE interface. This causes RSVP-TE 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>if>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-TE 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 due to not receiving an 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-TE with BFD is removed as soon as the last RSVP-TE session is cleared.
The registration of an RSVP-TE interface with BFD is performed independently of whether RSVP-TE hello is enabled on the interface or not. However, hello timeout clears all sessions toward the neighbor and RSVP-TE deregisters with BFD at the clearing of the last session.
An RSVP-TE session is associated with a neighbor based on the interface address that the PATH message is sent to. If multiple interfaces exist to the same node, each interface is treated as a separate RSVP-TE neighbor. The user must enable BFD on each interface, and RSVP-TE 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-TE 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-TE protocol adjacency.
no bfd-enable
hello-interval milli-seconds
no hello-interval
config>router>rsvp>interface
This command configures the time interval between RSVP-TE hello messages.
RSVP-TE hello packets are used to detect loss of RSVP-TE connectivity with the neighboring node. Hello packets detect the loss of a neighbor more quickly than it would take for the RSVP-TE 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 of the hello-interval. To disable sending hello messages, set the value to zero.
3000
specifies the RSVP-TE hello interval in milliseconds, in multiples of 1000. A 0 (zero) value disables the sending of RSVP-TE hello messages.
implicit-null-label {enable | disable}
no implicit-null-label
config>router>rsvp>interface
This command enables or disables the use of the implicit null label over a specific RSVP-TE interface.
The implicit null label is enabled for all LSPs for which the router is the eLER and for which the PATH message is received from the previous-hop LSR over the RSVP-TE interface.
With facility backup, if the eLER is also the merge point (MP) node, the incoming interface for the PATH refresh message over the bypass tunnel dictates whether the packet will use the implicit null label. Similarly, with one-to-one backup, if the eLER is also the detour merge point (DMP) node, the incoming interface for the PATH refresh message over the detour LSP dictates whether the packet will use the implicit null label.
By default, an RSVP-TE interface inherits the RSVP-TE level configuration.
The interface must be shut down before this command can be used.
The no form of this command resets the interface to the RSVP-TE level configuration.
no implicit-null-label
enables the implicit null label on the interface
disables the implicit null label on the interface
[no] refresh-reduction
config>router>rsvp>interface
This command enables the use of the RSVP-TE overhead refresh reduction capabilities on this RSVP-TE interface.
When this option is enabled, a 7705 SAR node will enable support for three capabilities:
it will accept bundle RSVP-TE messages from its peer over this interface
it will attempt to perform reliable RSVP-TE message delivery to its peer
it will use summary refresh messages to refresh PATH and RESV states
The reliable message delivery must be explicitly enabled by the user after refresh reduction is enabled. The other two capabilities are enabled immediately.
A bundle RSVP-TE message is intended to reduce the overall message handling load. A bundle message consists of a bundle header followed by one or more bundle sub-messages. A sub-message can be any regular RSVP-TE message except another bundle message. A 7705 SAR node will only process received bundle RSVP-TE messages but will not generate them.
When reliable RSVP-TE message delivery is supported by both the node and its peer over the RSVP-TE interface, an RSVP-TE message is sent with a message_id object. A message_id object can be added to any RSVP-TE message when sent individually or as a sub-message of a bundle message.
If the sender sets the ack_desired flag in the message_id object, the receiver acknowledges the receipt of the RSVP-TE message by piggy-backing a message_ack object to the next RSVP-TE message it sends to its peer. Alternatively, an ACK message can also be used to send the message_ack object. In both cases, one or many message_ack objects could be included in the same message.
The 7705 SAR supports the sending of separate ACK messages only, but is capable of processing received message_ack objects piggy-backed to hop-by-hop RSVP-TE messages, such as PATH and RESV.
The 7705 SAR sets the ack_desired flag only in non-refresh RSVP-TE messages and in refresh messages that contain new state information.
A retransmission mechanism based on an exponential backoff timer is supported in order to handle unacknowledged message_id objects. The RSVP-TE message with the same message_id is retransmitted 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.
There is also a maximum number of retransmissions of an unacknowledged RSVP-TE message rapid-retry-limit. The node will stop retransmission of unacknowledged RSVP-TE messages whenever the updated backoff interval exceeds the value of the regular refresh-time interval or the number of retransmissions reaches the value of the rapid-retry-limit parameter, whichever comes first. These two parameters are configurable globally on a system in the config>router>rsvp context.
Summary refresh consists of sending a summary refresh message containing a message_id list object. The fields of this object are populated each with the value of the message_identifier field in the message_id object of a previously sent individual PATH or RESV message. The summary refresh message is sent every refresh regular interval as 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 as if a regular PATH or RESV refresh message was received from the peer. If a specific message_identifier field does not match, then the node sends a message_id_nack object to the originator of the message.
The above capabilities are referred to collectively as ‟refresh overhead reduction extensions”. When the refresh-reduction is enabled on a 7705 SAR RSVP-TE interface, the node indicates this to its peer by setting a ‟refresh-reduction-capable” bit in the flags field of the common RSVP-TE header. If both peers of an RSVP-TE interface set this bit, all the above three capabilities can be used. Furthermore, the node monitors the settings of this bit in received RSVP-TE messages from the peer on the interface. As soon as this bit is cleared, the 7705 SAR stops sending summary refresh messages. If a peer did not set the ‟refresh-reduction-capable” bit, a node does not attempt to send summary refresh messages.
However, if the peer did not set the ‟refresh-reduction-capable” bit, then a node with refresh reduction enabled and reliable message delivery enabled will still attempt to perform reliable message delivery with this peer. If the peer does not support the message_id object, it returns the error message ‟unknown object class”. In this case, the 7705 SAR node retransmits the RSVP-TE message without the message_id object and reverts to using this method for future messages destined for this peer.
The no form of the command reverts to the default value.
no refresh-reduction
[no] reliable-delivery
config>router>rsvp>if>refresh-reduction
This command enables reliable delivery of RSVP-TE messages over the RSVP-TE interface. When refresh-reduction is enabled on an interface and reliable-delivery is disabled, then the 7705 SAR will send a message_id and not set ACK desired in the RSVP-TE messages over the interface.
The 7705 SAR does not expect an ACK but will accept it if received. The node will also accept message ID and reply 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-TE header, the node will enter 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-TE message pacing is disabled on all RSVP-TE 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 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 will also be generated in CLI after such an attempt.
The no form of the command reverts to the default value.
no reliable-delivery
subscription percentage
no subscription
config>router>rsvp>interface
This command configures the percentage of the link bandwidth that RSVP-TE 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 is exceeded, the reservation is rejected and a log message is generated.
The no form of this command resets the percentage to the default value.
100
specifies the percentage of the interface’s bandwidth that RSVP-TE allows to be used for reservations