Community discussions

MUM Europe 2020
 
kburzyns
just joined
Topic Author
Posts: 14
Joined: Mon Mar 09, 2015 8:50 am

Routing filter issue

Thu Mar 12, 2015 9:20 am

Hi,

I have three routers: "11", "12" and "13" connected as in the picture, running eBGP. I do NOT want to redistribute routes from router "13" to "12".
Pict1.png
I have prepared routing filter:
add action=discard chain=only_local_out invert-match=yes prefix=172.16.100.0/24
add action=discard chain=only_local_out invert-match=yes prefix=172.16.101.0/24
on router "11" (100 and 101 are local networks of "11"). When I attach rule to BGP instance it works pretty well.
Pict2.png
however, when I put it to the peer ...
Pict3.png
There are no BGP routes on router "12" (there should be routes to 100 and 101 networks as in the second picture). Is it a bug/feature or misconfiguration?


Ps.
I found a workaround:
add action=discard chain=only_local_out invert-match=yes locally-originated-bgp=yes
this rule resolves the problem, but I want to know why rule with defined addresses doesn't work.
You do not have the required permissions to view the files attached to this post.
Last edited by kburzyns on Tue Mar 31, 2015 8:59 am, edited 1 time in total.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: Routing filter issue

Tue Mar 24, 2015 12:30 am

Your logic is trying to be efficient - drop everything except this ______
However, the multiple negative statements have tripped you up.

Here are your rules:
1: add action=discard chain=only_local_out invert-match=yes prefix=172.16.100.0/24
2: add action=discard chain=only_local_out invert-match=yes prefix=172.16.101.0/24

Let's play router in our head:
Try prefix = 1.2.3.0/24....

Rule 1: 1.2.3.0/24 is not 172.16.100.0/24, so invert that match = true -> DISCARD.
So far so good....

Now try one you WANT to work:
172.16.100.0/24

Rule 1: 172.16.100.0/24 IS a match, so invert that = FALSE - rule fails, proceed to rule 2
Rule 2: 172.16.100.0/24 does NOT match 172.16.101.0/24 - invert that -> TRUE - Action = Discard

So, rule 2 drops the stuff rule 1 should keep, and rule 1 drops the stuff that rule 2 should keep.


In stead, be simpler:
1: add action=accept chain=only_local_out prefix=172.16.100.0/24
2: add action=accept chain=only_local_out prefix=172.16.101.0/24
3: add action=discard chain=only_local_out

This is much easier to read and follow, and it should fix your problem.
You could also use just one accept rule:
add action=accept chain=only_local_out prefix=172.16.100.0/23 prefix-length=24
If you don't understand this, then use the first method above. This one could have you pulling out your hair if you don't understand the difference between a prefix mask and a prefix length.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
kburzyns
just joined
Topic Author
Posts: 14
Joined: Mon Mar 09, 2015 8:50 am

Re: Routing filter issue

Wed Mar 25, 2015 9:13 am

Thank You, everything is clear now. I have had no idea that routing filter works like the firewall.

Your both propositions are understandable, but I will stay with my rule "add action=discard chain=only_local_out invert-match=yes locally-originated-bgp=yes" because it is not sensitive for adding new networks to advertise.

++
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: Routing filter issue

Wed Mar 25, 2015 2:13 pm

Thank You, everything is clear now. I have had no idea that routing filter works like the firewall.

Your both propositions are understandable, but I will stay with my rule "add action=discard chain=only_local_out invert-match=yes locally-originated-bgp=yes" because it is not sensitive for adding new networks to advertise.

++
That works for you right now, but it's actually not a good habit for you to form while learning BGP.

Suppose the current router is R1, and you use this filter.
Later, you add a new interior router (R2) to your network in the same ASN - This will be iBGP, and they should share their complete routing information. If R2 originates a prefix into your iBGP, then R1 will not send this new route to the EBGP neighbor, even though it should do so.

Another benefit of using explit prefixes is that it prevents you from accidentally advertising something later. Suppose you turn on "redistribute connected" and then add an interface 10.1.1.1/24 to the router - your router will try to put 10.1.1.1/24 into public BGP!

This rule works for you now in a very specific situation, but it's not consistent with best practice. It is much better to build good habits as soon as you can.

If you want to learn how to filter "my prefixes only" everywhere in a scalable way, you should experiment with BGP communities. You can have 5 thousand routers all following the same rules very easily using this.

Whenever you originate a route into BGP, add a community to it that means "my locally originated routes" - if your ASN is 500, then you might use 500:1 to mean this. You may then add 500:2 for "routes from my customers" And then on every ebgp router, you use a filter that allows only the routes with these two communities attached to them. This way, you can add 500 routes per week and never touch most of your ebgp routers.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
kburzyns
just joined
Topic Author
Posts: 14
Joined: Mon Mar 09, 2015 8:50 am

Re: Routing filter issue

Tue Mar 31, 2015 9:09 am

Now try one you WANT to work:
172.16.100.0/24

Rule 1: 172.16.100.0/24 IS a match, so invert that = FALSE - rule fails, proceed to rule 2
Rule 2: 172.16.100.0/24 does NOT match 172.16.101.0/24 - invert that -> TRUE - Action = Discard

So, rule 2 drops the stuff rule 1 should keep, and rule 1 drops the stuff that rule 2 should keep.
OK, I understand above. But why it works different,when I use rule in BGP Peer and in BGP Instance? Compare Pict2 and Pict3. The same rule is used, but effect is not the same. Your explanation suits to Pict3, but what for Pict2?

Thanks for sharing Your experience and good practices!
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: Routing filter issue

Tue Mar 31, 2015 2:56 pm

OK, I understand above. But why it works different,when I use rule in BGP Peer and in BGP Instance? Compare Pict2 and Pict3. The same rule is used, but effect is not the same. Your explanation suits to Pict3, but what for Pict2?

Thanks for sharing Your experience and good practices!
I noticed that in picture1 there are no filters at all.
Then there's picture 2 - output filter on peer but not the instance.

Is it possible that you cleared the BGP from 13 -> 11, but not 11 - > 12? Changing the filter will not cause the neighbor to change the routes you sent to it earlier. This is because BGP is designed to work with huge routing tables that can take minutes to transfer and install into the RIB. So in other words, until BGP goes through every route and refreshes the session, old information will not be withdrawn just because now it does not pass a filter that didn't deny it earlier.

In Cisco you can do a "soft reset in" or "soft reset out' with a peer to refresh the information gracefully. If you change the filters for a peer, for instance, you would then do this. If you just shut down the peer and start again, this is disruptive when you have a full routing table - it's around 500k routes in IPv4. The router must erase 500k routes from memory and then download all 500k again. A soft reset is like doing an audit in stead.

Eventually, even if you do not do a soft reset (or a hard reset), BGP will audit itself and withdraw the filtered routes.

Probably this is why you saw what you did.


EDIT: I just went and looked around in my Mikrotik here and found buttons in BGP > Peers: Refresh, Refresh All, Resend, Resend All - these appear to be the soft reset actions I was talking about with Cisco routers...
When given a spoon,
you should not cling to your fork.
The soup will get cold.

Who is online

Users browsing this forum: dalami, h0m3 and 8 guests