October 2002 - Test - lists.nanog.org

Re: UUNET Routing issues
by Petri Helenius 04 Oct '02

04 Oct '02

> > In my experience, TCP deals better with packet loss than a jittery RTT > (caused by huge buffering capability on linecards) > Unfortunately most people writing up SLAs have RTT measured as a very long average (so a little bouncing around does not matter) but have quite low packet loss targets. So they are biased towards large buffering to achive near-zero loss. Obviously the best option is to offer different classes of service, one providing constant latency with loss if neccessary and one providing minimal loss with excessive buffering. Pete

1 0

IPv4 country of origin
by Ralph Doncaster 04 Oct '02

04 Oct '02

I would like to restrict access from certain countries to content on my network (for security and legal reasons). So far the best algorithm I've been able to come up with is a combination of reverse DNS and APNIC/ARIN/RIPE whois queries. I've written a perl cgi that checks reverse DNS first, and if there is no gtld country code for the reverse mapping, does a whois query and parses the response for the address. The problem I have is that the country for the company that owns the IP block is sometimes not the country the IP block is used in. For example sungold22.de.ibm.com 194.196.100.86 Whois parsing indicates a country of UK, but from the reverse DNS a person can see that it is Germany. I've built the pattern of cc.ibm.com into my cgi, but I'm sure there are other blocks that I'm incorrectly identifying. I've looked at RADB entries, as well as origin AS for various IP blocks, and neither source looks any better than whois. Is there a more accurate method to determine the country of origin for an IP than the methods I've described above? -Ralph

12 23

wierd problem
by Mitchell S. Baltuch 04 Oct '02

04 Oct '02

I have a client who is having a problem with DNS. Most everyone can reach their web sites and send email, except those on attbi.com and rmi.net. For those people, dns lookups fail approximately 50% of the time. The domain used to be owned by someone who use rmi.net to host the domain. As far as I can tell, the gTLD servers return a correct response, and every other ISP appears to resolve the domain correctly. I have had no luck talking to ATT and RMI (earthlink) support (no surprise there). Any ideas how to diagnose this further. Thanks, Mitch -- Mitchell S. Baltuch Principal MountainStorm Technologies 806 W. 127th Court Westminster, CO 80234 303/324-8128 mbaltuch(a)mountainstorm.com http://www.mountainstorm.com

2 1

The Cidr Report
by cidr-report＠potaroo.net 04 Oct '02

04 Oct '02

This report has been generated at Fri Oct 4 20:32:37 2002 AEST. The report analyses the BGP Routing Table of the Route-Views router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-09-02 122059 87644 28-09-02 123673 89338 29-09-02 123700 89158 30-09-02 123661 89486 01-10-02 123327 89413 02-10-02 124542 90028 03-10-02 124827 89771 04-10-02 124944 88633 Possible Bogus Routes 39.0.0.0/8 AS4554 EP0-BLK-ASNBLOCK-4 Exchange Point Blocks AS Summary 14015 Number of ASes in routing system 5367 Number of ASes announcing only one prefix 2193 Largest number of prefixes announced by an AS AS209 : ASN-QWEST Qwest 72696064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Oct02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 124806 88707 36099 28.9% All ASes AS209 2193 1142 1051 47.9% ASN-QWEST Qwest AS4999 1028 132 896 87.2% SPRINTIPDIAL Sprint AS174 1824 1234 590 32.3% PSINET PSINet Inc. AS7132 595 73 522 87.7% SBIS-AS Southwestern Bell Internet Services AS3908 1115 610 505 45.3% SUPERNETASBLK SuperNet, Inc. AS701 1786 1284 502 28.1% ALTERNET-AS UUNET Technologies, Inc. AS2548 1586 1123 463 29.2% ICIX-MD-AS Business Internet, Inc. AS7018 1366 960 406 29.7% ATT-INTERNET4 AT&T WorldNet Services AS1221 1305 937 368 28.2% ASN-TELSTRA Telstra Pty Ltd AS4323 648 298 350 54.0% TW-COMM Time Warner Communications, Inc. AS7843 715 385 330 46.2% ADELPHIA-AS Adelphia Corp. AS3215 626 305 321 51.3% AS3215 France Telecom Transpac AS852 762 461 301 39.5% ASN852 Telus Advanced Communications AS6197 390 98 292 74.9% BATI-ATL BellSouth Network Solutions, Inc AS18566 291 4 287 98.6% COVAD Covad Communications AS7046 579 304 275 47.5% UUNET-CUSTOMER UUNET Technologies, Inc. AS6347 358 88 270 75.4% DIAMOND SAVVIS Communications Corporation AS4151 280 32 248 88.6% USDA-1 USDA AS1580 319 85 234 73.4% HQ, 5th Signal Command AS1 672 449 223 33.2% GNTY-1 Genuity AS4814 255 35 220 86.3% CHINANET-BEIJING-AP China Telecom (Group)Beijing Telecom CompanyBeijing China AS705 407 197 210 51.6% ASN-ALTERNET UUNET Technologies, Inc. AS1239 849 651 198 23.3% SprintLink Sprint AS4355 382 184 198 51.8% ERMS-EARTHLNK EARTHLINK, INC AS22927 215 20 195 90.7% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS690 518 325 193 37.3% NSFNET-T3-RT-AS Merit Network Inc. AS6595 250 66 184 73.6% DODDSEUR DoD Education Activity Network Assistance Center AS3356 378 211 167 44.2% LEVEL3 Level 3 Communications, LLC AS1791 184 21 163 88.6% SPRINTLINK3 Sprint Government Systems Division AS6327 180 19 161 89.4% SHAWFIBER Shaw Fiberlink Limited Total 22056 11733 10323 46.8% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Monitoring Bandwidth (transfer) in GB / MB
by Ryan White 04 Oct '02

04 Oct '02

I have been trying to search for a way to monitor customers bandwidth transfer usage by GB. I have not found any method to do this with rrdtool or mrtg. I could definitely be missing an industry term that I should search for since google does not return anything useful. Does anyone have a list or recommendation for such a tool? ----------------------------- Ryan White Niuhi, Inc.

3 2

Thanks! Re: Re: Root DNS Server Issues?
by John Neiberger 04 Oct '02

04 Oct '02

Thanks to everyone who helped me out and I hope you don't mind me making a fool of myself. :-) I (and others that I work with) learned quite a lot from your responses to this little incident. If I have to be a little bit foolish to learn something valuable, then so be it! <g> Thanks again, John

2 1

Re: wcom
by sgorman1＠gmu.edu 03 Oct '02

03 Oct '02

The details can be found here: http://www.matrixnetsystems.com/ea/advisories/20021003_instant_alert.jsp ----- Original Message ----- From: Ian A Finlay <iaf(a)andrew.cmu.edu> Date: Thursday, October 3, 2002 3:31 pm Subject: wcom > > I know, I know, don't believe everything you read... ;-) > > http://www.msnbc.com/news/816663.asp?0dm=C15MT > > "Struggling WorldCom Inc., one of the major backbone providers of > networksthat route traffic over the Internet, suffered a major > commercial Internet > outage beginning at 8 a.m. EDT on Thursday, according to a company > thatmonitors Internet performance." > > Article goes on to state the reason was a "software glitch". > > FWIW, > Ian > > >

5 4

Re: Security Practices question
by Barb Dijker 03 Oct '02

03 Oct '02

>I was assuming a more complex configuration than the wide-open one >advocated by Barb, which seems to add little to no security benefit. > >I'm sorry I wasn't clear on this point; of course pushing out a single >file to n machines shouldn't be a problem. Of course. And a complex sudoers setup can be in a single sudoers file distributed to thousands of hosts. The sudoers syntax allows for as much or as little complexity as suits your needs. ...Barb

1 0

Re: Security Practices question
by Michael Lamoureux 03 Oct '02

03 Oct '02

"eddy" == E B Dreger <eddy+public+spam(a)noc.everquick.net> writes: jm> Date: Wed, 2 Oct 2002 17:48:16 -0700 (PDT) jm> From: just me jm> In an environment where every sysadmin is interchangable, and any jm> one of them can be woken up at 3am to fix the random problem of jm> the day, you tell me how to manage 'sudoers' on 4000 machines. eddy> krb5/ksu Well, no. That's an excellent answer to someone else's question, but krdist would be a better answer to his question. ;-) But the real answer is: The same way you maintain everything else on the same 4000 machines. I assume if you're running 4000 machines you have some cookie-cutter secured baseline OS load that gets installed on them all when they're loaded, and then something like home-grown perl scripts wrapped around rdist or rsync, or a specific tool for the purpose like cfengine or synctree to push out changes and keep them all under control. I would assume that the sudoers file could be pushed out with the same mechanism. Or am I missing some implied complexity in your situation? If the implication is that you have 4000 one-off machines, I retract my next statement. ;-) BTW, I really envy "just me". I have yet to work anywhere where every [insert position here] is actually interchangable. Must be nice. IMHO, Michael

2 1

RE: wcom
by Mike Damm 03 Oct '02

03 Oct '02

IMO, quite possibly a 'who'. >From http://www1.worldcom.com/us/tools/maintmsg/: During the normal operations window on Thursday, October 3rd, 2002, WorldCom will be performing maintenance in the following cities: DOMESTIC: Atlanta, GA(ATAN, ATL1, ATL3, ATL4, ATL5); Boston, MA(BOS1, BOS6); Buffalo, NY(BUF1); Chicago, IL(CHI1, CHI2, CHI6); Cleveland, OH(CLE1); Washington, DC(DCA1, DCA6, DCA8, WASD); Denver, CO(DEN4); Detroit, MI(DET1); Dallas, TX(DFW7, DFW9); Newark, NJ(EWR1, EWR3); Kernersville, NC(GSO1); Houston, TX(HOU4, HOU7, HSN); Ashburn, VA(IAD6); Indianapolis, IN(IND6); Kansas City, MO(KCY1, KCY4); Los Angeles, CA(LAX1, LAX2, LAX4, LAX9); Miami, FL(MIA1); New York, NY(NYC1, NYC3, NYC9); Palo Alto, CA(PAO1); Philadelphia, PA(PHL1); Phoenix, AZ(PHX2); Pittsburgh, PA(PIT1); Sacramento, CA(SAC1); Santa Clara, CA(SCL1); Seattle, WA(SEA1, SEA4); San Francisco, CA(SFO1); San Jose, CA(SJC1, SJC5); Salt Lake City, UT(SLT1, SLT4); Saint Louis, MO(STL2); Vienna, VA(TCO1) --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Jim Popovitch [mailto:jimpop@rocketship.com] Sent: Thursday, October 03, 2002 12:54 PM To: Randy Bush Cc: nanog(a)merit.edu Subject: RE: wcom > -----Original Message----- > From: Randy Bush > Sent: Thursday, October 03, 2002 3:47 PM > > more measurement sans insight or analysis. sadly a popular > sport, though neither operations or research. > > what *caused* the outage? > Outages like that are more likely to to be caused by a "who" rather than a "what". ;) -Jim P.

1 0