route for linx.net in Level3?

Fri Apr 5 01:26:57 UTC 2013

In a message written on Fri, Apr 05, 2013 at 10:01:34AM +0900, Randy Bush wrote:
> 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->Output 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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130404/09917b25/attachment.sig>