- Test - lists.nanog.org

MCI outages
by William Allen Simpson 25 Jun '97

25 Jun '97

Well, we could talk about the repeated outages of MCI.... Last Thursday and again on Sunday, I saw all my traffic between myself in Michigan and my client in Mississippi going to Atlanta and a black hole, instead of via Houston and Memphis. This went for several hours before I called MCI NOC. I used to think the MCI NOC did an exemplary job. I guess that was when they were using BBN. Unfortunately, nowadays, IP address of routers are meaningless. They want "circuit numbers". Of course, I have no idea what _their_ circuit numbers are. Heck, I don't pay any attention to those under my control. The end result was they refused to take a trouble ticket, even though it was clearly their mis-routing problem. They did admit that there might be maintenance going on in the middle of a Sunday afternoon. The excuse was that "I'm not a direct customer on either end". Heck, even my next level up service provider isn't a direct customer. Long gone are the days when folks cooperated to resolve trouble reports. And has anyone else noticed a heck of a lot of route flapping between MCI and PSI, also through Atlanta? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: MCI outages
by sob＠academ.com 25 Jun '97

25 Jun '97

MCI reported to us in Houston that they had a bad card in one of their core routers here during the time you mentioned. The only way we knew about it was to call the NOC. Fortunately, we are a direct customer. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: logging systems/software
by jprovo＠ma.ultranet.com 25 Jun '97

25 Jun '97

> does anyone have any particular favorites for reasonable cost > logging/tracking systems for trouble reports, outage reports, customer > service problems, and complaints (such as might be received about spam > at an abuse address)? Here's a vote for RUST, the redesign of multireq, out of U of Utah CS. The direct decendant of NEU's req, it offers a lot of what a genuine job/trouble-tracking system needs to give to the people that will use it. It isn't very good for a managerial oversight of the 'call-duration' style, but for getting things done in-between shifts and distributed staff, it gets my solid vote. See ftp://ftp.cs.utah.edu/pub/rust. Current version is RUST v1.0b6pl0, from May 21, 1997. Cheers, -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: MCI outages
by James A. Farrar 24 Jun '97

24 Jun '97

At 06:02 PM 6/24/97 GMT, William Allen Simpson wrote: >Well, we could talk about the repeated outages of MCI.... Ok. > >Last Thursday and again on Sunday, I saw all my traffic between myself >in Michigan and my client in Mississippi going to Atlanta and a black >hole, instead of via Houston and Memphis. This went for several hours >before I called MCI NOC. Perhaps you would like to share exactly what you told the MCI NOC and what their response was? (offline of course, where it should be) BTW: I would also be interested in knowing the source and destination addresses you were having problems with. > >I used to think the MCI NOC did an exemplary job. I guess that was when >they were using BBN. Thank you, I will ignore the second sentence. > >Unfortunately, nowadays, IP address of routers are meaningless. They >want "circuit numbers". Of course, I have no idea what _their_ circuit >numbers are. Heck, I don't pay any attention to those under my control. Yes, circuit numbers usually determine if a person is a customer of provider X or Y that is calling to utilize provider Z's resources. Generally, it is a good practice to inquire about problems with the service provider that provides you services. > >The end result was they refused to take a trouble ticket, even though >it was clearly their mis-routing problem. They did admit that there >might be maintenance going on in the middle of a Sunday afternoon. > Perhaps an emergency maintenance was happening as a result of an unforeseen outage as I doubt a large service provider would schedule maintenance on a Sunday afternoon. >The excuse was that "I'm not a direct customer on either end". Heck, >even my next level up service provider isn't a direct customer. > The last time I recall MCI uses their customers circuit ID to open a service inquiry with. They generally don't open tickets for non customers that can't get to www.xyz.com although, my experience is that they are generally receptive to a notification of a possible problem that may be occurring within their network. >Long gone are the days when folks cooperated to resolve trouble reports. > I respectfully disagree with that statement. >And has anyone else noticed a heck of a lot of route flapping between >MCI and PSI, also through Atlanta? > Does this mean you think MCI's use of the Cisco default for route dampening should be adjusted? >WSimpson(a)UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 >BSimpson(a)MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > -jim

1 0

Re: PacBell
by Justin W. Newton 24 Jun '97

24 Jun '97

At 08:54 AM 6/24/97 -0700, Curt Howland wrote: > >> On Jun 24, Curt Howland <howland(a)conxion.com> wrote: >> >> > Not everyone you might want to peer with on the West Coast >> > is at the PAIX. >> >> Right, the PAIX by itself wouldn't be enough (though the >> lighting is really cool); but with the PAIX /and/ MAE-West? >Coverage might reach whatever % of the 'net you're looking >for with the PAIX and Mae-East alone, but that's not my major >criteria for choosing exchange points. >So maybe the question comes back to, "is everyone you want to peer >with on the West coast at the PAIX?" MAE /West/ Curt, MAE /West/ :). (We'll also bet at MAE East, btw, but that wasn't the point). Basically, I believe what JD wanted to know is whether or not traffic /is/ flowing better over PacBell NAP than it is through the others, and to which provider(s) it seems that the traffic is flowing better over that exchange, at this time. ********************************************************* Justin W. Newton voice: +1-415-482-2840 Senior Network Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net Director At Large, ISP/C http://www.ispc.org "The People You Know. The People You Trust." *********************************************************

1 0

Re: logging systems/software
by Joseph C. Pistritto 24 Jun '97

24 Jun '97

>Date: Tue, 24 Jun 1997 10:34:33 -0700 >To: richard welty <welty(a)balltown.cma.com> >From: "Joseph C. Pistritto" <jcp(a)pointcast.com> >Subject: Re: logging systems/software > >At 12:27 PM 6/24/97 -0400, you wrote: > >Well, there are two products I'm familiar with: > Remedy - which is not low cost, but is designed to do exactly what you're doing. In fact they used it a couple of years ago for InteropNet, (which is where I got experience using it). Not inexpensive, but a pretty mature system that lots of people use. Has web capabilities as well. > > There's also a "bug tracking" system named "Visual Intercept" that runs on NT and Windows machines. We use it at PointCast extensively for bug tracking. I think it can probably be used for what you want to do too (since it's just keeping track of problems in a database). One good thing is the schema is open, so you can run scripts against the SQL database it's using (we use it on NT's SQL Server). You can check out the web site at http://www.elsitech.com/. This is definately lower cost than the "big ones" like Remedy, Scopus, or Vantive, and requires a lot less administration. > > -jcp- > >>i'll take advantage of the relative quiet to ask quick (and hopefully >>non-controversial) question... >> >>does anyone have any particular favorites for reasonable cost >>logging/tracking systems for trouble reports, outage reports, customer >>service problems, and complaints (such as might be received about spam >>at an abuse address)? >> >>we need to select something here soon, as we're going to actually be in >>business shortly. >> >>thanks, >> richard (soon to be welty(a)inet-solutions.net) >>

1 0

Re: logging systems/software
by Tony Tauber 24 Jun '97

24 Jun '97

On Jun 24, 12:27pm, richard welty wrote: > Subject: logging systems/software > i'll take advantage of the relative quiet to ask quick (and hopefully > non-controversial) question... > > does anyone have any particular favorites for reasonable cost > logging/tracking systems for trouble reports, outage reports, customer > service problems, and complaints (such as might be received about spam > at an abuse address)? > > we need to select something here soon, as we're going to actually be in > business shortly. > > thanks, > richard (soon to be welty(a)inet-solutions.net) >-- End of excerpt from richard welty You might try digging around in: http://netman.cit.buffalo.edu/Products.html which seems to have pointers to lotsa stuff. Tony

1 0

Re: logging systems/software
by Tony Tauber 24 Jun '97

24 Jun '97

On Jun 24, 12:27pm, richard welty wrote: > Subject: logging systems/software > i'll take advantage of the relative quiet to ask quick (and hopefully > non-controversial) question... > > does anyone have any particular favorites for reasonable cost > logging/tracking systems for trouble reports, outage reports, customer > service problems, and complaints (such as might be received about spam > at an abuse address)? > > we need to select something here soon, as we're going to actually be in > business shortly. > > thanks, > richard (soon to be welty(a)inet-solutions.net) >-- End of excerpt from richard welty You might try digging around in: http://netman.cit.buffalo.edu/Products.html which seems to have pointers to lotsa stuff. Tony

1 0

Re: logging systems/software
by Joseph C. Pistritto 24 Jun '97

24 Jun '97

>Date: Tue, 24 Jun 1997 10:34:33 -0700 >To: richard welty <welty(a)balltown.cma.com> >From: "Joseph C. Pistritto" <jcp(a)pointcast.com> >Subject: Re: logging systems/software > >At 12:27 PM 6/24/97 -0400, you wrote: > >Well, there are two products I'm familiar with: > Remedy - which is not low cost, but is designed to do exactly what you're doing. In fact they used it a couple of years ago for InteropNet, (which is where I got experience using it). Not inexpensive, but a pretty mature system that lots of people use. Has web capabilities as well. > > There's also a "bug tracking" system named "Visual Intercept" that runs on NT and Windows machines. We use it at PointCast extensively for bug tracking. I think it can probably be used for what you want to do too (since it's just keeping track of problems in a database). One good thing is the schema is open, so you can run scripts against the SQL database it's using (we use it on NT's SQL Server). You can check out the web site at http://www.elsitech.com/. This is definately lower cost than the "big ones" like Remedy, Scopus, or Vantive, and requires a lot less administration. > > -jcp- > >>i'll take advantage of the relative quiet to ask quick (and hopefully >>non-controversial) question... >> >>does anyone have any particular favorites for reasonable cost >>logging/tracking systems for trouble reports, outage reports, customer >>service problems, and complaints (such as might be received about spam >>at an abuse address)? >> >>we need to select something here soon, as we're going to actually be in >>business shortly. >> >>thanks, >> richard (soon to be welty(a)inet-solutions.net) >>

1 0

Internet Routing Instability paper
by Rob Malan 24 Jun '97

24 Jun '97

We finished our camera-ready copy of our paper this weekend, and would like to share it with a larger audience. Vern's annoucement reminded us to get this note out. You can find a copy of the paper: "Internet Routing Instability" to appear in Sigcomm '97 at the IPMA website: http://www.merit.edu/ipma/analysis/ -Rob - The abstract follows: Internet Routing Instability Craig Labovitz, G. Robert Malan, and Farnam Jahanian. Proceedings of the ACM SIGCOMM '97 Conference, September 1997; Cannes, France. This paper examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this paper, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this paper is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.

1 0