Bug #12965
openFRR BFD peer configuration is handled incorrectly in some cases
0%
Description
FRR / Status / All):
- Interface: Default; Local Address: <non-default selection>
- Interface: <non-default selection>; Local Address: Default
Additionally, the BFD peer configuration page does not allow the selection of Virtual IPs. This can be problematic in cases where a BGP Neighbor uses BFD and is set to use a localhost VIP as the Update Source - in which case the BFD session can only be established when no BFD peer entry exists. This also forces the session to use default settings. For example:
When no BFD peer configuration exists and a BGP Neighbor is set to use BFD, the BFD Peer drop-down list within the neighbor configuration is empty, and saving the configuration results in a peer session being established correctly:
BFD Peers:
peer 10.255.5.1 multihop local-address 10.255.5.2 vrf default
ID: 1961905122
Remote ID: 2893233196
Active mode
Minimum TTL: 254
Status: up
Uptime: 31 minute(s), 12 second(s)
Diagnostics: ok
Remote diagnostics: ok
Peer Type: dynamic
Local timers:
Detect-multiplier: 3
Receive interval: 300ms
Transmission interval: 300ms
Echo transmission interval: 50ms
Remote timers:
Detect-multiplier: 3
Receive interval: 300ms
Transmission interval: 300ms
Echo transmission interval: 50ms
Presumably this is the "default" behavior referenced in the drop-down list's field description.
If a BFD peer configuration entry does exist, this "default" behavior is lost and the drop-down list forces a selection. This can potentially lead to a BGP Neighbor configuration with an incorrect BFD peer, and it no longer allows for a BFD session to be established with a VIP Local Source Address.
Lastly, editing a BFD peer entry always defaults the Profile option to None. Selecting a profile and clicking Save correctly writes the configuration, but the option must be re-selected on every edit.