# BFD module {#bfd_doc} ## Overview Bidirectional Forwarding Detection in VPP currently supports single-hop UDP transport based on RFC 5880 and RFC 5881. ## Usage ### General usage BFD sessions are created using APIs only. The following CLIs are implemented, which call the APIs to manipulate the BFD: #### Show commands: > show bfd [keys|sessions|echo-source] Show the existing keys, sessions or echo-source. #### Key manipulation ##### Create a new key or modify an existing key > bfd key set conf-key-id type secret Parameters: * conf-key-id - local configuration key ID, used to uniquely identify this key * type - type of the key * secret - shared secret (hex data) Example: > bfd key set conf-key-id 2368880803 type meticulous-keyed-sha1 secret 69d685b0d990cdba46872706dc Notes: * in-use key cannot be modified ##### Delete an existing key > bfd key del conf-key-id Parameters: * conf-key-id - local configuration key ID, used to uniquely identify this key Example: > bfd key del conf-key-id 2368880803 Notes: * in-use key cannot be deleted ##### Create a new (plain or authenticated) BFD session > bfd udp session add interface local-addr
peer-addr
desired-min-tx required-min-rx detect-mult [ conf-key-id bfd-key-id ] Parameters: * interface - interface to which this session is tied to * local-addr - local address (ipv4 or ipv6) * peer-addr - peer address (ipv4 or ipv6, must match local-addr family) * desired-min-tx - desired minimum tx interval (microseconds) * required-min-rx - required minimum rx interval (microseconds) * detect-mult - detect multiplier (must be non-zero) * conf-key-id - local configuration key ID * bfd-key-id - BFD key ID, as carried in BFD control frames Example: > bfd udp session add interface pg0 local-addr fd01:1::1 peer-addr fd01:1::2 desired-min-tx 100000 required-min-rx 100000 detect-mult 3 conf-key-id 1029559112 bfd-key-id 13 Notes: * if conf-key-id and bfd-key-id are not specified, session is non-authenticated * desired-min-tx controls desired transmission rate of both control frames and echo packets ##### Modify BFD session > bfd udp session mod interface local-addr
peer-addr
desired-min-tx required-min-rx detect-mult Parameters: * interface - interface to which this session is tied to * local-addr - local address (ipv4 or ipv6) * peer-addr - peer address (ipv4 or ipv6, must match local-addr family) * desired-min-tx - desired minimum tx interval (microseconds) * required-min-rx - required minimum rx interval (microseconds) * detect-mult - detect multiplier (must be non-zero) Example: > bfd udp session mod interface pg0 local-addr 172.16.1.1 peer-addr 172.16.1.2 desired-min-tx 300000 required-min-rx 200000 detect-mult 12 Notes: * desired-min-tx controls desired transmission rate of both control frames and echo packets ##### Delete an existing BFD session > bfd udp session del interface local-addr
peer-addr
Parameters: * interface - interface to which this session is tied to * local-addr - local address (ipv4 or ipv6) * peer-addr - peer address (ipv4 or ipv6, must match local-addr family) Example: > bfd udp session del interface pg0 local-addr 172.16.1.1 peer-addr 172.16.1.2 ##### Set session admin-up or admin-down > bfd udp session set-flags interface local-addr
peer-addr
admin Parameters: * interface - interface to which this session is tied to * local-addr - local address (ipv4 or ipv6) * peer-addr - peer address (ipv4 or ipv6, must match local-addr family) * admin - up/down based on desired action Example: > bfd udp session set-flags admin down interface pg0 local-addr 172.16.1.1 peer-addr 172.16.1.2 ##### Activate/change authentication for existing session > bfd udp session auth activate interface local-addr
peer-addr
conf-key-id bfd-key-id [ delayed ] Parameters: * interface - interface to which this session is tied to * local-addr - local address (ipv4 or ipv6) * peer-addr - peer address (ipv4 or ipv6, must match local-addr family) * conf-key-id - local configuration key ID * bfd-key-id - BFD key ID, as carried in BFD control frames * delayed - is yes then this action is delayed until the peer performs the same action Example: > bfd udp session auth activate interface pg0 local-addr 172.16.1.1 peer-addr 172.16.1.2 conf-key-id 540928695 bfd-key-id 239 delayed yes Notes: * see [Delayed option] for more information ##### Deactivate authentication for existing session > bfd udp session auth deactivate interface local-addr
peer-addr
[ delayed ] Parameters: * interface - interface to which this session is tied to * local-addr - local address (ipv4 or ipv6) * peer-addr - peer address (ipv4 or ipv6, must match local-addr family) * delayed - is yes then this action is delayed until the peer performs the same action Example: > bfd udp session auth deactivate interface pg0 local-addr 172.16.1.1 peer-addr 172.16.1.2 Notes: * see [Delayed option] for more information ##### Set echo-source interface > bfd udp echo-source set interface Parameters: * interface - interface used for getting source address for echo packets Example: > bfd udp echo-source set interface loop0 ##### Delete echo-source interface > bfd udp echo-source del Example: > bfd udp echo-source del ### Authentication BFD sessions should be authenticated for security purposes. SHA1 and meticulous SHA1 authentication is supported by VPP. First, authentication keys are configured in VPP and afterwards they can be used by sessions. There are two key IDs in the scope of BFD session: * configuration key ID is the internal unique key ID inside VPP and is never communicated to any peer, it serves only the purpose of identifying the key * BFD key ID is the key ID carried in BFD control frames and is used for verifying authentication #### Turning auth on/off Authentication can be turned on or off at any time. Care must be taken however, to either synchronize the authentication manipulation with peer's actions to avoid the session going down. ##### Delayed option Delayed option is useful for synchronizing authentication changes with a peer. If it's specified, then authentication change is not performed immediately. In this case, VPP continues to transmit packets using the old authentication method (unauthenticated or using old sha1 key). If a packet is received, which does not pass the current authentication, then VPP tries to authenticate it using the new method (which might be none, if deactivating authentication) and if it passes, then the new authentication method is put in use. The recommended procedure for enabling/changing/disabling session authentication is: 1. perform authentication change on vpp's side with delayed option set to yes 2. perform authentication change on peer's side (without delayed option) Notes: * if both peers use delayed option at the same time, the change will never be carried out, since none of the peers will see any packet with the new authentication which could trigger the change * remote peer does not need to support or even be aware of this mechanism for it to work properly ### Echo function Echo function is used by VPP whenever a peer declares the willingness to support it, echo-source is set and it contains a usable subnet (see below). When echo function is switched on, the required min rx interval advertised to peer is set to 1 second (or the configured value, if its higher). #### Echo source address Because echo packets are only looped back (and not processed in any way) by a peer, it's necessary to set the source address in a way which avoids packet drop due to spoofing protection by VPP. Per RFC, the source address should not be in the subnet set on the interface over which the echo packets are sent. Also, it must not be any VPP-local address, otherwise the packet gets dropped on receipt by VPP. The solution is to create a loopback interface with a (private) IPv4/IPv6 subnet assigned as echo-source. The BFD then picks an unused address from the subnet by flipping the last bit and uses that as source address in the echo packets, thus meeting RFC recommendation while avoiding spoofing protection. Example: if 10.10.10.3/31 is the subnet, then 10.10.10.2 will be used as source address