v7.1beta5 [development] is released!

That is what I had in mind, yes. At least it has the same functionality as an unreachable route.
Like you, I do not worry that much about DDoS, so it is a bit of a pity that we still have to suffer from feature reduction.
Hopefully this solution would also work on those hardware accelerated devices (I don’t have any).

No, this is wrong! See reply #216.

If I did so, as already mentioned, I would have to except one by one, and possibly dynamically, the subnets that actually exist, and have routes (some VPN related, some static, some dynamic, some even going through the same default gateway interface…). So instead of adding 192.168.0.0/16 I would have complex subnets. I really use the routing machinery to deal with the specific routes, and only packets going through the default route would need to be rejected.

What about the wave2 wifi package features? Will it support WDS or 802.11s meshing?

I think this will cause some headache for me as well… Let’s say I have a route 10.20.0.0/16 and 192.168.20.0/24 via OSPF. How can I excludes these from being catched by the above access-list and firewall rule?

That access list based on address-list is no good. The other workaround (reply #219) should be OK.

Ah, skipped that one too fast… Yes, looks promising.
I will give it a try as soon as a beta with OSPF setting for path cost is available.

When using multiple routing tables combined with a routing protocol in v6 I encounter the problem that the “connected route” for an interface is only inserted in the main table.
While this is usually no problem for the routing itself (ip route rules can be configured to look in the main table for local traffic), it causes a problem when using “bgp networks” to configure what the BGP instance should publish.
To work around that, I regularly copy the connected routes from main to the second routing table using winbox (open all DAC routes, do a Copy, change routing mark and distance and store).
However, that does not solve the problem for dynamically created interfaces like VPN or PPPoE.

Will the new architecture for routing and routing protocols in v7 fix this? If not, please think about a fix. E.g. some setting per interface to copy connected route to some specified table.
(it could be that using the VRF feature could solve part of these issues, but unfortunately there is too little documentation on how this exactly works to make it useful)

This is already on the list: https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status

“Some kind of mechanism to import/export routes from one vrf to another within same router”

Currently listed as not yet implemented but that page has not been updated for v7beta5.

I’ve accidently rebooted my RB4011 (without WiFi) after 5 days uptime on 7.1beta5. All was running fine but since this reboot it crashes every about 4 hours. Happened six times now. Sometimes a bit less than 4 hours, sometimes a little above.
There’s nothing else noticeable. No cpu load, no unusual memory usage (always <100MB usage), no slowdown, nothing. It just crashes, reboots (did not come back itself one time), and log just says “router was rebooted without proper shutdown”. Nothing else.

Does anybody know what RouterOS could be doing every about 4 hours?

The only thing that could be new is that I’m using EOIP over a Wireguard connection now (Wireguard without EOIP before that). Unfortunately I can’t deactivate it to test it at this time.

Make sure your RouterBOOT firmware is also upgraded to 7.1beta5. I had similar reboots on RouterOS 7.1beta5 (with wifi) and found out it was because I forgot to update the RouterBOOT firmware to 7.1beta5 as well.

Thank you but it already is updated :confused:

Do you use DoH with certificate verification?

I use that and have no reboots.

I had reboots every few hours as well, caused by cake simple queue. After disabling that, reboots happend only once a day. Then only netinstall finally resolved it and the device is rock stable right now (10d+ uptime)

I do not have reboot, but a big memory leakage.

No DoH, also no queues.
I’ve managed to remove the EoIP and route my stuff now again directly over Wireguard like before. Hope the crashes are gone now. I’ll report.

/edit: 12 hours uptime now. So it seems EoIP is kinda broken maybe?!

3.Routing-mark cannot add new mark routing name

You need to add routing table first, see example here.
https://help.mikrotik.com/docs/display/ROS/ROSv7+Basic+Routing+Examples#ROSv7BasicRoutingExamples-RoutingTables

Someone please chech this bug if also on 7.1beta5:
http://forum.mikrotik.com/t/bug-upgraded-package-signatures/148643/1

Thanks for the suggestion. I increased the drive on ESXI 6.5 VM from 64M to 128M and successfully started RouterOS