[RFC,PATCH 1/2] BGP: Implement iebgp_peer mode.

[David Barroso]

Hi,
from an architectural point of view this patch is one of many that will
help us migrating from an iBGP-only datacenter to an eBGP-only datacenter
so the idea is to have a feature that is as simple as possible with almost
no implications that can be turned on during the migration and then off
after it. A confederation would have a similar effect but would have other
side effects and would also require to change things in other places,
leading to a maintenance window we are actually trying to avoid with these
set of patches.

I am going to go a bit more in detail in a talk at NANOG71 in a couple of
weeks, but let me try to summarize it here.

The patches in question are:

http://bird.network.cz/pipermail/bird-users/2017-March/011084.html
http://bird.network.cz/pipermail/bird-users/2017-February/010925.html
http://bird.network.cz/pipermail/bird-users/2017-August/011468.html
http://bird.network.cz/pipermail/bird-users/2017-August/011469.html

By combining the patches above we are able to migrate a full POP from iBGP
with route reflectors to an eBGP-only setup without intervention and
without having to drain POPs:

1. The patch `Secondary remote AS support for protocol BGP ` let's us
configure the devices ahead of time to accept OPEN messages from different
AS's so we don't have to bother synch'ing changes.
2. The `Allow exchanging LOCAL_PREF with eBGP peers` patch allows us to
keep doing operations as we do now regardless of if the POP is formed by
eBGP or iBGP speakers.
3. And for the last two patches let's look at this scenario:

                /---- spine00 (AS65000)
leaf00 (AS12345)
                \---- spine01 (AS12345)

Prefix A coming from the spines:

from spine00:
protocol: eBGP
AS PATH:  65000 $AS_PATH

from spine01:
        protocol: iBGP
AS PATH:  $AS_PATH

a. The patch "Implement iebgp_peer mode" helps us with the eBGP vs iBGP
comparison. It doesn't try to do much else.
b. Now that eBGP vs iBGP is no longer a concern for this set of peers we
need to fix the AS_PATH or the one from spine01 will be shorter and, this,
win the election. This is where the patch "Implement
skip_private_as_path_prefix" comes in. Instead of manipulating the iBGP
speaker to prepend some AS we would rather skip the leading private AS's in
the eBGP speaker. The reason is that as we have many spines so you would
have to synch the changes so you wouldn't send all your traffic via only
one (or alternatively schedule a maintenance which we are trying to avoid).

So now with all the features in place we can:

1. Ahead of time, enable all the features; local-pref over eBGP, have
current and future AS configured, skip leading private AS's and compare
eBGP as iBGP in the corresponding sessions.
2. During the maintenance change "local as" to the new private AS, switch
by switch, causing only a small BGP session flap with no other implication.

And this is how we are migrating from iBGP to eBGP without human
intervention and without having to drain POPs. Once migration is complete
we can remove "compare_as_ibgp" flag.

In summary, I am not sure how useful some of these features could be in a
permanent design, it might allow people to build `confederation-like`
setups that are a bit simpler than using confederations but our goal is to
have a path to migrate POPs autonomously without having to put them in
maintenance mode. I understand these features are quite "temporary" and you
might be tempted to dismiss them due to their nature but I think they are
quite useful in production scenarios as they can simplify operations
dramatically.

Regards.
David Barroso


On Tue, 19 Sep 2017 at 15:08 Ondrej Zajicek <santiago at crfreenet.org> wrote:

> On Sat, Aug 12, 2017 at 10:22:06PM +0300, Lennert Buytenhek wrote:
> > Implement an 'internal eBGP' peer mode, where the remote peer uses a
> > different AS number than we do, as if it were an eBGP peer, but we
> > treat the peer as if were an AS-internal peer.  This enables
> > implementing a network setup according to the model documented in
> > RFC7938.  This makes two changes to the BGP route propagation logic:
> >
> > * When we are propagating a route to or from an internal eBGP peer,
> >   we will avoid resetting the MED attribute.
> >
> > * When comparing BGP-learned routes, we will consider routes learned
> >   from an 'internal eBGP' peer as iBGP routes as far as the RFC 4271
> >   9.1.2.2. d) check (Prefer external peers) is concerned.
>
> Hi
>
> I am inclined to integrate it (perhaps with some tweaks), but i wonder if
> it has some advantages compared to standardized solutions, namely BGP
> confederations and BGP route reflectors. It seems to me like a third way
> to do the same. Analogy with BGP confederations is obvious, BGP route
> reflectors are usually used in different way, but could be configured to
> work analogically (every router as RR, every IBGP link as mutual RR
> client). So why another approach?
>
> Also, it seems to me that it handles BGP_MED, but does not change
> behavior for BGP_NEXT_HOP nor BGP_LOCAL_PREF. Why?
>
> As BGP in 1.6.x branch and 2.0 branch diverged significantly, i am
> inclined to add the feature just to 2.0 branch, to avoid double work
> and reuse BGP confederation code that does essentially the same.
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at 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."
>
> --
David Barroso
linkedin <https://www.linkedin.com/in/dbarrosop> | twitter
<https://twitter.com/dbarrosop> | github <https://github.com/dbarrosop>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20170920/64a6dd80/attachment.html>