SP / Enterprise design (dis)similarities
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
On Mon, Oct 10, 2011 at 3:42 PM, Tom Lanyon <tom+nanog@oneshoeco.com> wrote:
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...
Route reflectors in the mix? Next-hop-self not so useful there... -M
2011/10/10 Tom Lanyon <tom+nanog@oneshoeco.com>
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
It depends on the size of the enterprise as well as the service provider.
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.
In alot of cases iBGP is easier than an IGP if you have a large number of routes or a large number of routers. In others it's easier to accept only a default from the SP and maybe a local table. This is highly subjective as well.
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).
This depends as well. There are pleanty of hosting customers that want a full or partial table which means you'll have to run BGP. There are all sorts of other limitations with and IGP as well.
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.
The more route aggregation the larger the potential for loops. Then again this is subjective as well. In general BGP isn't something to be avoided at all costs even at a small scale. It's much easier to scale a topology that is iBGP based than to try to move to an iBGP setup after it has grow too large for the IGP.
Finally - are there any reasons to avoid running next-hop-self on ibgp sessions?
I would go the other way and ask if there is any reason to advertise all the next-hop address into the IGP?
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...
The definition of clean is also subjective. There are many who would run the IGP only for loopbacks and /30's and force everything into BGP even at small scale. BGP makes it easier to control the routing relationships between companies and pretty much removes the need for redistribution. There are trade-offs though, such as load-balancing. It really depends on your environment though and the preference of your engineering team. In general there isn't really a such thing as SP vs. Enterprise. For example I've know of a large bank with an internal MPLS topology and about 8 public AS's used just to segregate traffic by country of origin. By most definitions this is an enterprise network although a very large one. On the other hand I've seen a service provider who's network consisted of 4 M10i's and a firewall in someone else's colo facility. You have to look at which protocols and services you need to make your network work as well as the ability to scale. That should dictate your design more than an imaginary line between SP and enterprise.
On Tue, Oct 11, 2011 at 1:12 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
The definition of clean is also subjective. There are many who would run the IGP only for loopbacks and /30's and force everything into BGP even at small scale. BGP makes it easier to control the routing relationships between companies and pretty much removes the need for redistribution. There are trade-offs though, such as load-balancing.
just loadbalance toward the next-hop, no?
2011/10/11 Christopher Morrow <morrowc.lists@gmail.com>
On Tue, Oct 11, 2011 at 1:12 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
The definition of clean is also subjective. There are many who would run the IGP only for loopbacks and /30's and force everything into BGP even at small scale. BGP makes it easier to control the routing relationships between companies and pretty much removes the need for redistribution. There are trade-offs though, such as load-balancing.
just loadbalance toward the next-hop, no?
It depends on the IGP, whether the paths have exactly the same metric and whether or not you need to run MPLS.
On Tue, Oct 11, 2011 at 1:19 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
2011/10/11 Christopher Morrow <morrowc.lists@gmail.com>
On Tue, Oct 11, 2011 at 1:12 AM, Keegan Holley <keegan.holley@sungard.com> wrote:
The definition of clean is also subjective. There are many who would run the IGP only for loopbacks and /30's and force everything into BGP even at small scale. BGP makes it easier to control the routing relationships between companies and pretty much removes the need for redistribution. There are trade-offs though, such as load-balancing.
just loadbalance toward the next-hop, no?
It depends on the IGP, whether the paths have exactly the same metric and whether or not you need to run MPLS.
sure.
Tom Lanyon wrote on 11/10/2011 01:42:
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.
Thanks, Tom
We recently started migrating from "IGP for everything" to "BGP for customers, IGP for infrastructure". We have chosen to go with the default route in IGP, since we consider IGP strictly internal (no redistribution allowed anywhere) and something to be trusted more than BGP. -- Tassos
participants (5)
-
Christopher Morrow
-
Keegan Holley
-
Matt Hite
-
Tassos Chatzithomaoglou
-
Tom Lanyon