v7.1beta6 [development] is released!

In v7, will there be done any to logging.

Like using RFC for time log format and fix the logging prefix mess?
When I made a support request for it, I was told that you would work on it.

http://forum.mikrotik.com/t/logging-prefix-is-a-mess-sup-105353-sup-144261-waiting-for-mt-to-support-rfc-5424/111067/1

For anyone struggling with OSPF interface-templates.

Setting interfaces=all (instead of unset interfaces) works too if you want to specify only networks.
And vice versa - setting networks=0.0.0.0/0 (instead of unset networks) works if you want to specify interfaces directly.
This way it won’t reset to improper values any time something is changed in the template from winbox GUI.

The reason is that logic AND is used with this fields, and interface has to fall under both condition.
While default interfaces=“” or networks=“” wrongly equals to “none”, i guess.

It’s marketed as beta, and there is hardware that is shipped with beta software!! Whatever it is, Mikrotik has decided to ship beta/testing/whatever software to it’s end customers. Of course you expect a more stable product then.

@raimondsp thanks for the info. Do you guys expect this by year end? (HW IPv6)

Good evening, I am using the rbm11g router, this router has 7.1beta6 firmware installed
The Quectel EC25-E module is connected to this device in mbim mode, but there is no connection. The module works, but the IP address of the provider is not issued, an error in the mbim operation is displayed
https://drive.google.com/file/d/1Cm53aY0mlV14RLt84cMFYu0beHQTiose/view?usp=sharing
https://drive.google.com/file/d/11HamUs2kuiQcJXx-_lHX09pUYSgeuP7E/view?usp=sharing

My OSPFv3 experience with v7.1beta6 on my RB493AH (MIPSBE 64MB RAM)

OSPFv2 was working fine.

/routing ospf instance
add name=OSPFv2 router-id=TestMTik
/routing ospf area
add instance=OSPFv2 name=Backbone-v2
/routing ospf interface-template
add area=Backbone-v2 interfaces=ether1
add area=Backbone-v2 interfaces=Loopback passive
add area=Backbone-v2 networks=x.x.x.x/19 passive

I enabled Safe Mode in Winbox.
Using the Winbox terminal:

I added an OSPFv3 Instance:

routing/ospf/instance/add name=OSPFv3 router-id=TestMTik version=3

And all was well. The instance appears in Winbox.

I added an OSPFv3 Area:

routing/ospf/area/add instance=OSPFv3 name=Backbone-v3

The new Area did not show up in Winbox. OSPFv2 stops interacting with it’s neighbors. Winbox looses connection due to the missing routes.

Using the Serial Console:

routing/ospf/export

The header with model and serial number displays immediately. Then nothing for a while.
After about 10 minuets it gives “#error exporting /routing/ospf/area” and given more time, it goes through the list of subsections for OSPF with similar errors.

The Winbox that I enabled safe mode in says that it’s been 40 minutes since it lost connection. The automatic reboot that is supposed to occur upon loss of connection has not happened. I’ll be using the console to restore a backup from before the upgrade to v7.1beta6 which did not have OSPFv3 configured.

Edit: It took more than 10 minutes to produce, but I got a support file from when OSPF seized up before I restored the backup. It’s attached here.
OSPFv3.zip (176 KB)

RB4011iGS+5HacQ2HnD
v7.1beta6 + wave2

errors in log:
memory - script - warning - DefConf gen: Unable to find wireless interface(s)
memory - system - error - critical - error while running customized default configuration script: interrupted

Name wifi is default - wifi1

I installed OpenWRT on both my CapAcs this weekend and I am truly impressed. My use case is they are dumb access points with 2 VLANs, one for my private network and one for my guest network. The transition went smoothly, the wife didn’t even notice.

So roaming is quite impressive. I start an infinite iperf3 test on my phone to a wired server and I can move around and see in real time the transition to 2.4 GHz and 5 GHz, whether it’s on the same access point or not.

Prior to that, I had to tweak the DBI on the radios because my ac devices were never connecting to the 5 GHz radio. (Minus 7 db on the 2.4 GHz). Now I don’t have to do that and my coverage is better. Also prior to that, my phone would get stuck on the same AP for a really long time.

It has been stable for 3 days now. I get around 400 mbit on my macbook pro and 200-300 on my phone.

Probably if you are doing a factory reset to load the DefConf, you may need to do it without the wifiwave2 package enabled, then enable the wifiwave2 package afterwards.

It isn’t just with yours - this happens to everybody with beta6 from what I can tell. I reported this exact issue already earlier in this thread, here: http://forum.mikrotik.com/t/v7-1beta6-development-is-released/149195/169

That’s the plan. Unless something utterly goes wrong.

I posted the same issue with an EC-25V. Worked fine under beta5 and stopped working under beta6.
Downgraded and everything is running again.


Are the DX3000/2000 Series products capable of HW IPv6 routing as well?

If yes, and if implementation is successful, do you expect they’ll hold at least 1000-2000 IPv6 prefixes?

Had to downgrade back to beta2 again. :frowning:
With beta6, I at least have been able to redistribute routes to BGP neighbours again. Haven’t had any success with beta3-beta5.

However, compared to beta2, two massive issues occured:

  • Forwarding of IPv6/GRE packets was super slow. Only got 20-30mbit/s inside the GRE, compared to over 800mbit/s (limited by the GRE peer) with beta2.
  • Output filters sometimes lead to BGP crashing(?). BGP Sessions were flapping, BGP neighbors report “Connections closed” errors. I haven’t been able to isolate the cause of this issue, but sessions have been stable without output filters (-> no announcements), so it probably has something to do with route exports.

I’m running RouterOS 7.1 on a CCR1036-8G-2S+ with up-to-date Routerboard firmware.

The DX3000/2000 Series products are capable of HW IPv6 routing (no HW Fasttrack, though). Both IPv4 and IPv6 routes share the same hardware memory; IPv6 routes occupy 4x more space than IPv4. If I’m not mistaken, the DX3000/2000 series products will be able to hold up to 3328 IPv6 prefixes (13312 / 4).

Please take into account that the DX8000 series have a completely different hardware routing engine than DX3000/2000, so we have to write two L3 HW offload implementations. We are focusing on the DX8000 first (CRS309, CRS317, etc.), then move on to DX3000/2000 (CRS305, CRS328, etc.).

IPv6 forward is not working on Hex - is this a known problem and is there a workaround for it?

What’s this mean for routeros though? (DX3000/2000 devices) Will we see hardware ipv6 routing so long as we either don’t configure any ipv6 firewall rules (ie, no way to get the route ‘out’ of the CPU) or if we do a VRF or something? Routing via CPU on these devices is abysmal, currently hanging a router-on-a-stick off them but I’d really like to ditch this process and get hardware offload onboard. NP16 is a fantastic device so this is a big ticket item for me and a lot of wisps.

For another network, I use IPv6 as an underlay so customers are isolated in a tunnel at the DMARC (can’t wait for vxlan over IP/evpn etc hopefully in hardware…SRv6 even better.). Similar question here in that I mostly want hardware IPv6 routing and a basic firewall for packets targeting the device just to be on the safe side. Generally packets will be encapsulated so no worries. Also, this is likely a DX8xxx series switch, probably CRS309 for those SFP+ ports. It’s not clear if you we’re saying that only the DX2/3 series can’t do fasttrack while the DX8x CAN.

RB4011iGS+5HacQ2HnD
v7.1beta6 + wave2

  1. errors in log:
    memory - script - warning - DefConf gen: Unable to find wireless interface(s)
    memory - system - error - critical - error while running customized default configuration script: interrupted

Name wifi is default - wifi1

Reset configuration - No default conf - couldn’t help

  1. Lan connection + latest Winbox 3.27 - couldn’t reboot a RB4011iGS+5HacQ2HnD. Only wifi device can reboot!

Well I do not determine the priorities and I do not know about that big customer that wanted hw acceleration, but I would (and I think I am not the only one) prefer this sequence of v7 implementation:

  1. finish the porting of everything that was in v6 so it can be realistically BETA-tested (maybe with exception of the routing code)
  2. add/finish the major features that have been promised for the past 5+ years to be available in v7 (new routing, new VPN protocols, better IPv6 support etc)
  3. work on completely new features that were not in v6 and now become possible (wifi wave2, hw accel etc)

I do appreciate that MikroTik work on new (for them) features like hw accel, but in the meantime I (and others) am waiting on features were promised for v7, are available as unfinished teasers, but now have to wait longer and longer for a stable version because the effort goes into features I don’t need on router or wifi devices…

Although I don’t know what their priorities are, one issue that i might see with where you place #1 is that to finish porting everything that is in v6 (meaning the various kernel modifications), they would lock themselves down to a particular kernel version. They might have to redo the modifications in #1 later if they wanted to upgrade the kernel. I suspect they are doing 2 and some of 3 beforehand on purpose, so that they can give the kernel one final update to whatever the latest LTS kernel is, before porting the modifications over, like GRE keepalives. This is just a guess, but otherwise, we would likely have seen GRE keepalives already. This means it would take longer for us to get a v7 with all the kernel modifications to v6, but we could get a newer kernel sooner.

Once v7 stabilizes, we are more likely to see kernel updates only very infrequently. I would rather see the kernel be as up to date as possible (as far as LTS goes) before that happens.