In fairness, they do have HWMPplus (which I’ve always thought was batman-adv clone, perhaps not…) but never used it.
It’s a real problem e.g. lack of innovation in routing beyond Dijkstra / link-state protocols. i.e. choosing path with multiple LTE uplinks, where signal metrics change frequently…and signal is likely most important thing for upstream route selection.
hwmp+ is nothing like batman-adv, it’s a 802.11s clone and is essentially just a link state replacement for RSTP that doesn’t split the network into a branch topology.
There’s nothing wrong with Dijkstra, it’s just being used with simplistic inputs for costing. If you had cost for latency, packet loss, port utilization in the mix then Dijkstra is still a very suitable algorythm.
The primary need of a mesh is that routing/path updates are adjustable on the fly and propogate out non-destructively. ie, not ospf which recomputes the whole thing every time causing scaling issues.
leading candidates are really batman-adv, babel, open/r or inventing something completely new. And open/r is really cumbersome/heavy.
I have done some work on it myself back in the days of AX.25 amateur packet radio, and in fact the current use I have for it still is amateur radio networking, and when approaching it without too much theoretical background I soon discovered that making only local observations and adjustments often results in routing loops.
(you cannot just say “well my (A) link to peer B is not so good or seems overloaded, let’s send the packets for B to peer C instead because I have a good link to there and I know they have a link to B via D” because C may then send them back to you because they think your path to B is better than theirs.
And while it is possible to avoid that somewhat by adding the criterion that packets should not be sent back to the peer where they come from, this is no longer sufficient when the network is more complex, and loops then occur)
So I can understand that any protocol that works well always has to do global re-calculations based on the locally observed information. That is where those complex and expensive algorithms enter the scene, and the requirement that everyone knows about everyone’s local situation.
This would just add complexity with ASIC/Hardware offloading.
What MikroTik can do is build RouterOS's underlying routing stack and possibly other network functions (like BFD) using FRR's latest base code and possibly fork it if required, or use it as is.
In some ways, FRR moves very fast in development compared to vendors (MikroTik, Cisco, Juniper etc). Like take RFC9234 for example it's partial on MikroTik and non-existent on the other vendors, but fully and natively supported on FRR.
Although a simple homeowner, good to see MT listening to many respected experts here.
DarkNate…FRR seems interesting for sure!
FRRouting (FRR) is a free and open source Internet routing protocol suite for Linux and Unix platforms. It implements BGP, OSPF, RIP, IS-IS, PIM, LDP, BFD, Babel, PBR, OpenFabric and VRRP, with alpha support for EIGRP and NHRP.
However, it says a routing protocol suite, not an operating system? What is it you are proposing?
How easy is it, for example, to rip out the RoS routing stack and inject a new one… is it a modular thing? Would one then have to redefine all the ICDs between modules… imagine that many are standard so maybe only modify proprietary items?
Read sarcastically:
Could it not be in a container… since MT is not fond of npk packages for things like zerotrust cloudflare! 
PS. Sorry IPNAT, didnt win the powerball, so wont be taking a private jet to Denver for training. 
Maybe next time.
Ok children, gather around the fire. Story time!
Once upon a time, RouterOS shipped with Quagga as it’s routing engine.
Quagga is a network routing software suite providing implementations of Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP) and IS-IS for Unix-like platforms, particularly Linux, Solaris, FreeBSD and NetBSD.[1]
Which itself was forked from GNU Zebra. [2]
Nowadays FRRouting is all the rage, which itself is forked from Quagga.
In the [g]olden days of RouterOS v2.x, a buggy version of Quagga was used for BGP/OSPF/RIP.
It was fully configurable/usable through Winbox/CLI, pretty much the same as ROS v3+ when MikroTik decided to reinvent the wheel and implement their own routing protocols suite, which never worked correctly. Ever. Until v7 Routing, which destroyed everything good about the old configuration paradigm of v6 routing stack, but still having new, more complex problems that are still not solved.
So, at some point, it was possible to incorporate Quagga into ROS. Nowadays? Who knows… never gonna happen, so don’t worry about it.
[1] https://en.wikipedia.org/wiki/Quagga_(software)
[2] https://en.wikipedia.org/wiki/GNU_Zebra
PS: +1 on IS-IS
LOL. For a company that likes re-writing routing code, EIGRP would seem like an ideal canvas. IS-IS gets them “current” for sure … but I could see how EIGRP actually sell more routers … than different yet another branch of Quagga…
@pe1chl - you don’t need to do a global re-compute, you need to update it. the recompute ospf does is a ‘wipe and start from scratch’ while partial updates just overwrite the necessary values in-place. It’s a dramatically different ‘experience’ when you have a lot of updates being pushed. OSPF will flap and lose packets while eBGP wont, it never actually drops the routes out. It’s a very important difference to highlight. Note that ISIS also does partial updates.
Back to batman-adv. It doesn’t just operate on a peer to peer model, it also sends packets from it’s edge ports that count up TTL so each router knows how far each peer is from an edge WITH a quality metric so that essentially eliminates the route flapping from link state.
For example, a link may be starting to get saturated from sites A>F. The network is A-> B,C,D,E,F, ie 5 backhauls from A. the quality of that path from A>F will slide down a bit as it get’s saturated. Now lets say that there is a full mesh of sites G-Z that can take many paths to A. Site N is going N>F>A because that’s the best calculated path, however it has a nearly as good of path N>J>B>A but the hop count played enough of a role to keep that from being the primary path. A very small drop in the quality calculation at F isn’t enough to make F look for a new path, but it could make N decide to start sending packets down the less saturated N>J>B>A path.
Using a more complex costing metric that doesn’t rely heavily on hop count but more more on latency, packet loss, and available capacity can route around sites that are getting a bit saturated dynamically. Further, if that N>J>B>A also starts to get saturated, some other route that is going over it may move to *>K>E>A. This all happens with some sane and adjustable windowing so routes/paths aren’t flipping around but taking a measured approach. They also have some stickness so routes with some similar quality numbers wont necessarily switch right when the score changes. say there’s a 147 and a 151 and the site has chosen the 147. if that increases to 152, it doesn’t necessarily switch because that’s very similar. In fact, it might send packets down both paths because they are reasonably similar.
Think about it, as an IT guy or ISP etc, what role does hop count actually play for you? I’d argue that you only use it for troubleshooting or some insights on why the important metrics are what they are. why is my latency high, why and where am I dropping packets, where are my bottlenecks. Hop count might have something to do with it, but we’d all likely take 10 hops on 10G fiber over 1 hop on a airmax ptp link.
We run chains of 60Ghz links because they are low latency and high capacity and we back those up with longer 5Ghz shots that are low capacity and medium latency. I use cost to favor 5 hops on 60ghz over the 5Ghz hop for obvious reasons. I would love my routing protocol to be aware of these things and handle them for me so I just hook links up and let the measurements do the heavy lifting.
Awesome chaos, only thing missing was rabbit on a skewer and rye… { so DarkNates’ suggestion seems like a darned good one, I wonder if FRSS allows source-address-lists on routing rules }
I recall there was/is kernel support, so maybe it isn’t that difficult. Dunno.
batman-adv is in the mainline kernel and has been for quite a while. Just a matter of enough people requesting it for mikrotik to consider it.
Yes, I fully agree with that. In wireless networks, a link with multiple hops may well be better than a link of a single hop.
That is why routing protocols like eBGP are not optimal for such networks without a lot of tweaking, and the tweaking usually is static so it does not take into account that wireless link quality can change, e.g. due to weather, external interference, etc.
So a protocol (any protocol) that can take that into account is very welcome. That does not only mean more flexible cost metric (which OSPF and IS-IS indeed have) but also a linkage to the actual situation (like CCQ, SNR, datarate etc as measured by the link devices). Preferably not via a scripting hack.
“Preferably not via a scripting hack.”
unfortunately multi-vendor networks leave little choice, especially when some of the vendors dont appropriately support snmp 
also, routeros would need to add an snmp poller, say a single OID poller, to be able to extract usable data from radios that are friendly.
I would be pretty cool to have a config item in a peer setup that was like “get capacity metric from snmp: snmpwalk oid x multiply by y to get it into usable” and then “get utilization from” etc. Then poll that and average it over a configurable timeframe.
That could make an ISIS implementation (that has partial updates… not OSPF…) much more dynamic. Could work for BGP also, but path prefixing is a bit ugly/cumbersome in trying to balance many links and using large variation like available throughput over time. ie, do you prepend 20 if you only have 100mbps and prepend 10 if you have 1G?
Something like ISIS with a 24 bit metric would let you assign huge ranges and then round down for ECMP purposes via ‘hacky’ scripts that pull snmp. If you’re using ubiquiti backhauls then you might be SOL with their terrible or absent snmp.
For simplicity, I’d just prefer a batman-adv implementation. unfortunately that might be very difficult to hardware accellerate.
What would be great is some signaling protocol using some of the batman-adv traits but then wrote routes straight to the FIB so native HW accell and fast tracks would work would be awesome.
You can do a lot in script, but if all your routing logic is in a long/complex scheduler/netwatch script, it quickly becomes an ugly hack and difficult to maintain. I think @msatter’s [PROPOSAL] Event driven scripting deserves some consideration. If scripts to control routing were more tied to “events” (change in config/counters/snmp/routes/etc)… it be WAY less of a “hack” and cleaner to apply heuristic-based routing on top of existing protocols (and, eventual, IS-IS).
I don’t know. But what I do know is the open source network community is moving at light speed vs network vendors. The price to performance/feature ratio is better with open networking vendors like say Cumulus or vBNG vendors that are using DPDK/XDP to push 100Gbps line-rate networking on commodity x64 hardware or ONIE hardware.
Times are changing fast, to the point Cisco themselves stole from open source:
https://fd.io/
MikroTik should make use of DPDK for packet forwarding/originating from the router itself and use XDP hardware offloaded mode for packet filtering. Their existing hardware line can definitely hit peak line-rate performance. But that’s not going to happen with MikroTik. Hence, we should move to open source derivatives.
Hell even VyOS added support for DPDK/VPP recently to support 100Gbps performance.
Takes resources and knowledge to keep on top of such developments. I hope MT is paying attention as it seems your saying, implementation is entirely possible.
Thumbs of for IS-IS support!
Maybe, maximal possible throughput at any cost on x86_64 should not be Mikrotiks focus since there are so many alternatives already?
What are you talking about? I’m talking about CCR, CRS and RB series, arm64 devices.
As for x64, that doesn’t matter, if it’s ASIC, I clearly gave Cisco as example whereby they use DPDK/VPP on their ASR 9000 series routers. The x64 aspect is only for the control plane in such hardware design, for data plane, it’s ASIC. What MikroTik can do is implemented DPDK/VPP/XDP for the data plane to push maximum performance in the ASIC + the CPU as well when user wants to forward traffic via CPU for firewall or they are using non-ASIC models from MikroTik such as CCR1072.
Code bits has arrived.
/routing/stats/process/print where tasks=isis
# TASKS PRIVATE-MEM-BLOCKS SHARED-MEM-BLOCKS PSS RSS VMS ID PID RPID PROCESS-TIME KERNEL-TIME MAX-BUSY MAX-CALC
11 isis 0 0 0 0 0 12 402 1 2s870ms 3s340ms 10ms 10ms
/ip/route/print where is-is
/routing/route/print where is-is
Having reached the RC’s. A minimum-viable-protocol (IPv4) implementation before 7.12 release could be … a long shot, IMO.
If I have to wait to 7.14, 7.16 for a IPv4 is-is implementation. Does it work out the gate as MVP. I will be very excited to pair it with IS-IS on Linux using FRRouting as the routing suite.