On 18 Feb 2017, 17:07 +0100, Lennert Buytenhek <buytenh@wantstofly.org>, wrote:
On Sat, Feb 18, 2017 at 12:27:22PM +0100, Tim Weippert wrote:
Hi Lennert,
Hello!
I've attached a patch that allows (selectively) exchanging LOCAL_PREF
with eBGP peers.
a perfect timing. Yesterday i thought about that ..
The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP
peers, but most modern BGP implementations have an override to allow
doing this anyway, and it is very useful in some scenarios, for example
if you have a network topology a la RFC7938.
[ ... ]
I'm not submitting this patch for inclusion yet at this point (which is
why there is no documentation), but this kind of functionality is useful
for us, and I'd like to hear from people whether they think this could
be useful for them, too. And of course, there will have to be a lot of
bikeshedding about the name of the config option! :-)
I thought about it yesterday as it could be helpfull in my situation, i
then come to the solution to use MED and/or an Community Setting which
will trigger the LOCAL_PREF in the foreign AS (eBGP Peering).
I think that is today a common way to do this. So i see the need but
there exists some ways which will be more standardized within BGP!?
If i had all eBGP AS Peerings under my control, it may be usefull to do
it directly with a LOCAL_PREF spreaded over the ASN, if not i think you
want enable it, as the foreign AS can set it to any value it want/think.
And you had to filter it again to not clash it with internal AS usage of
LOCAL_PREF?!
So for general implementations i think it isn't needed/usefull, but for
some special purposes it would be great to had the possibility to send
LOCAL_PREF towards eBGP borders.
Thanks for your feedback!
The idea here is that all eBGP peers are under control of one
organisation, but you want to speak eBGP and not iBGP between them
because eBGP gives you certain benefits over iBGP, such as a more
sensible loop detection algorithm. RFC7938 documents some cases
where you would want to do this and our use case is roughly similar
to this, and it's a fairly common design pattern in datacenter
networks.
It's generally a bad idea to accept LOCAL_PREF from an eBGP peer
that is not under your control, for reasons you mentioned and others.
My patch doesn't accept LOCAL_PREF from an eBGP peer unless you
specifically configure bird to do so (using 'ebgp localpref rx'), and
if you don't enable that option, bird will do what it always did, which
is to ignore the peer's value and fill in default_local_pref (which
will be 100 if you didn't change it).
Cheers,
Lennert