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

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/mikro ... g-filters/

Here is an example of the filters we tested with:

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 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

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

Code: Select all

/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.

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.

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!

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

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

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

... ...

Do you mean something like this?

Is this Unreal Engine's Blueprint? I imagine user reaction if we'd announce "WinBox3D, min. requirements. GeForce RTX3080"

NO the MTX5009

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

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.

This is a good suggestion.

+1

Only problem with these wizards and builders is that you still end up with a string, and if you want to edit the rule you still need to understand what "if (dst == 1.1.1.1) {accept}" means

Understand that we understand how and what should work, which prefix to allow for the entrance, which one to deny ... But at the same time dst == .... both at the entrance and at the exit ... This is the first thing that is misleading. Therefore, we ask that there is no confusion. In ROSv6 it was convenient, the very understanding was close to the very same quagga. Now it is absolutely not clear what and where. And such a question. How to write Nexthop-Direct? How to send the received route to a specific channel? In the manual, this topic is not developed at all.

rc2 just dropped, and it has tab-completion for filter rules.
A big step forward!

But it's still a long way from being usable.
I mean, you have no way to search, sort, show specific columns of attributes, etc.
If you have a 5-10 filters thats ok. But when you deal with hundreds of them, it's really not user friendly at all to have to look each filter expression to find where you've set a specific BGP-MED for example.

With the v6 filters you just show the Set BGP MED column, and filter by it (eg: Set BGP MED < 100). And boom! All related filters are shown immediately.

I honestly cannot understand how such a useful design was scrapped for this expression based system.

What would be handy is to have the "script" or "code" that one can import your current filters in to and then export the new V7 filters for importing in to a V7 device.

It seems from the development track, that this conversion will not be part of V7 and therefore you would probably have to start with a fresh installation.

https://help.mikrotik.com/docs/display/ ... col+Status

Just another "V7 and the filter string syntax is difficult at best to understand and use".
Try and at least make a basic Winbox GUI format that we can parse through.
Learning "code" and syntax is a pain in the arse. You need to at least update your examples to include MANY MANY more for people to learn from.
Thanks,

They have said they are in development of a new cross-platform Winbox replacement. Presumably this will allow them to create different GUI designs that will be more suitable for something like this.

They have said they are in development of a new cross-platform Winbox replacement. Presumably this will allow them to create different GUI designs that will be more suitable for something like this.

Source on this?
Also why dont they scrap winbox alltogether and just use the web gui with the new API? Less things to support and more quality into the web gui.
On topic: yes I think the route filtering syntax is too complicated and too little documented. The examples in the docs I tried to use a few months back, where outdated and did not work. I have not used route filters in ros7 since then. Still on ros6 because of that.

Source on this?

viewtopic.php?p=901944#p901944

The problem that I would see with moving entirely to a web gui would be that you would lose MAC winbox capabilities.

MT

Any chances on improving router filtering in UI/winbox now?, we are not asking for v6 like for like UI but at least some semblance of having a more polish product rather than as if the UI was design after having a drinking session in the party the routing filter is v7 is more powerful in v6 but counter intuitive or step backward to v6, I know a lot of energy is being devoted in the engine but I think we have to give some loved too in the UI

I think for advance users you can still leave the current UI as it is, but for basic filtering requirement can you copy whatever we have in v6 at lease a compromise?