BFD Considerations and Limitations

Consider the following when configuring BFD:
  • BFD asynchronous mode, which is based on the sending of BFD control packets between two systems to activate and maintain BFD neighbor sessions between devices, is supported. This means that for a BFD session to be created, BFD must be configured on both BFD peers.
  • If a LAG port goes down, an attempt is made to keep the BFD session active by moving the BFD session to the next available LAG member port so that the control path is not affected.
  • A maximum of 256 BFD sessions are supported.
  • A maximum number of 100 micro-BFD sessions are supported.
  • BFD supports both single-hop and multi-hop sessions.
  • BFD is not supported for tunnel and management interfaces.
  • Micro-BFD and Multi-hop-BFD cannot be enabled at the same time. Enabling micro-BFD automatically disables multi-hop for BFD. Switching from one mode to another requires a system reboot.
  • BFD sessions cannot be formed with overlapping addresses across VRFs.
  • BFD runs on data ports.
  • If ARP is not resolved for a neighbor when a BFD session is being set up, the ARP resolution process is initiated. Once ARP is resolved, the micro-controller is notified and the process of initiating a BFD session begins. If there is any change in the ARP, the BFD session is modified. When any ARP entry in use by a BFD session ages out, all respective BFD sessions are torn down. Therefore, the ARP application continually refreshes the ARP entries without aging them out as long as the next hop is reachable.
  • Multi-VRF is supported. For multi-hop sessions, the peer must be reached only through the VRF associated with the BFD session.
  • BFD session creation across multiple VRFs is not supported for overlapping IP addresses.
  • If Graceful Restart (GR) is configured, it is recommended to configure the holdover timer for all applications so that a peer does not immediately process a session failure notification, but instead waits for a specified time period in case a restarting router comes up. Refer to Holdpver Timer for more information.
  • If multiple applications initiate the same BFD session with a separate set of configuration parameters, the minimum value of the configuration parameters is considered to program the session by the micro-controller.
  • If one application configures a BFD session as active while a different application configures the same BFD session as passive, the BFD session will be programmed as passive by the micro-controller.
  • After BFD session information is passed to the micro-controller, the micro-controller can establish the BFD session and maintain the state machines on its own, tracking the session for any state changes and notifying BFD when necessary.
  • BFD is only supported for symmetric routing.
  • Micro-BFD should always be used for LAG interfaces.
  • OSPFv3 BFD sessions across overlapping link local addresses is not supported. For example, if an OSPFv3 BFD session is established on a VE between fe80::1 and fe80::100, where fe80::1 is the local IP and fe80::100 is the IP on the peer. OSPFv3 BFD sessions on another VE will not come up between fe80::1 and fe80::100. The link local address on the remote peer must be changed to a different value for OSPFv3 BFD sessions to come up.
  • For multi-unit LAGs, it is recommended to use Micro-BFD. Multi-hop BFD is not supported if micro-BFD is enabled.
  • BFD is supported for ICX 7850 platforms.
  • In a stack setup, a BFD session is programmed on the unit where the tx-port is present. Incoming BFD packets must be received on the same unit.
  • BFD IPv6 sessions are not allowed for the IPv6 address 0xFC00::/7 as this is a reserved address. 
  • BFD configuration on MCT setup is not supported but the configuration is not restricted.
Parent topic: BFD