Hi @mikrotik crew, first let me say how much I appreciate how v7 is shaping up.

That said, I'm getting pretty desperate for BFD to come back. It's a pretty critical component of our infrastructure and is one of the primary hold ups to rolling out v7

is there any chance we will see this in 7.4? or 7.5?

normally, I'd just wait, but some of your new products require v7 so I'm kinda stuck in the past and unable to use some of the features like l3hw which only lives in v7, but i need BFD which only lives in v6.

Thanks.

It wasn't universally working on v6, Support advised me not to use BFD on Tilera. It did work fine on Arm and CHR.

How I interpret RouterOS:

Beta = Alpha
Stable = Beta (following stable releases break previous functionality rendering it more of a beta than a stable)
2024 = Is probably a fair estimate to a Stable v7 (At least for core functions) It's a Mikrotik thing, They aim after they shoot.

+1

would like to use that again for at least 5 BGP sessions

+10 Also waiting on BFD to update the CCR2004 fleet.

+
We are also waiting for BFD.
Specifically it would be tremendous if BFD support for CCR2116, CCR1072 and CCR1009 would be implemented (CHR would also be beneficial).
We are left with ROS v6 until then for large part of our Branch Office (VPN) connections.

Having some v7 only hardware in the network, i am very pissed of, that BFD is not working.
Can you please speed up your BFD implementation?

+1 for RouterOS v7 BFD support.

It would be great.

Super frustrating that our CCR2004's are just bricks until BFD is implemented.

+1 for BFD in V7 - now that V7 seems to be stable, this is the one thing that is preventing us from upgrading all our CCR's from V6. We need to upgrade in order to get FQ_CODEL, and so we can start buying and deploying 2004's. But without BFD, we are stuck on V6. I suspect that once BFD is working Mikrotik will sell a lot of CCRs. I know several other folks who are holding purchases until BFD is available.

Currently not one of MikroTik "Top of the Line" / "Flagship" models (neither CCR2004, nor CCR2116, nor CCR2216) can really be used in production because of BFD feature not working/being implemented. None of them work with RouterOS v6 and v7 is not yet fully implemented.
Of course there are simpler configurations but it is unlikely that more expensive CCR2xxx models would be used for that.

Also it is unclear if there is also any related connection between BFD and BGP hold-time issues ...

Still - I do keep my fingers crossed.

@Mikrotik... release your software on github and let the community work on it as -community-edition... And for Features that will be cool, you can port the changes to your main codebase.

This is so annoying. CCR2004 is not stable with v6 (packet-loss) only in v7 the device acts like a router. But lacking of BFD make it complete unusable for us with a Layer-2 Network.

+1 for RouterOS v7 BFD support.

We really need BFD for BGP activate every HA services for our customers so it's must have for us.
Right now we must buy old mikrotik products with routerOS v6.

+1 for v7 BFD here too. Was just looking into it and found this thread.

yep. and keep on posting here on a regular. Obviously there are priorities and mikrotik has honestly been killing it on v7 development. I just want BFD moved up the priority list. I think it's probably at the top of many people's list right now.

Hopefully it supports multi-hop BFD and outbound interface selection as well. That's such a great feature on a few other platforms as a way to check if MY service is availabe on a specific connection. Handles situations where a link is partially up, ie link to ISP good but ISP suffering some connectivity issue.

I hope to see BFD soon but I remember when MikroTik was working on BFD issues in the CCR1K series maybe 10 years ago. It took several years to fix it. Not sure what the challenge is but i've seen lots of BFD bugs and issues even in recent Cisco/Juniper code. It's not the easiest protocol to implement apparently.

I can't imagine what is so difficult. Send packets to remote side. remote side considers you 'up' so long as those keep arriving with configured cadence. do this both ways. BGP, MPLS, OSPF all a hundred times more complex.

Sounds simple but ideally you'd want to implement it in the switching ASIC for L3HW. You can then really dial down those delays and still be reliable on devices with starved CPUs. (No idea whether Mikrotik is actually working on that).

Where can i vote for feature BFD? So that the development team can see what the users want!

Hopefully it supports multi-hop BFD and outbound interface selection as well. That's such a great feature on a few other platforms as a way to check if MY service is availabe on a specific connection. Handles situations where a link is partially up, ie link to ISP good but ISP suffering some connectivity issue.

I hate this kind of comment. We use BFD on a single hop only, it seems a trivial protocol to implement.
But when people start asking "once you are working on it can you please make it more complex", it is likely to take even longer.

BFD is already multihop by design. It's simpler to implement 'multihop' than it is implementing it on discovery, ie there's no discovery step, just put the target IP address in.

I'm asking that we get a full implementation, not a partial one.

I can do multi-hop on every single other platform I use (except edgerouter, which I've stopped using and just have legacy units out).

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?

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.

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 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/ ... l+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.

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!

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)

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 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!

I'm just curious.
Why do you want to monitor the link/circuit using software based "in-band" solution?
The answer is the hardware based "out-band" link/circuit monitoring. This means, the "monitoring" is an underlay L1 hardware, top of it the "network" ( routers ), underlay is invisible to the upper layers, there are vendors who already make this kind of equipment (Carrier Ethernet), so BFD is not the answer.

BFD handles multiple things. Link drops obviously, but STP blocks are also caught by BFD as well as basically anything between the routers that might hard or soft fail.

It’s also radio/link agnostic.

What about Latency and Jitter ?
This is not possible to measure/solve with "in-band".

Essentially irrelevant because we don’t have a routing protocol that can account for that . Latency and jitter issues should be reported to the operator. since a radio doesnt have enough info to decide if increased latency should take a link offline then there’s nothing to do.

One thing that has surprised me is that MikroTik did not develop an in-house protocol, or extensions to an existing routing protocol, to make its behavior dependent on actual wireless link characteristics like latency, jitter due to re-transmissions, packet loss (as observed by the actual link equipment) and that learns/knows the actual topology well enough to make smart decisions in a wireless network. Like when you have these links: it can see that two short links, A->B and B->C, may yield a better path from A to C than the longer direct path from A to C.
And it would then normally route traffic via B, unless B fails (or one of the links via B) and then it would route directly from A to C.
BGP cannot do that without extensive tweaking.
As Wireless is a core business of MikroTik, I would have expected something like this to be added years ago. But it never happened.

As Wireless is a core business of MikroTik, I would have expected something like this to be added years ago. But it never happened.

This is what OLSR is for. Mikrotik can make a fork of it and implement some sensors. We had this routing-protocol running on Ubiquiti Hardware with sensors for AirMax-Quality and AirMax-Capacity. OLSR made smart decisions how to route the traffic. Sometimes the routing was asymmetric, because upload was way better then download because of wireless link RF interference.

Ok, I did not know about that protocol... reading about it, it seems that "ad hoc" is an important part of it, and that (while valuable) is not critically important in our network.
It would be sufficient when every link is to be manually configured, even can be entered in a central database with geographical information (which we already have).
But of course when a manufacturer would design and implement a protocol, they would not want it to depend on that.

What I have been considering is to make a service running on some external device(s), or in a container now that this exists, which gathers link information using SNMP and/or API and then re-calculates the optimal routing and sends updates to the routers to tweak the operation of an existing routing protocol (BGP or OSPF) depending on measured parameters, with a certain repetition interval. So the actual routing is still done by BGP or OSPF, assisted by BFD for link failures, but the routes chosen when all links are up can be optimized.

For that, it would be valuable when there would be an API for "temporary configuration changes" where you could tweak e.g. routing filters or link metrics frequently, without storing these changes on flash.

As intriguing I find that WiFi routing topic, can we please stick to the topic of this thread?

There is not much to discuss w.r.t. the topic. v7 has no BFD, we all know that. It is claimed to be "a work in progress" for over 1.5 year now, but nothing is happening.
What we discuss here (and in other topics) apparently has no influence at all, it keeps getting delayed.

OSLR doesn't solve any of this. Too many design assumptionms that all links are roughly equivalent in nature. OSLR would offer little to no benefit for a standard wisp design. You cannot build business class networks off this, you can build 'good enough in a pinch' type networks.

We have 2 functional protocols in OSPF and BGP that are as effective and they already support BFD. WISPs do not generally run the lossy networks that most of the mesh protocols are meant to handle, and also are typically built with different speed backhauls and various eras of links across the network and with a fixed design. Much of the 'mesh' toolkit is wasted and most of the smarts are counter productive. I would love to see a more advanced wireless network specific protocol but that's beyond the scope of the request for BFD. Along those lines, I'd love to see batman-adv whith it's link quality metrics added as it truly stears around half duplex links and low quality links without taking a link down. OSPF, BGP, and especially with BFD thrown in the mix, can take a network hard down when it has 2-3% packet loss due to weather or whatever while something like batman-adv would just take us down the least lossy path.

BFD is a requirement for building those business class networks. Ie, rapid failover from primary paths. It's up to the operator to steet traffic and make decisions on which links are better than other or are preferred for a specific site. Again, OSPF and BGP offer the tools to do this, but both of them falld own when it comes to rapid link failure detection. And while both can be tuned to be super sensative, they both then fall down on reliability. BFD handles that link state much better and dramatically improves OSPF and BGP behavior.

There is not much to discuss w.r.t. the topic. v7 has no BFD, we all know that. It is claimed to be "a work in progress" for over 1.5 year now, but nothing is happening.
What we discuss here (and in other topics) apparently has no influence at all, it keeps getting delayed.

what recently got to my head was the thing as soon as something, and be it the least significant, coming to the next releases of v7 regarding BFD a horde of users will rush for B(FD) and certainly things will not work everywhere and right away - surely not! imagine all the (sometimes weird) setups we all have seen with mikrotik devices.
imagine some people with CCRs in their cores suddenly see a changelog with BFD stuff - "boom, yeah bfd, finally, click, activate, halt" and the whiplash continues

i hope mikrotik is doing some serious testing for these 1.5+ years now and we get a real good (new?) solution/implementation on BFD in v7 which will work solid again.

lest we not forget - BFD is not a "just click this button to activate, set'n'forget" protocol! a lot is dependant atop of it and it has to run very consistently!
mikrotik hopefully will get to us soon with some good news I hope...

lest we not forget - BFD is not a "just click this button to activate, set'n'forget" protocol! a lot is dependant atop of it and it has to run very consistently!
mikrotik hopefully will get to us soon with some good news I hope...

I requested a lot time ago an option for OSPF to increase costs by X instead of downing a link. Partly because I wanted to have a link detect issues but not actually fail. ie, there's a little packet loss so I want it to become a last-resort route.

Well, I should say that I require BFD in two different networks:
- one is at work, where we use GRE/IPsec tunnels between offices, run over fiber and DSL internet connections, with additional L2TP/IPsec over 4G as backup
- for the amateur radio hobby network (HAMNET/AMPRnet), where WiFi PtP links are combined with some internet tunnels to form a network

For the first case, it works perfectly with the v6 BFD implementation, and I am only requesting the same thing to come back in v7. Just a quick check of a link to be down, and have BGP switch to the alternative link quickly enough for the VoIP user only to experience a brief hickup, and the computer users not to notice it at all.
Link failures are seldom, but still it is important to recover from them without user irritation. The network is a star with some partial mesh (link between branch offices), and there is nothing to be done for "optimal path" selection, it is just "working path" selection (i.e. when the DSL re-trains, use the 4G).

For the second case, where the network is much larger and some links are not working that well, the BFD is used to remove links that do not work, but it would be nice (as mentioned above) when there would be a more gradual approach. That will probably not be really possible with BFD, and I certainly do not want to see a BFD implementation delayed over and over again to get it improved that it could do that. Release the d*mn thing so that we can have link failure detection again!

...Release the d*mn thing so that we can have link failure detection again!

...or at least help them TEST that thing and provide feedback for that!

(OT: r u an hamnet admin from germany?)

No, from the Netherlands. You can see my username, right?

No, from the Netherlands. You can see my username, right?

okay. no cannot see any signatures (also i cannot change mine as i noticed last week)
did not know about hamnet until today. great work. currently reading the documentation about it. cheers

i hope mikrotik is doing some serious testing for these 1.5+ years now and we get a real good (new?) solution/implementation on BFD in v7 which will work solid again.

lest we not forget - BFD is not a "just click this button to activate, set'n'forget" protocol! a lot is dependant atop of it and it has to run very consistently!
mikrotik hopefully will get to us soon with some good news I hope...

Mikrotik has not made BFD or routing protocols in general a priority in v7; as far as I or anyone else can tell, the priority is nice-to-have features like containers, and otherwise as long as the routing stack is functional enough to run a basic lab network Mikrotik is satisfied. Why make excuses for Mikrotik and their failures with v7? BFD is not nearly as hard to implement as OSPF or BGP, both of which Mikrotik reimplemented in v7, and Mikrotik implemented BFD in v6. Clearly Mikrotik's developers are capable of doing the work, but someone decided that actually meeting their users' needs is not worth the time.

Well, I can understand that not all developers are equal. To be tasked with something like new storage options is a different level than to write a BGP routing engine.
But what I find most surprising is that there apparently is a developer who is capable of extending the "netwatch" tool (which was very limited in the past, but in v7 has been reworked to allow different "watch types", including a ping that allows for some packet loss) and that this same developer could not write a BFD implementation, even if it was only a new watch type in Netwatch.

frankly, we don't know who is directing their priorities. Could be a big customer they are trying to appease. Rather than shit on them for not having the same priorities as us, we just need to tell them how important and widesprad the need is.

IMO, a worst case scenario would be if someone made the disastrous decision to develop an in-house solution from scratch, which is a pretty tough challenge given the complexity. If that's the case we'll proably have to wait pretty long for a first alpha release and even longer for a stable one. I can think of several reasons why it might go south.

https://github.com/dyninc/OpenBFDD
https://github.com/FRRouting/frr

But that is what MikroTik is doing all the time! They started out using Linux and a number of open-source packages, but they are replaced one by one with in-house solutions.
Maybe they did not like open-source that much after all (remember how they were called out for distributing modified open-source software without releasing the changes they made as sourcecode), and also of course there is the challenge of fitting everything in 16MB of flash.

See the recent trouble with the DNS resolver. They are trying to re-invent the wheel of a DNS resolver with some local DNS server capability, developing it all themselves and running into the well known problems (DNS does not work like you would guess it does, it is one of the oldest protocols still in use and has a lot of ideocracies). The past couple of releases they managed to break it every time.
An open-source alternative that does exactly what they need (and what they still have to develop, such as DNSSEC support) is available: unbound. It has a very elaborate regression testing facility, likely made after a lot of similar problems occurred as MikroTik are having now. But they are stubborn, they won't use unbound, they continue with their own development. Now, a typical unbound binary for other systems is ~1MB in size, so they may not have the space available to use it.

And who does not remember OpenVPN? Instead of using the open-source OpenVPN program, they wrote their own subset implementation years ago and left it as it was, while the open-source version changed and got new features, that were asked for time and time again. But nobody inside MikroTik wanted to touch the software anymore (I once read), and it had to be re-done for v7. But now it still is not complete and still has bugs. Using the open-source code apparently isn't an option, or all trouble would have been over.

For BGP (and OSPF?) it is the same thing. Now, here they may have had a point in that they wanted a multithreaded implementation that could run faster on multi-core processors. After all, on their 72-core CCR1072 beast, only a single core was used by BGP. Also they wanted to reduce memory footprint and have some other new features.
But, as every experienced developer knows, such projects are always more difficult than it initially seemed. Features are forgotten in the design, and at first release people ask to implement them but that turns out to be more difficult or impossible (here I am not thinking about BFD, but things like "received prefix count/limit", route aggregation, advertisement of not-actually-existing routes), and conversion of old configuration is also difficult (leaving "just clicked upgrade" users with problems).
And worst of all: over time the new routers have changed to having smaller number of faster cores, so the whole exercise probably was for nothing anyway.

I have studied the BFD RFC only briefly, but my opinion is that the simple case we all want, the link monitoring of a single-hop link using UDP packets, is quite easy to implement.
But it looks like either someone is trying to do a full implementation and holding it back until it is complete, or in fact the developer that is working on it does not spend any time on it at all, for some unknown reason (he has other things to do, he is on sick leave, he has left the company, whatever).

frankly, we don't know who is directing their priorities. Could be a big customer they are trying to appease. Rather than shit on them for not having the same priorities as us, we just need to tell them how important and widesprad the need is.

...a big customer that does not need a reliable and more complete BGP implementation? That would be pretty surprising to me, though perhaps I should not make any assumptions.

Really though, you can look through the forums going back years and you will see the same feature requests over and over with v7, the same complaints with each release, and the same promises about how everything is being worked on.

...a big customer that does not need a reliable and more complete BGP implementation? That would be pretty surprising to me, though perhaps I should not make any assumptions.

Actually unlikely they do. Most big companies are going to have routers on some sort of fiber circuit and in all likelyhood not need BFD at all, even if they have an ASN, their upstream almost certainly isn't going to use BFD with them. Mikrotik serves more units out to non-ISP networks. Things like zerotier and wireguard are in far more demand outside the ISP space.

No doubt mikrotik wants to be far more widespread than the fairly limited market that has dynamic routing or any want for BFD.

If I had my way I'd actually take SPB over BFD if I could move that up.

BFD is like the finishing touch on a fairly old network design at this point. Everywhere you look are efforts to change the model. wISPs with pretty traditional network designs are definitely in need of BFD as am I, but if v7.9 dropped in SPB support... I'm turning off notifications on this thread...

As a wisp operator, I need BFD as soon as possible unless something better comes along.

Those who think BFD is unimportant probably don't understand the importance of an in-place upgrade path for a large installation base.

Those who think BFD is unimportant probably don't understand the importance of an in-place upgrade path for a large installation base.

Agree. I run a quite large MT network with 500+ routers in it - 2216, 2004s, 317s. All fiber, OSPF, BGP and hopefully a lot of BFD soon. Without BFD its a long 40second or 300 second wait.

Of course there are some other v6->v7 upgrade concerns:
- where v6 has "update source" and it can be an interface name or IP address, v7 has "local address" and it can ONLY be an IP address. configurations with an interface name as update source will fail to convert correctly during the upgrade.
- in v6 the "routing filters" have an implicit "accept" at the end, the v7 filters have an implicit "discard". any routing filters in v6 that have been written only to e.g. set a local preference or prepend a BGP hop, but do not do anything to accept/discard some prefixes, will not be converted correctly during upgrade.
- in v6 the "bgp networks" have a "synchronize" option. without that, the prefix will be announced even when the route is not present. v7 no longer has this option, it will advertise ONLY prefixes that actually exist in the routing table. so any "bgp networks" in v6 that don't have synchronize=yes will have the potential to fail in v7.
- in v6 it is possible to configure "route aggregation", e.g. when you are the central router in a star network with a lot of /30 to neighbors, you can advertise an entire /24 (for example) instead of all those /30 routes. v7 does not have that option.
- the above two changes each may not be so important, but the two changes combined are unfortunate.
- there is an incompatibility in "route refresh" between v6 and v7. when doing route refresh from a v6 router, e.g. after editing filters, v7 routers log "RECV RouteRefresh with invalid subtype: 0" and do not process the refresh. when using filters to determine path through the network, e.g. using community values and associated local preference, and changing the filters in a v7 router, the resulting lack of a refresh may bring the network down until you manually close/reopen the session.

I have been doing some upgrades, and done tests to see what would happen during upgrades, and these things are certainly to be noted before clicking "upgrade" on remote routers!
Then of course I do not even mention the deteriorated monitoring/overview of BGP sesssions: in v6 you can keep a BGP peers window open in winbox and see in one overview how all connections are doing, if they are up and for how long, how many prefixes are received on them. In v7 the BGP sessions window does not auto-refresh but still shows MISLEADING status information like a ticking uptime, hinting that sessions are established even when they are NOT. An F5 refresh is REQUIRED to see current status, and even then it is not possible to see the number of received prefixes (the column always shows 0).
And oh, there is no BFD. The setting is there, but enabling it just kills the connection.

Some of those things are just done differently. Advertise a route as a black hole and it’ll go out despite not being really there and connected, and that’s also a means to aggregate a bunch of /30, which you can filter out . It’s not the same, and in many ways it’s a lot less convenient to do it that way.

The problem is that you no longer can advertise a random prefix that does not really exist in your routing table. v6 could do that, but v7 can't.

The problem is that you no longer can advertise a random prefix that does not really exist in your routing table. v6 could do that, but v7 can't.

I'm saying you can literally just drop a black hole route in and that's exactly what it does.

For instance, I have a couple /24 I split out on different fiber circuits. I advertise the /24 in a black hole on all the head end routers, then I advertise the specific /29 or /30 out as connected for the customer that bought the static block and I set a community on the /25-/32 in that subnet so by upstream (this is a supported feature) will set localpref to that circuit. This is on routeros v7.

it's not as convenient as just advertising a prefix out, but the functionality is there.

Filter rules are of course a challenge and need to be properly tested. Even when rigorous tests have been carried out, there will unfortunately always pop up things you've missed to think of and then it's important that there is a productive monitoring tool available to quickly resolve any issues once you're in production. V7 is limited in that way.

Regarding filters, complex rule sets quickly becomes incomprehensible and in these cases a declarative interface would be preferable.

As for the other shortcomings, we can only hope that Mikrotik invests some time to scrub off the worst edges in order to and whenever possible, make v7 more practical and admin-friendly like v6.

However, BFD is showstopper.

Filter rules are of course a challenge and need to be properly tested. Even when rigorous tests have been carried out, there will unfortunately always pop up things you've missed to think of and then it's important that there is a productive monitoring tool available to quickly resolve any issues once you're in production. V7 is limited in that way.

Regarding filters, complex rule sets quickly becomes incomprehensible and in these cases a declarative interface would be preferable.

As for the other shortcomings, we can only hope that Mikrotik invests some time to scrub off the worst edges in order to and whenever possible, make v7 more practical and admin-friendly like v6.

Most people don't actually consider v6 admin friendly, mostly because it's pretty inflexible. Every complaint about routing and filtering I've seen especially in comparison with v6, I can resolve and improve on and people get an 'ah ha' moment about how effective the new system is vs the old.

Maybe you should do a deep dive into the filter rules. Maybe it's just brackets and squiggly lines in the text that makes it seem difficult? They are no more difficult but are more flexible than cisco or juniper rules. And you can do essentially all your matching on address lists. I took the time to learn the new syntax and now it so simple and so flexible I can do so much more with very little effort. I'm doing community marking on </24 subnets to nudge my upstream provider into using local pref and I'm dynamically updating that with scripts that move IP addresses between access lists which is how my filters map it. All of that fits in just a few lines of filter that is super easy to read. The more complex the rule set, the more advantage v7's filters have over previous because it's done with fewer lies of config.

If you read the post again, you'll probably notice I wasn't referring to the rules. However for that matter, so is a set of complex v7 rules as easy to comprehend, manageable and offers a great holistic view much like Malbolge or Microsoft SDDL ; -)

If you read the post again, you'll probably notice I wasn't referring to the rules. However for that matter, so is a set of complex v7 rules as easy to comprehend, manageable and offers a great holistic view much like Malbolge or Microsoft SDDL ; -)

"Filter rules are of course a challenge".
Literally the opening of the post. I don't know what you're claiming is lacking here. Add a rule, test a rule, record results and fix if you did it wrong. Like anything else, you should lab changes and test changes which of course routeros v7 allows you to do.

Again, I suggest that maybe you are writing overly complex rules *because you can* but not because you need to.

I find essentially everything implemented in routeros7 better than v6. It's simpler to administer with more flexible options and it's more open to other kits accessing the data via API as well. It's lacking a few items that haven't made it yet (ie BFD) which sucks, but the things that are implemented IMO are done better.

I would love for you to list a few items that are missing or less elegant. I'm not playing a condecending card here, actually post it so we can discuss. especially the incomprehensible rules. I'm confident that if you do this, i can offer you up a version that is much cleaner and easier to maintain than routeros v6 offered. I literally just had an 'argument' about similar issues and the other party was adamant that routeros v7 was a regression but once he posted the issue I had a dramatically simpler rewrite that was much much better and faster than on v6.

I'm up for the challenge. post the issue(s)

Quoting myself: ”Regarding filters, complex rule sets quickly becomes incomprehensible and in these cases a declarative interface would be preferable”.

Either we are talking past each other or we simply have different views on the matter. Either way it's OT so please open a new thread if you want to continue to debate this subject and I’ll join you there.

Maybe you should do a deep dive into the filter rules. Maybe it's just brackets and squiggly lines in the text that makes it seem difficult? They are no more difficult but are more flexible than cisco or juniper rules.

The thing is that RouterOS previously had the philosophy that it was not necessary to study languages and syntaxes except for the very most advanced topics (scripting).
You made a filter rule by entering the conditions you want to match and the results you want to achieve into a GUI panel or at most a list of options in a command line that has auto-completion and listing of available options, and does not allow entry of syntactically incorrect commands.

When you leave that philosophy, you might as well argue that RouterOS is redundant and we can just put a Debian Linux install on the router, managed using the usual tangle of files in /etc and /var, each with their own syntax.
You can make a perfect router using that, and you have all the freedom that one sometimes would like to have in RouterOS.
But people choose not to do that, usually to keep things understandable for themselves, for co-workers, etc.
The new style route filters are a departure from the philosophy, and even when they provide some flexibility for weird cases, I actually never had a need for that. The old route filters were just fine.
I hope that MikroTik at least will make a traditional (in the RouterOS sense) interface to generate/edit the "simple case" filters, with an optional "complex filter" case where you can enter the filter manually in a text box. (i.e. restore what we had in v6, with the v7 case as an option for the very rare cases where it is required)

I 100% agree with pe1chl on everything he says all this time about BGP, BFD, Filters and routing in general in ROSv7.

It's an oxymoron to having to wait for almost a decade for v7 to solve the routing shortcomings of v6, only to get a v7 that lacks basic routing functionality/stability/usability, in favor of storage, and other, new, non-router related features.

just had to bring it up here xD

Unfortunately they are not allowed.
Otherwise, they will lose the North American market.

Unfortunately they are not allowed.
Otherwise, they will lose the North American market.

pardon?

If you need BFD and BGP, use Cisco or Juniper

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.

You don't understand how stupid that remark is, don't you?

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?

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?

Looking at https://help.mikrotik.com/docs/display/ ... l+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: viewtopic.php?t=186941, viewtopic.php?t=184231, viewtopic.php?t=184103, (Older)viewtopic.php?t=93775, many v7.x release note topics ...

Home users or small shops without need for redundancy won`t be interested in BFD.
But companies/customers that have bought/would think of buying many MikroTik CCR`s 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.

In retrospect, it was probably a bad idea to release v7 without it, but would you have accepted the wait to v7 until now?

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.

I would love for you to list a few items that are missing or less elegant.

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.

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.

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?

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

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?

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?

... would have been better to just use FRR instead ...

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?

Can you give us an ETA for BFD becoming available for external (beta) testing?

WIP, ie soon!

+1 for BFD.

Here's a silly thought... If Mikrotik doesn't want to open source their software, what would prevent us from flashing a lightweight Linux distro onto some of the arm-based routers and just run FRR? Personally, I would like to see my new CCR2216's run Ubuntu or Alpine Linux. Then I could use one configuration utility for everything. It would sure make automation a lot easier.

Sorry if this is a dumb question or has already been answered.

what would prevent us from flashing a lightweight Linux distro onto some of the arm-based routers and just run FRR?

Support for MikroTik hardware and the SoCs they use in mainline linux, bootloader peculiarities, to name a few.
MikroTik makes it purposely hard for anyone to get current GPL source code for their hardware.

On the one hand choosing a GPL licensed platform for your products (Linux) and then re-implementing lots of standard features from scratch for which better open source implementations exist is admittedly a weird hill to die on but it's a business decision MikroTik has made because it must believe that there is somehow more value in it.

On a different, more observational and possibly off-topic note:
In my opinion, the even weirder hill to die on is the one where people come out onto public forums and berate a company's employees for business decisions their employers made. I find it oddly fascinating and wonder whether there really is no viable competition for MikroTik that people can choose from in this case. I work for a big name brand network equipment manufacturer and in the customer segments we serve there are a handful of other big name brands and customers generally run parallel PoCs with a number of them for any larger investment (e.g. equipment refreshes). If we floundered the way MikroTik has been since RouterOS 7 we'd likely lose the customer.
It seems that in the low-cost segment there really isn't a lot of companies interested in punching above their weight the way that MikroTik does. Which is interesting and I'm trying to find out what this tells me about this market segment.

And don't get me wrong: I love MikroTik for exactly that scrappiness and punching above it's weight in my home network. From what I see on the YouTube channel and on the forums it also seems MikroTik has excellent people working there. I personally still wouldn't run a business on a MikroTik platform, but I know many here do successfully. So what do I know?

On the one hand choosing a GPL licensed platform for your products (Linux) and then re-implementing lots of standard features from scratch for which better open source implementations exist is admittedly a weird hill to die on but it's a business decision MikroTik has made because it must believe that there is somehow more value in it.

I'm not sure this is so much about GPL as it is about having decided to ship devices with 16MB of storage—the better open source implementations simply won't fit. In other words, the value is in saving a couple of pennies on NAND with each device.

I'm trying to find out what this tells me about this market segment.

Let me support you here.
It can tell you that "floundering" is all the same in all market segments. Should be true for the whole IT business.
Of course there are a lot of men in fast cars, trying to tell the contrary.
Unfortunately a good percentage of these men have not a gleam what they're talking about.
Considering this, can have a beneficial impact on the systems you run.

Another +1 for this.

I need it in a use-case with OSPF + BFD for Anycast DNS setup

soon

VTI, IPsec queue

If you want BFD, BGP, VTI - use Cisco
Mikrotik only for home and SOHO

MT, show him that he is wrong.

v7.10 have / will have initial BFD support.
Lets test.

-EDIT- By the way, there is nothing about BFD in the change logs for v7.10-beta5. Very funny.

Where did get that info from?

Where did get that info from?

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

Before everyone gets disappointed (again): Why not wait for the change logs to mention an actual implementation?
You know, it's been asked for enough to warrant an actual entry in the change log.

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

Well, I meant as in an actual release note, not ”planned”..

https://mikrotik.social/@mikrotik/110389938433147844

Wtf (excuse my French ; -) but has MT started to drop different release notes in different channels? Seriously or fake (“#leaked”) ??
Nothing in here at least: “v7.10beta [testing] is released!”

Probably just prepping it.

Somewhere I have seen that line in the normal announcements, I remember...

And that wiki page was changed on May 18 for that line, so pretty recent too.

viewtopic.php?p=1003732#p1003732

!) route - added BFD (CLI only);

Pls excuse my ignorance (I'm just curious and want to learn), but why was BFD such a strongly demanded feature?

From what I'm researching, it's a really simple module that allows more granular/realtime implementation of a remote host is-alive/ping check? I guess this could be essential for HA purposes in some mission-critical or ISP-like production deployments, but other than that what am I missing? Why so much hype over this feature?

Pls excuse my ignorance (I'm just curious and want to learn), but why was BFD such a strongly demanded feature?

From what I'm researching, it's a really simple module that allows more granular/realtime implementation of a remote host is-alive/ping check? I guess this could be essential for HA purposes in some mission-critical or ISP-like production deployments, but other than that what am I missing? Why so much hype over this feature?

If a router goes down you want routing tables updated across your network as quickly as possible. If routers are directly connected (i.e. with just a cable between them) that is simple enough, the neighboring routers will see links going down and will begin recalculating routing tables and sending updates. The problem is that routers are often not so directly connected -- they are often connected via a switch or something similar (maybe a wireless bridge), and then a router going down will not result in its neighbors seeing links go down. Protocols like BGP and OSPF have timers that will eventually detect when a router went down, but those timers are relatively long -- if you need a full 60s just to detect that a router is down, that is 60s where packets are being silently dropped. You can set those timers to their minimums, but that is still measured in seconds which is a relatively long time.

BFD detects a peer going down in less than a second, and that means your network will start the process of computing new routes sooner. It can be used together with BGP and OSPF, and it works across implementations/vendors (except for RouterOS v7...).

From what I'm researching, it's a really simple module that allows more granular/realtime implementation of a remote host is-alive/ping check? I guess this could be essential for HA purposes in some mission-critical or ISP-like production deployments, but other than that what am I missing? Why so much hype over this feature?

A typical use is to mark a dead BGP peer as down. Left on its own, the BGP process can take more than 90 seconds to do this - and when we are talking about ISPs routers... it won't cut it.

With BFD one can have the route marked as down in less than a second.

It is not only about "router going down", it also (and mainly) is about "link going down".
When you have a partial mesh of WiFi PtP links or Internet tunnels between many different locations, and there are alternative paths, you want your routing to adapt quickly when a link is down.
With BGP+BFD that will happen in a second. E.g. when you have Internet tunnels over DSL lines and you have alternate internet via 4G, you want to switch over to 4G when the DSL line is down.
Preferably so quickly that the user does not notice an interruption.
This works well with BFD.

Another important point is that it is a standard. When the other side offers BFD, or when you have deployed an elaborate network with RouterOS v6 and using BFD, it is not straightforward to upgrade a single router when you cannot have BFD there. Sure it is possible to code workarounds using ping/netwatch, but it won't be compatible with the peer that uses BFD.
(that is why I suggested so often to add a BFD mode to netwatch, to make it at least possible to do that)

Well, now we finally have a beta with BFD! I have installed it on a test CHR and it appears to work. Later tonight I will upgrade my home router and test it more.
Still no idea why that took so long... but at least the wait is over.

it looks like BFD is only available for BGP. I cant find a way to enable BFD for OSPF links... hopefully that is coming soon.

it looks like BFD is only available for BGP. I cant find a way to enable BFD for OSPF links... hopefully that is coming soon.

https://help.mikrotik.com/docs/display/ROS/BFD

Features not yet supported

echo mode
enabling BFD for OSPF
enabling BFD for ip route gateways
authentication

I do not know, if the man who said that once ... was a wise man ... but for me ... it sounds wise.
.
"You should not underestimate the snake simply because it has no horns.
No one knows if it may one day become a dragon."
.
水滸伝

wow ... it really is happening.
awesome

glad to see multihop in there.

got very instable BFD sessions with min-rx/-tx below 50ms and a multiplier less than 3 in combination

got very instable BFD sessions with min-rx/-tx below 50ms and a multiplier less than 3 in combination

Sorry, but who does/needs that?!?! This is absolutely not a "usual" setup. When I turn my room light on and off so quickly, I don't need to be surprised when it pops... there are people here... always complaining....
Please be happy that BFD is available. Many thanks to the mikrotik team!

got very instable BFD sessions with min-rx/-tx below 50ms and a multiplier less than 3 in combination

Sorry, but who does/needs that?!?! This is absolutely not a "usual" setup. When I turn my room light on and off so quickly, I don't need to be surprised when it pops... there are people here... always complaining....
Please be happy that BFD is available. Many thanks to the mikrotik team!

If you're running VoIP traffic over it then this is about the rigth frequency. 50ms, 3 drops, and then a few more ms to update the routing table puts you in a 160-170ms failover time which is about how low you need to be to avoid having any noticable packet loss.

These are the settings I've used for years to maintain realtime traffic and have re-routing go unnoticed by end users.

If you have this at 1s for instance, you can almost feel the ground shake when 5% of your subscribers all stomp at once when you've laged their FPS shooter out and killed them.

After all, what's the point of BFD unless it's dramatically faster than your dynamic routing's built-in timers?

got very instable BFD sessions with min-rx/-tx below 50ms and a multiplier less than 3 in combination

Sorry, but who does/needs that?!?! This is absolutely not a "usual" setup. When I turn my room light on and off so quickly, I don't need to be surprised when it pops... there are people here... always complaining....
Please be happy that BFD is available. Many thanks to the mikrotik team!

not complaining. just testing some values i got in other cisco setups, and which are realistic for BFD setups.

i am more than happy seeing bfd coming to v7
trust me. i have 3 CRS2006 on shelf eager to wait for a well functioning BFD... and hey, it just came to live in v7 world and MT works on it

https://help.mikrotik.com/docs/display/ROS/BFD

BFD is available in v7.10rc3 for BGP and OSPF

https://help.mikrotik.com/docs/display/ROS/BFD

BFD is available in v7.10rc3 for BGP and OSPF

Where is the news?

https://help.mikrotik.com/docs/display/ROS/BFD

BFD is available in v7.10rc3 for BGP and OSPF

Where is the news?

OSPF wasn't in v7.10rc1 but it's in v7.10rc3. Only BFD doc reflects this, while the release note is little vague

https://help.mikrotik.com/docs/display/ROS/BFD

BFD is available in v7.10rc3 for BGP and OSPF

Where is the news?

wasnt really mentioned in the release notes for 7.10rc3, but via the documentation - you can see its there.

I was able to get BFD+OSPF working for v7.10rc3 to ROS v6.48.9. I was also able to get BFD+OSPF working over Wireguard to BIRD OSPF+BFD working on the other side.

Everything can be configured via the GUI or CLI. However, to enable OSPF BFD, you need to set the flag for the OSPF Interface Template via the CLI

Are we assuming that BFD will be CLI only in 7.10? ie, we're in the RCs, I wouldn't think we'd see a winbox change in an RC.

not that it's super important, the bgp and ospf options are in winbox.

Winbox support should be in the latest RC.

Much thanks to the MikroTik team for getting this implemented. I've been running BFD for a while via CLI and was pleased to see it added to the GUIs. I have a handful of 2116's running BGP + OSPF to each other and they've all been solid for the past week or so.

How stable is BFD for those testing it? I see random interruptions between CCR2216 and Cisco ASR 1001-X as well as FortiGate 60E and 900D. Still trying to figure that one out.

After some tinkering:
Looks like it somehow interacts with L3HW-Offloading. I disabled it, now BFD seems to be stable.

After upgrade from 6.48.6 to 7.10 default timers bfd isn't correct

6.48.6
/routing bfd interface
set [ find default=yes ] disabled=no interface=all interval=0.2s min-rx=0.2s \
multiplier=5
7.10
/routing bfd configuration
add disabled=no interfaces=all min-rx=200us min-tx=200us multiplier=5

After upgrade from 6.48.6 to 7.10 default timers bfd isn't correct

6.48.6
/routing bfd interface
set [ find default=yes ] disabled=no interface=all interval=0.2s min-rx=0.2s \
multiplier=5
7.10
/routing bfd configuration
add disabled=no interfaces=all min-rx=200us min-tx=200us multiplier=5

what is not correct? you know 0.2s = 200ms right, right?

200us = 200 forum users...

Just to drop this hint here:
I had a issue with BFD. BGP-Session went down at 03 am and was not coming back. I was able to ssh into the device from a direct neighbor. As i issued /routing/bfd/session print the CLI hangs. Then i did a Port-Forwarding via PUTTY to the malfunction device and run a Winbox-Session, as i was requesting BFD -> Sessions the WinBox Session stopped working. With anoter session i was able to issue a reboot. After the reboot, BGP-Session and BFD-Session worked.

Perhaps there is an issue with BFD in current 7.10 version.

Will try to install newest 7.10.x but i am not able to get into the same situation that was killing BFD - so i dont know how to reproduce the issue.

Fixes to BFD were made in the 7.11 beta releases.

Okay, i will try 7.11 beta, every day the router stops bgp-routing because of lacking BFD.

I have to CTRL-C to abort the /routing/bfd/session/print command.


After Reboot BFD and BGP start working again.

+10

I have several 60g links where i usually use bfd, cause the interface will remain online even in disconnect status

i use only stable channel cause all the equipment is in production 24/7, ill use recursive routing for now

---- Side NOTE for Future ---
IS ALREADY IMPLEMENTED, I WAS USING 7.8, UPDATED TO 7.12.1 AND IS THERE
Already implemented

Any Eta for bfd implementation for static route?

Any Eta for bfd implementation for static route?

+10