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.
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)
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.
Had to downgrade back to beta2 again.
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.).
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.
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:
finish the porting of everything that was in v6 so it can be realistically BETA-tested (maybe with exception of the routing code)
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)
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.