Hello, can yomeone please explain me the following behaviour: There's one eBGP session (b_dtag1) and one iBGP session with one of our RR Servers (b_rr1). The RR redistributes the blackhole prefixes learned from the Spamhouse BGP Feed (BGPf). The prefix 64.112.128.0/18 is supposed to be blackholed. These are the two routes learned from the two peers: bird> show route all 64.112.128.0/18 64.112.128.0/18 via X.X.X.X on eth0 [b_dtag1 Apr06] * (100) [AS3320i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 3320 3491 25847 46879 BGP.next_hop: X.X.X.X BGP.local_pref: 100 blackhole [b_rr1 15:36 from Y.Y.Y.Y] (100/-) [AS65535i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 65190 BGP.next_hop: 192.168.2.11 BGP.med: 0 BGP.local_pref: 40000 BGP.community: (65190,1000) (65535,65281) As you can see the (older) regular eBGP route is picked over the blackhole route: Based on the Route selection rules from http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 I expected that the first (Prefer route with the highest Local Preference attribute) and the second (Prefer route with the shortest AS path) rule would result in the blackhole route being picked. Best Regards Thomas Goldberg
On Mon, Apr 07, 2014 at 05:28:24PM +0200, Thomas Goldberg wrote:
Hello,
can yomeone please explain me the following behaviour: There's one eBGP session (b_dtag1) and one iBGP session with one of our RR Servers (b_rr1). The RR redistributes the blackhole prefixes learned from the Spamhouse BGP Feed (BGPf).
The prefix 64.112.128.0/18 is supposed to be blackholed.
These are the two routes learned from the two peers: bird> show route all 64.112.128.0/18 64.112.128.0/18 via X.X.X.X on eth0 [b_dtag1 Apr06] * (100) [AS3320i] ... blackhole [b_rr1 15:36 from Y.Y.Y.Y] (100/-) [AS65535i] ...
As you can see the (older) regular eBGP route is picked over the blackhole route:
Based on the Route selection rules from http://bird.network.cz/?get_doc&f=bird-6.html#ss6.2 I expected that the first (Prefer route with the highest Local Preference attribute) and the second (Prefer route with the shortest AS path) rule would result in the blackhole route being picked.
Hello That is because only resolvable routes are considered (RFC 4271 9.1.2.1), main reason for that condition is to eliminate routes whose bgp_next_hop cannot be resolved using IGP, it also affects routes whose bgp_next_hop is resolved to a unreachable/blackhole/prohibit route. In your case, it could be fixed by adding higher protocol preference (different attribute than bgp_local_pref, currently 100) to b_rr1. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
2014-04-07 18:29 GMT+02:00 Ondrej Zajicek <santiago@crfreenet.org>:
Hello
That is because only resolvable routes are considered (RFC 4271 9.1.2.1), main reason for that condition is to eliminate routes whose bgp_next_hop cannot be resolved using IGP, it also affects routes whose bgp_next_hop is resolved to a unreachable/blackhole/prohibit route.
In your case, it could be fixed by adding higher protocol preference (different attribute than bgp_local_pref, currently 100) to b_rr1.
Unfortunately increasing the preference of the b_rr1 session is not an option as from my understanding it would completely eliminate the bgp route selection rules (All routes learned via b_rr1 are preferred over b_dtag1). Is there any other solution for this besides doubling the iBGP connections (adding seperate blackhole only sessions with higher preference)?
You might consider some kind of import filter in order to change local_preference only forl blackholed prefixes (following was NOT checked ) filter blackhole { if (bgp.nexthop ~ blackhole ) then { bgp_local_pref = 500 ; accept; } accept; } On Tue, Apr 8, 2014 at 6:50 PM, Thomas Goldberg <t.goldberg77@gmail.com>wrote:
2014-04-07 18:29 GMT+02:00 Ondrej Zajicek <santiago@crfreenet.org>:
Hello
That is because only resolvable routes are considered (RFC 4271 9.1.2.1), main reason for that condition is to eliminate routes whose bgp_next_hop cannot be resolved using IGP, it also affects routes whose bgp_next_hop is resolved to a unreachable/blackhole/prohibit route.
In your case, it could be fixed by adding higher protocol preference (different attribute than bgp_local_pref, currently 100) to b_rr1.
Unfortunately increasing the preference of the b_rr1 session is not an option as from my understanding it would completely eliminate the bgp route selection rules (All routes learned via b_rr1 are preferred over b_dtag1). Is there any other solution for this besides doubling the iBGP connections (adding seperate blackhole only sessions with higher preference)?
Hello Thomas, On Tue, Apr 8, 2014 at 5:50 PM, Thomas Goldberg <t.goldberg77@gmail.com> wrote:
2014-04-07 18:29 GMT+02:00 Ondrej Zajicek <santiago@crfreenet.org>:
Hello
That is because only resolvable routes are considered (RFC 4271 9.1.2.1), main reason for that condition is to eliminate routes whose bgp_next_hop cannot be resolved using IGP, it also affects routes whose bgp_next_hop is resolved to a unreachable/blackhole/prohibit route.
In your case, it could be fixed by adding higher protocol preference (different attribute than bgp_local_pref, currently 100) to b_rr1.
Unfortunately increasing the preference of the b_rr1 session is not an option as from my understanding it would completely eliminate the bgp route selection rules (All routes learned via b_rr1 are preferred over b_dtag1). Is there any other solution for this besides doubling the iBGP connections (adding seperate blackhole only sessions with higher preference)?
We faced the same problem in the past. The preference can be set on a per route basis during the import. If you add the following line to your import filter it should do the trick for you: preference = bgp_local_pref; That way the bgp local preference is used as the bird internal preference too. Having read only the mentioned section of RFC 4271 someone might argue that bird should consider blackhole routes as resolvable too: "A route Rte1, referencing only the intermediate network address, is considered resolvable if the Routing Table contains at least one resolvable route Rte2 that matches Rte1's intermediate network address and is not recursively resolved (directly or indirectly) through Rte1." Based on your example: Rte1 is 64.112.128.0/18 with next_hop = 192.168.2.11 Rte2 is a route which resolves 192.168.2.11 to the blackhole interface So Rte1 can be resolved using Rte2 and should be considered resolvable. That's how it's implemented on our alcatel/cisco/juniper routers too, bird seems to be the exception here. Overall I'm a little confused about the implementation now too. If the next hop is not resolvable it shouldn't be concidered at all but bird apparently still considers blackhole routes as a last resort or with higher bird preference. Best Regards, Frederik Kriewitz
On Tue, Apr 08, 2014 at 07:11:36PM +0200, Frederik Kriewitz wrote:
On Tue, Apr 8, 2014 at 5:50 PM, Thomas Goldberg <t.goldberg77@gmail.com> wrote:
Is there any other solution for this besides doubling the iBGP connections (adding seperate blackhole only sessions with higher preference)?
We faced the same problem in the past. The preference can be set on a per route basis during the import. If you add the following line to your import filter it should do the trick for you: preference = bgp_local_pref; That way the bgp local preference is used as the bird internal preference too.
That will work, but in this case i would prefer an alternative: do not depend on recursive resolution of bgp_next_hop to blackhole route, but set blackhole destination directly in filters: if bgp_next_hop = A.B.C.D then { dest = RTD_BLACKHOLE; } In that case recursive resolution of next hop is not used and resolvability test does not apply.
Having read only the mentioned section of RFC 4271 someone might argue that bird should consider blackhole routes as resolvable too:
...
That's how it's implemented on our alcatel/cisco/juniper routers too, bird seems to be the exception here.
Well, it is debatable whether IP covered by unreachable/blackhole/prohibit routes should be considered resolvable for these purposes. I would say that semantically such addresses are more-or-less equivalent to addresses not covered by any routes.
Overall I'm a little confused about the implementation now too. If the next hop is not resolvable it shouldn't be concidered at all but bird apparently still considers blackhole routes as a last resort or with higher bird preference.
That is true, BIRD currently cannot completely suppress a route based on unreachability of the nexthop, it just make unresolvable route a lowest priority route in its preference group. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (4)
-
Frederik Kriewitz -
MrBr ＠ GMail -
Ondrej Zajicek -
Thomas Goldberg