I see what you are saying, and I understand that the default route would be originated per neighbor, or per peer group for all neighbors within that peer group. My biggest concern is that if the aggregation router with this configuration was to lose connectivity back to the routers which provide it with external routing information, it would still announce the default to that neighbor. Do you feel that this is an acceptable risk, taking into consideration that the aggregation router has redundant connectivity to those routers that provide it with it's external routing information and it is highly unlikely that the router would lose it's view of the world? -----Original Message----- From: Mike Leber [mailto:mleber@he.net] Sent: Saturday, September 14, 2002 4:19 PM To: Lupi, Guy Cc: 'nanog@merit.edu' Subject: Re: BGP Default Route On Sat, 14 Sep 2002, Lupi, Guy wrote:
I was wondering how people tend to generate default routes to customers running bgp.
Typically you would only originate default via BGP to a customer that isn't taking a full view. neighbor 10.10.10.2 default-originate neighbor 10.10.10.2 filter-list 9 out ip as-path access-list 9 deny ^.*$
Is it from the aggregation router that customers are directly connected to, or from one or more core/border routers?
In the example above the default originate is done via a specific BGP session, so it isn't router wide on either core or border routers.
If one is using a default route to null 0...
I'll leave the rest of this for somebody else to answer. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
The answer is you can do it all sorts of ways. Why are you originating default? If you are originating default because you are the only gateway for a customer, whatever partial connectivity your router has is better than effectively turning them off if you have a network partition. If your customer has more than one upstream they really should take full views so they have the ability to make routing decisions based on that information. This fixes your concern and is the best engineering choice. A hack would be to conditionally announce default based on the presence of some specific other route. This would be doing additional work to implement a suboptimal solution which a simpler use of BGP (full views) fixes automatically. Yes, as much as you can, your routers should be meshed with more than one connection each. Mike. On Sat, 14 Sep 2002, Lupi, Guy wrote:
I see what you are saying, and I understand that the default route would be originated per neighbor, or per peer group for all neighbors within that peer group. My biggest concern is that if the aggregation router with this configuration was to lose connectivity back to the routers which provide it with external routing information, it would still announce the default to that neighbor. Do you feel that this is an acceptable risk, taking into consideration that the aggregation router has redundant connectivity to those routers that provide it with it's external routing information and it is highly unlikely that the router would lose it's view of the world?
-----Original Message----- From: Mike Leber [mailto:mleber@he.net] Sent: Saturday, September 14, 2002 4:19 PM To: Lupi, Guy Cc: 'nanog@merit.edu' Subject: Re: BGP Default Route
On Sat, 14 Sep 2002, Lupi, Guy wrote:
I was wondering how people tend to generate default routes to customers running bgp.
Typically you would only originate default via BGP to a customer that isn't taking a full view.
neighbor 10.10.10.2 default-originate neighbor 10.10.10.2 filter-list 9 out
ip as-path access-list 9 deny ^.*$
Is it from the aggregation router that customers are directly connected to, or from one or more core/border routers?
In the example above the default originate is done via a specific BGP session, so it isn't router wide on either core or border routers.
If one is using a default route to null 0...
I'll leave the rest of this for somebody else to answer.
Mike.
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
+----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
On Sat, Sep 14, 2002 at 04:20:18PM -0400, Lupi, Guy wrote:
I see what you are saying, and I understand that the default route would be originated per neighbor, or per peer group for all neighbors within that peer group. My biggest concern is that if the aggregation router with this configuration was to lose connectivity back to the routers which provide it with external routing information, it would still announce the default to that neighbor. Do you feel that this is an acceptable risk, taking into consideration that the aggregation router has redundant connectivity to those routers that provide it with it's external routing information and it is highly unlikely that the router would lose it's view of the world?
Taking just defaults from multiple transit providers affords some protection against failures in the provider access circuits, but probably not from routing or connectivity failures within the providers. In some configurations it can certainly be adequate to just take a default. Consider the case where a customer has a single transit provider (who sends default) but one or more peers (who send a peer view). Taking a full table from the transit provider doesn't change the basic behaviour of the network (undeliverable packets get dropped). There are 101 motivations for multi-homing, though. You can't even always classify your peers as either "peers" or "transit" without including variations like "partial transit", or "domestic transit", or "transit to that one particular AS who refuses to peer with us for business reasons, whose routes we otherwise have no way of learning". Hence, it's difficult to come up with a general rule of thumb for when defaults are appropriate, and when they are not. Just as with every other aspect of your network design, you need to sit down and figure out your failure modes, and come up with a strategy that protects you against the ones for which the cost of failure is greater than the cost of protection (or some other appropriate metric). Joe
participants (3)
-
Joe Abley -
Lupi, Guy -
Mike Leber