When you enable BFD, BFD establishes a session from one endpoint (the firewall) to its BFD peer at the endpoint of a link using a three-way handshake. Control packets perform the handshake and negotiate the parameters configured in the BFD profile, including the minimum intervals at which the peers can send and receive control packets. BFD control packets for both IPv4 and IPv6 are transmitted over UDP port 3784. BFD control packets for multihop support are transmitted over UDP port 4784. BFD control packets transmitted over either port are encapsulated in the UDP packets.
After the BFD session is established, the Palo Alto Networks implementation of BFD operates in asynchronous mode, meaning both endpoints send each other control packets (which function like Hello packets) at the negotiated interval. If a peer does not receive a control packet within the detection time (calculated as the negotiated transmit interval multiplied by a Detection Time Multiplier), the peer considers the session down. (The firewall does not support demand mode, in which control packets are sent only if necessary rather than periodically.)
When you enable BFD for a static route and a BFD session between the firewall and the BFD peer fails, the firewall removes the failed route from the RIB and FIB tables and allows an alternate path with a lower priority to take over. When you enable BFD for a routing protocol, BFD notifies the routing protocol to switch to an alternate path to the peer. Thus, the firewall and BFD peer reconverge on a new path.
A BFD profile allows you to Configure BFD settings and apply them to one or more routing protocols or static routes on the firewall. If you enable BFD without configuring a profile, the firewall uses its default BFD profile (with all of the default settings). You cannot change the default BFD profile.
When an interface is running multiple protocols that use different BFD profiles, BFD uses the profile having the lowest Desired Minimum Tx Interval. See BFD for Dynamic Routing Protocols.
Active/passive HA peers synchronize BFD configurations and sessions; active/active HA peers do not.
BFD is standardized in RFC 5880. PAN-OS does not support all components of RFC 5880; see Non-Supported RFC Components of BFD.
PAN-OS also supports RFC 5881, Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop). In this case, BFD tracks a single hop between two systems that use IPv4 or IPv6, so the two systems are directly connected to each other. BFD also tracks multiple hops from peers connected by BGP. PAN-OS follows BFD encapsulation as described in RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths. However, PAN-OS does not support authentication.
BFD Platform, Interface, and Client Support
PAN-OS supports BFD on PA-3000 Series, PA-5000 Series, PA-7000 Series, and VM-Series firewalls. Each platform supports a maximum number of BFD sessions, as listed in the Product Selection tool.
BFD runs on physical Ethernet, Aggregated Ethernet (AE), VLAN, and tunnel interfaces (site-to-site VPN and LSVPN), and on Layer 3 subinterfaces.
Supported BFD clients are:
Static routes (IPv4 and IPv6) consisting of a single hop OSPFv2 and OSPFv3 (interface types include broadcast, point-to point, and point-to-multipoint) BGP IPv4 (IBGP, EBGP) consisting of a single hop or multiple hops RIP (single hop)
Non-Supported RFC Components of BFD
Demand mode Authentication Sending or receiving Echo packets; however, the firewall will pass Echo packets that arrive on a virtual wire or tap interface. (BFD Echo packets have the same IP address for the source and destination.) Poll sequences Congestion control
BFD for Static Routes
To use BFD on a static route, both the firewall and the peer at the opposite end of the static route must support BFD sessions. A static route can have a BFD profile only if the Next Hop type is IP Address.
If an interface is configured with more than one static route to a peer (the BFD session has the same source IP address and same destination IP address), a single BFD session automatically handles the multiple static routes. This behavior reduces BFD sessions. If the static routes have different BFD profiles, the profile with the smallest Desired Minimum Tx Interval takes effect.
In a deployment where you want to configure BFD for a static route on a DHCP or PPPoE client interface, you must perform two commits. Enabling BFD for a static route requires that the Next Hop type must be IP Address. But at the time of a DHCP or PPPoE interface commit, the interface IP address and next hop IP address (default gateway) are unknown.
You must first enable a DHCP or PPPoE client for the interface, perform a commit, and wait for the DHCP or PPPoE server to send the firewall the client IP address and default gateway IP address. Then you can configure the static route (using the default gateway address of the DHCP or PPPoE client as the next hop), enable BFD, and perform a second commit.
BFD for Dynamic Routing Protocols
In addition to BFD for static routes, the firewall supports BFD for the BGP, OSPF, and RIP routing protocols.
The Palo Alto Networks implementation of multihop BFD follows the encapsulation portion of RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths but does not support authentication. A workaround is to configure BFD in a VPN tunnel for BGP. The VPN tunnel can provide authentication without the duplication of BFD authentication.
When you enable BFD for OSPFv2 or OSPFv3 broadcast interfaces, OSPF establishes a BFD session only with its Designated Router (DR) and Backup Designated Router (BDR). On point-to-point interfaces, OSPF establishes a BFD session with the direct neighbor. On point-to-multipoint interfaces, OSPF establishes a BFD session with each peer.
The firewall does not support BFD on an OSPF or OSPFv3 virtual link.
Each routing protocol can have independent BFD sessions on an interface. Alternatively, two or more routing protocols (BGP, OSPF, and RIP) can share a common BFD session for an interface.
When you enable BFD for multiple protocols on the same interface, and the source IP address and destination IP address for the protocols are also the same, the protocols share a single BFD session, thus reducing both dataplane overhead (CPU) and traffic load on the interface. If you configure different BFD profiles for these protocols, only one BFD profile is used: the one that has the lowest Desired Minimum Tx Interval. If the profiles have the same Desired Minimum Tx Interval, the profile used by the first created session takes effect. In the case where a static route and OSPF share the same session, because a static session is created right after a commit, while OSPF waits until an adjacency is up, the profile of the static route takes effect.
The benefit of using a single BFD session in these cases is that this behavior uses resources more efficiently. The firewall can use the saved resources to support more BFD sessions on different interfaces or support BFD for different source IP and destination IP address pairs.
IPv4 and IPv6 on the same interface always create different BFD sessions, even though they can use the same BFD profile.
If you implement both BFD for BGP and HA path monitoring, Palo Alto Networks recommends you not implement BGP Graceful Restart. When the BFD peer’s interface fails and path monitoring fails, BFD can remove the affected routes from the routing table and synchronize this change to the passive HA firewall before Graceful Restart can take effect. If you decide to implement BFD for BGP, Graceful Restart for BGP, and HA path monitoring, you should configure BFD with a larger Desired Minimum Tx Interval and larger Detection Time Multiplier than the default values.

Related Documentation