This is the documentation for the 20.02 version. Looking for the documentation of the latest version? Have a look here.
BFD Session Authentication¶
TNSR supports SHA1 and meticulous SHA1 authentication. In either mode, a secret key is used to create a hash of the outgoing packets. The key itself is not sent in the packets, only the hash and the ID of the key.
A sequence number is used to help avoid replay attacks. With SHA1, this sequence number is incremented occasionally. With meticulous SHA1, the sequence number is incremented on every packet.
The receiving peer will check for a key matching the given ID and then compare a hash of the BFD payload against the hash sent by the peer. If it matches and the sequence number is valid, the packet is accepted.
Define BFD Keys¶
There are two keys defined for each BFD session:
The Configuration Key ID. An unsigned 32-bit integer which identifies an internal unique key in TNSR. Neither the key itself nor this ID are ever communicated to peers. The secret component of this key must be generated outside of TNSR. It is a group of 1 to 20 hex pair values, such as
The BFD key ID. An unsigned 8-bit integer (
0-255) which is the key ID carried in BFD packets, used for verifying authentication.
bfd-key-id must be specified, or
neither can be present.
To define a new configuration key ID:
tnsr(config)# bfd conf-key-id <conf-key-id> tnsr(config-bfd-key)# authentication type (keyed-sha1|meticulous-keyed-sha1) tnsr(config-bfd-key)# secret < (<hex-pair>)[1-20] >
tnsr(config)# bfd conf-key-id 123456789 tnsr(config-bfd-key)# authentication type meticulous-keyed-sha1 tnsr(config-bfd-key)# secret 4a40369b4df32ed0652b548400
Setup BFD Authentication¶
Authentication will only be active if both the
conf-key-id are defined for a BFD session.
delayed keyword is also supported for BFD session which tells
BFD to hold off any authentication action when receiving BFD messages until a
peer attempts to authenticate or uses new credentials.
Only one host can have the
delayed option enabled,
otherwise credentials will never update as both peers will be waiting on the
other one to act first.
BFD implementations vary, so authentication changes may disrupt
live BFD sessions. The best practice to avoiding disruption when operating
with third party BFD implementations is to set
delayed on the TNSR side.
When adding authentication to an existing BFD session, or changing active
authentication settings, make the changes first on the node with
set then configure the peer to match.
To activate authentication, add the chosen identifiers to a BFD session:
tnsr(config)# bfd session <bfd-session> tnsr(config-bfd)# bfd-key-id <bfd-key-id> tnsr(config-bfd)# conf-key-id <conf-key-id> tnsr(config-bfd)# delayed (true|false) tnsr(config-bfd)# exit
tnsr(config)# bfd session otherrouter tnsr(config-bfd)# bfd-key-id 123 tnsr(config-bfd)# conf-key-id 123456789 tnsr(config-bfd)# delayed false tnsr(config-bfd)# exit
View BFD Keys¶
To view a list of keys and their types, use the
show bfd keys command:
tnsr# show bfd keys Conf Key Type Use Count --------- --------------------- ---------- 123456789 meticulous-keyed-sha1 1 234567890 keyed-sha1 0
To view only one specific key, pass its ID to the same command:
tnsr# show bfd keys conf-key-id 123456789 Conf Key Type Use Count --------- --------------------- ---------- 123456789 meticulous-keyed-sha1 1