Feedback on RouterOSv7 route filtering

I’ve been trying to get this out for a while but my workload keeps getting in the way :slight_smile:

This a summary of feedback on the routing filter syntax from myself and the opinions of a number of other MikroTik users on the new route filtering format. Hopefully it will help further the conversation on changes in the syntax to make it easier to work with.

https://stubarea51.net/2021/08/24/mikrotik-routerosv7-first-look-feedback-on-routing-filters/

Here is an example of the filters we tested with:

### MikroTik RouterOS 7.1rc1 ###

/routing filter rule
add chain=dead.beef.101 rule="if (dst==200:dead:beef:101::/64) {accept}"
add chain=dead.beef.102 rule="if (dst==200:dead:beef:102::/64) {accept}"
add chain=dead.beef.agg rule="if (dst in 200:dead:beef::/48) {accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.101) {set bgp-local-pref 300; accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.102) {accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.agg && dst-len<128) {set bgp-local-pref 150; accept}"

Just a note instead of matching chains you could use address lists, then it will translate easily from cisco or free range config with prefix-list

/ipv6/firewall/address-list 
add list=dead.beef.101 address=200:dead:beef:101::/64

/routing/filter/rule 
add chain=bgp-out-v6 rule="if (dst in dead.beef.101) {set bgp-local-pref 300; accept}"

And in addition, you can use the same list in firewall filtering if needed.

Completion is the next important routing filter feature that is already a work in progress.
At least if I look at your cisco and free range examples with completion it would be easy to convert to ROS filters.

And these are all filters? Dear community, I propose to add to this topic all possible filter variations according to the new scheme from ROSv7. This will really help with the move.

I am trying to convert all my filters to the new version. Faced a problem, I can not announce / 32 mask until I write it in routes. Which creates huge problems. Previously, I indicated the desired IP in the BGP settings and the prefix was announced, now it is some kind of trash

What about Winbox?
I certainly hope that you do not intend to leave v7 route filters as they are in Winbox right now and that you return to a more v6 route filters GUI style.

What are your suggestions on how to represent it in winbox? Simply “make it like v6” is not possible because of new features.

It does not need to be identical to how it was in v6. But it should be similar. No hand typing of entire statements.
The matching part of the statement should be one page, separate text fields and checkboxes for various variables.
You can make a separate page for BGP matching or you can keep it together with the main matching page.
Then a separate page for the ‘actions’, again you can keep what was traditionally under bgp actions as separate or together.
As for the new features you can add them on top of that.

I don’t mind having a ton of text fields and check boxes on many many pages. The important thing is that the GUI reveals to me the variables and makes the configuration ‘somewhat’ self explanatory. Unfortunately writing the entire filter statement in a single text box does not reveal the variables and is not self explanatory, that is the advantage of GUIs over CLIs. Arguably as v7 is right now it is not even a (traditional) CLI but a code snippet.

I see you are testing IPv6 on dead beef networks as I do. Nice!

Yes! I also like 200:co1d:cola::/48 and 200:7ac0:cafe::/48

:wink:

Which new features are creating a challenge? That might help the user community to provide some feedback.

Hi Maris/ Raimonds

I can understand why filters are different in v7.

What might make the changes easier to digest for users is a graphical “filter builder” in WinBox that allows you to select the various attributes, operators and actions then builds the filter statement for you.

Do you mean something like this?

Seems like a overkill

:open_mouth:

Is this Unreal Engine’s Blueprint? I imagine user reaction if we’d announce “WinBox3D, min. requirements. GeForce RTX3080” :wink:

NO the MTX5009 :mrgreen:

imgui, yeah it looks cool, but somehow doubt that ever will be added in winbox.

Ahh, that is cool. But no, that is not what I was imagining.

It just needs to be something simple, a step-through GUI. Kind of like the “rules” editor in Microsoft Outlook.

Or it can be virtually identical to v6 rules GUI.

1st tab: [matchers] with dropdowns/checkboxes/input fields with the addition of adding multiple of those items (matchers) with and/or operators
2nd tab: [actions] with dropdowns/checkboxes/input fields with the addition of adding multiple items (actions)
3rd tab: [else actions] with dropdowns/checkboxes/input fields with the addition of adding multiple items (actions)

Maybe it’s not really possible, since I still cannot really get my head around the new syntax and options (btw documentation really needs to be updated for v7 BGP in general - not just rules).
But not having a proper GUI or at least auto-complete in CLI, makes the new BGP engine non-usable, frankly.

As mkamenjak said, having all options in front of you (especially in the ‘winbox way’) it makes them almost self-explanatory.

Also I agree with SirPrikol. Not being able to advertise prefixes arbitrarily, and having to have a route installed is a PITA to migrate to the new paradigm.
In the meantime, I still cannot figure out how to advertise anything at all (even by having static routes added). Are there any tutorials on how to do these basic BGP stuff on v7?

I really hoped v7 BGP would be just an improvement under the hood while keeping the GUI/CLI that made it -at least to me- superior to other solutions.
But it turns out it’s a completely different beast - ie: learn everything we know about using BGP on ROS, from scratch.

I will support ChaOs. It’s better to do it through the GUI and make it clear. Otherwise, keep the rules of the quagga bird in your head and now even from mikrotik - this is already becoming a mess. Look for where you misspelled … It’s better then to sit on the 6th version of ROS and endure the lack of multitasking, than to try to learn completely new rules. Because of this, the move may be postponed for several years. With the condition that many put mikrotik at the point of traffic exchange and do not have their own networks, but they need to accept and give away strangers. Which may not be announced in the routes at any

This is a good suggestion.

+1