Hi all, I've noticed that BIRD doesn't advertise the best external route to iBGP peers (as it "should" according to RFC 1771) if there is already an iBGP route for the same destination. I realize this is a point where most BGP implementations deviate from the standard, although many of them offer knobs to enable best external route propagation[1][2]. Still, this is a useful behaviour, especially in active-backup setups where backup paths are completely hidden from the rest of the AS. In essence, it looks as if BIRD can do this with sorted tables and the secondary BGP option, but unfortunately sorted tables are incompatible with iBGP's multihop operation due to the recursive gateway calculation strategy. Another option is of course add-paths, but then BIRD advertises all received paths, leading to a larger memory consumption than necessary. So, in case I'm missing something, is there another way to achieve best external route propagation over iBGP? Regards, Apollon [1] http://www.juniper.net/documentation/en_US/junos13.2/topics/example/policy-a... [2] http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/x...
On Thu, Apr 09, 2015 at 01:10:57PM +0300, Apollon Oikonomopoulos wrote:
Hi all,
I've noticed that BIRD doesn't advertise the best external route to iBGP peers (as it "should" according to RFC 1771) if there is already an iBGP route for the same destination. I realize this is a point where most BGP implementations deviate from the standard, although many of them offer knobs to enable best external route propagation[1][2].
Hi I doubt that the current BGP standard (RFC 4271) specifies best-external behavior. But generally, it is a good idea and there is even an IETF draft (draft-ietf-idr-best-external [1]) for that. I just thought a week ago about writing a best-external example to other BIRD examples [2].
So, in case I'm missing something, is there another way to achieve best external route propagation over iBGP?
The idea is simple - just add a separate routing table, say 'ibpg', connect all IBGP protocols to that table and set them lower preference. EBGP and other protocols would be connected to regular 'master' table. 'ibgp' and 'master' would be connected by pipe which allows all routes but restores default preference for BGP routes propagated from 'ibgp' to 'master'. Therefore routes in master table would be sorted as usual, while in ibgp table all EBGP routes would be before all IBGP routes: table ibgp; protocol bgp ibgp1 { table ibgp; preference 50; local 1.2.3.1 as XXX; neighbor 1.2.4.1 as XXX; } protocol bgp ibgp2 { table ibgp; preference 50; local 1.2.3.1 as XXX; neighbor 1.2.5.1 as XXX; } protocol bgp ebgp1 { import ...; export ...; preference 100; # default local 1.2.6.1 as XXX; neighbor 1.2.6.2 as YYY; } protocol pipe { table master; peer table ibgp; import filter { if source = RTS_BGP then preference = 100; accept; }; export all; } [1] https://tools.ietf.org/html/draft-ietf-idr-best-external-05 [2] https://gitlab.labs.nic.cz/labs/bird/wikis/Examples -- 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."
Hi, On 16:17 Thu 09 Apr , Ondrej Zajicek wrote:
On Thu, Apr 09, 2015 at 01:10:57PM +0300, Apollon Oikonomopoulos wrote:
So, in case I'm missing something, is there another way to achieve best external route propagation over iBGP?
The idea is simple - just add a separate routing table, say 'ibpg', connect all IBGP protocols to that table and set them lower preference. EBGP and other protocols would be connected to regular 'master' table. 'ibgp' and 'master' would be connected by pipe which allows all routes but restores default preference for BGP routes propagated from 'ibgp' to 'master'. Therefore routes in master table would be sorted as usual, while in ibgp table all EBGP routes would be before all IBGP routes:
You're right, setting the route preference that way didn't occur to me. Thanks for the hint! Regards, Apollon
participants (2)
-
Apollon Oikonomopoulos -
Ondrej Zajicek