v7.1beta6 [development] is released!

RouterOS RouterOS beta
181

Here is the documentation: L3 Hardware Offloading. Fasttrack hardware offloading is available only on DX8000 devices. On DX3000/DX2000, Fasttrack connections do not get offloaded and are processed by the CPU.

Summary:

  • IPv4 hardware routing is available on all CRS3xx devices.
  • IPv4 Fasttrack offloading is available only on DX8000 devices. DX3000/DX2000 hardware does not support it.
  • IPv6 hardware routing is not available yet. It should be released later this year.
  • Theoretically, the hardware of the DX8000 series support IPv6 Fasttrack offloading. However, IPv6 Fasttrack needs to be implemented on the software side first.
182

I want to quote Brook’s law:

While it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”

In other words, the development takes time, and assigning more developers to the same task is not always effective and sometimes even counterproductive. For example, if we had moved developers from Wireguard or L3HW Offloading to aid in routing protocols development, would the latter be finished by this day? Maybe, or maybe not. However, the one is certain: there wouldn’t be Wireguad and L3HW now. I can assure you that MikroTik did NOT sacrifice the existing (in v6) features to favor the new ones. On the contrary, the developer staff has been greatly expanded. For instance, such new features as Wireguard, RestAPI, or L3 HW Offloading have been developed by newly hired developers while the existing staff continued doing #1 and #2 of your list.

183

I know about that, I have developed software for many years, but I also recognize the phenomenon that it is much more attractive to work on shiny new features than to make existing features that were broken by accident or because of unfinished work to be working again.

One example is mentioned above: GRE keepalives. That would have required a kernel patch, and apparently this patch has not yet been ported to the new kernel.
But it would seem to be a task requiring at most a couple of hours, and not fixing it will block some users from testing the new version.
That is why I suggest making everything from v6 OK again so you can have existing v6 users betatesting v7 and reporting any found issues, while in the meantime you continue development of isolated new features.
To me that appears to be a better sequence than to work in parallel on many things and then after X time suddenly release a completely new version.

It is not like the lead time for v7 is short by any means. We have been promised a v7 that fixes everything for well over 5 years (did not look it up, I think it is way more than that), so by now one would expect that the basic task of migrating the codebase from v6 to v7 is well understood within MikroTik. After all it was postponed many times, probably for good reasons (the overwhelming amount of internal patches that were made to opensource software used in RouterOS without being sent back to upstream, and that all have to be reviewed before they can be applied to current versions of the same software).

184

That is the basic problem behind kernel upgrades in RouterOS and it is caused by working on a fork of the Linux kernel instead of submitting patches back to the kernel developers and getting them accepted.
I understand why they do that, because it is very difficult to get patches accepted and it will take several developer FTE extra to coordinate that, probably much more than to re-develop the patches every couple of years to track the kernel.
I think now a new kernel version for v7 has been decided (a long-term supported version) and only security fixes from upstream will be integrated into their own fork.
We will have that same kernel (at least that version number) for the next 5-10 years.

185

Thank you for the fast and clear response!

We are working towards transitioning to SRv6 on our WISP mesh and we hope the netPower 16P can play a big part in it as P router on every node, along with a router-on-a-stick as PE device.

186

Is there any hope for jumbo frames and L3 HW to work at the same time?

187

Yes, it is also on the roadmap.

188

What do they expect to be different this time? This sounds like the same process that got us here — 5 years of unprocessed feature backlog, big bang release, etc.

189

I look forward to it very much, it is my biggest obstacle to using L3 HW

190

keep in mind that mikrotik doesn’t have to ‘port’ a lot of things from v6, they have up-to-date mainline packages they can bring in and just ‘port’ the UI for it. ie, they aren’t going to re-implement openvpn from v6… they’ll bring in mainline openvpn w/o having to do any weird stuff to it because they aren’t held back by the old kernel.

A LOT of things are already much more mature.

I’m sure the devs, who are doing great work, are focusing on the fundamentals first because other things depend on them. They likely, as hinted at by raimondsp, have a core group of devs on this part and it takes the time it takes. They can add more devs, but those devs will need to work on the other pieces like vxlan or openvpn and so on and they aren’t tied so tightly into the core group as their packages don’t need to be tightly integrated like routing+hw offload does for example.

191

Having contributed to the Kernel before I would say the process works pretty well, as long as you are able to align your own development processes with it.
I would argue MikroTik has about as much work with maintaining a fork of their own as it would have putting everything upstream.
I believe MikroTik would have a tougher time because they simply aren’t producing the quality required to successfully upstream kernel changes. This is judging from the GPL source drops I have seen (MikroTik’s rocky relationship with the GPL aside). A lot of the modifications they do is to integrate upstream SoC vendor’s architecture support and workarounds and hacks required to support quirky designs.
I can see how not bothering to upstream these changes can reduce external dependencies and friction. And it is my observation that this aligns well with MikroTik’s culture of taking things in, working on them in isolation and then presenting the world with what they came up with. It seems to be working well for MikroTik and it’s probably what makes RouterOS the unique Frankenstein of a router platform we know and love.

192

@felixka
should be noted that when Mikrotik got into this hardware vendors weren’t “linux first”. Many MIPS platforms had other kernels as their first target (vxworks, qnx, highly customized essentially forked linux kernel) so they had to do serious work on them and then linux was basically ported to that platform.

Today, it’s linux first. chipset vendors are already working on mainline kernel support before their SoC comes out and openwrt is probably going to run it on day 1. There’s an SDK to integrate with on day 1. Marvel drops a new SoC, you can probably get your system running on it in a day by building a kernel targeting it.

It’s still dev work for sure, but instead of kernel patches and having to run your own fork, you’re probably using a a very near mainline kernel and putting your efforts into your own kit using the vendor SDKs. Likely no less effort up-front, but also way less effort in the future because maintaining that ‘forked’ kernel isn’t necessary. I’m sure there are little things that need address patching hardware support in and bug squashing but nothing like running your own fork.

193

They have removed IP accounting.

194

Incorrect. RouterOS does not run the opensource openvpn implementation, it has its own crippled version.
And it was already rewritten for v7 it seems.
What I mean with implementing the v6 features is to make everything that was done in v6 by patching the kernel and other software again working in v7, either by reworking the patches or maybe by using whatever became available in newer kernel and software from upstream.
Just so that v7 can be realistically used and tested.

195

I don’t mean work in the development, but work w.r.t. convincing kernel developers that some addition is a good idea, that it should not be done in a
different way, that the coding style is what the reviewer wants to see, that the documentation is according to the required templates, etc.
This can make submitting a 5-line patch into a long discussion and a lot of work, and an understandable decision is to just not bother with it.

196

you guys are way too deep in the weeds here. In the past maybe a bunch of kernel patches were necessary but today the kernel is really mature and most anything mikrotik wants to do is likely in mainline already, else it’s being handled by the SoC vendors because they need that feature to work too.

197

I’m pretty sure none of these are in mainline, even today: PPP BCP, GRE keepalives, iptables and ebtables “set priority” and other priority related handling. Probably more things aside from those.

For something like GRE keepalives I can a potential reason for hesitation to add it to the kernel - it is a Cisco proprietary extension and is not part of the normal GRE standard. They may say that Linux GRE should only support what is part of the standard and not support things that Cisco added to it. For BCP, not many people use it, and they could argue it is not worth including because it is so rarely used.

198

Hi All …

I’m trying desperately to get a v6 config running on v7 beta 6. I need OSPF and BGP to be working and
I am almost there; except I can’t get outgoing BGP route filters to work. The session to my test router
is up, and my input filters work and I can receive route updates. I can send updates as well but not
filter them. If I put them in the main routing table as blackhole routes, they are announced and my test
router receives them. Take 'em out of routing table; they go away on the test router. Nothing I seem
to do in /routing/filter/rule with the “cmcs-out” chain makes any difference. I am testing with the first
entry for 207.225.52.0/24. I’ve also eliminated all rules except the last default reject.

Thanks in advance!
Reiney

================================================

[admin@7.1-tst] /routing/bgp/template> print
Flags: * - default; X - disabled, I - inactive
0 * name=“default” no-client-to-client-reflection=no routing-table=main router-id=63.225.11.26 as=395245

[admin@7.1-tst] /routing/bgp/connection> print
Flags: D - dynamic, X - disabled, I - inactive
0 name=“cmcs”
remote.address=65.19.14.33 .as=14818
local.default-address=65.19.14.34 .role=ebgp-peer
connect=yes listen=yes routing-table=main router-id=63.225.11.26 as=395245 redistribute=static
output.filter=cmcs-out-select
input.filter=bgp-in

1 name=“lumen”
remote.address=67.132.229.1 .as=209
local.default-address=67.132.229.2 .role=ebgp-peer
routing-table=main router-id=63.225.11.26 as=395245
output.filter=lumen-out-select
input.filter=bgp-in

[admin@7.1-tst] /routing/filter/rule> print where chain=cmcs-out
Flags: X - disabled, I - inactive
5 chain=cmcs-out rule=if ([prfx value=dst207.225.52.0/24]) then={ action reject}

6 chain=cmcs-out rule=if ([prfx value=dst63.229.162.0/24]) then={ action accept }

7 chain=cmcs-out rule=if ([prfx value=dst63.233.220.0/23]) then={ action accept }

8 chain=cmcs-out rule=if ([prfx value=dst65.19.8.0/23]) then={ action accept }

9 chain=cmcs-out rule=action do=reject

[admin@7.1-tst] /routing/filter/select-rule> print
Flags: X - disabled, I - invalid
0 chain=cmcs-out-select do-where=cmcs-out

[admin@7.1-tst] /routing/bgp/session> print
Flags: E - established
0 E remote.address=65.19.14.33 .as=14818 .id=1.2.3.4 .refused-cap-opt=no .capabilities=mp,rr,as4
.messages=31 .bytes=674 .eor=“”
local.role=ebgp-peer .address=65.19.14.34 .as=395245 .id=63.225.11.26 .capabilities=mp,rr,gr,as4
.messages=30 .bytes=648 .eor=“”
output.procid=20 .filter=#e0e6289500011128
input.procid=20 .filter=bgp-in ebgp
hold-time=3m keepalive-time=1m

199

Hello,

After upgrading my 4011 (from stable) I noticed CPU usage jumped from 0-1% all round to constant 7-10% (one core - cpu0 - is always 20-30%). “Networking” is taking 60% of that.
Has anyone else ran into a similar issue? Any ideas on why this could be happening and where to start looking?

200

Are there plans for IPV6 address delegation via DHCP?