[RFC,PATCH 1/2] BGP: Implement iebgp_peer mode.
Ondrej Zajicek
santiago at crfreenet.org
Tue Sep 19 15:08:48 CEST 2017
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."
More information about the Bird-users
mailing list