MPLS and RSVP-TE
226
MPLS Guide
© 2022 Nokia.
Use subject to Terms available at: www.nokia.com
3HE 18686 AAAB TQZZA
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.
Default no authentication-key — the authentication key value is the null string
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, etc.), 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 — 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.
hash2 — 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.
bfd-enable
Syntax [no] bfd-enable
Context config>router>rsvp>interface
Description 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.
To Next Page
Loading...
