Interface Commands
Page 168 7210 SAS M, T, X, R6, Mxp MPLS Configuration
Guide
The RSVP sender complies to the procedures for RSVP message generation in RFC 2747, RSVP
Cryptographic Authentication.
A 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.
Default no authentication-key - The authentication key value is the null string.
Parameters authentication-key — 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.
hash-key — 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 — Specifies 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 — Specifies 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
Description 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.
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.
Note that 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 of neighbor gets its first
session. This means when this node sends or receives a new Path message over the interface. If
however the session did not come up, due to not receiving a Resv for a new path message sent after
the maximum number of re-tries, the LSP is shutdown and the node de-registers 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 RSVP hello is
enabled on the interface or not. However, hello timeout will clear all sessions towards the neighbor
and RSVP de-registers with BFD at clearing of the last session.
Note that 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, then each interface is treated as a