Tech Tip - Dynamic Routing: BFD

[Chris_Atkinson]

Background

Bidirectional Forwarding Detection (BFD) is a fast fault detection protocol used to monitor links between network devices like routers and switches. It's purpose is to detect link failures (to quickly facilitate routing around them) rather than device failures which is an important distinction in the case of a clustered pair of Firewalls.

In a ClusterXL environment "Standby" cluster members do not respond to BFD. Hence when considering the configuration of BFD we need to pay attention to the underlying network fabric and parameters such as the ClusterXL dead timeout. Does the network topology require / warrant BFD and what is it really achieving for us?

If care isn't taken BFD can have unintended consequences for routing stability & cluster failovers resulting in downtime.

Timers & Best Practices

• For a non-clustered security gateway the calculated BFD timeout should be at least 1 second, preferably 3 seconds (or more) for reliability. For more details, see RFC 5880.
• On Cluster Members, make sure the calculated timeout is longer than the time necessary for the cluster to complete an unattended failover in your environment. We recommend that you first test failover in your environment.

• Do not use the IP Reachability Detection feature in combination with the Graceful Restart feature in dynamic routing protocols, unless the routing protocols support the BFD "c-Bit".

Source: Check Point R82 Gaia Advanced Routing Admin Guide - IP Reachability Detection Configuring in Gaia Cl...

Access Policy

Routing related protocols such as BGP, OSPF etc need to be allowed by the security gateway access policy in order for routing adjacencies / neighbors to be able to form successfully. In general this traffic is not covered by implied rules.

Configuration of the necessary rules for common routing protocols are covered by the following knowledge article; similar rules are required to allow BFD traffic as an example (UDP destination ports control: 3784 & echo: 3785) e.g.

Source	Destination	Service	Action	Install On
BFD neighbors Relevant Security Gateways	BFD neighbors Relevant Security Gateways	BFD-Single_hop	Accept	Relevant Security Gateways

sk39960: How to allow Dynamic Routing protocols traffic (OSPF, BGP, PIM, RIP, IGRP) through Check Po...

Priority Queues

As relevant to BFD should be default in current versions, please see: sk105762: Firewall Priority Queues in R80.x / R81.x

[akurtasanov]

Should Explicit NAT rule with Hide under VIP for BFD service be used in the ClusterXL?

[Chris_Atkinson]

I don't recall having to manipulate NAT relative to BFD in the past, what's the scenario / version that you are trying to deploy - what are you seeing?

[akurtasanov]

In the case of using NoNat rules. We have a top-level NoNat rule for the 10.0.0.0/8 network and all BFD requests fall under it. BGP itself, according to traffic data, ignores this rule and works fine. And according to the documentation, it is not entirely clear whether the BFD in the clusterxl should initially leave the active node under the VIP address or its own address of the active node, but in the latter case, it is not clear how to set up the BFD session.

As Example:
ClusterXL VIP - 10.0.0.1, Node1 - 10.0.0.2, Node2 - 10.0.0.3
BGP node - 10.0.0.4

In the case of NoNat, we have a BGP session between 10.0.0.1 and 10.0.0.4.
If configure BFD, the session 10.0.0.2 and 10.0.0.4 or 10.0.0.3 and 10.0.0.4 appears (depends on which node is the primary one).
But due to the fact that BGP peering is between 10.0.0.1 and 10.0.0.4, BFD is not working correctly.
And it's not entirely clear from the documentation how the BFD should behave initially, whether it's worth making Hide Nat Rule for 10.0.0.2 and 10.0.0.3 under 10.0.0.1 or somehow configuring 4 BFD sessions, although it's unclear how.

[Chris_Atkinson]

The number of BFD sessions needed is based on links not multiplied by cluster members, the cluster is a single logical router.

[akurtasanov]

Therefore, in my case, I have to overlap he NoNat rule
src 10.0.0.0/8 dst 10.0.0.0/8 Srv Any NewSrc Original NewDst Original
with more prioritized Hide Nat Rule like this
src 10.0.0.0/8 dst 10.0.0.4 Srv BFD NewSrc Hide_10.0.0.1 NewDst Original

Is that right?

[Chris_Atkinson]

Has the settings described in sk34180 been changed for your environment?

[akurtasanov]

No. By default perform_cluster_hide_fold is true. Nothing changed.
I was planning to get a simple answer:
1) Yes, bfd should be with VIP
2) No, bfd works without VIP with the private address of the active node.
And then sort it out further or open the case in TAC

[Chris_Atkinson · Accepted solution]

It should be the VIP. Actually I think your case is already described here:

https://community.checkpoint.com/t5/Firewall-and-Security-Management/ClusterXL-BFD-Bidirectional-For... 

[Chris_Atkinson]

OSPF & BFD

Important - In ClusterXL, the Graceful Restart re-starter role is supported for IPv6 OSPFv3 only; for IPv4 OSPFv2 the member acts as a Graceful Restart helper. In addition, do not combine BFD (IP Reachability Detection) with Graceful Restart unless both peers support the BFD C-bit - otherwise BFD still tears down the OSPF adjacency on failover. Confirm C-bit support on both peers as this SK notes:

sk185166 - OSPF Routes Disappear After ClusterXL HA Failover When BFD Is Enabled with Extreme Switch...

BGP & BFD

For BGP Graceful Restart to work with BFD without an outage, the Graceful Restart Helper must have the "cBit" detection and the cBit value must be set to 0 (depends on the control plane) by the cluster.

Important - You must create a matching configuration on the BGP peers of the Check Point cluster. Check Point strongly recommends to fully test this configuration to make sure it works properly. Some BGP peer routers can support BFD but not include cBIT detection in BGP. Refer to the relevant vendor's documentation.

Source: BGP Behavior During ClusterXL Failover

Refer also: sk175923 - Border Gateway Protocol (BGP) behavior during ClusterXL failover