Re: Identifying DoS sources quickly (was: Bogon list or Dshield.orgtype list)
## On 2002-07-30 08:23 -0700 Randy Bush typed: RB> RB> >> Not a complete solution but a start: RB> >> IP Source Tracker: RB> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 RB> > limit/120s/120s21/ipst.htm RB> >> Available as of 12.0(22)S for 7500 and 12000 series Cisco routers. RB> RB> ah yes. the new enterprise image. :-( RB> RB> Am I missing the joke ? AFAIK 12.0S only has the "service provider" feature set -- Rafi
Re: redundancy [was: something about arrogance]
Pedro Roque Marques wrote: >--- Start of forwarded message --- >From: [EMAIL PROTECTED] (Patrick Evans) >To: Jim Shankland <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] >Newsgroups: jnx.ext.nanog >Subject: Re: redundancy [was: something about arrogance] >Message-ID: <[EMAIL PROTECTED]> >Date: 31 Jul 02 00:32:49 GMT >References: <[EMAIL PROTECTED]> >Organization: Juniper Networks, San Francisco, California > > >On Tue, 30 Jul 2002, Jim Shankland wrote: > > > >>Patrick Evans <[EMAIL PROTECTED]> writes: >> >> >> >>>My first project, if network availability were a key issue, within any >>>organisation would be to a) obtain [an AS number] and b) make use of >>>it. >>> >>> >>Heh. How many bits in an AS number, again? >> >> >> >*grin* > >That's a problem with the underlying protocol. I get paid to run >operational networks, not bleat endlessly about "how much work would >it *really* take to implement 24bit AS numbers?" :) > > The plan is 32 bits... (see draft-ietf-idr-as4bytes-05.txt for details). Essentially i think it just takes interest/demand from ISPs since the mechanism can be implemented and deployed without in a non disrruptive way. >Crying about protocol deficiencies is a distant second to keeping a >business up and running these days. > > imho, protocol efficiencies are not so much the problem. If it is clear the scale routing must operate on the right hardware/software can be engineered... that assuming that people are willing to upgrade their existing boxes and that it isn't a requirement that it must run on 5 year old small entreprise boxes. The later seems to be the biggest problem although. Effectivly the growth of routing table size is bound by the maximum memory size and CPU capacity present in the most common boxes used in the network and not by protocol efficiency. It is not so much of a question if one can build a database engine and respective distribution protocol than can scale upto n million paths but of the limits of the current day moral equivalent of the AGS+. Thus all the people that have these deployed in their networks tend to be concerned about the need to upgrade them as the size of the routing table increase. As one of the posters was king enought to point out these sometimes end up being more issues of economics/buisiness than of engineering. regards, Pedro.
Re: MAE ATM
On Tue, 30 Jul 2002, Mark Kent wrote: > http://www.nanog.org/2.95.NANOG.notes/mae-west.html "Milo believes that some day there will be a working B-ISDN infrastructure. When that happens, there will no longer be a need for interconnection points like MAE-WEST." Or maybe not... Charles > -mark >
Re: MAE ATM
>> How did people interconnect before may 1998, fddi? fddi, some remote with netedge boxes at either end of an atm link. There were some 10baseT connections too, there was at least one low end Catalyst switch dedicated to plain ethernet. Here is a big hint: http://www.nanog.org/2.95.NANOG.notes/mae-west.html -mark
Re: MAE ATM
> How did people interconnect before may 1998, fddi? The MAE, later MAE-East, began as FOIRL, which was 10mbps Ethernet over fiber. Later it was upgraded to a shared FDDI ring with Ethernet attached segments; later still, a mix of switched FDDI and switched 100Base-T and GigE. The FDDI portion was turned off last summer, about a year ago now, and what remains is a mix of GigE, OC-48 links, and a little bit of remaining 100Base-T. But mostly, it's fallen into disuse relative to Equinix Ashburn and PAIX-VA. -Bill
Re: MAE ATM
How did people interconnect before may 1998, fddi? Scott On Wed, 31 Jul 2002 [EMAIL PROTECTED] wrote: > > May 1998 > > > > > > Out of curiousity, when were MAE East/West ATM established? > > -- > > Omachonu Ogali > > [EMAIL PROTECTED] > > http://www.informationwave.net > > >
Re: MAE ATM
limited trials began in very early 1998, and it was formally available to customers in mid 1998. - jsb On Tue, 30 Jul 2002 [EMAIL PROTECTED] wrote: > > Out of curiousity, when were MAE East/West ATM established? > -- Jeff Barrows, President Firefly Networks http://FireflyNetworks.net +1 703 287 4221 Voice +1 703 288 4003 Facsimile An Advanced Internet Engineering & Professional Services Organization
Re: MAE ATM
May 1998 > > Out of curiousity, when were MAE East/West ATM established? > -- > Omachonu Ogali > [EMAIL PROTECTED] > http://www.informationwave.net >
Re: redundancy [was: something about arrogance]
On Tue, 30 Jul 2002, Jim Shankland wrote: > Patrick Evans <[EMAIL PROTECTED]> writes: > > > My first project, if network availability were a key issue, within any > > organisation would be to a) obtain [an AS number] and b) make use of > > it. > > Heh. How many bits in an AS number, again? > *grin* That's a problem with the underlying protocol. I get paid to run operational networks, not bleat endlessly about "how much work would it *really* take to implement 24bit AS numbers?" :) Crying about protocol deficiencies is a distant second to keeping a business up and running these days. -- Patrick Evans, allegedly Email: [EMAIL PROTECTED] CV: www.pre.org/pre/cv Wheels: Kawasaki ZXR400L9
Re: redundancy [was: something about arrogance]
Patrick Evans <[EMAIL PROTECTED]> writes: > My first project, if network availability were a key issue, within any > organisation would be to a) obtain [an AS number] and b) make use of > it. Heh. How many bits in an AS number, again? Jim Shankland
MAE ATM
Out of curiousity, when were MAE East/West ATM established? -- Omachonu Ogali [EMAIL PROTECTED] http://www.informationwave.net
Re: redundancy [was: something about arrogance]
On Tue, 30 Jul 2002, David Schwartz wrote: > One more just for kicks. Client had a 100Mbps circuit from their sole > provider (100Mbps to colocated router, DS3 from this router to their > premises). The circuit had been in place for several years and the contract > had long since expired. One day, they got a call Er, what does due diligence mean to you? (We're wy into no-shit-sherlock territory here) (For the record, I'd consider any operation without an AS number a startup, and my first project, if network availability were a key issue, within any organisation would be to a) obtain one and b) make use of it. YMMV, but some V are more equal then others. Particularly in the current economic climate.) -- Patrick Evans, allegedly Email: [EMAIL PROTECTED] CV: www.pre.org/pre/cv Wheels: Kawasaki ZXR400L9
Re: Identifying DoS sources quickly (was: Bogon list or Dshield.orgtype list)
On Tue, 30 Jul 2002 [EMAIL PROTECTED] wrote: > The owners of the attacking devices are accessories to the crime > although I'm sure they could plead ignorance and avoid any liability. But > what if they could not plead ignorance? What if we could identify some of > the attacking devices, and what if the victim sent a legal "cease and > desist" letter to the owners of the attacking devices? I wonder how the new pending RIAA legislation would change things, since it proposes to totally shield the attackers from criminal penalties. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
RE: redundancy [was: something about arrogance]
At 1:23 PM -0400 2002/07/30, Derek Samford wrote: > At the same time, I've been able to maintain aggregation of all > of my routes, and maintain true stability in my network. There is > absolutely no excuse to fill up the routing tables with nonsense. Seeing as I don't understand much about this process, I would love to hear a detailed explanation of how you have managed to do all this. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
Re: redundancy [was: something about arrogance]
At 3:23 AM -0700 2002/07/30, Pedro R Marques wrote: > It is my impression, from reading this list and tidbits of gossip, > that the most common causes of failure are: > - link failure > - equipment failure (routers mostly), both software and hardware > - configuration errors Most likely true. > To do so, one can look at: > - 2 external links to distinct providers > - 2 external links to the same provider The latter doesn't protect you from a mis-configuration problem from the same provider, upstream of their redundant links to you. Moreover, it also doesn't protect you if they have a SPOF above your redundant links, even if logically they have two (or more) separate outward links, if they are over the same fiber, or the fibers in question are physically close to each other, then a single backhoe could take you out. A second provider doesn't necessarily protect you against the backhoe problem, but it would reduce the chances of a problem caused by an upstream misconfiguration. > While i can't speak to the economics part of the equation (although > i would expect it to be cheaper to buy an additional link than connect > to a different provider) from a point of view of restoration, > protecting a path with an alternate path from the same provider > is certainly an aproach that gives you much better convengence times. Perhaps, perhaps not. I would be willing to bet that there are at least a few large providers that effectively run each city as a separate business, and they'll rape you just as much or more for two connections as you would pay to get one connection each from two companies. > Unless the main concern is that the upstream ISP fails entirely... > which given the fact that it tends to have frontpage honors on the > NYTimes this days does not apear to be an all to common occurence > (i mean operationally, not financially - clarification added to > dispel potential humorous remarks). Again, I think that this is at least partly dependant on who the upstreams are. If they're small enough, then a single backhoe could take out all the fiber (or cause the remaining fiber to be loaded well past capacity and practically useless) or cause a power loss across the entire facility. Even if you buy connectivity from a pretty big upstream, what with WorldCom and Qwest both being in serious trouble (and KPN/Qwest having completely shut down operations), I would indeed be very concerned about complete failure of my upstream. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
Re: OC-768 availability?
David Charlap wrote: > > I think an OC-192 network using 56K modems in the core would be a pretty > obvious giveaway as well. Yes! Sheesh. Nobody uses K56Flex any more. Peter E. Fry
Re: OC-768 availability?
Not necessarily. Don't forget that exchangecolo is in Hunters Point:) so its not totally unusual for people to put their networks in the hood. :) On Tue, 30 Jul 2002, David Charlap wrote: > > I think an OC-192 network using 56K modems in the core would be a pretty > obvious giveaway as well. > > -- David > > Rowland, Alan D wrote: > > Compton, CA, US and Sealand would be the giveaways. > > > > Scott Weeks wrote: > >> > >> No, he's not for real. It's a satire in the likes of Bandy Rush and such. > >> Children need to have their fun... > >> > >>> [EMAIL PROTECTED] wrote: > >>> > >>> I am currently running a network of cisco 2621s with the OC-192 NM for my > >>> upstream connections. The internal network links are a mixture of K56Flex > >>> modems and GRE tunnels. > >>> > >>> I am looking to upgrade to OC-768 real soon now and am wondering what the > >>> prospects are for OC-768 availability on the 2621 platform. I've found the > >>> 2621 to be rock-solid, except when I ping it, so I'd like to keep my network > >>> on that platform if possible. > >>> > >>> In addition, if anyone knows the availability of OC-768 circuits between the > >>> following cities I'd appreciate any fiber maps and an approximate price > >>> range: > >>> Ottawa, ON, CA > >>> Midland, ON, CA > >>> Goderich, ON, CA > >>> Toronto, ON, CA > >>> Compton, CA, US > >>> Sealand > >>> > >>> At each site I plan to announce a /24 from a /20 I was allocated so if > >>> everyone could please update their prefix filters now that would be great. > >>> > >>> Thank you. > >>> > >>> -- Dalph Roncaster >
Re: routing table size
"Mark Radabaugh" <[EMAIL PROTECTED]> wrote: >Obviously you can't keep leaving big 'reserved' holes in your >allocations to downstreams for potential growth. I've seen RIPE allocate /20s under the proviso that the customer use the first /23 now and apply to use the rest of the space as they grow. -- Tim
Re: OC-768 availability?
I think an OC-192 network using 56K modems in the core would be a pretty obvious giveaway as well. -- David Rowland, Alan D wrote: > Compton, CA, US and Sealand would be the giveaways. > > Scott Weeks wrote: >> >> No, he's not for real. It's a satire in the likes of Bandy Rush and such. >> Children need to have their fun... >> >>> [EMAIL PROTECTED] wrote: >>> >>> I am currently running a network of cisco 2621s with the OC-192 NM for my >>> upstream connections. The internal network links are a mixture of K56Flex >>> modems and GRE tunnels. >>> >>> I am looking to upgrade to OC-768 real soon now and am wondering what the >>> prospects are for OC-768 availability on the 2621 platform. I've found the >>> 2621 to be rock-solid, except when I ping it, so I'd like to keep my network >>> on that platform if possible. >>> >>> In addition, if anyone knows the availability of OC-768 circuits between the >>> following cities I'd appreciate any fiber maps and an approximate price >>> range: >>> Ottawa, ON, CA >>> Midland, ON, CA >>> Goderich, ON, CA >>> Toronto, ON, CA >>> Compton, CA, US >>> Sealand >>> >>> At each site I plan to announce a /24 from a /20 I was allocated so if >>> everyone could please update their prefix filters now that would be great. >>> >>> Thank you. >>> >>> -- Dalph Roncaster
Re: OC-768 availability?
And my question is that a real oc768 or a Sears oc768. Like Cisco, sure its a gig E port but oh wait, you wanted to use it for more than 200 mb/s? On Tue, 30 Jul 2002, blitz wrote: > > I believe many are working on it, but I haven't seen/heard of much progress > since I learned of this, some 4 years ago now.. > Add to that the bandwidth glut with all the DWDM and I guess they've got > breathing room... > > At 09:34 7/30/02 -0700, you wrote: > > >I believe Junpier does have a OC-768 interface under testing if I'm not > >mistaken... > > > > > >Signal received 0. Kurt Erik Lindqvist <[EMAIL PROTECTED]> said: > > > > > > > > > > > > --On Monday, July 29, 2002 21:32:02 -0400 blitz <[EMAIL PROTECTED]> wrote: > > > > > > > Seriously, I don't see OC768 coming online en masse until they get the > > > > kinks worked out of optical switching. The transit times are so short > > > > thru the innards, in the order of picoseconds, that electronics is way > > > > too slow to perform such mundane tasks like determining where a packet is > > > > supposed to go. Thus, all this will require optical computing to be > > > > available cheaply and a lot more widespread than it is now. > > > > > > ...and : > > > > > > a) Someone got the money to buy the gear > > > > > > b) We have used the current capacity (see a). > > > > > > - kurtis - > > > >-- > >-- > >http://www.zeromemory.com - metal for your ears. >
Re: custom dialup kits
On Tue, 30 Jul 2002, Miguel Mata-Cardona wrote: > > who make these kits nowaday? Had some contacts, but most of them > are gone. URL or contact email will be very appreciated. www.rockstar.com is the current industry favorite... Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: OC-768 availability?
I believe many are working on it, but I haven't seen/heard of much progress since I learned of this, some 4 years ago now.. Add to that the bandwidth glut with all the DWDM and I guess they've got breathing room... At 09:34 7/30/02 -0700, you wrote: >I believe Junpier does have a OC-768 interface under testing if I'm not >mistaken... > > >Signal received 0. Kurt Erik Lindqvist <[EMAIL PROTECTED]> said: > > > > > > > > --On Monday, July 29, 2002 21:32:02 -0400 blitz <[EMAIL PROTECTED]> wrote: > > > > > Seriously, I don't see OC768 coming online en masse until they get the > > > kinks worked out of optical switching. The transit times are so short > > > thru the innards, in the order of picoseconds, that electronics is way > > > too slow to perform such mundane tasks like determining where a packet is > > > supposed to go. Thus, all this will require optical computing to be > > > available cheaply and a lot more widespread than it is now. > > > > ...and : > > > > a) Someone got the money to buy the gear > > > > b) We have used the current capacity (see a). > > > > - kurtis - > >-- >-- >http://www.zeromemory.com - metal for your ears.
RE: redundancy [was: something about arrogance]
That is even worse than what we have been talking about. You should be running a P2P T1 back to yourself, and distributing the access from a POP, or have the carrier you're reselling the T1 for allocate a /24. There is no reason to run BGP for a single /24 whatsoever, it should be announced in Carrier address space. Using your AS for another company totally violates the whole idea of an "Autonomous System". Derek -Original Message- From: Manolo Hernandez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 1:30 PM To: Derek Samford Cc: [EMAIL PROTECTED]; 'Pedro R Marques'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: redundancy [was: something about arrogance] Yes their is a reason to some /24s advertised to the world. If this a class on BGP they would tell you that was a nono, but since this is the real world it happens and is sometimes required. It is required when you need to give a customer T-1 access at a location seperate from yours and has a seperate connection to the net and you are using your AS on the access router. A /24 is a solution that works nicely and still works with your aggregated /20 address. On Tue, 2002-07-30 at 13:23, Derek Samford wrote: > > I couldn't possibly agree more. In fact, my approach has been to create > a mesh between different Colo centers, and keep it at about 3 Transit > carriers. Because of the different methods of interconnection, I haven't > ever had a long-term outage. Also, I've been able to filter any issues > that are beyond my carrier's immediate reach (i.e. congested peering > points.) At the same time, I've been able to maintain aggregation of all > of my routes, and maintain true stability in my network. There is > absolutely no excuse to fill up the routing tables with nonsense. > > Derek > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Phil Rosenthal > Sent: Tuesday, July 30, 2002 12:52 PM > To: 'Pedro R Marques'; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: redundancy [was: something about arrogance] > > > I have in the past single-homed to Level(3) and Verio, each in their own > facility in NC. > In that time, both carriers had about 1 solid hour a month of solid > downtime (some months were worse, some were better). Some of the outages > were on the order of 8 solid hours (verio) or 4 hours (level3). > > We did not run HSRP with Level3, so it may be difficult to guarantee the > uptime of one gige handoff... But we ran HSRP with verio, and of all the > outages (about 20 of them) -- Maybe two of them were avoided because of > HSRP. > > Other than that, it was all downtime. > > At this point, I couldn't conceive single-homing to any uplink anymore. > > --Phil > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Pedro R Marques > Sent: Tuesday, July 30, 2002 6:23 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: redundancy [was: something about arrogance] > > > > Brad writes: > >I'm probably demonstrating my ignorance here (and my stupidity > > in > > stepping into a long-standing highly charged argument), but I'm > > completely missing something. For reasons of redundancy & > > reliability, even if you were to buy bandwidth in only one location, > > wouldn't you want to buy it from at least two different providers? > > >If you buy bandwidth from two different providers at two > > different locations, this would seem to me to be a good way to > > provide backup in case on provider or one location goes > > Tango-Uniform, and you could always backhaul the bandwidth for the > > site/provider that is down. > > Several other posters have mentioned reasons why redundancy between 2 > different connections to separate providers are not, in most situations, > > the preferable aproach but i would like to add another point/question... > > When considering redudancy/reliability/etc it is important to think > about what kind of failures do you want to protect against vs cost of > doing so. > > It is my impression, from reading this list and tidbits of gossip, that > the most common causes of failure are: > - link failure > - equipment failure (routers mostly), both software and hardware > - configuration errors > > All of those are much more frequent than the failure of an entire ISP (a > > transit provider). It is expected, i believe, of a competent ISP to > provide redudancy both within a POP and intra-POP links/equipment and > its connections to upstreams/peers. > > As such, probably the first level of redundancy that a origin AS > (non-transit) would look at would be with the intent to protect from > failures of its external connectivity link and termination equipment > (routers on both ends). > > To do so, one can look at: > - 2 external links to distinct providers > - 2 external links to the same provider > > While i can't speak to the economics part
RE: redundancy [was: something about arrogance]
Yes their is a reason to some /24s advertised to the world. If this a class on BGP they would tell you that was a nono, but since this is the real world it happens and is sometimes required. It is required when you need to give a customer T-1 access at a location seperate from yours and has a seperate connection to the net and you are using your AS on the access router. A /24 is a solution that works nicely and still works with your aggregated /20 address. On Tue, 2002-07-30 at 13:23, Derek Samford wrote: > > I couldn't possibly agree more. In fact, my approach has been to create > a mesh between different Colo centers, and keep it at about 3 Transit > carriers. Because of the different methods of interconnection, I haven't > ever had a long-term outage. Also, I've been able to filter any issues > that are beyond my carrier's immediate reach (i.e. congested peering > points.) At the same time, I've been able to maintain aggregation of all > of my routes, and maintain true stability in my network. There is > absolutely no excuse to fill up the routing tables with nonsense. > > Derek > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Phil Rosenthal > Sent: Tuesday, July 30, 2002 12:52 PM > To: 'Pedro R Marques'; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: redundancy [was: something about arrogance] > > > I have in the past single-homed to Level(3) and Verio, each in their own > facility in NC. > In that time, both carriers had about 1 solid hour a month of solid > downtime (some months were worse, some were better). Some of the outages > were on the order of 8 solid hours (verio) or 4 hours (level3). > > We did not run HSRP with Level3, so it may be difficult to guarantee the > uptime of one gige handoff... But we ran HSRP with verio, and of all the > outages (about 20 of them) -- Maybe two of them were avoided because of > HSRP. > > Other than that, it was all downtime. > > At this point, I couldn't conceive single-homing to any uplink anymore. > > --Phil > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Pedro R Marques > Sent: Tuesday, July 30, 2002 6:23 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: redundancy [was: something about arrogance] > > > > Brad writes: > >I'm probably demonstrating my ignorance here (and my stupidity > > in > > stepping into a long-standing highly charged argument), but I'm > > completely missing something. For reasons of redundancy & > > reliability, even if you were to buy bandwidth in only one location, > > wouldn't you want to buy it from at least two different providers? > > >If you buy bandwidth from two different providers at two > > different locations, this would seem to me to be a good way to > > provide backup in case on provider or one location goes > > Tango-Uniform, and you could always backhaul the bandwidth for the > > site/provider that is down. > > Several other posters have mentioned reasons why redundancy between 2 > different connections to separate providers are not, in most situations, > > the preferable aproach but i would like to add another point/question... > > When considering redudancy/reliability/etc it is important to think > about what kind of failures do you want to protect against vs cost of > doing so. > > It is my impression, from reading this list and tidbits of gossip, that > the most common causes of failure are: > - link failure > - equipment failure (routers mostly), both software and hardware > - configuration errors > > All of those are much more frequent than the failure of an entire ISP (a > > transit provider). It is expected, i believe, of a competent ISP to > provide redudancy both within a POP and intra-POP links/equipment and > its connections to upstreams/peers. > > As such, probably the first level of redundancy that a origin AS > (non-transit) would look at would be with the intent to protect from > failures of its external connectivity link and termination equipment > (routers on both ends). > > To do so, one can look at: > - 2 external links to distinct providers > - 2 external links to the same provider > > While i can't speak to the economics part of the equation (although i > would expect it to be cheaper to buy an additional link than connect to > a different provider) from a point of view of restoration, protecting a > path with an alternate path from the same provider is certainly an > aproach that gives you much better convengence times. > > This comes from the fact that in terms of network topology, the distance > > between 2 links to the same upstream is much shorter than 2 links to > different upstreams. While, if you protect a path with an alternate path > > to the same ISP you can expect convergence to occur within the IGP > convergence times of your provider, with 2 different providers you need > global
RE: redundancy [was: something about arrogance]
I couldn't possibly agree more. In fact, my approach has been to create a mesh between different Colo centers, and keep it at about 3 Transit carriers. Because of the different methods of interconnection, I haven't ever had a long-term outage. Also, I've been able to filter any issues that are beyond my carrier's immediate reach (i.e. congested peering points.) At the same time, I've been able to maintain aggregation of all of my routes, and maintain true stability in my network. There is absolutely no excuse to fill up the routing tables with nonsense. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Phil Rosenthal Sent: Tuesday, July 30, 2002 12:52 PM To: 'Pedro R Marques'; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: redundancy [was: something about arrogance] I have in the past single-homed to Level(3) and Verio, each in their own facility in NC. In that time, both carriers had about 1 solid hour a month of solid downtime (some months were worse, some were better). Some of the outages were on the order of 8 solid hours (verio) or 4 hours (level3). We did not run HSRP with Level3, so it may be difficult to guarantee the uptime of one gige handoff... But we ran HSRP with verio, and of all the outages (about 20 of them) -- Maybe two of them were avoided because of HSRP. Other than that, it was all downtime. At this point, I couldn't conceive single-homing to any uplink anymore. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Pedro R Marques Sent: Tuesday, July 30, 2002 6:23 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: redundancy [was: something about arrogance] Brad writes: >I'm probably demonstrating my ignorance here (and my stupidity in > stepping into a long-standing highly charged argument), but I'm > completely missing something. For reasons of redundancy & > reliability, even if you were to buy bandwidth in only one location, > wouldn't you want to buy it from at least two different providers? >If you buy bandwidth from two different providers at two > different locations, this would seem to me to be a good way to > provide backup in case on provider or one location goes > Tango-Uniform, and you could always backhaul the bandwidth for the > site/provider that is down. Several other posters have mentioned reasons why redundancy between 2 different connections to separate providers are not, in most situations, the preferable aproach but i would like to add another point/question... When considering redudancy/reliability/etc it is important to think about what kind of failures do you want to protect against vs cost of doing so. It is my impression, from reading this list and tidbits of gossip, that the most common causes of failure are: - link failure - equipment failure (routers mostly), both software and hardware - configuration errors All of those are much more frequent than the failure of an entire ISP (a transit provider). It is expected, i believe, of a competent ISP to provide redudancy both within a POP and intra-POP links/equipment and its connections to upstreams/peers. As such, probably the first level of redundancy that a origin AS (non-transit) would look at would be with the intent to protect from failures of its external connectivity link and termination equipment (routers on both ends). To do so, one can look at: - 2 external links to distinct providers - 2 external links to the same provider While i can't speak to the economics part of the equation (although i would expect it to be cheaper to buy an additional link than connect to a different provider) from a point of view of restoration, protecting a path with an alternate path from the same provider is certainly an aproach that gives you much better convengence times. This comes from the fact that in terms of network topology, the distance between 2 links to the same upstream is much shorter than 2 links to different upstreams. While, if you protect a path with an alternate path to the same ISP you can expect convergence to occur within the IGP convergence times of your provider, with 2 different providers you need global BGP convergence to occur. This gets to be longer dependent on how topologically distant your 2 upstreams are... for instance attempting to protect a path to an ISP with very wide connectivity with a protection path from one with very limited connectivity would be a particularly bad case as you would have to wait for the path announced by the larger ISP to be withdrawn n times from all its peering points and the protection path to make its way through in replacement. It is counter-intuitive to me what i perceive to be the standard practice of attempting to multi-home to 2 distinct providers by origin-only ASes... from several points of view: convergence times, load on the global routing system, complexity of m
RE: OC-768 availability?
FYI, the technology seems like it might be available at the component level (dated 3/2002) http://www.eetimes.com/story/OEG20020313S0015 http://biz.yahoo.com/prnews/020430/sftu082_1.html (april 2002?) http://www.cisco.com/univercd/cc/td/doc/pcat/15808.htm (7/13/2002) Deepak Jain AiNET > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Dr. Mosh > Sent: Tuesday, July 30, 2002 12:35 PM > To: [EMAIL PROTECTED] > Subject: Re: OC-768 availability? > > > > I believe Junpier does have a OC-768 interface under testing if I'm not > mistaken... > > > Signal received 0. Kurt Erik Lindqvist <[EMAIL PROTECTED]> said: > > > > > > > > --On Monday, July 29, 2002 21:32:02 -0400 blitz > <[EMAIL PROTECTED]> wrote: > > > > > Seriously, I don't see OC768 coming online en masse until they get the > > > kinks worked out of optical switching. The transit times are so short > > > thru the innards, in the order of picoseconds, that electronics is way > > > too slow to perform such mundane tasks like determining where > a packet is > > > supposed to go. Thus, all this will require optical computing to be > > > available cheaply and a lot more widespread than it is now. > > > > ...and : > > > > a) Someone got the money to buy the gear > > > > b) We have used the current capacity (see a). > > > > - kurtis - > > -- > -- > http://www.zeromemory.com - metal for your ears. > >
RE: redundancy [was: something about arrogance]
I have in the past single-homed to Level(3) and Verio, each in their own facility in NC. In that time, both carriers had about 1 solid hour a month of solid downtime (some months were worse, some were better). Some of the outages were on the order of 8 solid hours (verio) or 4 hours (level3). We did not run HSRP with Level3, so it may be difficult to guarantee the uptime of one gige handoff... But we ran HSRP with verio, and of all the outages (about 20 of them) -- Maybe two of them were avoided because of HSRP. Other than that, it was all downtime. At this point, I couldn't conceive single-homing to any uplink anymore. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Pedro R Marques Sent: Tuesday, July 30, 2002 6:23 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: redundancy [was: something about arrogance] Brad writes: >I'm probably demonstrating my ignorance here (and my stupidity in > stepping into a long-standing highly charged argument), but I'm > completely missing something. For reasons of redundancy & > reliability, even if you were to buy bandwidth in only one location, > wouldn't you want to buy it from at least two different providers? >If you buy bandwidth from two different providers at two > different locations, this would seem to me to be a good way to > provide backup in case on provider or one location goes > Tango-Uniform, and you could always backhaul the bandwidth for the > site/provider that is down. Several other posters have mentioned reasons why redundancy between 2 different connections to separate providers are not, in most situations, the preferable aproach but i would like to add another point/question... When considering redudancy/reliability/etc it is important to think about what kind of failures do you want to protect against vs cost of doing so. It is my impression, from reading this list and tidbits of gossip, that the most common causes of failure are: - link failure - equipment failure (routers mostly), both software and hardware - configuration errors All of those are much more frequent than the failure of an entire ISP (a transit provider). It is expected, i believe, of a competent ISP to provide redudancy both within a POP and intra-POP links/equipment and its connections to upstreams/peers. As such, probably the first level of redundancy that a origin AS (non-transit) would look at would be with the intent to protect from failures of its external connectivity link and termination equipment (routers on both ends). To do so, one can look at: - 2 external links to distinct providers - 2 external links to the same provider While i can't speak to the economics part of the equation (although i would expect it to be cheaper to buy an additional link than connect to a different provider) from a point of view of restoration, protecting a path with an alternate path from the same provider is certainly an aproach that gives you much better convengence times. This comes from the fact that in terms of network topology, the distance between 2 links to the same upstream is much shorter than 2 links to different upstreams. While, if you protect a path with an alternate path to the same ISP you can expect convergence to occur within the IGP convergence times of your provider, with 2 different providers you need global BGP convergence to occur. This gets to be longer dependent on how topologically distant your 2 upstreams are... for instance attempting to protect a path to an ISP with very wide connectivity with a protection path from one with very limited connectivity would be a particularly bad case as you would have to wait for the path announced by the larger ISP to be withdrawn n times from all its peering points and the protection path to make its way through in replacement. It is counter-intuitive to me what i perceive to be the standard practice of attempting to multi-home to 2 distinct providers by origin-only ASes... from several points of view: convergence times, load on the global routing system, complexity of management, etc, dual connectivity to different routers of the same provider (using distinct physical paths) would seem to me to make more sense. Unless the main concern is that the upstream ISP fails entirely... which given the fact that it tends to have frontpage honors on the NYTimes this days does not apear to be an all to common occurence (i mean operationally, not financially - clarification added to dispel potential humorous remarks). So, my question to the list is, why is multi-homing to 2 different providers such a desirable thing ? What is the motivation and why is it prefered over multiple connections to the same upstream ? Is the main motivation not so much reliability but having a shorter as-path to more destinations ? This would apear to me to be a clear advantage since that doesn't necessarily re
RE: custom dialup kits
Not sure what you're looking for here. Phone jack converters? Available at many airport gift shops and a Google search results in http://kropla.com/sources.htm Best regards, _ Alan Rowland -Original Message- From: Miguel Mata-Cardona [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 8:21 AM To: [EMAIL PROTECTED] Subject: custom dialup kits who make these kits nowaday? Had some contacts, but most of them are gone. URL or contact email will be very appreciated. -- Miguel Mata-Cardona Intercom El Salvador [EMAIL PROTECTED]
RE: OC-768 availability?
Compton, CA, US and Sealand would be the giveaways. Best regards, _ Alan Rowland Who lives just south of Compton -Original Message- From: Scott Weeks [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 4:31 PM To: Williams, Ken Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: RE: OC-768 availability? No, he's not for real. It's a satire in the likes of Bandy Rush and such. Children need to have their fun... scott On Mon, 29 Jul 2002, Williams, Ken wrote: : : hah 2621 rockin oc-192 are you for real? : : -Original Message- : From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] : Sent: Monday, July 29, 2002 4:10 PM : To: [EMAIL PROTECTED] : Subject: OC-768 availability? : : : : : Hello, : : I am currently running a network of cisco 2621s with the OC-192 NM for my : upstream connections. The internal network links are a mixture of K56Flex : modems and GRE tunnels. : : I am looking to upgrade to OC-768 real soon now and am wondering what the : prospects are for OC-768 availability on the 2621 platform. I've found the : 2621 to be rock-solid, except when I ping it, so I'd like to keep my network : on that platform if possible. : : In addition, if anyone knows the availability of OC-768 circuits between the : following cities I'd appreciate any fiber maps and an approximate price : range: : Ottawa, ON, CA : Midland, ON, CA : Goderich, ON, CA : Toronto, ON, CA : Compton, CA, US : Sealand : : At each site I plan to announce a /24 from a /20 I was allocated so if : everyone could please update their prefix filters now that would be great. : : Thank you. : : -- Dalph Roncaster : : Communicate in total privacy. : Get your free encrypted email at https://www.hushmail.com/?l=2 : : Looking for a good deal on a domain name? : http://www.hush.com/partners/offers.cgi?id=domainpeople :
Re: OC-768 availability?
I believe Junpier does have a OC-768 interface under testing if I'm not mistaken... Signal received 0. Kurt Erik Lindqvist <[EMAIL PROTECTED]> said: > > > > --On Monday, July 29, 2002 21:32:02 -0400 blitz <[EMAIL PROTECTED]> wrote: > > > Seriously, I don't see OC768 coming online en masse until they get the > > kinks worked out of optical switching. The transit times are so short > > thru the innards, in the order of picoseconds, that electronics is way > > too slow to perform such mundane tasks like determining where a packet is > > supposed to go. Thus, all this will require optical computing to be > > available cheaply and a lot more widespread than it is now. > > ...and : > > a) Someone got the money to buy the gear > > b) We have used the current capacity (see a). > > - kurtis - -- -- http://www.zeromemory.com - metal for your ears.
custom dialup kits
who make these kits nowaday? Had some contacts, but most of them are gone. URL or contact email will be very appreciated. -- Miguel Mata-Cardona Intercom El Salvador [EMAIL PROTECTED]
Re: verio arrogance
> I think you may have misread my comment. ARIN ALLOWS the issuance of /24s to > multihomed enterprises. The recent policy decision was made to allow > upstreams to do this sort of allocation, without having to receive any other > justification, other than multihomed status. This could seem to be RIR > recognition of /24 as the globally routed "common denominator" - for those > who insist on basing their filter policies on ARIN guidelines. :) ARIN also _allows_ the issuance of /32s to anyone. They, however, do not issue /32s directly, nor do they issue /24s to multihomed entities directly, without heavy justification. As such, the ARIN allocation would be the larger aggregate from which the /24 is carved. If ARIN were to (as I believe RIPE is presently doing or trialing) begin assigning controlled amounts of small multihomer space from a specific netblock, then we could filter knowing roughly what the longest prefix is which contains the largest aggregates of all assignments. However, this would be up to the RIR, and they certainly don't have to do it. The RIR published data provides just that: They say for a specific range what the longest prefix is which is expected to not be further aggregatable. As such, responsible filterers will know: 1) at what point, if they were to filter, they would be likely to filter away folks who CAN NOT further aggregate (which is bad) 2) at what point, if they were to cease filtering, they would be receiving ONLY more-specifics. The onus then moves to the assignees to announce their largest aggregates, and should they choose to deaggregate beyond that to /32, becomes a moot point (except to those who don't filter). Anyway, I'm done, if anyone wants to discuss this further with me, mail me direct.
Re: Identifying DoS sources quickly (was: Bogon list or Dshield.orgtype list)
> How many ISPs would identify the user of an IP address for the purposes of > sending a "cease and desist" letter when contacted by a lawyer? Despite 9/11, privacy still counts for something. It's rather dangerous to give out private user information without a court order. If one of our suscribers were involved in a DoS, we would deal with it inernally, saving any records in the event of a court search warrant. -Ralph
Re: Identifying DoS sources quickly (was: Bogon list or Dshield.org type list)
>> Not a complete solution but a start: >> IP Source Tracker: > http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 > limit/120s/120s21/ipst.htm >> Available as of 12.0(22)S for 7500 and 12000 series Cisco routers. ah yes. the new enterprise image. :-(
Re: Identifying DoS sources quickly (was: Bogon list or Dshield.org type list)
Hank Nussbacher wrote: > > So, to restate the problem, how do we identify some of the sources of a > > DoS attack quickly, maybe even while the attack is still in progress? > > Not a complete solution but a start: > IP Source Tracker: > http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 limit/120s/120s21/ipst.htm > > Available as of 12.0(22)S for 7500 and 12000 series Cisco routers. > Hank, one major flaw with this is that you can't track back further when you are on an (ethernet based) IXP. IIRC older versions of IOS gave L2 information (MAC address) as well which helped you to identify the last hop. -- Arnold -- Arnold Nipper / nIPper consulting e-mail: [EMAIL PROTECTED] phone/mob: +49 172 265 0958 fax: +49 6224 9259 333
Re: Identifying DoS sources quickly (was: Bogon list or Dshield.orgtype list)
On Tue, 30 Jul 2002 [EMAIL PROTECTED] wrote: > That's the obvious solution to the problem if the problem is how to track > down the source(s) of a DoS attack. However, in any DoS attack, there is > always a victim and one or more devices sendingattack traffic to the > victim. The owners of the attacking devices are accessories to the crime > although I'm sure they could plead ignorance and avoid any liability. But > what if they could not plead ignorance? What if we could identify some of > theattacking devices, and what if the victim sent a legal "cease and > desist" letter to the owners of the attacking devices? Now, the victim is > in a position to sue the owners of these attacking devices if they don't > fix the problem by securing their machines. And once this happens and gets > some press coverage, a whole bunch of other machine owners will wake up > and realize that they could be stuck with big legal bills if they don't > secure their machines. > > So, to restate the problem, how do we identify some of the sources of a > DoS attack quickly, maybe even while the attack is still in progress? Not a complete solution but a start: IP Source Tracker: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s21/ipst.htm Available as of 12.0(22)S for 7500 and 12000 series Cisco routers. -Hank
Identifying DoS sources quickly (was: Bogon list or Dshield.org type list)
>As far as tracking DoS, I've read some good papers on the subject and it >always boils down to tracking MAC addresses and going interface by >interface to the source, demanding inter-ISP cooperation, and finally >legal assistance. This has been tried during a few severe instances with >poor results. That's the obvious solution to the problem if the problem is how to track down the source(s) of a DoS attack. However, in any DoS attack, there is always a victim and one or more devices sending attack traffic to the victim. The owners of the attacking devices are accessories to the crime although I'm sure they could plead ignorance and avoid any liability. But what if they could not plead ignorance? What if we could identify some of the attacking devices, and what if the victim sent a legal "cease and desist" letter to the owners of the attacking devices? Now, the victim is in a position to sue the owners of these attacking devices if they don't fix the problem by securing their machines. And once this happens and gets some press coverage, a whole bunch of other machine owners will wake up and realize that they could be stuck with big legal bills if they don't secure their machines. So, to restate the problem, how do we identify some of the sources of a DoS attack quickly, maybe even while the attack is still in progress? >Bots/Zombies are traded openly on IRC and there is no >accountability for personal security. ISPs won't shut someone down >because they've been "hacked", merely send them a warning Email or >call--a process that takes days in my experience. How many ISPs would identify the user of an IP address for the purposes of sending a "cease and desist" letter when contacted by a lawyer? Considering that failure to provide the identity would result in the ISP themselves getting sued by the DoS victim? As long as *SOME* ISPs would cooperate with a DoS victim, there is enough to get the legal ball rolling. The alternative is to painfully backtrack until you find an uncooperative ISP and then sure them. As I said before, if there was a central registry something like dshield.org that collected data on the destination IP addresses of DoS attacks along with estimated magnitude based on analysing the traffic from random source addresses blocked by ingress filters, then we have something an ISP can use to analyze their outgoing traffic. If you are an ISP and you have netflow data that contains destination addresses which also occur in the DoS victim registry then you should be willing to act on that data. Of course, it's up to you what you do with it. You may offer the DoS victim the identity of the source provided that they serve you with the right legal documents. Or you might go to the owner of the machine yourself with the evidence and warn them that they are aiding and abetting cyber terrorists and could suffer the legal consequences if they don't secure their machines. It's certainly not perfect but it's worth a try. --Michael Dillon
RE: verio arrogance
(SNIP) > > Currently, RIR's will issue an AS and will allow the issuance > of a /24 to a > > multihomed enterprise, simply on the basis of being multihomed. > From this > > point of view, it's easy to make the case that the proper "RIR-approved" > > boundary for prefix filtering should be at the /24 level. At > any rate, Verio > > has been slowly liberalizing their filtering policy, and bring > it into line > > with the rest of the industry. > > If the RIR is issuing /24s, then they denote such on their > minimum allocation > lists, allowing providers to accept /24s from such blocks. > I think you may have misread my comment. ARIN ALLOWS the issuance of /24s to multihomed enterprises. The recent policy decision was made to allow upstreams to do this sort of allocation, without having to receive any other justification, other than multihomed status. This could seem to be RIR recognition of /24 as the globally routed "common denominator" - for those who insist on basing their filter policies on ARIN guidelines. :) It's often comforting to believe that there is a little more order than chaos on the internet, that there are standards or professional bodies out there to make law or proscribe best practice. However, this is simply not the case. ARIN and it's brethren are simply there to hand out numbers, not to provide a guideline on or even suggestion how to filter prefixes. Of course, we can all decide on our own, based on business imperatives, the best way to do that. I just hate to see people thinking that there is some sort of unspoken correlation between ARIN issuance guidelines and "best practice" filtering. - Dan
RE: redundancy [was: something about arrogance]
> You cannot as easily be held hostage. I have consulted for > a few ISPs and > have my share of war stories. > > Here's a (true!) example. One day, a certain head of a > fairly large ISP > decided that he wouldn't route traffic to or from IPs he had > assigned that > didn't reverse resolve because he felt it was imperative that > people be able > to find network contacts in this way (I think he got sick of > being the one to > get the abuse emails). He told my client three days before implementing a > sweep and filter. He had the equivalent of about 38 /24s from this ISP > distributed over about 180 customers, they were his sole uplink. [SNIP] Often overlooked is the redundancy in business processes. We tend to view events with an external-forces engineering perspective while frequently the culprits are uninformed decisions, knee-jerk reactions and opportunism by humans at our vendors. (Not to downplay other risks.) -John -- John Ferriby - PGP Key: www.ferriby.com/pgpkey smime.p7s Description: application/pkcs7-signature
Re: redundancy [was: something about arrogance]
On Tue, 30 Jul 2002 03:23:24 -0700, Pedro R Marques wrote: >All of those are much more frequent than the failure of an entire ISP (a >transit provider). It is expected, i believe, of a competent ISP to >provide redudancy both within a POP and intra-POP links/equipment and >its connections to upstreams/peers. Yes, but when the ISP that all your redundant links go to and that you got all your IPs from goes out of business, what's the mean time to repair? 30 days? >So, my question to the list is, why is multi-homing to 2 different >providers such a desirable thing ? What is the motivation and why is it >prefered over multiple connections to the same upstream ? You cannot as easily be held hostage. I have consulted for a few ISPs and have my share of war stories. Here's a (true!) example. One day, a certain head of a fairly large ISP decided that he wouldn't route traffic to or from IPs he had assigned that didn't reverse resolve because he felt it was imperative that people be able to find network contacts in this way (I think he got sick of being the one to get the abuse emails). He told my client three days before implementing a sweep and filter. He had the equivalent of about 38 /24s from this ISP distributed over about 180 customers, they were his sole uplink. Here's another good one. A client needed a /22 immediately for a major customer about to come online, set it up fast or lost the account. We made sure to met all the IP assignment guidelines and our justification was impeccable, we had >90% utilization of a /18. The only problem was, the client's provider had a screw up in their allocations and justifications and their applications were being refused by ARIN until they fixed their problems. Now what? One more just for kicks. Client had a 100Mbps circuit from their sole provider (100Mbps to colocated router, DS3 from this router to their premises). The circuit had been in place for several years and the contract had long since expired. One day, they got a call -- they had 5 days to agree to a new (and MUCH higher) pricing scheme with a much higher minimum paid bandwidth amount or their circuit would be turned off. The kicker -- they had to agree to a two year term! The other issue is provider misconfigurations/meltdowns. They're not common, but if you're multihomed, you can just shut down the circuit to the misconfigured providers. There have been a few cases of these that I've seem where the repair time was several hours. If you add cases where just one POP was out, the number goes way up. If you're only in one location yourself and only use one provider, all of your redundant links will likely go to the same POP. DS
redundancy [was: something about arrogance]
Brad writes: >I'm probably demonstrating my ignorance here (and my stupidity in > stepping into a long-standing highly charged argument), but I'm > completely missing something. For reasons of redundancy & > reliability, even if you were to buy bandwidth in only one location, > wouldn't you want to buy it from at least two different providers? >If you buy bandwidth from two different providers at two > different locations, this would seem to me to be a good way to > provide backup in case on provider or one location goes > Tango-Uniform, and you could always backhaul the bandwidth for the > site/provider that is down. Several other posters have mentioned reasons why redundancy between 2 different connections to separate providers are not, in most situations, the preferable aproach but i would like to add another point/question... When considering redudancy/reliability/etc it is important to think about what kind of failures do you want to protect against vs cost of doing so. It is my impression, from reading this list and tidbits of gossip, that the most common causes of failure are: - link failure - equipment failure (routers mostly), both software and hardware - configuration errors All of those are much more frequent than the failure of an entire ISP (a transit provider). It is expected, i believe, of a competent ISP to provide redudancy both within a POP and intra-POP links/equipment and its connections to upstreams/peers. As such, probably the first level of redundancy that a origin AS (non-transit) would look at would be with the intent to protect from failures of its external connectivity link and termination equipment (routers on both ends). To do so, one can look at: - 2 external links to distinct providers - 2 external links to the same provider While i can't speak to the economics part of the equation (although i would expect it to be cheaper to buy an additional link than connect to a different provider) from a point of view of restoration, protecting a path with an alternate path from the same provider is certainly an aproach that gives you much better convengence times. This comes from the fact that in terms of network topology, the distance between 2 links to the same upstream is much shorter than 2 links to different upstreams. While, if you protect a path with an alternate path to the same ISP you can expect convergence to occur within the IGP convergence times of your provider, with 2 different providers you need global BGP convergence to occur. This gets to be longer dependent on how topologically distant your 2 upstreams are... for instance attempting to protect a path to an ISP with very wide connectivity with a protection path from one with very limited connectivity would be a particularly bad case as you would have to wait for the path announced by the larger ISP to be withdrawn n times from all its peering points and the protection path to make its way through in replacement. It is counter-intuitive to me what i perceive to be the standard practice of attempting to multi-home to 2 distinct providers by origin-only ASes... from several points of view: convergence times, load on the global routing system, complexity of management, etc, dual connectivity to different routers of the same provider (using distinct physical paths) would seem to me to make more sense. Unless the main concern is that the upstream ISP fails entirely... which given the fact that it tends to have frontpage honors on the NYTimes this days does not apear to be an all to common occurence (i mean operationally, not financially - clarification added to dispel potential humorous remarks). So, my question to the list is, why is multi-homing to 2 different providers such a desirable thing ? What is the motivation and why is it prefered over multiple connections to the same upstream ? Is the main motivation not so much reliability but having a shorter as-path to more destinations ? This would apear to me to be a clear advantage since that doesn't necessarily reflect in better qualitify of interconnection. My apologies in advance if these seem to be stupid questions... thanks, Pedro.
Re: OC-768 availability?
--On Monday, July 29, 2002 21:32:02 -0400 blitz <[EMAIL PROTECTED]> wrote: > Seriously, I don't see OC768 coming online en masse until they get the > kinks worked out of optical switching. The transit times are so short > thru the innards, in the order of picoseconds, that electronics is way > too slow to perform such mundane tasks like determining where a packet is > supposed to go. Thus, all this will require optical computing to be > available cheaply and a lot more widespread than it is now. ...and : a) Someone got the money to buy the gear b) We have used the current capacity (see a). - kurtis -
Re: OC-768 availability?
I heard that as well, as well as holographic processing...can't remember who however, but Lucent (or whoever they are this week) or Nortel (presently circling the drain) come to mind.. At 19:53 7/29/02 -0700, you wrote: >Wasn't one of the major switch companies working on a system of bubbles. >I'm not sure if it was foundry or Juniper or who but >someone was trying to route packets or rather switch packets in a device >at high speed by using bubbles to reflect and switch the light instead >of converting to electrons. > >On Mon, 29 Jul 2002, blitz wrote: > > > > > Seriously, I don't see OC768 coming online en masse until they get the > > kinks worked out of optical switching. The transit times are so short thru > > the innards, in the order of picoseconds, that electronics is way too slow > > to perform such mundane tasks like determining where a packet is supposed > > to go. > > Thus, all this will require optical computing to be available cheaply > and a > > lot more widespread than it is now. Cross your fingers and hope for a > > quantum breakthrough... > > OC192 is already pushing the limits of present technology. > > And add to that, the sorry state of the major players in telecom, and I > > don't think you'll see them willing to pony up an investment in something > > like that until it's well established. > > A typical egg/chicken situation.. > > > > > > > > At 16:10 7/29/02 -0700, you wrote: > > > > > > >Hello, > > > > > >I am currently running a network of cisco 2621s with the OC-192 NM for my > > >upstream connections. The internal network links are a mixture of K56Flex > > >modems and GRE tunnels. > > > > > >I am looking to upgrade to OC-768 real soon now and am wondering what the > > >prospects are for OC-768 availability on the 2621 platform. I've found > the > > >2621 to be rock-solid, except when I ping it, so I'd like to keep my > > >network on that platform if possible. > > > > > >In addition, if anyone knows the availability of OC-768 circuits between > > >the following cities I'd appreciate any fiber maps and an approximate > > >price range: > > >Ottawa, ON, CA > > >Midland, ON, CA > > >Goderich, ON, CA > > >Toronto, ON, CA > > >Compton, CA, US > > >Sealand > > > > > >At each site I plan to announce a /24 from a /20 I was allocated so if > > >everyone could please update their prefix filters now that would be great. > > > > > >Thank you. > > > > > >-- Dalph Roncaster > > > > > >Communicate in total privacy. > > >Get your free encrypted email at https://www.hushmail.com/?l=2 > > > > > >Looking for a good deal on a domain name? > > >http://www.hush.com/partners/offers.cgi?id=domainpeople > >
