Routing filter order

shyrwall · Tue Jul 04, 2017 2:07 pm

Hi

So if I understood this correctly the routing filters are processed from top to bottom in the same chain. Each rule in the filters has a rule number.

Example, routing filter print.

0 chain=IPV4-TRANSIT-IN invert-match=no action=accept set-bgp-local-pref=100 set-bgp-prepend-path="" set-bgp-med=5000
1 chain=IPV4-TRANSIT-IN invert-match=no action=discard set-bgp-prepend-path=""
2 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-as-path=^$ invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
3 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-communities=41281:9000 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
4 chain=IPV4-TRANSIT-OUT invert-match=no action=discard set-bgp-prepend-path=""
---

What is the purpose of this rule number? Since it obviously has nothing to do with the actual order of the rules being interpreted.

I can for example move rule #2 IPV4-TRANSIT-OUT to be first like this,

0 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-as-path=^$ invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
1 chain=IPV4-TRANSIT-IN invert-match=no action=accept set-bgp-local-pref=100 set-bgp-prepend-path="" set-bgp-med=5000
2 chain=IPV4-TRANSIT-IN invert-match=no action=discard set-bgp-prepend-path=""
3 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-communities=41281:9000 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
4 chain=IPV4-TRANSIT-OUT invert-match=no action=discard set-bgp-prepend-path=""
---

Which would make the whole thing very confusing when looking at.

So my questions are. Is there any difference in processeing when doing the above? When moving rules in a chain so it's not grouped together but keeping the same order?

If there is no difference then maybe Mikrotik should instead change/add so the assignment of a number to the rules are grouped per chain. Example ,

0 chain=IPV4-TRANSIT-IN invert-match=no action=accept set-bgp-local-pref=100 set-bgp-prepend-path="" set-bgp-med=5000
1 chain=IPV4-TRANSIT-IN invert-match=no action=discard set-bgp-prepend-path=""
0 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-as-path=^$ invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
1 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-communities=41281:9000 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
2 chain=IPV4-TRANSIT-OUT invert-match=no action=discard set-bgp-prepend-path=""

--

Another example is if you print a single chain , routing filter print where chain=IPV4-TRANSIT-IN it will assign a number from 0 and up. Confirming that the rule number is just some incremental counter not really connected to the actual rule just to the output of the print.

What confuses everything more then is the following,

routing filter print where chain=IPV4-TRANSIT-OUT :

0 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-as-path=^$ invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
1 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-communities=41281:9000 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
2 chain=IPV4-TRANSIT-OUT invert-match=no action=discard set-bgp-prepend-path=""

If I now want to move let's say rule #1 to be #0 I can't use the numbers provided in the output but I have to use the numbers provided when printing all the rules,

routing filter print :

0 chain=IPV4-TRANSIT-IN invert-match=no action=accept set-bgp-local-pref=100 set-bgp-prepend-path="" set-bgp-med=5000
1 chain=IPV4-TRANSIT-IN invert-match=no action=discard set-bgp-prepend-path=""
2 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-as-path=^$ invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
3 chain=IPV4-TRANSIT-OUT match-chain=IPV4-WORLD-OUT bgp-communities=41281:9000 invert-match=no action=accept set-bgp-prepend-path="" set-bgp-med=1000
4 chain=IPV4-TRANSIT-OUT invert-match=no action=discard set-bgp-prepend-path=""

routing filter move numbers=3 destination=2

--

I'm sorry for the confusing post. I hope someone understands

And either can say that i'm doing it wrong or that maybe mikrotik can assign a number to rules within their chain. Just like in for example cisco "route-map IPV4-TRANSIT-OUT permit 10", "permit 20" etc.

--

Cha0s · Fri Jul 07, 2017 5:08 pm

As far as I can tell it's just a number to help process the rules in the right order.

It doesn't matter if they are consecutive numbers or not. It's still the same. Number 5 is always bigger than number 2 regardless if there are numbers 3 and 4 in the middle or not.

When you have all rules listed you get something like

0, rule, chain A
1, rule, chain A
2, rule, chain B
3, rule, chain A
4, rule, chain C
5, rule, chain A

So what does that mean?

chain A will be processed in the same order as shown in the full list view.

0, rule, chain A
1, rule, chain A
3, rule, chain A
5, rule, chain A

The rule numbers mean nothing except letting the router know in which incremental order to process them. number 5 will always be bigger than number 3 even if number 4 is missing.

If it makes it confusing to watch it like that, it's up to the user to 'group' the rules together so they are more human readable.
It makes no difference to ROS itself if you have the rules/chains mixed together (but in the right order) or if you have all the rules/chains grouped together (which is my preferred way of implementing my rules).

It's the same in IP > Firewall and probably other places too (I don't recall atm).

I agree that when moving rules around via CLI it is kind of confusing. But in Winbox it is rather intuitive. Most of the time you don't even care about the rule number. You just move rules around and they just work.

shyrwall · Fri Jul 07, 2017 5:47 pm

Ok. So as I thought then. No difference on how it works just how it looks in cli/winbox.
I'm just trying to imagine on how it looks in the internal "database" (or however its stored). To keep track of where a rule in the chain is I feel that there has to be some internal number unique for that rule in the chain. Or it would for example be a pain programmatically to move a rules order. If there isn't some internal number unique to that chain.

For example, if I have a bunch of rules,

0 chain1
1 chain2
2 chain3
3 chain3
4 chain4

And I move chain3 so it is in the top (and gets #0 and #1) instead I doubt it will rewrite the number of all the rules in the "internal config database". If I could guess I bet the numbers aren't really stored. They are just interated when the cli/winbox prints the rules.

So to my point then. If there is some internal number that is keeping track then it would be nice to be able to have it displayed as a column and/or being able to move a rule by that number in the cli.
I don't want to be dependant on winbox. And in the cli this is just to messy for me.

As for ip->firewall I agree that it is done similar. But in ip->firewall you would have a bunch of different possible keys. In the routing->filter the chain-name is the only key.

murgatroid · Thu Jun 28, 2018 6:45 am

This had me scratching my head for a while. Although you might re-order the rules, the new order is not active.

However, if you 'enable' a rule in a filter chain (even if it is already 'enabled') it causes the chain to be flushed and re-applied in the correct (new) order.

Maybe Mikrotik can add this to their docs?

Cha0s · Mon Jul 09, 2018 5:55 pm

This had me scratching my head for a while. Although you might re-order the rules, the new order is not active.

However, if you 'enable' a rule in a filter chain (even if it is already 'enabled') it causes the chain to be flushed and re-applied in the correct (new) order.

Maybe Mikrotik can add this to their docs?

This has been a bug for ages. It has been reported many times over the years but it's just being ignored.

Thu Jul 19, 2018 5:12 am

This bug has been driving me insane for the last 8 years.

It is like Mikrotik's routing developer left 8 years ago. There have been only minor bug fixes, and no improvements to BGP/OSPF/RIPv2/PIM/LDP/RSVP in this time period, even when there are a large number of repeatable bugs.

It is extremely frustrating as a customer to see bugs like this go unresolved for so long.

Hammy · Thu Jul 19, 2018 5:27 pm

I've also noticed that copying a rule *CAN* screw things up, but creating new rules from scratch (or pasting into the CLI) works just fine.

pe1chl · Thu Jul 19, 2018 7:45 pm

When you add a new rule it is added at the bottom by default, when you do not want it there (because it has to be processed somewhere between the existing rules) you can move it, but that move will not make the software re-process the filters, as it should.
Disable/enable does that. This is the source of most of the confusion.

Cha0s · Thu Jul 19, 2018 7:50 pm

When you add a new rule it is added at the bottom by default, when you do not want it there (because it has to be processed somewhere between the existing rules) you can move it, but that move will not make the software re-process the filters, as it should.
Disable/enable does that. This is the source of most of the confusion.

When you copy an existing rule though, it actually adds the new rule bellow the rule you just copied. But it is shown at the bottom instead.
Hitting F5 will refresh the rules list and show it in the correct position without the need to move anything. (also the same applies to IP > Routes > Rules)
But still it doesn't always work and you need to disable/enable the new rule.

Also I prefer selecting the rules and clicking only enable (even if they are already enabled).
This way they are getting re-processed without having routes leaked even for a second when doing disable/enable.

eset · Thu Jan 31, 2019 10:50 am

I have following error I don't understand that routing filtering

Two IPsec tunnel with different peers. Set BGP on each session

/routing bgp peer
add address-families=ip,vpnv4 in-filter=casino-in name=up-gcp_casino out-filter=casinio-out remote-address=169.254.0.2 remote-as=65502 ttl=default
add address-families=ip,vpnv4 in-filter=bb-in instance=up-gcp_bb name=up-gcp_bb out-filter=bb-out remote-address=169.254.0.6 remote-as=65506 ttl=default

/routing bgp instance
set default as=65500 client-to-client-reflection=no out-filter=casinio-out redistribute-ospf=yes router-id=169.254.0.1
add as=65500 client-to-client-reflection=no name=up-gcp_bb out-filter=bb-out redistribute-ospf=yes router-id=169.254.0.5

So I've added the following Route Filtering

/routing filter
add action=accept chain=casino-in
add action=accept chain=bb-in
add action=accept chain=casino-out prefix=10.5.0.0/22
add action=accept chain=casino-out prefix=172.16.0.0/23
add action=accept chain=bb-out prefix=10.5.0.0/22
add action=accept chain=bb-out prefix=172.16.0.0/23
add action=accept chain=bb-out prefix=10.10.0.0/24
add action=accept chain=bb-out prefix=172.16.16.0/30
add action=discard chain=casino-out
add action=discard chain=bb-out
add action=discard chain=all-out distance=!0-1

but that doesn't work. Because advertisement shows that

/routing bgp advertisements> pr
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
up-gc... 10.254.254.252/32 169.254.0.1 igp
up-gc... 10.11.0.0/24 169.254.0.1 igp
up-gc... 10.5.0.0/22 169.254.0.1 igp
up-gc... 10.255.255.0/24 169.254.0.1 igp
up-gc... 10.255.254.0/24 169.254.0.1 igp
up-gc... 10.254.254.251/32 169.254.0.1 igp
up-gc... 172.16.17.0/30 169.254.0.1 igp
up-gc... 10.10.0.0/24 169.254.0.1 igp
up-gc... 10.11.1.0/24 169.254.0.1 igp
up-gc... 10.12.0.0/24 169.254.0.1 igp
up-gc... 10.10.2.0/24 169.254.0.1 igp
up-gc... 10.254.254.253/32 169.254.0.1 igp
up-gc... 10.12.1.0/24 169.254.0.1 igp
up-gc... 172.16.0.0/23 169.254.0.1 igp
up-gc... 10.5.0.0/22 169.254.0.5 igp
up-gc... 10.10.0.0/24 169.254.0.5 igp
up-gc... 172.16.0.0/23 169.254.0.5[/quote

As you see 169.254.0.1 (casino-out) has a lot's of addresses although I said that I want only two:

add action=accept chain=casino-out prefix=10.5.0.0/22
add action=accept chain=casino-out prefix=172.16.0.0/23

jprietove · Thu Jan 31, 2019 10:57 am

Maybe it's a typo? Look here:

/routing bgp peer
add address-families=ip,vpnv4 in-filter=casino-in name=up-gcp_casino out-filter=casinio-out remote-address=169.254.0.2 remote-as=65502 ttl=default
                                                                                ^^^^^^^

You wrote casinio-out instead of casino-out

eset · Thu Jan 31, 2019 11:39 am

You wrote casinio-out instead of casino-out

Damn I didn't catch that... :/ Thanks. Sorry to bother. So I quess I understand it good

Routing filter order

Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Re: Routing filter order

Who is online