- Test - lists.nanog.org

Re: whois changes
by owen＠DeLong.SJ.CA.US 17 May '99

17 May '99

Absolutely, but I think this brings up a bigger issue... This is basically another attempt by NSI to claim they own the data contained in WHOIS. This concerns me much more than the arbitrary and cavalier way they make changes. Owen > You agree that you will not reproduce, sell, transfer, or > modify any of the data presented in response to your search request, or > use of any such data for commercial purpose, without the prior > express written permission of Network Solutions. > > > > The verbage change broke my script, only because of sloppy programming on my > part, but.... Since whois'es sometimes close before you get the entire > report, I needed a way to know I got the entire message. > > This effect anyone else? Anyone else in favor of a "HEADS-UP" from > networksolutions before these take place? :) > > > Kevin Day > DragonData > >

3 2

Re: Is anyone actually USING IP QoS?
by Vadim Antonov 17 May '99

17 May '99

Pete Kruckenberg <pete(a)kruckenberg.com> wrote: >The presentations I've seen about QoS implementations have >all seemed to contain major sections about how the networks >had to work around problems or scale back the implementation >because of resource limitations (CPU, memory, etc). Haven't >seen anyone implement RSVP on a wide scale, due to similar >types of problems. It is painfully obvious that RSVP cannot be implemented on a large scale for years now for reasons having to do more with fundamental properties of algorithms (i.e. complexity) than with particulars of protocols or implementations. RSVP - perpetuum mobile of 90s? :) >Sounds like QoS is marketing material, >not the stuff networks are built on. Is that still the case? Yep. Altough not _all_ QoS schemes are broken-as-designed. The most trivial per-packet priority combined with ingress priority mix shaping works. Ths idea of end-to-end whatever reservations or guarantees is usually propounded by people who either neglected their CS courses or those who are trying to sell it. >How the heck are people able to deploy native-IP networks >with these kinds of limitations/problems with QoS? Or did I >miss something about QoS recently? Yep. The biggest QoS secret is that nobody actually needs it. Bandwidth is cheap and is growing cheaper. The manpower needed to deploy and maintain QoS is getting more and more expensive. --vadim

1 0

NANOG - Question format suggestion
by Rodney Joffe 17 May '99

17 May '99

At previous NANOGs, people who have been watching via mbone and whatever other flavors of broadcast were working have had to make comments/ask questions via the NANOG list, or by emailing a friend with connectivity in the meeting. This also holds true for the ietf stuff as far as I remember. As we know, the NANOG list takes a looooong time to distribute, by which time the subject matter the question relates to, and/or the session is long since forgotten. I'd like to suggest that at each session the NANOG organizers identify an email address or irc channel of some kind that is monitored by the moderator for remote questions... /rlj CenterGate Research Group http://www.centergate.com "Technology so advanced, even *we* don't understand it"

4 3

Smurf attack from AS1717
by Henry R. Linneweh 17 May '99

17 May '99

the attack was without warrant. and started: 11:42:53 AM: Dial-Up Adapter [0000][Ref# 2] Blocking incoming ICMP: src=193.51.125.253, dst=206.173.231.208, type 0. and ended at: 11:43:10 AM: Dial-Up Adapter [0000][Ref# 2] Blocking incoming ICMP: src=193.49.21.7, dst=206.173.231.208, type 0. generating 9486 lines from AS1717 inetnum: 193.51.125.0 netname: FR-SHSNET6 descr: LISH - CNRS descr: Laboratoire d'Informatique pour les Sciences de l'Homme descr: 54 Boulevard Raspail, F-75006 PARIS, France country: FR admin-c: Jean-Louis Leonhardt tech-c: Philippe Leca remarks: RERIF changed: rensvp(a)urec.fr 940928 source: RIPE Your probe of 193.49.21.7/24 yielded the following results: Network: 193.49.21.0, Netmask: 255.255.255.0, Broadcast: 193.49.21.255, Responded: Yes (broadcast=4, network=0), Duplicates: 3 CONCLUSION: This network is a potential smurf amplifier. id: 1025582 created: 1998-10-23 17:13:24 CET updated: 1999-05-16 21:01:34 CET network: 193.49.21.0/24 net-descr: not-analyzed last-probed: 1999-05-16 21:17:04 CET responding: Yes duplicates: 3 (highest seen, resets to 0 when 0 seen) fixed: never home-as: 1717 as-descr: not-analyzed ====================================== Your probe of 193.51.125.253/24 yielded the following results: Network: 193.51.125.0, Netmask: 255.255.255.0, Broadcast: 193.51.125.255, Responded: Yes (broadcast=44, network=0), Duplicates: 43 CONCLUSION: This network is a potential SEVERE smurf amplifier. id: 1025926 created: 1998-10-23 19:55:46 CET updated: 1999-03-19 13:06:37 CET network: 193.51.125.0/24 net-descr: not-analyzed last-probed: 1999-05-16 21:18:19 CET responding: Yes duplicates: 45 (highest seen, resets to 0 when 0 seen) fixed: never home-as: 1717 as-descr: not-analyzed

2 1

Is anyone actually USING IP QoS?
by Pete Kruckenberg 17 May '99

17 May '99

There is so much hype and marketing going on about IP QoS these days, it's hard to tell what's /just/ hype and marketing and what's actually in production. I'm wondering if anyone is actually using any of the IP QoS features offered by various vendors in a production environment. I'm particularly interested to know if the famed replacement of ATM QoS features (basic stuff, like prioritization, traffic policing and traffic shaping, sustained and peak rates) has happened in a native IP network (ie POS or IP over PtP circuits), particularly one that runs multiple services (like some real-time stuff like voice, video, streaming, and some non-real-time stuff). There have been a lot of announcements and rumors about this kind of stuff (like Enron Communications PureIP network, Convergent's fully-Cisco [possibly L3] network, Level3's IP-only network, etc), but so far it seems like the only people running native IP on their network don't need QoS at the level that ATM provides, or aren't running any QoS. And it seems like anyone who has built/is building a multi-service network is using ATM because of the QoS issues, amongst other things. The presentations I've seen about QoS implementations have all seemed to contain major sections about how the networks had to work around problems or scale back the implementation because of resource limitations (CPU, memory, etc). Haven't seen anyone implement RSVP on a wide scale, due to similar types of problems. Sounds like QoS is marketing material, not the stuff networks are built on. Is that still the case? How the heck are people able to deploy native-IP networks with these kinds of limitations/problems with QoS? Or did I miss something about QoS recently? Pete.

2 1

5/16 Ameritech exchange maintenance completed
by Mark A. Cnota 16 May '99

16 May '99

Just a quick follow-up: The maintenance scheduled for this morning has been successfully completed. Customers who find any problems which may be related to this activity should call the Ameritech NOC at 800.972.3441. thanks, -Mark >Delivered-To: nanog-outgoing(a)merit.edu >X-Sender: mcnota(a)mailhost.chi.ameritech.net >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 >Date: Sat, 15 May 1999 09:36:37 -0500 >To: nanog(a)merit.edu >From: "Mark A. Cnota" <mcnota(a)ameritech.net> >Subject: 5/16 maintenance: Ameritech exchange >Sender: owner-nanog(a)merit.edu >X-Loop: nanog > > >Hello everyone, > >Just a quick reminder- Ameritech's ATM exchange point will be undergoing >maintenance this weekend. The planned window is 12:00 am to 6:00 am >(Central Time) tonight (Sunday May 16th). All customers of this exchange >will experience an interruption in service during this window. I would >suspect many others may experience some indrect effects as well. Ameritech >customers are welcome to e-mail me privately with any questions. > >thanks, > >-Mark

1 0

Re: whois changes
by joe＠vpop.net 16 May '99

16 May '99

Yes, I can *guess* what the handle is. The point is that you can't get it via whois. You can *guess* that it $domain$x-DOM, but where is this documented? And why turn 2 whois queries into at least 3? A whois on a domain should at least return the handle - you think? -joe On Sat, 15 May 1999 18:02:26 -0700 (PDT), Andrew Doane <adoane(a)best.com> wrote: >wasn't very hard... -- NewsHub: http://www.NewsHub.com/tech/ | MultiTrace: http://www.MultiTrace.com/ | Explore Your Net! DomainSurfer: http://www.DomainSurfer.com/ |

2 1

Re: IXC Fiber cut Michigan
by Sean Donelan 16 May '99

16 May '99

hcb(a)clark.NET (Howard C. Berkowitz) writes: >Is this another argument for SONET rings and against tree structuring? It is an argument for diversity. SONET rings offer diversity against certain failure modes, but they too have other types of interesting failures. SONET failures tend to be more complex, and so far seem to take much, much longer to fix than a simple fiber cut. SONET rings have several good points. What is not good is thinking the buzzword "SONET" as uttered by salespeople (and some engineers) means more than it actually is. Automatic Protection Switches exist in the copper world too. Phone companies have been selling APS systems for decades, they still have trouble actually delivering on those promises. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: IXC Fiber cut Michigan
by Sean Donelan 16 May '99

16 May '99

Jared Mauch <jared(a)puck.Nether.net> writes: > IXC Ticket number 86537 Well, this fiber cut interrupted service between MICHNET's router at AADS and the rest of Merit/MICHNET. The problem for me was the michnet router was still advertising it could reach the rest of michnet, and therefore traffic (such as nanog mail) went into the IXC fiber blackhole until I could manually re-route through somewhere else. Of course, everyone else who was in the same boat, won't see this message until the circuit is restored. > the Sean/Claus FTL sled was NOT seen in the area. I can neither confirm nor deny access to Mr. Kringle's sled. Any sign of Qwest contractors in the area? :-) -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 6

Mbone receivers
by john heasley 15 May '99

15 May '99

anyone on the mbone have a moment or two to help test multicast connectivity in preparation for nanog in Eugene? preferrably, dvrmp/mbone and native mcast. i am sourcing some video in a session called 'heasley test'. the path is behind AS2914 to AS10888 for dvrmp. native for those who we mbgp with at paix, pennsauken, or ames mix's. Session Name: heasley test Description: testing native mc Group: 0.0.0.0, ttl: 0, Contiguous allocation: 1 Lifetime: from 18:00:00 UTC May 15 1999 until 18:00:00 UTC May 18 1999 Uptime: 02:50:31, Last Heard: 00:04:05 Announcement source: 205.238.1.71, destination: 224.2.127.254 Created by: heas 3135780259 3135780345 IN IP4 pita.shrubbery.net Phone number: heasley 503-641-6313 Email: heasley <heas(a)shrubbery.net> URL: Media: video 57672 RTP/AVP 31 Media group: 224.2.224.8, ttl: 127 tia. -heas

2 1