- NANOG - lists.nanog.org

Re: The Year of the Backhoe Continues...
by Randy Bush 02 Dec '97

02 Dec '97

do people really think that the relative fiber cut rate is any higher than in the past? there's a bit more fiber, hence the term 'relative'. but i suspect that the predominant factor is that new victims have a better means of broadcasting their displeasure. randy

4 3

Router problems between 'psp.sk.canet.ca' and 'regional1.sk.canet.ca'
by James Philpott 01 Dec '97

01 Dec '97

See attached trace route for clarity. This is taken from my IP address of 204.29.28.142 while trying to reach 207.195.95.27. As of hop 11 all goes well and then a game of packet Ping-Pong ensues between psp.sk.canet.ca [192.68.63.1] and regional1.sk.canet.ca [192.68.63.101]. Any assistance would be appreciated. This message was already forwarded to 'canet-eng(a)canet.ca'. Regards, James Philpott <><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><> James Philpott jamesp(a)metainfo.com MetaInfo (206)674-3746 http://www.metainfo.com/support/onlineresources.htm <><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><> Sending 48 data bytes to ? [207.195.95.27] 1:Received echo from ? [204.29.28.253] in 0 msec. 2:Received echo from ? [204.29.28.254] in 10 msec. 3:Received echo from milo-s7.wa.com [198.202.20.5] in 10 msec. 4:Received echo from dilbert-fe4-0.wa.com [192.135.191.254] in 170 msec. 5:Received echo from dogbert.nwnexus.com [206.63.0.254] in 20 msec. No data received from intermediate hop. 7:Received echo from core2-fddi-1.Seattle.mci.net [204.70.203.65] in 40 msec. No data received from intermediate hop. 9:Received echo from canet.Seattle.mci.net [166.48.217.254] in 50 msec. 10:Received echo from psp2.bc.canet.ca [205.207.238.133] in 20 msec. 11:Received echo from psp.sk.canet.ca [205.207.238.26] in 50 msec. 12:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 13:Received echo from psp.sk.canet.ca [192.68.63.1] in 61 msec. 14:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 15:Received echo from psp.sk.canet.ca [192.68.63.1] in 60 msec. 16:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 17:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 18:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 19:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 20:Received echo from regional1.sk.canet.ca [192.68.63.101] in 81 msec. 21:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 22:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 23:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 24:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 25:Received echo from psp.sk.canet.ca [192.68.63.1] in 90 msec. 26:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 27:Received echo from psp.sk.canet.ca [192.68.63.1] in 81 msec. 28:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 29:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 30:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 31:Received echo from psp.sk.canet.ca [192.68.63.1] in 130 msec. TraceRoute Statistics for 207.195.95.27 31 packets transmitted, 28 packets received, 9% packet loss round-trip (ms) min/avg/max = 0/65/170

1 0

Router problems between 'psp.sk.canet.ca' and 'regional1.sk.canet.ca'
by James Philpott 01 Dec '97

01 Dec '97

See attached trace route for clarity. This is taken from my IP address of 204.29.28.142 while trying to reach 207.195.95.27. As of hop 11 all goes well and then a game of packet Ping-Pong ensues between psp.sk.canet.ca [192.68.63.1] and regional1.sk.canet.ca [192.68.63.101]. Any assistance would be appreciated. Regards, James Philpott <><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><> James Philpott jamesp(a)metainfo.com MetaInfo (206)674-3746 http://www.metainfo.com/support/onlineresources.htm <><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><!><=><> Sending 48 data bytes to ? [207.195.95.27] 1:Received echo from ? [204.29.28.253] in 0 msec. 2:Received echo from ? [204.29.28.254] in 10 msec. 3:Received echo from milo-s7.wa.com [198.202.20.5] in 10 msec. 4:Received echo from dilbert-fe4-0.wa.com [192.135.191.254] in 170 msec. 5:Received echo from dogbert.nwnexus.com [206.63.0.254] in 20 msec. No data received from intermediate hop. 7:Received echo from core2-fddi-1.Seattle.mci.net [204.70.203.65] in 40 msec. No data received from intermediate hop. 9:Received echo from canet.Seattle.mci.net [166.48.217.254] in 50 msec. 10:Received echo from psp2.bc.canet.ca [205.207.238.133] in 20 msec. 11:Received echo from psp.sk.canet.ca [205.207.238.26] in 50 msec. 12:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 13:Received echo from psp.sk.canet.ca [192.68.63.1] in 61 msec. 14:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 15:Received echo from psp.sk.canet.ca [192.68.63.1] in 60 msec. 16:Received echo from regional1.sk.canet.ca [192.68.63.101] in 60 msec. 17:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 18:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 19:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 20:Received echo from regional1.sk.canet.ca [192.68.63.101] in 81 msec. 21:Received echo from psp.sk.canet.ca [192.68.63.1] in 70 msec. 22:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 23:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 24:Received echo from regional1.sk.canet.ca [192.68.63.101] in 70 msec. 25:Received echo from psp.sk.canet.ca [192.68.63.1] in 90 msec. 26:Received echo from regional1.sk.canet.ca [192.68.63.101] in 80 msec. 27:Received echo from psp.sk.canet.ca [192.68.63.1] in 81 msec. 28:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 29:Received echo from psp.sk.canet.ca [192.68.63.1] in 80 msec. 30:Received echo from regional1.sk.canet.ca [192.68.63.101] in 90 msec. 31:Received echo from psp.sk.canet.ca [192.68.63.1] in 130 msec. TraceRoute Statistics for 207.195.95.27 31 packets transmitted, 28 packets received, 9% packet loss round-trip (ms) min/avg/max = 0/65/170

1 0

Re: Horrible Service Agreements
by Brian Horakh 01 Dec '97

01 Dec '97

>Cryptography can be used to produce non-transferrable keys >allowing some party to send message to a particular recipient. >Messages can include "right to respond" keys. That is a cute idea, you can only email somebody who has emailed you first, unless of course you both like to go ostrich hunting then you can email any fellow ostrich hunters. Of course if i'm a good ole spamming sportin goods store, this is a really convenient way to get a list of all the other ostrich hunters out there so I can sell ostrich hunting supplies. All I have to do is find a message board about ostrich hunting and send 'em all some good ole' spam. Perhaps the legal approach of holding an ISP responsible is a more appropriate (and much more easily accepted method). Let me ask you... Which one is a easier measure, creating legal teeth which ISP's can use against spamming or getting every vendor who produces a SMTP mail product to upgrade to some new Secure-SMTP protocol? Keep in mind it would take the IETF 2 or 3 years before they could even agree on a standard (and that's if Microsoft Exchange div. didn't have their goons on the committee). So by the year 2001 we have a Secure-SMTP mail product that is an IETF standard, now the conversion process... lets be optimistic 1-2 years.. The year is now 2003 ... What sane company would stop receiving non-secure SMTP mail from potential customers? Do you honestly think that all the ISP's in the country are going to stop delivering non-authenticated mail? I can just picture tech support "i'm sorry Granny, you can't receive email from little Johnny who's gone off to college anymore! ! ! because he's not considered trustworthy." .. The Internet doesn't move quick enough to get changes like that implemented within the system, its grown to large, to fast, and is much to rigid. If you don't believe me just look at UUCP (which I think can officially be declared dead? How many sendmail.cf's still allow user!domain(a)smtp.relay.com) If the government takes the time to give ISP's tools to stop the people/companies it will stop 99.9% of the people out there, you will still get the occasional person who will not remove you from a list, or snag addresses from mechanisms such as Usenet and the www. However that .1% won't even be enough to get mentioned on a list such as NANOG. Laws that have harsh punishments, and require financial restitution, combined with the ability to trace back to a specific USER and/or company will almost 99.9% spam free net. It is the ISP's responsibility to respond quickly to user feedback (even from foreign systems), and to properly configure their mailers to be used to relay non-returnable messages. Companies like hotmail, and rocketmail must take measures to make sure their customers are not performing these types of actions (possibly making it more difficult to get accounts, and getting restraining orders on regular offenders). I'm sure as the problem continues to escalate at the phenomenal rate it has lately this problem will solve itself as the companies who COULD stop the problematic users, will begin to find their staff time being consumed, and reputations being sullied. Just my two cents, -Brian Horakh Network Systems Engineer City of Escondido, CA. ! ! !

1 0

NANOG-POST switchover
by Susan R. Harris 01 Dec '97

01 Dec '97

Greetings - just wanted to let you know that we've cut over to the new NANOG posting process. In order to post to NANOG(a)merit.edu, you must also be subscribed to NANOG-POST(a)merit.edu. To subscribe, send e-mail to majordomo(a)merit.edu with 'subscribe nanog-post' (without the quotes) as the text of the message. You will receive a confirmation request; once you respond, you'll be able to post to the NANOG mailing list. --Susan Harris

1 0

Re: User-level ISP performance measurement
by Scott Huddle 01 Dec '97

01 Dec '97

John, Check out Inverse Network Technology. http://www.inversenet.com -scott > From owner-nanog(a)merit.edu Mon Dec 1 15:15 EST 1997 > Date: Mon, 1 Dec 1997 14:50:29 -0500 (EST) > From: John R Levine <johnl(a)iecc.com> > To: nanog(a)merit.edu > Subject: User-level ISP performance measurement > MIME-Version: 1.0 > Sender: owner-nanog(a)merit.edu > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 1422 > > I hope I'm not reopening a huge can of worms here, but ... > > Some of my relatives have started a small ISP in western Vermont. (They > already run the local telco.) They're wondering how to compare the > performance that their users see to the ISPs in the adjacent town. I told > them that there isn't anything published that'll be of much use, since the > stuff I've seen tries to measure backbone performance and for the most part > does so ineptly. > > For user level stuff, it seems to me that you could pick a representative set > of actions (visit large and small web sites, download e-mail, scan > newsgroups), dial in via PPP every hour for a week being sure to flush out > caches and otherwise start from a consistent user state, do the actions, time > them all, and make some simple stats. This would be miserable to do > manually, but pretty straightforward to do automatically. Is there anything > available, either as a product or service, that does this sort of analysis? > > One of the other hats I wear is as a director of a software testing tools > company, and we could certainly whip up this kind of stuff in no time using > our existing products if there were a demand for it. > > Regards, > John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", > Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner > Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47 > >

1 0

User-level ISP performance measurement
by John R Levine 01 Dec '97

01 Dec '97

I hope I'm not reopening a huge can of worms here, but ... Some of my relatives have started a small ISP in western Vermont. (They already run the local telco.) They're wondering how to compare the performance that their users see to the ISPs in the adjacent town. I told them that there isn't anything published that'll be of much use, since the stuff I've seen tries to measure backbone performance and for the most part does so ineptly. For user level stuff, it seems to me that you could pick a representative set of actions (visit large and small web sites, download e-mail, scan newsgroups), dial in via PPP every hour for a week being sure to flush out caches and otherwise start from a consistent user state, do the actions, time them all, and make some simple stats. This would be miserable to do manually, but pretty straightforward to do automatically. Is there anything available, either as a product or service, that does this sort of analysis? One of the other hats I wear is as a director of a software testing tools company, and we could certainly whip up this kind of stuff in no time using our existing products if there were a demand for it. Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47

1 0

Re: The Year of the Backhoe Continues...
by Sean Donelan 01 Dec '97

01 Dec '97

>do people really think that the relative fiber cut rate is any higher than >in the past? there's a bit more fiber, hence the term 'relative'. but i >suspect that the predominant factor is that new victims have a better means >of broadcasting their displeasure. Your tax-dollar at work, I wrote the FCC and asked them this morning. Here is the reply a I got back (very impressive response time, less than 2 hours): "For the five consecutive quarters prior to the Third quarter of 1996, cable outages were higher than they have been since then. Nevertheless there continues to be s significant overall increase in the number of cable outages since the start of outage reporting in the third quarter of 1992. Typically, about half of the cable outages are dig-ups. This information is is an informal estimate and its accuracy is not guaranteed or in any way certified by the FCC. The outage reports we receive are only available in hard copy. The FCC outage database is a rough internal working tool and not suitable for formal distribution, therfore it is not made public." So I think that means the answer to Randy's question is no. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Status: RE: The Year of the Backhoe Continues...
by Bownes, Robert M. (EXCH) 01 Dec '97

01 Dec '97

Wiltel's cable was cut by a front-loader that was in a disposal yard digging outside of their right-of-way (where they should not have been digging). Wiltel is currently locating their hand-holes. They are stretching out a temporary patch cable using 3M mechanical splices to attempt temporary restoration. No ETR at this time. >---------- >From: Nathan Stratton[SMTP:nathan@robotics.net] >Sent: Monday, December 01, 1997 11:52 AM >To: Bownes, Robert M. (EXCH) >Cc: 'nanog(a)merit.edu' >Subject: Re: The Year of the Backhoe Continues... > >On Mon, 1 Dec 1997, Bownes, Robert M. (EXCH) wrote: > >> Just got a note from our NOC... >> >> > >> >Worldcom fiber failure in Dover FL....techs enroute.... >> > >> >249 ds-3's down....ETA for Worldcom tech 10-15 mins >> > >> no ETR > >Is this due to the "fiber upgrade"? > >

1 0

The Year of the Backhoe Continues...
by Bownes, Robert M. (EXCH) 01 Dec '97

01 Dec '97

Just got a note from our NOC... > >Worldcom fiber failure in Dover FL....techs enroute.... > >249 ds-3's down....ETA for Worldcom tech 10-15 mins > no ETR

2 1