- NANOG - lists.nanog.org

at&t?
by jamie rishaw 16 Nov '00

16 Nov '00

anyone have a trouble # to report at&t ds1 problems? i am at home, left the palm at work, blah.. TIA jamie

1 0

Re: PSINet outage?
by Ben Browning 16 Nov '00

16 Nov '00

At 14:14 11/15/2000 -0500, John Fraizer wrote: >Does anyone care to explain how it could effect one or the other >exclusively? RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers http://www.landfield.com/rfcs/rfc1149.html --- Ben Browning <benb(a)oz.net> oz.net Network Operations Tel (206) 443-8000 Fax (206) 443-0500 http://www.oz.net/

3 2

Qwest fiber contractor hiring practices
by Sean Donelan 16 Nov '00

16 Nov '00

I hope besides appealling the verdict, Qwest considers revamping its contractor hiring, training and oversight practices. Reporting on the Qwest/AT&T fiber lawsuit, Newsbytes had this paragraph. http://www.newsbytes.com/news/00/158214.html > But it wasn't three outages that bugged the jury. What they didn't > like, one juror said, was Qwest's attitude, according to the Austin > American-Statesman. Attorney Joe Latting, who represented AT&T, said > a Qwest supervisor testified at trial, "We just hire these people > from the neck down," the paper said. AT&T had accused Qwest of hiring > unqualified personnel. Here was my message on Qwest's fiber trenching operations last year. >Subject: Call for Qwest to conduct a training stand-down >From: Sean Donelan <SEAN(a)SDG.DRA.COM> >Date: Tue, 4 May 1999 23:48:22 -0500 >Delivered-To: nanog-outgoing(a)merit.edu >Sender: owner-nanog(a)merit.edu > >I'm seeing a disturbing pattern develop. Qwest contractors seem to be >involved in an unusual number of cases of damaging other providers >fiber. I understand that everyone makes mistakes, and a wide-variety of >other equipment operators have caused many fiber cuts. But Qwest's name >seems to show up with unusual frequency in the last year. Here are the >ones I found in my notes. > >Milwaukee-to-Chicago May 4, 1999 >Smyrna, GA March 11, 1999 >Gurnee, IL November 19, 1998 (drilled fiber three times over > a mile) > >Anyone have notes about others? I have a vague recollection of a couple >of more, but couldn't find them in my notes. > >I don't know who Qwest is hiring to bury its fiber, but I would like >to call on Qwest to conduct an immediate stand-down until it can review >its fiber installation practices, training and supervision with its >contractors. Including review of safe digging/drilling practices around >other providers' fiber. >-- >Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation

1 0

Re: unexpected generousity
by Sean Donelan 16 Nov '00

16 Nov '00

I guess its been long enough since the last time that folks have gotten lax with their filters. Filtering default, loopback, etc should be in every peer's BGP configuration whether you trust them or not. Who do you blame, the fool who announces default to the world, or the world for listening to it. Every router I know has enough memory and processing power to filter the basic (updated) martian list. This was a preventable accident. On Tue, 14 November 2000, Randy Bush wrote: > what am i misunderstanding here > > route-views.oregon-ix.net>sh ip bg 48.0.0.0 > BGP routing table entry for 0.0.0.0/0, version 27074 > Paths: (1 available, best #1) > Not advertised to any peer > 3333 5597 > 193.0.0.56 from 193.0.0.56 (193.0.0.56) > Origin IGP, localpref 100, valid, external, best

2 1

Re: fibre map database
by Sean Donelan 16 Nov '00

16 Nov '00

On Wed, 15 November 2000, Ran Atkinson wrote: > At 19:40 15/11/00, Sean Donelan wrote: > >The NCS supposedly has a database showing all AT&T, MCI, Sprint, > >and LEC fiber routes in the country so when the Pentagon orders > >diverse circuits to a missle silo, they know if it is really diverse. > > Chuckle. And they probably think it is accurate > and complete, too. :-) That's why they have HF radios and satellites :-) No one is safe. Yep, NORAD had their "diversely routed, triple-redundant" cables cut in the past too. I asked one of the major credit card processing companies how they do maintain diversity. The answer, they have an inhouse department whose full-time job is verifying the route diversity of their circuits because they haven't had much luck relying on carriers to deliver. Its not a matter of paying for it, or having enough money. They have a lot of money, and still can't get reliable diversity. I do not know of any way to order a circuit, and have an assurance it will remain physically diverse for the life of the circuit. You must constantly monitor it, regularly audit it, and keep NTP records so you can tell when the speed of light changes on the circuit. And even then you can't be sure because the carriers' own records often aren't accurate enough to tell if the circuit is physically diverse.

1 0

Re: Level 3 problems - was Re: Uunet to Level 3 San Jose peering problems?
by Sean Donelan 16 Nov '00

16 Nov '00

> Someone should start a database, where you enter information of where a > fiber cut took place, what end points were effected, and start building > correlations. That might be somewhat interesting. Russia, Iraq, North Korea, or who ever is the designated rogue country this week probably has a copy; but us network engineers aren't allowed to see it. The NCS supposedly has a database showing all AT&T, MCI, Sprint and LEC fiber routes in the country so when the Pentagon orders diverse circuits to a missle silo, they know if it is really diverse. But that doesn't help for the new carriers, with cheap bandwidth, which much of the Internet seems to use.

2 1

Re: 10.x.x.x networks
by Eliot Lear 16 Nov '00

16 Nov '00

Michael Long wrote: > I've been having a friendly arguement with some friends at work about > wheather it's right or wrong to use 10.255.255.0/24 for a network. > Technically it should work, but during our conversations we keep coming > back to best practiced IP schemes. I'm wondering what others think about > this. Is using 10.255.255.0/24 and possibly the reverse 10.0.0.0/24 bad > practice? Although this should work, I would recommend that before someone use either of these addresses (and in particular 10.0.0.0/24) please consider how many other networks with that address exist. Without getting into the whole renumbering argument again on nanog (#include <flame.h>), if you are able to choose a portion of 10/8 space with some amount of randomness you can reduce the potential for conflicts in those cases where two private networks need to merge. -- Eliot Lear lear(a)cisco.com

1 0

Qwest to pay $350 million for fiber cut( Re: PSINet outage?)
by Sean Donelan 16 Nov '00

16 Nov '00

On Wed, 15 November 2000, max_smetannikov(a)ziffdavis.com wrote: > Is anybody else hearing about PSINet having a major outage that is > affecting Internet and e-mail traffic all along eastern seaboard? MS It was a fiber cut. And carriers are getting very serious about fiber cuts. In Austin a jury ordered Qwest to pay over $350 million to AT&T for repeatedly cutting a fiber optic line. http://biz.yahoo.com/apf/001115/cut_cable_.html Also, I'll be moderating a panel at the Underground Damage Prevention conference at the end of November in Boston with representatives from a couple of carriers on protecting against Internet fiber cuts. http://www.damageprevention.com/ If any carriers have a story about what a great job they are doing, I would love to include a mention of it at the panel. I have lots of horror stories, but I would love to announce some successes. So far the only success story I have is from Sprint, who had 61 fiber cuts last year, but only one of them affected traffic. http://www3.sprint.com/PR/CDA/PR_CDA_Press_Releases_Detail/1,1694,857,00.ht… If you are doing something great, I want to mention it.

2 1

Re: [doable?] peer filtering (was Re: Trusting BGP sessions)
by Sean Donelan 15 Nov '00

15 Nov '00

On Wed, 15 November 2000, john heasley wrote: > > great, that must be why these problems dont occur. which solution are > you using? i'm not flinging s*!@ over the fence; i'm truely interested. If the problem is truely no router vendor make a router capable of holding a fully filtered route table we need to tell the router vendors this is a mandatory requirement or we won't buy their routers. Remember, once upon a time when no router could handle more than 30,000 routes or 64,000 routes. Once the router vendors were told what was needed, they built a box to meet that need. It is not a given that no router will never support filtering a full tier-1 ISP's route table. Its just no one has made it a requirement. Lets make it a requirement of the router vendors.

4 3

RE: [doable?] peer filtering (was Re: Trusting BGP sessions)
by Mathew Butler 15 Nov '00

15 Nov '00

If I'm understanding, Sean's suggesting a two-tier system: 1) Providers tell each other, in an administratively-verifiable manner, what routes they have authorization to announce; 2) From moment to moment, the routes that come in across BGP are filtered on a provider-by-provider basis against the information that was shared in the administratively-verifiable manner. The 'administratively verifiable manner' could be a registry, or it could be an automated mailing list that all network operators could subscribe to that required digital signatures on each update, or it could be anything else. The simplest form would be a registry that only accepted secure updates from the people authorized to update their part of it, and a registry oversight that ensured compliance with Internet and legal policy. (i.e., "No one is allowed to advertise routes through their network to other networks unless they have a routing or peering relationship with the other networks in question." and, "Routing and peering relationships between networks shall be noted in this registry.") My personal belief is that there needs to be one person at each network operations center who knows (and is told) everything about what's going on related to this, and should have a large percentage of his/her time blocked out to "Maintaining Internet Routing Relationships" -- and that it should become a matter of course that if this function is not performed properly, that tertiary and carrier networks should not be held responsible for filtering out any routing based on 'stale data' (in this case, we could define 'stale data' to be 28 days old, or some arbitrary number). This would require, of course, the ability for a 'registry refresh' command to be issued by an organization's Routing Liaison to update the last-checked times for -all- entries owned by that organization. It would also require the ability for that title to arbitrarily change hands. (The larger issue is, "can a Registry be created such that it is easy enough to use that people will be willing to use it, that it is responsive enough to advertise changes in a quick manner, that is flexible enough to understand and take action on all the non-standard problems that people will come up with, and which is able to be legally and contractually bound to perform those duties in an accountable fashion?") -Mat Butler -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Wednesday, November 15, 2000 2:51 PM To: akyol(a)akyol.org Cc: nanog(a)merit.edu Subject: Re: [doable?] peer filtering (was Re: Trusting BGP sessions) No I'm not suggesting basing it on what a provider is currently advertising. But rather on what the provider has registered and is authorized to announce. The set of authorized routes may be the same or a superset of what the routes the provider is currently announcing. If you want asymetric routes, you can register and authorize traffic via either route; and then dynamically announce which route you want to use moment to moment. On Wed, 15 November 2000, "Bora Akyol" wrote: > If I understand you correctly, you want to filter inbound traffic from a > service provider to another based on what that service provider is > advertising and based on the decision process that we run. > > How do you suggest we handle asymmetric routes? > > Bora > > ----- Original Message ----- > From: "Sean Donelan" <sean(a)donelan.com> > To: <heas(a)shrubbery.net> > Cc: <nanog(a)merit.edu> > Sent: Wednesday, November 15, 2000 2:05 PM > Subject: Re: [doable?] peer filtering (was Re: Trusting BGP sessions) > > > > > > On Wed, 15 November 2000, john heasley wrote: > > > > > > great, that must be why these problems dont occur. which solution are > > > you using? i'm not flinging s*!@ over the fence; i'm truely interested. > > > > > > If the problem is truely no router vendor make a router capable of > > holding a fully filtered route table we need to tell the router vendors > > this is a mandatory requirement or we won't buy their routers. Remember, > > once upon a time when no router could handle more than 30,000 routes or > > 64,000 routes. Once the router vendors were told what was needed, they > > built a box to meet that need. > > > > It is not a given that no router will never support filtering a full > > tier-1 ISP's route table. Its just no one has made it a requirement. > > > > Lets make it a requirement of the router vendors. > > > > > >

1 0