June 1997 - NANOG - lists.nanog.org

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

paper on analyzing packet traces of TCP behavior available
by Vern Paxson 24 Jun '97

24 Jun '97

[My apologies to those of you who will receive multiple copies of this announcement from other mailing lists ...] The paper "Automated Packet Trace Analysis of TCP Implementations", to appear in SIGCOMM '97, is now available from: ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.Z I've appended the abstract. Vern Automated Packet Trace Analysis of TCP Implementations Vern Paxson Network Research Group Lawrence Berkeley National Laboratory vern(a)ee.lbl.gov We describe "tcpanaly", a tool for automatically analyzing a TCP implementation's behavior by inspecting packet traces of the TCP's activity. Doing so requires surmounting a number of hurdles, including detecting packet filter measurement errors, coping with ambiguities due to the distance between the measurement point and the TCP, and accommodating a surprisingly large range of behavior among different TCP implementations. We discuss why our efforts to develop a fully general tool failed, and detail a number of significant differences among 8 major TCP implementations, some of which, if ubiquitous, would devastate Internet performance. The most problematic TCPs were all independently written, suggesting that correct TCP implementation is fraught with difficulty. Consequently, it behooves the Internet community to develop testing programs and reference implementations.

1 0

paper on end-to-end Internet packet dynamics available
by Vern Paxson 24 Jun '97

24 Jun '97

[My apologies to those of you who will receive multiple copies of this announcement from other mailing lists ...] The paper "End-to-End Internet Packet Dynamics", to appear in SIGCOMM '97, is now available from: ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z I've appended the abstract. Vern End-to-End Internet Packet Dynamics Vern Paxson Network Research Group Lawrence Berkeley National Laboratory vern(a)ee.lbl.gov We discuss findings from a large-scale study of Internet packet dynamics conducted by tracing 20,000 TCP bulk transfers between 35 Internet sites. Because we traced each 100 Kbyte transfer at both the sender and the receiver, the measurements allow us to distinguish between the end-to-end behaviors due to the different directions of the Internet paths, which often exhibit asymmetries. We characterize the prevalence of unusual network events such as out-of-order delivery and packet corruption; discuss a robust receiver-based algorithm for estimating ``bottleneck bandwidth'' that addresses deficiencies discovered in techniques based on ``packet pair''; investigate patterns of packet loss, finding that loss events are not well-modeled as independent and, furthermore, that the distribution of the duration of loss events exhibits infinite variance; and analyze variations in packet transit delays as indicators of congestion periods, finding that congestion periods also span a wide range of time scales.

1 0