I've been studying a little about the routing filter syntax of MikroTik's RouterOS version 7. It's very flexible and has the potential to be very powerful.
(P.S.: I congratulate whoever chose this syntax.)

However, I realize that the actions options that are available now are quite limited.

Is there any Roadmap to release more possibilities for these Actions?

I wondered that in { [actions] } it would be possible to have a hook for scripts and commands from RouterOS itself.
P.S.: Actually, being pragmatic, it could hook to anything... But let's start small. haha.

Anyone with a bit of reasoning can conclude that if used the wrong way it can be deadly.
For example, some 'j'enius can make a rule that upon receiving the default route, call a reboot script. Or anything else as stupid as that. However, I see that for this, the stance may be the same as with scripting today: "Use this at your own risk!".

BGP Flowspec
An example of how an advanced hook action to a Script would be useful is to allow users to implement their own BGP Flowspec rules themselves.

As far as I can imagine, if today there were a { [actions] } in /routing/filter/rule that allowed a call to a script where the debug.fwp-ptr attribute was passed as one of the call arguments of the script, it would be possible to create a set of scripts in which you could create dynamic entries in /ip/firewall/filter/ and /ip/firewall/raw/ to then have very similar results to the BGP Flow Spec protocol.

This is the sample function for adding to an address-list in filter/mangle/raw rules:
This is then the call to the function with the name "ruleAddresToLIst" from a rule to add and address to a list: Implementing this kind of flexibility is complex and for a simple add to list you have already 5 options to select from. Two for address and three for Timeout.

@fischerdouglas
We need to find someone good with scripting on RouterOS,
and people should stop making requests to MikroTik until they fix all the things that are already wrong,
without needing to insert other problems that they CAN NOT keep up with.

Implementing this kind of flexibility is complex and for a simple add to list...

Exactly...
It would be enough for the filter to "pass" the record (even in hexadecimal) to the script...
And based on the name of the script you call, do a different action.

Code: Select all

:global ruleAddresToList do={ /ip firewall address-list add list=$listName address=$Address timeout=$Timeout }

Code: Select all

$ruleAddressToList Address=$dst-address Timeout=00:00:05 listName=testlist
$ruleAddressToList Address=$src-address Timeout=non-dynamic listName=testlist 

Thank you @msatter for your collaboration!

But I believe that it will need to be a bit more elaborate.

When we are talking about flowspec, we will have several other attributes.
Some of the match criteria: src-address, dst-address, src-port, dst-port, etc.
Some of the action criteria: drop, permit, rate-limiting, to-other-interface, to-other-vrf, etc...

There can be many attributes, and passing all these attributes in the script call may use more memory than is desirable.
In this case, I think that passing the unique identifier of the route(debug.fwp-ptr) to the hook, and from within the script fetching these attributes with a find might be more elegant.

Also...
I don't know how the RouterOS scripting handles the equivalent of processing queues.
But a care that needs to be taken is that the processing of the hook called does not block the processing of the next rules that the BGP peer is sending.

This will be hard work.
But I believe that good things can come out of here.
Thank you once again, and I remain with your cooperation.

Hello @rextended!
Thanks for your response.

We need to find someone good with scripting on RouterOS,

Well... I'm not one of those guys.
I know almost nothing about scripting in RouteOS.
I played around with it for about 2-3 hours, and what came out that might be useful is this:
https://github.com/fischerdouglas/route ... ssList.rsc

From what little I've dealt with, I've found RouterOS' scripting feature to be quite powerful.
Maybe it has some limits that I think don't need to exist.
But: "Behind every silly message sign lies an even sillier story."
So I wonder where the parsimony in releasing more power for the use of Scripting could have come from.

and people should stop making requests to MikroTik until they fix all the things that are already wrong,
without needing to insert other problems that they CAN NOT keep up with.

On that, I partly agree.

The part where I agree with you:
Yes. If for every colleague who has an idea and makes a request to the MikroTik dev team they stop and develop everything they ask for... They will never progress with more elaborate features.

The part where I disagree with you:
The amount of users that would actually make use of more advanced things like filtering based on BGP Flow Spec within MikroTik's niche market is quite small.
So, marketing-wise, it doesn't make that much sense to put effort into releasing features like this.
However, the same niche market that will make use of more advanced things like this is made up of people who have some more advanced skills when it comes to design, configuration, and some Scripting.
So, from where I can see it, if MikroTik's dev team puts some effort into increasing the flexibility and power of tools like /routing/filter or scripting, it will enable this more advanced audience to solve their own problems, and consequently reduce the backlog of low-demand features such as packet filtering based on BGP Flow Spec.

That's the idea behind this suggestion.

Route Leak Between VRFs

Another use for that hook on routing filter action can be the solution to the lack of mechanism to route leaking between VRFs.
For the desired routes, you can call a script that will do the job adjusting routing rules.

And then tadã..
You have automated Route Leak!

QoS policy propagation using BGP (QPPB)

I'm not sure if RouterOS v7 accepts and propagates QPPB.
But I'm quite sure that it does no support applying on the data-plane the QoS Policies that come trough BGP.

This is another example of a resource that could be deployed by more advanced users of RouterOS who has that kind of needs.

I know that lua scripting stayed on the past...

But just to exemplify, FRR allows you to do hooks to lua scripting passing arguments.
And it can be done on several point of tal tool, including when interacting with the RIB.

Justo to be clear, I'm not "inventing a thing".
Other engines bring similar possibilities, like:
- Old Cisco IOS and TCL scripts called by embedded event manager and other hooks.
- Accell on auth events
- Junos
- Arista EOS
I'm just bringing the idea and expanding the horizons and reduce the number of silly features on the backlog.


I'm pretty sure that it scares when your guys think:
"And how it will be when a support ticket whit this *** been used?"

To, that... What about something like developer mode of Android?
If you are in dev-mode, you are on your own!
If a "show tech-support" arrives with that:
"Welll, as very well explained on this page on the docs, is a support case reaches with this kind of feature, we will not even look until it been disabled... bla bla bla..."

+1 to action = script on routing filters!