- NANOG - lists.nanog.org

Smurf Woes
by Jason Weisberger 08 Feb '99

08 Feb '99

If anyone has had any success with CAR as a Smurf suppressant, can you drop me some email - I want to compare some notes. -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275 Friends applaud, the comedy is over. --Ludwig van Beethoven's last words. d.1827

1 0

NIC database/whois
by Becki Kain 08 Feb '99

08 Feb '99

anyone else noticed the NIC "losing" a set of domain registrations, around the time of January 11 (during their "speculator" issues), where the NIC took the modify, modified the domain, then reset it to it's previous settings (from January 9)? also, is there a way to do the old "whois server <server NIC name>" to show everything a server is registered for? I can't seem to get that to work, no matter what whois I try. thanks beckers Becki Kain beckers(a)furph.com -- furph, Inc. WWW/Unix/Windows Solutions 734-513-7763 (voice) info(a)furph.com http://www.furph.com 734-513-7759 (FAX)

2 1

Re: Discussing, or not discussing, major business outages
by George Herbert 07 Feb '99

07 Feb '99

Dave Rand writes: >>George Herbert: >> I would like to see the issue discussed in general terms >> at least; what is appropriate for notifications, what are >> fair responsibilities to customers, the public, other ISPs etc. >> in terms of this sort of event. > >As has happened in the past, it is my opinion that the techincal contacts >for that organization should step forth at the appropriate time with >details. This may, in fact, be after connectivity has been lost. >Often, last minute negotations can restore services with only a momentary >outage. No one but the people directly involved should be aware of this, >for business reasons. Sometimes, business go through tough times for >reasons beyond their control. No reflection on the technical abilities of >the people involved - but just business. The reason I asked the question is that I have been bit today by a series of 4 outages (all completely unrelated to the provider I referred to which is going out of business) from unrelated ISP links or business-critical systems of which at least 2, probably 3 should have resulted in proactive notifications or at least prompt reactive warnings to the customers/users and neighboring parties, and such notifications and warnings did not happen. I am now passing 13 hours of work today in reaction to those events. This has made me extremely sensitive to this sort of issue today. This provider which went out of business apparently has, in fact, cut off lines and forced customers to move (though not all of them) at this time, though I do not have firsthand knowledge of this. They are off the net completely as far as I am able to tell (though I could be wrong... I am busy fighting my own fires, and things may be more up than I can see right now). I agree that this is no reflection on the technical abilities of the people involved. It is, as Dave says, just business, and not all businesses succeed. But there is ethical responsibility to operate, and if it comes to that cease operations, in a manner that provides for minimal trouble for your customers, suppliers, and other related businesses. There appears to be a tendency for the "right time" to talk, as judged by the ISPs which are shutting down, to be woefully late. It is business, but business in a way that can significantly affect operational issues and stability. >I'm certain that others would like to see the insides of every company >exposed at all times. While it may be important to the customers, or >potential customers, it should be a part of the diligence of the customer to >inspect the worthiness of their supplier. >I'm equally certain that the providers in question will step forward at >the appropriate time to establish facts. Obviously, most businesses need to operate with careful limits on public disclosure, because operational issues are often of competitive importance and it's very easy to lose significant amounts of money via trivial information leaks. But that does have its limits. -george william herbert gherbert(a)crl.com I do not work for CRL nor speak for it.

2 1

Why the temptation for dial users to crank back rwin/mtu?
by mcmanus＠appliedtheory.com 07 Feb '99

07 Feb '99

Hi Folks, As we know[1], packet sizes on the network fall almost exclusively into one of 4 categories: Small (<50 byte) dataless packets.. tcp acks/syns/rsts.. 576 byte packets 1500 byte packets runt packets less than sender MTU.. It's always been my belief that the 576 values were generated by hosts that didn't support Path MTU discovery and wanted to be conservative and avoid fragmentation. Fair enough.. but, as I'm sure everybody knows, there's a plethora of website/utilities ([2],[3],[4],[5],[6],..) imploring windows dial users to use any one of a number of tools/techniques to play with their mtu/rwin settings to 'make things faster'.. In typical windows fashion nothing is quantified in any meaningful fashion and the only motivation provided is typically some garbage like "windows comes setup for LAN not internet use".. these tools tend to crank down both rwin and mtu an awful lot. apparently there's some performance value in this (at least to the immediate user) because they keep doing it in droves. It's not obvious to me why the heck this would be. (warning: I am a protocol guy, but I'm not a dialup guy at all.. and even less of a windows guy) MTU - at least this makes a little bit of sense.. If they're doing HTTP/1.0 stuff with parallel connections then a smaller MTU is going to make that parallelization latency much more effective and perceived performance will go up some.. it doesn't impact full document retrieval time though (at least not positively!).. are dial links really lossy enough that chopping the segment size to 1/3 is a big win in retransmit time or are the win95/98 stacks really braindead enough that they don't do pmtud so are just trying to dodge fragmentation? I found it really odd that [7] which I use all the time to track features in a myriad of shipped OS's actually has a blank entry for pmtud on both of those (neither yes nor no..) RWIN - this is the one that boggles my mind.. it gets set way way way down by the above mentioned tools.. I've seen it as low as 2500 bytes recently. Anyone have any insight into the value of pushing this all the way down? The web pages generally mumble about capping the amount of data that needs to be resent in case of a failure.. which is of course true in the extreme case, but I'd much rather have the congestion window providing the throttle than the hard-limit of rwin that can just cap transfer rates on you.. about the only reason I can think of for small RWINs is to conserve the buffer space, but it sure seems worth a few K to me to be sure I can work with high latency links. You could argue that 3 or 4 K is sufficient for any reasonable latency that is bottlenecked by a modem's throughput.. and eventually I might give in (or maybe not ;)).. what I don't get is why this results in any kind of perceived performace increase on the part of the user under any condition.. It almost implies that TCP congestion control is too conservative, although almost all work on that indicates it's a little too aggressive (which would be the side to err on..) Any thoughts? -P [1] http://www.caida.org/Papers/Inet98/ [2] http://www.cerberus-sys.com/~belleisl/tune_faq/tuning.htm [3] http://www.trumpet.com.au/wsk/faq/config.htm [4] http://www.mc-pro.com/hardware/windialup.shtml [5] http://www0.delphi.com/pccompat/mtu.html [6] http://www.pattersondesigns.com/tweakdun/index.html [7] http://www.psc.edu/networking/perf_tune.html

3 3

Re: Discussing, or not discussing, major business outages
by dlr＠bungi.com 07 Feb '99

07 Feb '99

[In the message entitled "Discussing, or not discussing, major business outages" on Feb 6, 23:06, George Herbert writes:] > > I would like to see the issue discussed in general terms > at least; what is appropriate for notifications, what are > fair responsibilities to customers, the public, other ISPs etc. > in terms of this sort of event. > As has happened in the past, it is my opinion that the techincal contacts for that organization should step forth at the appropriate time with details. This may, in fact, be after connectivity has been lost. Often, last minute negotations can restore services with only a momentary outage. No one but the people directly involved should be aware of this, for business reasons. Sometimes, business go through tough times for reasons beyond their control. No reflection on the technical abilities of the people involved - but just business. I'm certain that others would like to see the insides of every company exposed at all times. While it may be important to the customers, or potential customers, it should be a part of the diligence of the customer to inspect the worthiness of their supplier. I'm equally certain that the providers in question will step forward at the appropriate time to establish facts. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

The Cidr Report
by Tony Bates 05 Feb '99

05 Feb '99

This is an auto-generated mail on Fri Feb 5 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 05Feb99 0) General Status Table History ------------- Date Prefixes 290199 55694 300199 55734 310199 55712 010299 55847 020299 55793 030299 55899 040299 55881 050299 55641 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4500 Number of ASes announcing only one prefix: 2232 (1187 cidr, 1045 classful) Largest number of cidr routes: 353 announced by AS701 Largest number of classful routes: 881 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Feb99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 386 140 246 63.7% BCnet Backbone AS2493 315 169 146 46.3% iSTAR Internet, Inc. AS174 656 541 115 17.5% Performance Systems International AS11305 115 13 102 88.7% UNKNOWN AS3749 158 66 92 58.2% TECNET AS1267 111 30 81 73.0% IUNET-AS AS4755 152 72 80 52.6% Videsh Sanchar Nigam Ltd. India AS4293 211 140 71 33.6% IMCI AS7046 273 207 66 24.2% UUNET-CUSTOMER AS4200 161 99 62 38.5% AGIS (Apex Global Information Ser AS4740 389 328 61 15.7% Ozemail Pty Ltd (ASN-OZEMAIL) AS1221 405 345 60 14.8% AARNET-AS AS701 881 825 56 6.4% Alternet AS1239 529 474 55 10.4% SprintLink Backbone AS7657 142 90 52 36.6% The Internet Group Limited AS72 89 37 52 58.4% Schlumberger Information Network AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS10928 100 50 50 50.0% UNKNOWN AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS719 452 407 45 10.0% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 173 135 38 22.0% AGT Advance Communication AS803 72 36 36 50.0% SaskNet Backbone AS6897 64 28 36 56.2% Global-One Spain AS7745 39 4 35 89.7% BIGSKY-AS AS7122 112 77 35 31.2% MTS ADVANCED Network Policy AS6332 98 64 34 34.7% TELNOR AS2764 334 301 33 9.9% connect.com.au pty ltd AS4307 32 1 31 96.9% SVINET-1 For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

NANOG 15 - Wacky Paparazzi Pics
by Craig A. Haney 05 Feb '99

05 Feb '99

URL-> http://seamless.kludge.net/nanog/15 Pics include: ------------- - SkyCache Gang http://seamless.kludge.net/nanog/15/jpg/19990202-11.jpg - Breaking into the Qwest NOC http://seamless.kludge.net/nanog/15/jpg/19990202-05.jpg - Microsoft attends NANOG, Port in progress http://seamless.kludge.net/nanog/15/jpg/19990202-27.jpg - Trialing the @HOME official download counter (non-caching) http://seamless.kludge.net/nanog/15/jpg/19990202-19.jpg - @HOME employee goes to Jail http://seamless.kludge.net/nanog/15/jpg/19990202-31.jpg - Sprint caught in the act of Private Peering with Microsoft http://seamless.kludge.net/nanog/15/jpg/19990202-34.jpg - SPRINT drives employees to loony farm http://seamless.kludge.net/nanog/15/jpg/19990202-30.jpg - Police Line-up in the Vault...who is guilty? http://seamless.kludge.net/nanog/15/jpg/19990202-33.jpg Enjoy.

1 0

Re: spam whore, norcal-systems.net
by Dean Anderson 05 Feb '99

05 Feb '99

At 11:45 AM 2/3/1999 -0800, Dan Hollis wrote: >On Wed, 3 Feb 1999, Dean Anderson wrote: >> Unless of course the publicity is that Verio can't be trusted to keep >> private information private. Or that the publicity is that Verio thinks it >> can use any private information that passes through it to its own ends. > >Now we see Dean's true motives. It isnt legal issues at all, but rather >smear campaigns of people he doesnt agree with. Calling me pro-spam is a smear. Smearing is when you switch from argument to hateful or false labeling. Smearing attempts to avoid the issues by name calling. Privacy laws were passed that apply to Verio. They apply to everyone. They apply to you, too. Smear all you want. It doesn't change that. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: Data Collection and Statistics Analysis
by John Zollo 04 Feb '99

04 Feb '99

Thanks for your feedback! The only problem is Concord is pretty expensive -- something like $100K I think. I should've specified that in my original post, along with the fact that the reason I need the percentile data is to be able to compute fees for bursts above a baseline amount of traffic. I'm not /that/ familiar with concord, but I don't think there's an easy way to integrate it with a billing system of some sort. Is there anything else you can think of? thanks! john On Thu, 4 Feb 1999, James Regovich wrote: > Concord Communications has Network Health that provides very comprehensive > analysis of networks, including frame and ATM. It's a pricey package, but > well worth it. > > You can get a sample analysis of your network at > http://www.concord.com/checkup.htm and a demo of the reports at > www.comcord.com/webdemo/start_here.htm > > This is the most detailed and comprehensive package I have seen. > > Jim Regovich > Sprint Internet Service Center > (703) 689-7049 > jamesr(a)sprint.net > > <For security, this message encoded using double-rot13> > > On Thu, 4 Feb 1999, John Zollo wrote: > > > > > I'm trying to find an application that will SNMP poll my routers > > and calculate statistics a little more complicated than the simple > > average in MRTG. For instance, other than a mean average, I'd like to > > see a break-up in percentiles -- especially the top percentiles. Does > > anyone have any suggestions of a program that will do this? By the way, > > I'd like to stick to UNIX for the polling and analysis platform. > > > > Thanks in advance for any help!!! > > John Zollo > > > > > > > > > > > > > >

1 0

Data Collection and Statistics Analysis
by John Zollo 04 Feb '99

04 Feb '99

I'm trying to find an application that will SNMP poll my routers and calculate statistics a little more complicated than the simple average in MRTG. For instance, other than a mean average, I'd like to see a break-up in percentiles -- especially the top percentiles. Does anyone have any suggestions of a program that will do this? By the way, I'd like to stick to UNIX for the polling and analysis platform. Thanks in advance for any help!!! John Zollo

1 0