[PATCH,RFC] Allow exchanging LOCAL_PREF with eBGP peers.

[Lennert Buytenhek]

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