Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: T3 or not to T3

  • From: Dean Gaudet
  • Date: Sun Jul 21 20:35:47 1996

In message <>, 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

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

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.

- - - - - - - - - - - - - - - - -

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.