[145498] in North American Network Operators' Group
SP / Enterprise design (dis)similarities
daemon@ATHENA.MIT.EDU (Tom Lanyon)
Mon Oct 10 18:43:10 2011
From: Tom Lanyon <tom+nanog@oneshoeco.com>
Date: Tue, 11 Oct 2011 09:12:14 +1030
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi all,
Looking for some advice or experience in a small enterprise / hosting =
provider context.
There's plenty of BCP information around for SPs in the network design =
realm, and I'm curious how much of this applies to enterprises too. =
Commonly advised items like:
* pull-up statics created on core devices, not network border =
devices
* using iBGP to carry customer prefixes, not an IGP
* announcing defaults over iBGP or IGP
In some cases I imagine it may be simpler to have all BGP finish at the =
network border devices and not have to worry about running both IGP and =
iBGP sessions inwards to the core and/or aggregation devices. I =
understand the limitations of putting our Internet prefixes in an IGP, =
but for a hosting provider style network where everything is ethernet =
connected and within data centres there's much less route flapping to =
deal with (there's no bouncing DSL lines, for example).
In the case that there is both iBGP and IGP running internally, is there =
any reason to choose one or the other to originate a default route to =
our aggregation/access layers? At some point I imagine it's going to be =
redistributed into the IGP (or re-originated in the IGP), so would think =
it would be best to just always run the default in the IGP to keep =
things consistent.
Finally - are there any reasons to avoid running next-hop-self on ibgp =
sessions? The upside is we get to avoid distributing all of our =
transit/peer upstream point to point links into the rest of the network. =
Again, I understand this may be undesirable from a SP perspective, but =
when our 'clients' are all a bunch of internal servers it makes sense to =
keep iBGP/IGP as clean as possible...
Thanks,
Tom
