- NANOG - lists.nanog.org

RMON probes .vs. sniffer
by Peter Giza 27 Jun '97

27 Jun '97

Has/Is anyone using Axon, NetMetrix etc, or evaluated these tools as a replacement for a sniffer? We're trying to decide whether to buy one or the other. The HP product provides a lot of nice graphs etc, but how practical is it for diagnostics and monitoring for intrusion etc. TIA -pete -- --/ Peter E. Giza || Technical Consultant || ADSmart Corporation fone 508.684.3609 || phax 508.684.3618 || page 800.632.1746 || http://www.adsmart.net /--

2 1

RE: Keynote/Boardwatch Internet Backbone Index A better test!!!
by Peter Cole 27 Jun '97

27 Jun '97

I would like to see the test run again with the following change. >From each provider test the response time of the other 28 sites and not the providers own web server. Then average the response times for these other 28 web servers and report that average response time from that provider. The providers with good connectivity to the rest of the net should have lower average response time. P.S. One might also be interested in the top one hundred web sites average response time. Peter Cole of Telescan, Inc. (281)588-9155 Better computing through lack of sleep. > ---------- > From: Golan Ben-Oni[SMTP:bnite@tremere.ios.com] > Sent: Thursday, June 26, 1997 3:53 PM > To: nanog(a)merit.edu > Subject: Keynote/Boardwatch Internet Backbone Index > > For shits and grins: > > http://www.keynote.com/measures/backbones/backbones.html > > -Golan >

1 0

Keynote/Boardwatch Internet Backbone Index
by Golan Ben-Oni 27 Jun '97

27 Jun '97

For shits and grins: http://www.keynote.com/measures/backbones/backbones.html -Golan

3 2

RE: Internet Backbone Index
by Chris A. Icide 27 Jun '97

27 Jun '97

Interesting enough, Take this little tidbit. The methodology in general was performance testing of the backbone's web site. (Which in itself is probably an accurate measurement goal for the level of subscribers to that magazine) However, Nap.Net's web site was sitting behind a Fractional T1 off of our chicago node while the web page was being overhauled during this test period. So, the rating for Nap.Net reflects a Fractional (actually 22 channels) T1 performance. This is interesting in the light that Nap.Net still scored above the average and the median. Chris ---------- From: Sean Donelan[SMTP:SEAN@SDG.DRA.COM] Sent: Thursday, June 26, 1997 5:34 PM To: nanog(a)merit.edu Subject: Internet Backbone Index I guess it was only a matter of time. The Keynote/Boardwatch Internet Backbone Index http://www.keynote.com/measures/backbones/backbones.html I'm not going to comment on the methodology flaws, but it does show what will fill the information gap. I do like the line "The world's fastest network provides good service to its users only if it does a good job of connecting to the rest of the Internet." Unfortunately I don't think this study really shows that. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

4 3

Re: Keynote/Boardwatch Internet Backbone Index A better te
by Mark Borchers 27 Jun '97

27 Jun '97

Jack, I think you've stated for yourself the reason that this Index has drawn some criticism. By it's name it purports to be an index of backbone speed or backbone congestion or a combination of the above. Not only is it not really an index of these items, it could further be argued that there's not even any reliable way to draw conclusions about backbone performance from the Keynote measurements. As you say, there are many other variables. So why not give this thing a name that reflects it's real identity as an end-to-end test from the Keynote Perspective Agent locations to various WWW servers. > This assumes that you consider web server location and web server > performance to NOT be a part of overall network performance. Our view > steps back a bit from that. The majority of traffic would appear to be > webcentric. From an end users perspective, what does a web site on a > specific network look like and how does that compare to a web site on > another network? There are ENDLESS variables contributing to that > including intercity links, hub architecture, host hardware, host software, > peering, connectivity points with other networks, transit agreements, type > of routers, ATM switching (or not). All contribute. We think most people > notice Internet performance (or lack thereof) while viewing world wide web > pages.

1 0

Internet Backbone Index
by Sean Donelan 27 Jun '97

27 Jun '97

I guess it was only a matter of time. The Keynote/Boardwatch Internet Backbone Index http://www.keynote.com/measures/backbones/backbones.html I'm not going to comment on the methodology flaws, but it does show what will fill the information gap. I do like the line "The world's fastest network provides good service to its users only if it does a good job of connecting to the rest of the Internet." Unfortunately I don't think this study really shows that. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: MCI outages (summary)
by James A. Farrar 27 Jun '97

27 Jun '97

At 02:32 AM 6/26/97 GMT, William Allen Simpson wrote: >To summarize private reports, MCI NOC lost a fair number of its top >technical staff when they "consolidated" their customer oriented NOCs >into a single unit last year. Now, the folks answering the phone aren't >well trained in Internet; instead they are telco oriented. I noticed >that, too. > > >> ... we don't do >>maintenance in the middle of a sunday afternoon, unless of >>course, you were in australia at the time. >> >That explains why it took half a day to fix your routing problem. >Maintenance shift must come on duty around 10 pm EDT, eh? > border1.hsn#sh clock 20:47:57.710 EDT Thu Jun 26 1997 border1.hsn uptime is 4 days, 4 hours, 39 minutes >And, of course, you've seen the note that you had a router down in >Houston at about those times. Must be official policy not to "admit" >outages. > MCI has an outage list that one may subscribe to if they wish to be notified of events that may affect the Internet community. You should inquire with your service provider about that, thanks. > 4) traceroutes clearly showed that it was an MCI problem. Please forward the trace route in order to further assist you. > > 5) call MCI NOC with information. > > 6) get shrugged off with a recommendation that I send my problem to > trouble(a)mci.com. This would be amazing if it were not so incredibly > stupid, since it was my inability to get my email that brought the > problem to my attention. > <trouble(a)mci.net> would actually be the correct address should you wish to provide some information, thank you. > >>you expect our >>front line noc to know you by name? > >Goodness gracious, while that personal touch can be pleasant, it is not >required. But, I do expect them to have an idea what the IP addresses >of their own routers are, and not have to go on hold to find out about >traceroutes.... > Perhaps you should ensure you are actually calling MCI's NOC, thanks. > >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 Regards, Jim Farrar MCI Internet Operations

1 0

Re: PSI woes
by James A. Farrar 27 Jun '97

27 Jun '97

At 03:01 AM 6/26/97 GMT, William Allen Simpson wrote: >> From: dlr(a)bungi.com (Dave Rand) >> Is anyone else having routing problems with PSI? >> >I don't talk directly to PSI, but Morningstar/Ascend does, and I see the >peering between MCI and PSI drop for hours on a regular basis. I find >that the "host unreachable" comes from either #5 or #7 below: > Interesting sir, perhaps you could share what is considered "a regular basis"? Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State 206.157.77.50 4 174 442930 1122979 77754087 0 0 2w6d I will tell you that some /24 announcements are flapping however, I will not waste the time of the individuals on this list to get into that under this forum. Again, if you wish to discuss your concerns offline, my offer to assist you is still open however, you haven't offered much data at this point to be of use. I have not received your source and destination addresses of reported trouble nor any offline communication as of yet for that matter. > 5: 192.203.195.5 cpe3-fddi-1.WillowSprings.mci.net. (109 ms) (109 ms) (107 ms) > 6: 166.48.23.253 bordercore2-hssi1-0.WillowSprings.mci.net. (190 ms) (136 ms) (134 ms) > 7: 204.70.4.9 core3.Atlanta.mci.net. (420 ms) (501 ms) (418 ms) > 8: 206.157.77.50 ast-psi-nap.Atlanta.mci.net. (199 ms) (208 ms) (301 ms) > 9: 38.1.2.5 se2.sc.psi.net. (160 ms) (169 ms) (219 ms) > >Sure would be nice to put the "net" back in Internet. > >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: MCI outages (summary)
by Chris A. Icide 26 Jun '97

26 Jun '97

We've been peering with MCI for a while, and was an MCI customer way back when. It has been my experience that when we make a call to the MCI NOC to report a problem, we have recieved as good (if not better) performance from the NOC as a PEER as we did as a customer. Since I am very happy in the response for all problems that are technical in nature, I would say this is good. However, if the problem in "political" in nature, forget getting any kind of answer from anyone, unless you "know" someone inside. Chris ---------- From: Joe Shaw[SMTP:jshaw@insync.net] Sent: Thursday, June 26, 1997 11:06 AM To: Robert_Gutierrez(a)3com.com Cc: nanog(a)merit.edu Subject: Re: MCI outages (summary) >From what I understand of MCI's peering agreement, you have to come into at least 3 NAPs with DS3 bandwidth or better to even be considered to peer. So, I think if you peer with MCI, you'd definitely carry enough weight with them that they'd take an interest with what problems you have. Joe Shaw - jshaw(a)insync.net NetAdmin - Insync Internet Services "Learn more, and you will never starve." - Paraphrase of Lee On Thu, 26 Jun 1997 Robert_Gutierrez(a)3com.com wrote: > OK, here's a scenario for you. Traceroute fails inside MCI somewhere. So > you > call your upstream, and said upstream only has a peering relationship with > MCI -- ie: not a paying customer. I'm under the impression that unless > you're > a paying customer, then (to quote a 70's phrase) "you don't have nothin' > comin'". > > For those ISP/IBP's out there, can a BGP peer open a trouble ticket with > you to have a problem looked at? Or does the "paying customer" have to > open the TT. What if I can't get the "paying customer" to open up the TT > (ie: you think I can get sex.com to open a TT with their upstream, as if > they > would care longer than the time to hit the "D" key on my message). > > rob > > >

1 0

Re: MCI outages (summary)
by Robert_Gutierrez＠3com.com 26 Jun '97

26 Jun '97

> I think the traceroute fails at this hop. Outages work just like > routing, you pay , X pays MCI, if your not happy you call X, > X calls MCI, if X doesn't call MCI, then why would you buy service from > them? This is the standard operator proceure, if there ever was one. (I hope the formatting is OK. I'm not a Lotus Notes fan ...) OK, here's a scenario for you. Traceroute fails inside MCI somewhere. So you call your upstream, and said upstream only has a peering relationship with MCI -- ie: not a paying customer. I'm under the impression that unless you're a paying customer, then (to quote a 70's phrase) "you don't have nothin' comin'". For those ISP/IBP's out there, can a BGP peer open a trouble ticket with you to have a problem looked at? Or does the "paying customer" have to open the TT. What if I can't get the "paying customer" to open up the TT (ie: you think I can get sex.com to open a TT with their upstream, as if they would care longer than the time to hit the "D" key on my message). rob

4 3