Currently, replacing a large existing installed base of MT units doesn’t appear to be an attractive first hand choice. But as the saying goes, never say never…
Already two vendor replacements due to no bfd.
classic MikroTik
work
It does not explain a roadmap on the subject.
BFD does not say it will come or it will never come.
It plunges the user into darkness.
It was mentioned already several times in several different topics that BFD is work in progress.
You don’t understand how stupid that remark is, don’t you?
It has been “a work in progress” for well over 1.5 years…
At some point in time people can no longer wait for your pathetically slow progress…
If you need BFD and BGP, use Cisco or Juniper
Yeah, thanks. You must be fun at parties.
Same as pe1chl, I really do not get all those stupid comments.
There are large installations based of ROS6 using BFD. Without BFD, there is no way to upgrade to ROS7 and most important not possible to use any of the newer ROS7 only devices.
The ask for BFD is not a new feature request. It is about feature parity with ROS6 so existing installations cane be updated.
And BFD is claimed to be WIP since almost 2 years.
I believe that MikroTik does understand how very stupid that remark is/was – but are to ashamed to admit that MikroTik is having Network competency issues implementing the protocol in RoS 7.x … Perhaps the expertise is finally coming into fruition and BFD will be in RoS 8.x … RoS 8 is about to hit the beta stream … just a little more patience is needed …
Everyone here knows how BFD is important to you all.
Development has many stages. Fortunately now BFD is in active internal testing stage, so - very close.
When it was “in development” previously, it was in research / theory phase.
In retrospect, it was probably a bad idea to release v7 without it, but would you have accepted the wait to v7 until now?
We expect MikroTIk to have a checklist of all items in v7 that have no feature parity relative to v6, and work on that with highest priority.
Only after those items have all been implemented or documented as “will not come back” (e.g. /ip/accounting), we expect major “new features”.
I think that is not too much to ask.
When this was a feature that is so difficult that it requires a year of “research/theory” plus another 8 months of “development” we expect the old code to be temporarily used, with its limitations, in v7.
Or a workaround to be implemented temporarily, e.g. a “type BFD” in /tool/netwatch. That is probably a place where experiments and quick development are easier, plus there is a developer who knows that part of the code.
you can’t use “old code” in v7
You are joining mrz in the “stupid remark” contest?
Looking at https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview page it can be seen that on Apr 15, 2023 information for upcoming version RouterOS 7.10 was added and it is still mentioned/planned that there will not be BFD support even in RouterOS version 7.10. For me - I don`t see much use of v7.x versions till BFD implementation.
As with redundant setups for VPN servers/routers (for using OSPF) and certain BGP use cases BFD is the necessity component why some part of larger (network) MikroTik users are locked to RouterOS 6.x versions and missing out on many other improvements in RouterOS version 7.x.
We have tried v7 in test environment but cannot go with it in real life as failovers/flaps without working BFD seem unworkable.
We can`t even use CCR2xxx devices as they need v7.x.
There are a lot of places in this forum were many users have expressed the need for working BFD implementation on RouterOS v7.x versions to be able to move forward from 6.x versions. See: http://forum.mikrotik.com/t/v7-and-bfd-any-eta/158848/1 http://forum.mikrotik.com/t/bgp-with-bfd/156641/1 http://forum.mikrotik.com/t/bfd-in-7-1-3/156533/1 (Older)http://forum.mikrotik.com/t/bfd-ospf-ccr1036-issue/85182/1 many v7.x release note topics …
Home users or small shops without need for redundancy wont be interested in BFD. But companies/customers that have bought/would think of buying many MikroTik CCRs and CRS`s would probably be looking for working BFD.
We are looking for BFD to be able to update our fleet. Best of luck to MikroTik engineers with working and timely BFD solution!
@normis, thanks for the awesome news. I’m glad you guys released v7 sooner than later, lots of non-BFD needs out there for sure. I’m a big fan but to be honest I’ve very much been exploring other products because my need for BFD has eclipsed my fondness of mikrotik.
Fair enough. But IMO, the bad idea was merging the kernel change (which no doubt was PITA given the driver model changed) AND a new BGP/routing engine all in one release.
In my case, I was already waiting 5 years from the “In V7” noted in docs for MBIM support, because that required the new kernel…
While belated, this is good news re BFD.
not to compare it to v6, but i think OSPF interface-templates would work a lot better for our use-case if you could pick an address-list for the network, like you already can with bgp networks.
just some QoL improvements. can’t imagine it’d take more than a few hours for adding address-list support for OSPF considering they already have it working for bgp networks.
Kudos to the MikroTik team for keeping their cool given the tone by a few customers.
Given that we’re dealing with humans on either side of the keyboards I don’t think they deserve the abuse they are receiving here, regardless of what their employers’ strategy, roadmap and quality of delivery may be.
thank you!
exactly what i was thinking when i read some stupid comments of people assumingly not knowing how deep down some implementations go in the linux kernel. (not to speak of the workload of merging to a new major kernel release!)
thanks for the held up kindness of the MT staff despite some folks around here.
As much as I want BFD, given the push to get ROSv7 ready for new platforms like CCR2K and CRS5xx, I think getting ROSv7 into stable releases and working through bugs on major features was much more important.
Glad to hear it’s going to be out soon 
I would have been willing to wait for containers, rose storage, etc. BFD is not a new feature from the perspective of RouterOS users, whereas containers etc. most certainly are.
It would also be nice to see a postmortem on this. I cannot understand how BFD could take this long just to get to internal testing unless Mikrotik ignored all the people who have been submitting FRs and voicing their complaints, and instead focused on other features (that fewer users, if any, were asking for). I get that development happens in stages, but it should not have taken this long, and if the problem is a lack of developers available to work on BFD then perhaps it would have been better to just use FRR instead (which would have other benefits as well – for example IS-IS would be on the table). I am pretty sure Mikrotik did not implement Wireguard or VXLAN and instead relied on open source implementations; why not do the same with routing protocols?
Can you give us an ETA for BFD becoming available for external (beta) testing?
it would be just awesome if there would be native support for FRR in MT (like a npk package like the “rose” npk for example!) — speaking of, is there a topic covering that route?