[no] interface ip-int-name
config>router>rsvp
Supported on all 7210 SAS platforms as described in this document.
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.
shutdown
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 [authentication-key | hash-key] [hash | hash2]
no authentication-key
config>router>rsvp>interface
Supported on all 7210 SAS platforms as described in this document.
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.
no 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.
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.
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.
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.
[no] bfd-enable
config>router>rsvp>interface
Supported on all 7210 SAS platforms as described in this document.
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.
no bfd-enable
hello-interval milli-seconds
no hello-interval
config>router>rsvp>interface
Supported on all 7210 SAS platforms as described in this document.
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.
hello-interval 3000
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 [enable | disable]
no implicit-null-label
config>router>rsvp
Supported on all 7210 SAS platforms as described in this document.
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.
implicit-null disable
Keyword to enable the implicit null label.
Keyword to disable the implicit null label.
[no] refresh-reduction
config>router>rsvp>interface
Supported on all 7210 SAS platforms as described in this document.
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.
no refresh-reduction
[no] reliable-delivery
config>router>rsvp>interface>refresh-reduction
Supported on all 7210 SAS platforms as described in this document.
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.
no reliable-delivery
subscription percentage
no subscription
config>router>rsvp>interface
Supported on all 7210 SAS platforms as described in this document.
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.
subscription 100
Specifies the percentage of the interface bandwidth that RSVP allows to be used for reservations.