Limitations and Precautions for BFD

Read this section carefully to learn the limitations and precautions before you configure BFD.

All models support BFD for IPv4 and BFD for IPv6 functions.
All models except the USG6510E/6510E-POE/6530E support interworking between static BFD and hot standby.

The BFD function is not license-controlled.

Multicast address detection is supported only in BFD for IPv4 but not BFD for IPv6.
In mirroring mode, hot standby cannot interwork with BFD.
In mirroring mode, the standby FW does not send BFD packets. Therefore, its BFD status is always Down. If hrp track bfd-session is configured, the VGMP group to which the standby FW belongs decreases its priority by 2. Therefore, if the BFD status or an interface of the active FW becomes Down, the active/standby switchover does not take place.
In hot standby scenarios, BFD configurations do not support backup. You must configure them on both FWs.
In inter-DC cluster scenarios, BFD configurations do not support backup. You must configure them on the cluster members independently.
Virtual systems do not support the BFD function.
When the FW functions as the two ends of a BFD session, you cannot create tunnels excluding IPSec at both ends. Otherwise, the BFD session cannot go Up. This is because the FW does not support tunnel (excluding the IPSec tunnel) encryption and decryption for BFD packets.

When the network is in poor quality or overloaded, increase the BFD detection interval as required.
When the FW functions as the two ends of a BFD session, a larger BFD detection interval is recommended if any other NE on the link between the two ends uses a low-speed interface (such as virtual template, dialer, or tunnel interface) or the IPSec or L2TP tunnel.
If the FW is deployed between two routers, and the routers detect each other through BFD, you are advised to properly prolong the BFD time (longer than 100 ms is recommended) to prevent BFD flapping resulting from occasional network congestion.