From stuff I've seen here and elsewhere I think the most important reason for this is congestion at NAPs making it impossible to suck (or shove) lots of bandwidth at anything but your provider's backbone.
In using "NAPs" above, are you just talking about the NSF NAPs or all interconnections? I think it may be an overstatement to say that all NAPs are congested. Perhaps that not what you meant. My experience is that provider backbones are congested at times as well. It is unclear how fast providers can address these types of problems. My experience is that providers often don't have large enough ingress into the NAPs. So, sometimes the NAPs are congested and sometimes the providers have inadequate facilities to make the best use of the NAPs.
I haven't considered yet the maintenance/logistical cost of managing 15 T1s to 6 or 7 providers vs. the "ease" of two frac-T3s to two providers.
Generally for each connection to each provider, you would have to set up BGP. This will have some cost in processing and memory in your border routers. This will also involve dealing with full routing information and maintaining valid filters relating to the the changes that occur in other parts of the Internet. I believe that some providers have people who spend full time just doing this task, so you might have to allocate the same resources to do that. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
In message <199607220013.TAA27391@academ.com>, Stan Barber writes:
From stuff I've seen here and elsewhere I think the most important reason for this is congestion at NAPs making it impossible to suck (or shove) lots of bandwidth at anything but your provider's backbone.
In using "NAPs" above, are you just talking about the NSF NAPs or all interconnections?
I'm not clear on the distinction -- but since the first location we want to do this would be based in San Francisco, I'm referring mostly to mae-west, the pacbell nap, and CIX. It should be relatively inexpensive to long-haul a few T1s further away from the California NAPs. (and it would be relatively expensive to move the machines... because of the people involved in maintaining them. Which is a pain, 'cause doing high-availability stuff in an earthquake zone seems silly.)
Generally for each connection to each provider, you would have to set up BGP.
Yeah, definately. But most backbones seem to have "customer routes" as an option, and if I trust them enough to get those routes correct then I will hopefully not have to bother with extreme amounts of filtering. It's pretty easy to enforce "no transit" at the packet filtering level -- only packets destined for my nets will be allowed in. Is there some other aspect of filtering I'm forgetting about? We have a dedicated and backup network engineer at any rate. The border router would be a cisco 7200 or 7500 series with 128Mb. Dean
It's pretty easy to enforce "no transit" at the packet filtering level -- only packets destined for my nets will be allowed in. Is there some other aspect of filtering I'm forgetting about? We have a dedicated and backup network engineer at any rate. The border router would be a cisco 7200 or 7500 series with 128Mb.
Dean
Hmm... If you do provide transit for others, making a dynamic filter can be difficult if you base transit on as-path filters rather than route filters. I hear that Sprint, one of the few large providers (that imposes filters on customer BGP sessions) that still bases customer peering filters on as-path filters rather than on a per-session route filter list either manually constructed or built automagically from databases, is considering going or is going to go to route filtering its customer sessions rather than as-path filtering. Now, I'm talking here about the BGP sessions, not the actual flow of data. And it's been a long weekend, sorry if that sentence was hard to parse. Avi
On Mon, 22 Jul 1996, Avi Freedman wrote:
I hear that Sprint, one of the few large providers (that imposes filters on customer BGP sessions) that still bases customer peering filters on as-path filters rather than on a per-session route filter list either manually constructed or built automagically from databases, is considering going or is going to go to route filtering its customer sessions rather than as-path filtering. Now, I'm talking here about the BGP sessions,
This makes sense is this the "Right Way" to do things, IMO. However, this requires a significant degree of router configuration automation, and some sort a reliable database to do in a large scale. But then again, I'm sure Sprint has the resources to handle this type of a challenge. -dorian
Yeah, definately. But most backbones seem to have "customer routes" as an option, and if I trust them enough to get those routes correct then I will hopefully not have to bother with extreme amounts of filtering. It's pretty easy to enforce "no transit" at the packet filtering level -- only packets destined for my nets will be allowed in. Is there some other aspect of filtering I'm forgetting about? We have a dedicated and backup network engineer at any rate. The border router would be a cisco 7200 or 7500 series with 128Mb.
Dean
Is this really how people enforce "no transit"? I have been told that packet filtering is quite cpu expensive. I would think that packet filtering on a router that is probably already overburdened is not an attractive solution. Jim
Yeah, definately. But most backbones seem to have "customer routes" as an option, and if I trust them enough to get those routes correct then I will hopefully not have to bother with extreme amounts of filtering. It's pretty easy to enforce "no transit" at the packet filtering level -- only packets destined for my nets will be allowed in. Is there some other aspect of filtering I'm forgetting about? We have a dedicated and backup network engineer at any rate. The border router would be a cisco 7200 or 7500 series with 128Mb.
Dean
Is this really how people enforce "no transit"? I have been told that packet filtering is quite cpu expensive. I would think that packet filtering on a router that is probably already overburdened is not an attractive solution.
Jim
I'm not sure if this is how people enforce it; you're correct that it's pretty expensive to do it this way. We run a periodic script that sends 8-10 pings for various destinations, including non-existent ones, into exchange-point neighbors to see where the packets go. If packets for nowhere IPs come back at you, they're defaulting into you... Avi
participants (5)
-
Avi Freedman
-
Dean Gaudet
-
Dorian R. Kim
-
Jim Van Baalen
-
sob@academ.com