Community discussions

MikroTik App
 
mmc
newbie
Topic Author
Posts: 41
Joined: Wed Dec 29, 2004 1:44 am

ros7 routing filter rules unusable - missing move functionality

Mon Dec 13, 2021 5:09 pm

hi,

via winbox i found no way how to move any rule.

via cli it shall work with the 'move' command, but the move command doesn't do anything within the same chain:
[admin@m] /routing/filter/rule> print
Flags: X - disabled, I - inactive 
 0   ;;; source-adress for all generated traffic
     chain=ospf_in rule="set pref-src 192.168.1.1;" 

 1   chain=ospf_out rule="if (dst in 192.168.0.0/16) {\r\n accept;\r\n}" 

 2   chain=ospf_out rule="if (protocol connected) {\r\n accept;\r\n}" 

 3   chain=ospf_out rule="reject;" 

 4   chain=ospf_in rule="reject;" 

 5   chain=ospf_in rule="accept;" 
[admin@m] /routing/filter/rule> move 1 2
[admin@m] /routing/filter/rule> print
Flags: X - disabled, I - inactive 
 0   ;;; source-adress for all generated traffic
     chain=ospf_in rule="set pref-src 192.168.1.1;" 

 1   chain=ospf_out rule="if (dst in 192.168.0.0/16) {\r\n accept;\r\n}" 

 2   chain=ospf_out rule="if (protocol connected) {\r\n accept;\r\n}" 

 3   chain=ospf_out rule="reject;" 

 4   chain=ospf_in rule="reject;" 

 5   chain=ospf_in rule="accept;" 
[admin@m] /routing/filter/rule> 
disable and enable works well, but that's it.

this makes the whole new routing filters absolutely unusable for my point of view, when you have real life setups with tons of complex filtering.

somebody any idea how this could work?
 
aleksis
newbie
Posts: 25
Joined: Wed Apr 30, 2014 12:13 pm

Re: ros7 routing filter rules unusable - missing move functionality  [SOLVED]

Mon Dec 13, 2021 7:28 pm

move command argument 'destination' works like "place-before" so to move rule 1 one place further you have to do 'move 1 3'.
 
mmc
newbie
Topic Author
Posts: 41
Joined: Wed Dec 29, 2004 1:44 am

Re: ros7 routing filter rules unusable - missing move functionality

Wed Dec 15, 2021 5:37 am

@aleksis: yes you are right, thanks, that works with cli move command now:
[admin@m] /routing/filter/rule> print
Flags: X - disabled, I - inactive 
 0   chain=one rule="accept;" 

 1   chain=one rule="reject;" 

 2   chain=two rule="accept;" 

 3   chain=two rule="reject;" 
[admin@m] /routing/filter/rule> move 0 2
[admin@m] /routing/filter/rule> print
Flags: X - disabled, I - inactive 
 0   chain=one rule="reject;" 

 1   chain=one rule="accept;" 

 2   chain=two rule="accept;" 

 3   chain=two rule="reject;" 
[admin@m] /routing/filter/rule> move 0 3
[admin@m] /routing/filter/rule> print
Flags: X - disabled, I - inactive 
 0   chain=one rule="accept;" 

 1   chain=two rule="accept;" 

 2   chain=one rule="reject;" 

 3   chain=two rule="reject;" 
[admin@m] /routing/filter/rule> move 2 1
[admin@m] /routing/filter/rule> print
Flags: X - disabled, I - inactive 
 0   chain=one rule="accept;" 

 1   chain=one rule="reject;" 

 2   chain=two rule="accept;" 

 3   chain=two rule="reject;" 
[admin@m] /routing/filter/rule> 
but for my point of view it's still unusable. when you have a lot routing filters in separate chains (in a typical bgp peer setup you easily have 100+ rules), the cli only handling is too limited to deal with big tables.
move needs a winbox implementation and also a proper sorted view respecting the flow order of the rules.

Who is online

Users browsing this forum: edupre and 21 guests