Does R81, R80.40, or R80.30 support BFD Echo (BFD = Bidirectional Forwarding Detection)?

[Russell_W]

I have started researching (and test configuring) the use of BFD with OSPF between Check Point and another product (FRR, as integrated into pfSense).

I've managed to get the devices to "speak BFD" to each other without much issue.  Where I have confusion:  whether Check Point supports BFD Echo in particular.

First:  BFD Echo is NOT the same as ICMP echo-request/reply aka Ping.  Nevertheless there is this odd tangle of language in Gaia Advanced Routing R81 Administration Guide (PDF page 180):

d. In the Type field, select the BFD type.

[...]

Ping

Detects whether remote IP addresses are reachable using ICMP ping.

BFD Echo packets use the UDP destination port 3785.

Note - BFD only works if both ends are configured to perform the same
BFD type - on both ends perform singlehop, on both ends perform
multihop, or on both ends perform ping.

e. Click Save.

The layout and language suggests that ICMP ping is a BFD type, and that both ends have to be configured to this same "BFD type" for BFD to work.  I am clear that BFD Echo uses UDP 3785 and is 100% not ICMP ping (echo-request/echo-reply), but I am stymied by this reference to BFD Echo and no instruction on how to turn it up other than... Ping (aka ICMP ping).

Whether eyeballing the Gaia Portal or Clish commands I'm not finding a way to turn on or even reference BFD Echo.

Finally, there's this bit of output from the pfSense/FRR side, when talking to the Gaia gateway (R81 JHF 27).  Note that the pfSense device DOES have BFD Echo capabilities and is the device referred to with the word "local" in the output below:

BFD Peer: peer [redacted IP address of R81 device] local-address [redacted IP address of pfSense/FRR device] vrf default interface [redacted interface name]

ID: [redacted ID]
Remote ID: [redacted Remote ID]
Active mode
Status: up
Uptime: 5 hour(s), 58 minute(s), 42 second(s)
Diagnostics: ok
Remote diagnostics: ok
Peer Type: configured
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: 0ms

Note the Echo transmission interval is:

• every 50ms from the "Local" (pfSense/FRR) device, but;
• every 0ms from the Remote (Gaia R81) device.

Gaia side output from:

show ip-reachability-detection address [redacted IP address of pfSense/FRR device]

makes no reference whatsoever to BFD Echo, but it does confirm that the Gaia R81 device is happily chattering away with the pfSense/FRR device via BFD.  Lots of pretty stats, lots of yes-my-peer-is-up-we-are-happy.  Just no tell on use/non-use of BFD Echo.  (happy to paste output if there are interested parties.

All this suggests to me that the Check Point doc needs tuning to clarify that BFD Echo does in fact exist in the universe, but is not actually implemented (much less configurable) on Gaia R81 or prior.

Or... am I missing something?

Thanks!

[PhoneBoy]

@Sundeep_Mudgal can you comment on this?
The most obvious way to confirm one way or the other would be tcpdump. 

[Russell_W]

@PhoneBoy, good point about the tcpdumps.  I took a run at (similar) idea with fw monitor (to avoid any SXL-related misses). 

What I see -- regardless of which device is the initiator of BFD traffic -- is strictly UDP 3784 back-and-forth.  No UDP 3785 (BFD Echo) whatsoever.

At the same time, in Clish:

show ip-reachability-detection address [redacted IP address of pfSense/FRR device]

continues to show:

Protocol:  BFD (singlehop)

And on the pfSense/FRR side, I dug out this bit of diagnostic output:

BFD Peers:

peer [redacted IP address of Gaia R81 device] vrf default

Control packet input: 636 packets
Control packet output: 627 packets
Echo packet input: 0 packets
Echo packet output: 0 packets

So the fw monitor and the pfSense/FRR device would seem to agree about what is going on.

Both of the above are with the following config Clish-side, though:

set ip-reachability-detection bfd detect-multiplier 3
set ip-reachability-detection ping address [redacted IP address of pfSense/FRR device] enable-ping on

So... I'm lost.  The docs are still murky on how all this works/should be configured,  But enable-ping is on and BFD is still clearly "BFD-ing away."

The lack of BFD Echo traffic could very well be a negotiation/interop issue (rather than lack of Gaia capability to do BFD Echo at all).  I don't have a pair of Gaia R81 boxes available to spin up a "Gaia-only BFD Echo test" -- yet -- but will spin this up in the lab to see if I can provide some clarity.

Appreciate your hopping on the question.  More to come.

[G_W_Albrecht]

What is the issue with this now, which communication does not work ? Could not get to that by your posts...

[Russell_W]

BFD Echo (UDP 3785) appears to be inoperative, and the Gaia Advanced Routing R81 Administration Guide is not clear on how to configure the product to make BFD Echo work (thus making it difficult to determine whether the problem is failure or misconfiguration).

[G_W_Albrecht]

What is BFD Echo used for that does not work in your test configuration and why not involve TAC ?

[Sundeep_Mudgal · Accepted solution]

Gaia does not support sending/receiving of BFD echo packets.

[Russell_W]

@Sundeep_Mudgal , @PhoneBoy , thanks for the assist on this.  That is what the data I saw points to -- appreciate the sanity check and confirm.

I suppose there is one obvious issue that follows:  the Gaia Advanced Routing R81 Administration Guide is apparently, then, incorrect on this point.

In addition to the detail from Guide in the original post, there's this from the "Parameters" section of the Guide's "Configuring IP Reachability Detection in Gaia Clish" section:

ping address <IPv4 Address> enable-ping {off | on}

This feature detects whether various remote IP addresses are reachable using ICMP ping.

Disables ( off ) or enables ( on ) BFD Echo for this IP address.

The same BFD Echo configuration instruction is in the R80.40 version of the Guide.

Don't know what one does about correcting the Guides, but at least the inaccuracy is known...

[Sundeep_Mudgal]

Thanks...we will get the guide updated.

[Russell_W]

Grazie mille!  Thank you!