RouterOS version 7.1beta2 has been released in public “development” channel!
What’s new in 7.1beta2 (2020-Aug-21 12:29):
!) added “bgp-network” output filter flag;
!) added bonding interface support for Layer3 hardware offloading;
!) added IPv6 nexthop support for IPv4 routes;
!) added Layer3 hardware offloading support for CRS309-1G-8S+IN, CRS312-4C+8XG-RM and CRS326-24S+2Q+RM;
!) added WireGuard support;
*) disk - improved external disk read/write speeds;
*) ospf - fixed point to point routes becoming inactive;
*) route - fixed source address selection of outgoing packets;
*) other minor fixes and improvements;
This level 3 offloading looks very interesting. Do we have any numbers to show what it can mean as this has the potential to put emphasis on the R in CRS
It does routing at wirespeed, in all ports. There are several constraints, and a limit of 4096 connections, if I’m not wrong. But in some use cases it will be a killing feature.
Observations (not really new for this build but maybe off the radar):
when a static route is disabled, it disappears from the listing entirely, as if it has been deleted. when the window is closed/reopened, it appears again in greyed-out status.
the BGP functionality still exists only in CLI and not in winbox. I would have hoped (or maybe this is the time to do that!) that all GUI info is derived from a common set of tables that is shared by all the user interfaces, so the work does not have to be done 3 times…
when I close the Log window and re-open it, winbox completely hangs.
any hint on how to flash this on a HAP MINI? On previous beta, it said internal storage is not enough to upgrade… it’s a brand new model, factory reset… maybe because of beta and so build not optimized yet? Will it ever be a version for low storage devices?
It’s Wireguard v1.0.0 proper (as shipped with v5.6).
Note for whoever wants to give it a spin: you need to use the cli to set the peer endpoint - Winbox doesn’t allow you to set the port (it will default to 0).
@Paternot
I 4 1 do NOT believe that It will do routing at wire-speed … why I do not believe that … because for L3 wire-speed requires an ASIC and non of the hardware specs I see have that L3 ASIC in the gear. Yes there will be an improvement in performance but nowhere near wire-speed.
Just tried this version and had to go back to 6.4x.
Bug [SUP-15464] which is partly fixed in 6.4x is still present in 7.1x (retain correct MTU PPPoE through a SFP on a 4011) restarting the SFP does not help.
Changing the MTU manually on a interface crashes the router (tested it on a 4011 and 750-Gr2) remark, MTU set in the configuration by a 6.4x seems to be honored
In routing I noticed something different on the route for the gateway PPPoE connection, the first was 0.0.0.0/0 but that a label DAv instead of DAS (v from VPN) and I have IKEv2 defined but not all traffic has to go through a tunnel. I assume this “v” indicates that the IKEv2 tunnels are terminated on the PPPoE.
I did upgrade my firmware to 7.1x but to no avail. And I first downgraded to 6.47.2 before upgrading to the 7.1beta2
What do you think the, let’s say 98DX8208 chip in the CRS309 is? It’s a switching ASIC that has lots of functionality built in, L3 forwarding among them. MT simply didn’t implement it up to now.
@macgaiver
I am not familiar with that specific switch chip so I am in part writing out of ignorance of that specific chip.
I am familiar with how CISCO does in on their MLS devices. Typically for wire-speed routing in the Cisco Switch world Cisco requires three entities to implement multilayer switching: the switching engine (SE), the route processor (RP), and the MLS protocol. The SE performs the switching function, the RP performs the routing function, and the MLS protocol provides for communication between these two devices. This aside, there is one very simple concept that makes it all possible: the flow. A flow can be defined as a stream of packets from the same source to the same destination using the same application. As an example, a flow could be an HTTP session between a source browser and a target server. In a Cisco MLS network, the initial packet in a session is routed via the RP, but all subsequent packets in that particular session are switched by the SE. The SE maintains a cache about these flows and can determine whether or not a given packet is part of an established session. If so, the SE rewrites the pertinent packet info as if it had been processed by the router and then switches the packet. This process is commonly referred to as “route once, switch many.” It occurs at switch speed, not at the slower router speed.
So in terms of MikroTik and RouterOS I do not see ANY functionality that mimics or deals with wire-speed Routing at the switch level.
