Page 1 of 1

Single-hop BFD session is not restored after reboot or power outage

Posted: Fri Apr 12, 2024 6:01 pm
by korobeynikov
We use the single-hop BFD protocol to control the availability of the ISP link.

BFD configuration:
[korobeynikov@MikroTik] /routing/bfd> export
# 2024-04-12 23:52:46 by RouterOS 7.14.2
# software id = XXXX-XXXX
#
# model = RB3011UiAS
# serial number = XXXXXXXXXXXX
/routing bfd configuration
add disabled=no interfaces=static min-rx=1s min-tx=1s
add addresses=203.0.113.153/32 disabled=no interfaces=ether1 min-rx=1s min-tx=1s multiplier=3
I have a route created via WinBox for network 0.0.0.0/0 via gateway 203.0.113.153%ether1 and the property Check Gateway = bfd.

After creating the route, the BFD session is activated:
[korobeynikov@MikroTik] /routing/bfd/session> print
Flags: U - up, I - inactive 
 0 U multihop=no vrf=main remote-address=203.0.113.153%ether1 local-address="" state=up state-changes=2 
     uptime=12s desired-tx-interval=1s actual-tx-interval=1s required-min-rx=1s remote-min-rx=1s remote-min-tx=1s 
     multiplier=5 hold-time=3s packets-rx=12 packets-tx=1

Moreover, if we print the route, we will get the following:
[korobeynikov@MikroTik] /ip/route> export
/ip route
add check-gateway="(unknown)" disabled=no distance=10 dst-address=0.0.0.0/0 gateway=203.0.113.153%ether1 pref-src="" routing-table=main scope=30 suppress-hw-offload=no target-scope=10
What means check-gateway="(unknown)"?

But the saddest thing happens after the device is overloaded or the lights are turned off/on - the BFD session does not recover.
Using the Torch tool, I see that the ISP is sending packets via UDP to port 3784, but my device is not.

To activate a BFD session, you must first turn off the route and then turn it on.
Packets begin to flow in both directions.

I believe this is a serious software bug.

P.S. I know about other ways to control the gateway, but this topic is about BFD.

Re: Single-hop BFD session is not restored after reboot or power outage

Posted: Fri Apr 12, 2024 6:09 pm
by loloski
I don't think check-gateway = bfd is already implemented

https://help.mikrotik.com/docs/display/ ... l+Overview

Re: Single-hop BFD session is not restored after reboot or power outage

Posted: Sat Apr 13, 2024 9:49 am
by korobeynikov
I don't think check-gateway = bfd is already implemented
Thanks for the link!

It is worth noting that the service itself is implemented and works perfectly when blocking UDP packets on port 3784.
The only question is to start the service after booting the device and write it in the configuration.

I would like to get some feedback from the developers.

Re: Single-hop BFD session is not restored after reboot or power outage

Posted: Mon Apr 15, 2024 1:00 pm
by BrateloSlava
As far as I can see from the documentation:
Features not yet supported
  • echo mode
  • enabling BFD for ip route gateways
  • authentication

Re: Single-hop BFD session is not restored after reboot or power outage

Posted: Mon Apr 15, 2024 3:51 pm
by Larsa
I would like to get some feedback from the developers.

Since this is a user forum, I believe you have a better chance of getting a response if you direct your question to: support@mikrotik.com.

Re: Single-hop BFD session is not restored after reboot or power outage

Posted: Mon Apr 15, 2024 4:51 pm
by mrz
As it was already mentioned here, BFD for static routes is not ready. Currently BFD session can be created by routing protocols with enabled BFD, static route may use existing session, if destination address match, but it cannot create the new session.

Re: Single-hop BFD session is not restored after reboot or power outage

Posted: Tue Apr 16, 2024 11:16 am
by korobeynikov
As it was already mentioned here, BFD for static routes is not ready. Currently BFD session can be created by routing protocols with enabled BFD, static route may use existing session, if destination address match, but it cannot create the new session.
Maybe if you explicitly specify the interface. The only question is the launch after loading.
I cannot refuse the protocol at the moment, since the operator turned it on for us and we coordinated it for a long time.