This is not correct, the protocol is different for a single hop and for multihop. It even uses a different port number.
I do not know what you mean with “discovery”. What I need (and I think what many users need) is a BFD implementation that works on a directly connected BGP peer (TTL=1), e.g. over a WiFi link or via a tunnel, by sending UDP to the peer (preferably also with TTL=1) and monitoring it. Nothing more.
Nice when it is fully implemented, but please do not delay it any further for that.
i think pe1chl is exactly right here.
a BFD implementation in general should be deployed between 2 direct peers to monitor that particular link
overall, i don’t see a practical use-case for a multihop BFD?
https://www.rfc-editor.org/rfc/rfc5880
BFD can provide failure detection on any kind of path between
systems, including direct physical links, virtual circuits, tunnels,
MPLS Label Switched Paths (LSPs), multihop routed paths [...]
Practicaly it speeds up detection of lost paths when using multi hop BGP, but can be used also for static routes.
I also think: there are much more important things still missing from ROS than multihop BFD.
Yes, I think the top priority now is to implement the single-hop echo mode that was also supported in v6.
I think v6 had some multihop support put people considered it broken.
Anyway, we do not use that. We only use BFD to closely watch WiFi links and internet tunnels (GRE/IPsec, L2TP/IPsec) between peers in a private network.
That is the function that prohibits us from upgrading to v7 in a lot of places. And I have seen many other users with the same situation.
I think a BFD implementation with that functionality can be coded “in a friday afternoon” and I cannot understand why it is a “work in progress” for well over a year now.
I can only imagine, there might be some issues with strict timing requirements, but otherwise, it must be quite easy to implement, compared to other protocols.
I have even suggested to add a BFD mode to Netwatch as a new “type”, which would do the simple 1-hop BFD echo protocol.
In the up/down scripts we could then enable/disable the BGP peer.
Not optimal but at least it would allow deployment of v7 routers in an existing v6 network with extensive usage of BFD.
It seems the Netwatch developer has some time to develop things, while the routing developer (when he still works at MikroTik) apparently hasn’t.
But unfortunately that has not resulted in a solution either…
Now the only hope we have is the report of one user on the announce topic that he apparently has got an alpha release that has BFD support…
Yeah thanks, I have seen that remark. Also I have seen this:
https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview
Here in the table ou can see that the line on BFD support is not colored red for v7.7, like for 7.6. I´m not sure if that means anything.
Making some noise here on BFD is surely the best we can do. 
+1 for BFD
+1 for BFD
+1 for BFD
It is a “work in progress”, they still claim (today). Putting +1 in a forum topic is not going to change that.
Yes, that is true…but as I sit here with new (V7 ONLY) hardware waiting to go into service, I figured my “+1” couldn’t hurt!
+1 for BFD in my networks.
I am whining about BFD ever since v7 was released. The best that I got was the remark that “BFD is a work in progress”. But that was in september 2021 !!!
That remark was repeated even in this topic. Every time I ask about it, I get the same response, or people get annoyed.
My idea about “a work in progress” is an activity that has been assigned to someone, who actually performs work on it, say at least a day a week, and makes progress towards the final goal. But it is beyond my belief that BFD requires a year and a half of such work to complete.
So for me, it is “a work” but not “in progress”.
one running an arm, arm64 or x86_64 routerOS could give this a try within a docker container (a pity to be kind of “forced” in such a direction to workaround to get som basic functions)
https://github.com/dyninc/OpenBFDD
it is not pretty, but it might work.
or FRRouting in a docker (which even enables EIGRP in some forms - but that is off-topic)
one obstacle might be the implementation in the correct “plane” in rOS7 devices…
BFD is intended to be lightweight and run in the forwarding plane, as opposed to the control plane (as is the case with routing protocols). While early implementations of BFD ran on the control plane, most of the newer implementations run in the forwarding plane [ from junos BFD docs ]
also the cross process communication in this context might not be THAT easy for MT on rOS7 i reckon.
still hoping this will get solved sooner then later (and also BGP related stuff as well)
Can we spent money, for getting prioritized?
My CCR2004 is keeping rebooting every 30-50 Minutes. I am stuck on v6 because of missing BFD. I am not able to upgrade to v7 as long as BFD is not working.
I keep thinking I’ve kind of got things ‘worked around’ having BFD, but then yesterday I have a link that went soft-down. 80% packet loss. Somehow, the sessions kept alive so the link did fail. I had to manually bypass it so had an unneccessary service issue. BFD is the solution here, it doesn’t put up with packet loss like this.
BFD is at the top of my list. I know there are lots of things to work on, but this one feature is starting to be THE feature people are crediting for their unwilllingness to use ROS7
There should be a repository where we can get all the drivers needed to bake a own linux kernel.
I can dispense the WinBox when i have plain access to the linux console. But i need a reliable hardware at a good pricepoint where mikrotik comes into the game. But there are no alternative firmwares available where we can start with. I am not so experienced, so i could not bake a bootloader and a working linux kernel for the mikrotik hardware.
Forwarding packages and doing some BGP-Stuff (including ECMP) with BFD seams to be a unsolvable task for the mikrotik software developers.
I did this on x64 hardware all day long without any hassle.
Too busy with consumer features it seems!