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@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."