
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">Hi,<br />

<br />

Can you make the LOCAL_PREF something that can be matched on? Example:<br />

<br />

if ! bgp_path.local_pref = 80 then {<br />

bgp_local_pref = 100;<br />

}<br />

<br />

This way one can limit the influence of the adjacent neighbor to either 80 or 100 (default).</div>

<div name="messageSignatureSection"><br />

Kind regards,<br />

<br />

Job</div>

<div name="messageReplySection"><br />

<div name="messageReplySection"><br />

On 18 Feb 2017, 17:07 +0100, Lennert Buytenhek <buytenh@wantstofly.org>, wrote:<br />

<blockquote type="cite">On Sat, Feb 18, 2017 at 12:27:22PM +0100, Tim Weippert wrote:<br />

<br />

<blockquote type="cite">Hi Lennert,<br /></blockquote>

<br />

Hello!<br />

<br />

<br />

<blockquote type="cite">

<blockquote type="cite">I've attached a patch that allows (selectively) exchanging LOCAL_PREF<br />

with eBGP peers.<br /></blockquote>

<br />

a perfect timing. Yesterday i thought about that ..<br />

<br />

<blockquote type="cite">The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP<br />

peers, but most modern BGP implementations have an override to allow<br />

doing this anyway, and it is very useful in some scenarios, for example<br />

if you have a network topology a la RFC7938.<br /></blockquote>

<br />

[ ... ]<br />

<br />

<blockquote type="cite">I'm not submitting this patch for inclusion yet at this point (which is<br />

why there is no documentation), but this kind of functionality is useful<br />

for us, and I'd like to hear from people whether they think this could<br />

be useful for them, too. And of course, there will have to be a lot of<br />

bikeshedding about the name of the config option! :-)<br /></blockquote>

<br />

I thought about it yesterday as it could be helpfull in my situation, i<br />

then come to the solution to use MED and/or an Community Setting which<br />

will trigger the LOCAL_PREF in the foreign AS (eBGP Peering).<br />

<br />

I think that is today a common way to do this. So i see the need but<br />

there exists some ways which will be more standardized within BGP!?<br />

<br />

If i had all eBGP AS Peerings under my control, it may be usefull to do<br />

it directly with a LOCAL_PREF spreaded over the ASN, if not i think you<br />

want enable it, as the foreign AS can set it to any value it want/think.<br />

And you had to filter it again to not clash it with internal AS usage of<br />

LOCAL_PREF?!<br />

<br />

So for general implementations i think it isn't needed/usefull, but for<br />

some special purposes it would be great to had the possibility to send<br />

LOCAL_PREF towards eBGP borders.<br /></blockquote>

<br />

Thanks for your feedback!<br />

<br />

The idea here is that all eBGP peers are under control of one<br />

organisation, but you want to speak eBGP and not iBGP between them<br />

because eBGP gives you certain benefits over iBGP, such as a more<br />

sensible loop detection algorithm. RFC7938 documents some cases<br />

where you would want to do this and our use case is roughly similar<br />

to this, and it's a fairly common design pattern in datacenter<br />

networks.<br />

<br />

It's generally a bad idea to accept LOCAL_PREF from an eBGP peer<br />

that is not under your control, for reasons you mentioned and others.<br />

My patch doesn't accept LOCAL_PREF from an eBGP peer unless you<br />

specifically configure bird to do so (using 'ebgp localpref rx'), and<br />

if you don't enable that option, bird will do what it always did, which<br />

is to ignore the peer's value and fill in default_local_pref (which<br />

will be 100 if you didn't change it).<br />

<br />

<br />

Cheers,<br />

Lennert<br /></blockquote>

</div>

</div>

</body>

</html>