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.
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.
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.
+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 …
@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.
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.
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).
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).