- Test - lists.nanog.org

Re: Verio Peering Question
by smd＠clock.org 03 Oct '01

03 Oct '01

| As a network | provider, we need to have robust network connectivity. An upstream that | aggregates my routes more, thus endangering my network connectivity | would *quickly* lose my business. Then you have a good reason to begin negotiations with other networks with a view to them accepting your unaggregated/unaggregatable prefixes, and can account for this as a cost of doing business. | Is your position, honestly, that a provider the size of IgLou doesn't | *deserve* to have robust network connectivity because we're not big | enough? If so, I'll be sure to avoid purchasing any transit from you. I'm saying that if you are in the business of providing transit, you must be prepared to absorb some costs, rather than dump them on your fellow transit providers. Transit from me is a luxury I doubt you need or can afford, but feel free to take my earlier advice: shut up and send a cheque. Sean.

2 1

Re: 800-number outage?
by Kevin Day 03 Oct '01

03 Oct '01

According to Ameritech, at 8:15am they had a "server overload" that knocked out toll-free service for the 5 state area. They said it came back up for a while, but is definately back down now. Oddly enough, 800-244-4444 (ameritech customer support) works fine for me, but an 800# we have through ameritech ourselves doesn't, so it's not a case of internal v.s. external working/not working. Also, we've got a DS3 down since around 8:45am, and our carrier doesn't have a non 800# to open a ticket (that they're aware of). Yet another reason for people to test and maintain non-toll free numbers for critical services... -- Kevin > > > I just heard off a friend that there is a possible Ameritech Fiber cut...is > there any validity to that? There doesn't seem to be the usual noise around > fiber cuts, so I'm guessing that's not the case? > > Does anyone from the Ameritech side have a defintive answer? > > > > Ameritech SCP that handles lookups to the national SMS > database is having software problems, it seems to be working soft of now. > > > > > > > Does anyone know about this outage? > > Seems like every 800-type number in the country is out right > now...is > > it a network problem somewhere? > > > -- Kevin Day toasty(a)dragondata.com - kevin(a)stileproject.com

1 0

MFN: September 11 outage report
by Sean Donelan 03 Oct '01

03 Oct '01

MFN filed their September 11 FCC outage report on September 28. Two cables, 312 fibers, destroyed at the WTC and lower Manhattan 144 fibers destroyed serving 50 Broad Street 864 fibers destroyed serving 140 West Street http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/20… Hopefully, MFN will be filing a final outage report later.

1 0

Re: 800-number outage?
by Spencer.Wood＠dot.state.oh.us 03 Oct '01

03 Oct '01

Customers inside of Ameritech Areas are affected by the outage. From what I understand, the Translation database is corrupt and/or missing..... I'm not sure if it's isolated to Ameritech, or the entire SBC Network.... Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us Phone: 614.387.0710/Fax: 815.361.0714/Pager: 866.591.9954 ************************************************************* "Los, Ralph" <rlos(a)EnvestNet.com> Sent by: owner-nanog(a)merit.edu 10/03/2001 11:18 AM To: "'nanog(a)merit.edu'" <nanog(a)merit.edu> cc: Subject: 800-number outage? Does anyone know about this outage? Seems like every 800-type number in the country is out right now...is it a network problem somewhere? Ralph M. Los Asst. Vice-President, Internet Systems and Security EnvestnetPMC rlos(a)envestnet.com (312) 827-3945 (direct) (312) 296-9003 (wireless w/voicemail) * If you haven't been hacked, you don't know where your vulnerabilities lie*

1 0

RE: 800-number outage?
by Los, Ralph 03 Oct '01

03 Oct '01

I just heard off a friend that there is a possible Ameritech Fiber cut...is there any validity to that? There doesn't seem to be the usual noise around fiber cuts, so I'm guessing that's not the case? Does anyone from the Ameritech side have a defintive answer? Ralph M. Los Asst. Vice-President, Internet Systems and Security EnvestnetPMC rlos(a)envestnet.com (312) 827-3945 (direct) (312) 296-9003 (wireless w/voicemail) * If you haven't been hacked, you don't know where your vulnerabilities lie* -----Original Message----- From: John Lodden [mailto:jrl@lodden.com] Sent: Wednesday, October 03, 2001 10:20 AM To: Los, Ralph Cc: nanog(a)merit.edu Subject: Re: 800-number outage? Ameritech SCP that handles lookups to the national SMS database is having software problems, it seems to be working soft of now. -John Lodden MichTel, Inc. > > > Does anyone know about this outage? > Seems like every 800-type number in the country is out right now...is > it a network problem somewhere? > > Ralph M. Los > Asst. Vice-President, Internet Systems and Security > EnvestnetPMC > rlos(a)envestnet.com > (312) 827-3945 (direct) > (312) 296-9003 (wireless w/voicemail) > * If you haven't been hacked, you don't know where your vulnerabilities lie* >

1 0

Re: Exodus "locking down" customer gear due to bankruptcy?
by JC Dill 03 Oct '01

03 Oct '01

On 06:03 PM 10/1/2001 -0400, Tim Wilde wrote: >Perhaps your sources are confused by changed procedures; in Boston I've >seen signs posted that equipment can no longer be carried in or out via >the lobby area, and must traverse the shipping & receiving area, but no >evidence of customers being prevented from leaving; in fact, I'm pretty >certain that there's no such restriction being enforced. How odd. In Chicago, I had boxes that had been shipped and held in their shipping and receiving which I was forced to take into the lobby for the purpose of unpacking and putting the equipment on carts before I was allowed to take them into the colo and install in our cabinets. The reverse procedure was used to pack up the boxes I was shipping home, I had to take the equipment out of the colo to the lobby and THEN pack it up, IN THE LOBBY. Needless to say, I found this policy a royal pain in the youknowwhat. They claim this is a company-wide policy, but if it is it hasn't been enforced in Seattle (SE2) or in DC (DC2). I have yet to test how they enforce it in Santa Clara (SC4). jc

3 2

Job fair at NANOG 23?
by Pete Kruckenberg 03 Oct '01

03 Oct '01

Seem to be a lot of people looking for jobs, any chance of having a job fair at the next NANOG? Or even a job posting board with a place to match people with companies (in person or just boxes where resumes can be dropped)? On a related note, the group I'm working for is hiring: Opening for experienced network engineer working on large, multi-service research/education network in Utah. State of Utah isn't going out of business or doing lay-offs anytime soon, it's a fun work environment run more like a start-up than a govt agency. Competitive salary and benefits. Job posting is at http://www.med.utah.edu/hr/joblist/jobdetail.cfm?id=10061 application is at http://www.med.utah.edu/hr/webappv1.0.PDF You can email me as well, I work there in the net. eng group. Pete.

1 0

Re: Verio Peering Question
by Paul Vixie 03 Oct '01

03 Oct '01

> > there has to be a limit. > > A limit is needed, but the filtering method in question to me essentially > says this: > > if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat > as much as you want.. we feel this is an acceptable practice. i strongly doubt that the policy was formulated on that basis. it may or may not be equivilent to what you said, but you have not described anyone's (whom i'm aware of) actual motivations with the above formulation. > Yet, if you're a legitimately multihomed customer wants to push out a > single /24 (1 AS, 1 prefix) that is not considered acceptable. actually there's a loophole. nobody filters swamp /24's that i know of, since so much of the oldest salty crusty layers of the internet are built on those. > The only kind of prefix filtering I would want to implement is something > that can accomplish: > > 1. Define threshold, say /20 or /18 or hell even /8. > 3. all prefixes longer than threshold get held until entire tables are > loaded > 3. start looking at the longer prefixes across the entire ipv4 space > starting with the longest and finishing at threshold+1 > 4. if prefixes longer than threshold appear as part of a larger aggregate > block that *originate* from the same AS, drop. > 5. if prefixes longer than threshold originate from a different AS than > the aggregate, accept. i wish you luck in implementing this proposal. i think that folks with multivendor global networks will find it completely impractical, but you can probably pull it off in a regional zebra-based network with no problem. > This way I could get rid of redundant information yet at the same time not > cause any trouble to smaller multihomed customers. I'm not saying that we > should allow /32's to be pushed everywhere either. As you said there has > to be a limit, and /24 seems to be a pretty good one if something along > the lines of the above mentioned filtering algorithm could be used. let's do some math on this. swamp space is more or less 192/8 and 193/8 (though parts of other /8's were also cut up with a pretty fine bladed knife). if every 192.*.*/24 and 193.*.*/24 were advertised, that would be more prefixes than the entire current table shown in tony bates' reports (~100K vs 128K). that is of course just the existing swamp. and it would be hard to handle but even harder to prevent since there's no real way using today's routers to say "accept the current /24's in 192/8 and 193/8 but don't allow new ones". this is the bogey man that gives people like smd nightmares. then there's everything else. if 20 /8's were cut up into /24's then tony bates' report would have 1.3M more things in it than are there today. if the whole IPv4 space were cut up that way then we'd see 16M routes globally. those numbers may seem unreasonable, either because current routers can't hold them, or because current routing protocols would never be able to converge, or because you just can't imagine humanity generating even 1.3M /24's let alone 16M of them. multihoming is a necessary property of a scalable IP economy. actually, provider independence is necessary, multihoming is just a means to that end. if you don't think there are more than 1.3M entities worldwide who would pay a little extra for provider independence, then you don't understand what's happened to *.COM over the last 10 years. in that case i'll simply ask you to take my word for it -- you make 1.3M slots available, they'll fill up. i do not know the actual limit -- that is, where it ends. i know it's going to be higher than 1.3M though. i also know that the limit of humanity's desire for "provider independence without renumbering" (or "multihoming") is currently higher than what the internet's capital plant, including budgetted expansions, can support. and i strongly suspect that this will remain true for the next 5..10 years. > I'm sure in reality there's many reasons this would not be able to be > implemented (CPU load perhaps) but it would atleast do something more than > a "gross hack" that nails some offenders, not all by any means, and > impacts multihomed customers who are only a portion of the problem that > the current prefix filtering solution does not solve. people are out there building networks using available technology. forget about CPU load and look at delta volume and convergence. the "internet backbone" is not fat enough to carry the amount of BGP traffic that it would take to represent the comings and goings of 16M prefixes. 1.3M is probably achievable by the time it comes due for natural causes. do any of our local theorists have an estimate of how much BGP traffic two adjacent core nodes will be exchanging with 1.3M prefixes? is it a full DS3 worth? more? less? every time you change out the capital plant on a single global AS core in order to support some sea change like 10Gb/s sonet or 200K routes, it costs that AS's owner between US$200M and US$1B depending on the density and capacity. bean counters for old line telcos used to want a 20 year payback (depreciation schedule) on investments of that order of magnitude. today a provider is lucky to get five years between core transplants. bringing the period down to two to three years would cause "the internet" to cost more to produce than its "customers" are willing to pay. so in the meanwhile, verio (and others who aren't mentioned in this thread) are using the technology they have in order to maximize the period before their capital plant becomes obsolete. as i said in a previous note, they are certainly balancing their filters so that filtering more would result in too many customer complaints due to unreachability, but filtering less would result in too many customer complaints due to instability. anyone who wants the point of equilibrium to move in the direction of "more routes" should be attacking the economies which give rise to the problem rather than attacking the engineering solutions which are the best current known answer to the problem. in other words go tell cisco/juniper/whomever your cool idea for a new routing protocol / route processing engine / cheap OC768-capable backplane and maybe they'll hire you to build it for them.

4 3

Exodus "locking down" customer gear due to bankruptcy?
by Christopher A. Woodfield 03 Oct '01

03 Oct '01

I've heard anecdotal evidence that Exodus has a clause buried in at least some of their contracts that effectively prohibits the customer from removing their equipment from their facilities in the event of bankruptcy. Not the customer filing Ch. 7/11, but EXODUS going bankrupt. Furthermore, it appears that as they have indeed filed Chapter 11, they are actively enforcing this, at least at their Northern Virginia facility. Has anyone else heard of this or been affected by this? Exodus customers, can any of you look up your contracts and see if you can dig this up? I'm interested in hearing the exact language, if it is indeed a standard clause...I'm thinking there's no way that this could be enforceable, although it would probably take a TRO to get them to let customers claim their gear. -Chris --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

7 11

Gordius has left the building. Was: RE: The Gorgon's Knot.
by Bender, Andrew 03 Oct '01

03 Oct '01

Deepak Jain wrote: > The problem is where the RIB, or forwarding table is exported to > the line cards which frequently have less than 128MB of usable > RAM/SRAM/memory storage/etc. This essentially means that the line > cards can only directly talk to other line cards for a specified, > limited number of routing prefixes. I do not know the algorithms > used when the line card is out of memory, but in many cases this > memory is not field upgradeable beyond a certain point. Srinivasan, Vargese, and others have demonstrated / observed that space is not a material problem for the architecture you describe. Rather, it is the time to complete a longest-match (or equivalent) operation for each forwarding event, especially for high(er) interface speeds. Regardless, 128MB is a LOT of table memory, especially when it is virtually unknown to see anything larger than 10-20Mbit CAMs; prior to reduction / expansion / etc, there's scarcely 11B of unique information in an IPv4 route. Adding in some bytes for mysterious 'other stuff', this is easily 4-8MM routes. We'll have to see another knee in route proliferation before this becomes a problem, and space exhaust would most certainly prevent this from happening. > Many smaller networks can and do use PCs for BGP and for > forwarding because their total forwarding needs at their core are > say sufficiently less than 800mb/s upto which PCs seem to handle. > However, the desires and models of these smaller networks don't > scale much beyond this level with currently available PC > technology. Agreed... as regards PCs lets remember that history has offered certain commentary on the non-role of PCs (indeed general purpose computers) in network infrastructure... viz. there aren't many GRFs / DDP516Rs / etc. around anymore. I doubt this is an 'interesting problem' for the op or planning community. Regards, Andrew Bender taqua.com

2 1