[162186] in North American Network Operators' Group
Re: route for linx.net in Level3?
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Thu Apr 4 21:27:15 2013
Date: Thu, 4 Apr 2013 18:26:57 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <m2fvz5eqoh.wl%randy@psg.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Apr 05, 2013 at 10:01:34AM +0900, Randy Bush w=
rote:
> it's putting such things in one's igp that disgusts me. as joe said,
> igp is just for the loopbacks and other interfaces it takes to make your
> ibgp work.
While your method is correct for probably 80-90% of the ISP networks,
the _why_ people do that has almost been lost to the mysts of time.
I'm sure Randy knows what I'm about to type, but for the rest of
the list...
The older school of thought was to put all of the edge interfaces
into the IGP, and then carry all of the external routes in BGP.
This caused a one level recursion in the routers:
eBGP Route->IXP w/IGP Next Hop->Output Interface
The Internet then became a thing, and there started to be a lot of
BGP speaking customers (woohoo! T1's for everyone!), and thus lots
of edge /30's in the IGP. The IGP convergence time quickly got
very, very bad. I think a network or two may have even broken an
IGP.
The "solution" was to take edge interfaces (really "redistribute
connected" for most people) and move it from the IGP to BGP, and
to make that work BGP had to set "next-hop-self" on the routes.
The exchange /24 would now appear in BGP with a next hop of the
router loopback, the router itself knew it was directly connected.
A side effect is that this caused a two-step lookup in BGP:
eBGP-Route->IXP w/Router Loopback Next Hop->Loopback w/IGP Next Hop->Outp=
ut Interface
IGP's went from O(bgp_customers) routes to O(router) routes, and
stopped falling over and converged much faster. On the flip side,
every RIB->FIB operation now has to go through an extra step of
recursion for every route, taking BGP resolution from O(routes) to
O(routes * 1.1ish).
Since all this happened, CPU's have gotten much faster, RAM has
gotten much larger. Most people have never revisited the problem,
the scaling of IGP's, or what hardware can do today.
There are plenty of scenarios where the "old way" works just spiffy,
and can have some advantages. For a network with a very low number of
BGP speakers the faster convergence of the IGP may be desireable.
Not every network is built the same, or has the same scaling
properties. What's good for a CDN may not be good for an access
ISP, and vice versa, for example.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBUV4oYbN3O8aJIdTMAQLyIg//fmaDBmWtcgRw41t7G0BeO7tWQAz170yb
1GI6iQjzTs4guktoG0s3V0nta5RvSLz3ePQaa4fg1dJKA4BzsVQmCrU3qSuGMsq+
xjILQIE94OhZPcvDwi7cB1sEXZXbrMSUe7tlxb3Z05FLYGNzcnwPKqVDADENXLTP
z51IlHfyKJCkujqU61AmGXy59oStJ1hAJj2RnMRutxGGzVuLBlAEJx/a8hqdNIHW
H6crqaSJf88EFBX9feVqgwN9x1dV5s/E3oTTUhiVRVoJVlEXNgB9fgtgDa/NmUDl
UsTznKLGql6SlAeylZ19qSl8GgURb/O2bTCBbMsMjTnOiX+f2e/vNAIoBFIXP2NL
5DdGmkj4F19zThtEgvzh0Bj9PqeRhC5t6q3wTuqzAcir0zEmBFTxjDuJEnu9QddL
1Z+Sx2NRO+DGa8UjInoiSfvzf2Wf+GwT97CNQtsEO3xmEQ0IGymtuJQ5VcWoAnYu
aGcAUgYMZNWcYbuqCBsK2f83H4r9F7Cdb5OLMXaLgZYSPPB5Rt/VE3cWtBIf6sHP
05xSQ/lBiCCQq10bahBG+diA9ybdDfCFrSHFHkCbdzTpF3IlKXkuLf2zrH5ulL4l
FI6/HMNwN2m6/8blk73M74hl2mTVgVhJUHhfqpqxn2A+Bn9p2TfN5tss8gaq6No7
4QJ5jcv7iLE=
=Lkgw
-----END PGP SIGNATURE-----
--4Ckj6UjgE2iN1+kY--
