August 2000 - NANOG - lists.nanog.org

Re: g.root-servers.net returns NXDOMAIN for com.
by Michael Shields 07 Aug '00

07 Aug '00

In article <27673.965401287(a)ftel.net>, Mark Milhollan <mlm(a)ftel.net> wrote: > >Hence, if you randomly query the one server that is returning NXDOMAIN > >for com, all com lookups will fail. > > This is why BIND 8 has the bogus characteristic, or why one may need to > edit their root hint file. Too bad both require a reload/restart. As well as manual configuration at every resolver on earth. I don't think that's a scalable solution. The root servers need to work. -- Shields.

2 1

RE: [OT] Valley of the Boyz
by Karyn Ulriksen 07 Aug '00

07 Aug '00

I can't speak for other women, but I live technology and science. Both my grandfather's were tinkerers and "crack-pot inventors" and I loved to hang out in their workshops (usually against their will - "why, don't you go make brownies with your grandmother..."). I rebuilt my own volkswagen clear down to the crank shaft when I was 17. Been building out computers since about the same time. Well, I might add. Although tape drives don't do it for me. Tell me I can't do some thing and I'll do it and do it well. I have dreams where everything has a route. Explain the inner workings of circuit boards and chips and I'm all ears. I recently emailed a friend of mine synopsis of a day in my life written entirely in Perl. I find that men generally want to talk about other things with women than technology is the real problem. Men heading for management when they can't cut it? Yeah, well, that happens, too. And it happens often. And they aren't usually very good at it either. I'm here. I'm staying. I'm making your salary or more. Like it or lump it. I didn't stick it out as the only girl in wood shop to hear a bunch of whining from geeks whose ideas of women are at most secretaries. Obviously, the jerk who wrote the article was on the same mental track as those who have posted here to have offered someone like that woman he quoted as a glowing example of womanhood in the tech industry. If there were as many women in the industry as guys, there would probably be an equal number of wooses on both sides. Stop being a bunch of woosies! BTW, the guys I work with are generally great and we exchange data equally. Maybe this isn't true everywhere, but guys CAN be such jerks about the whole women in the tech field thing. But, I'm not much into baking brownies, so get over it. --------------------------------------------------------------------- Best regards, Karyn Ulriksen Director of Network Operations PublicHost, A SiteStream Company 22 Mauchly, Suite 200 Irvine, California 92618 USA Phone: (949) 743-2000 email: kulriksen(a)publichost.com URL: http://www.publichost.com

1 0

Internet disaster plan proposed
by Sean Donelan 07 Aug '00

07 Aug '00

I didn't get to the IETF this time, but apparently the US and Japanese governments asked the IETF to work on an Internet disaster plan. http://www.idg.net/ic_211526_1794_9-10000.html I not really sure I understand what the technical problem is. It seems to be mostly and administrative issue how to use the existing tools.

3 2

[OT] Valley of the Boyz
by John M . Brown 07 Aug '00

07 Aug '00

http://www.cnn.com/2000/TECH/computing/08/03/it.women/index.html

2 1

Re: Strange things which should never happen (was Re: RFC 1918)
by Patrick W. Gilmore 06 Aug '00

06 Aug '00

At 03:15 PM 7/15/00 -0700, Joe Rhett wrote: >> >I don't know my TCP/IP stack well enough, but what happens when a host >> >with multiple interfaces, one of which is assigned an RFC1918 address, >> >receives an packet through another interface with a source address the >> >same RFC1918 address. Are the stacks smart enough to realize the packet >> >is really an external packet, or will they assume the packet came from >> >inside. > >> Nope - at least none of the ones I have seen. > >Hate to disagree, but all modern security-aware OSes can now be configured >to validate which interface a packet should be received on. If the packet >comes from a different interface it is generally dropped. > >In solaris, the option are: > > ip_strict_dst_multihoming > and > ip6_strict_dst_multihoming I was under the impression that hosts only check the *destination* IP address. Feel free to correct me if I am mistaken (as I am sure 472 of you will do :). Sean was asking about packets with a *source* address in a subnet which is on another one of their interfaces. So we are looking at a host which has, for instance, 1.1.1.1/24 on e0 and 2.2.2.2/24 on e1. If a packet hits e0 with a destination address of 1.1.1.1 and a source address of 2.2.2.10, why would the host reject it? The destination address is correct, and the packet was routed to the correct interface. I think Sean is worried about the response to that packet. The host might send the reply/ACK/return/whatever packet out the second interface. If the e1 is addressed with RFC1918 space, and the packet were sourced from an RFC1918 address in another network, the reply would obviously go to the wrong location. If someone knew your internal network well enough, this might even be used as a form of DoS attack. >Joe Rhett Chief Technology Officer TTFN, patrick

2 1

pgh. savvis network outtage
by deeann mikula 06 Aug '00

06 Aug '00

as of about 8am, pittsburgh pa fell off of savvis's network. according to the noc guy i talked to, "this is very serious, and has already been escalated to 2nd and 3rd tier..." i asked him what the story was, and he said that it was a hardware failure at the pgh. pop, affecting 100% of the customers wired into that switch. (altho he didn't say specifically that it was a switch that was broken...) btw, its been down since 8am and its now like 1:30pm and they still don't know anything more. i know who (some) of the other UUnet customers are in pgh., but i don't know any savvis ones. hope this information helps someone out. (they don't have network status page either, so you basically have to call to find this out. kudos for them, though, they apparently left voicemail on my office phone...altho my mobile phone is supposed to be the primary number for notifications, but at least they made an attempt.) deeann m.m. mikula director of operations telerama public access internet http://www.telerama.com

1 0

Looking for network maps/info for South/Central America
by -DAL- 04 Aug '00

04 Aug '00

Hello, I realize this is the North American netops group but is there something similar for Central/South America? Basically I am researching connectivity between various countries in Central and South America, esp. Panama and Ecuador; i.e. who are the providers, how much bandwidth exists between countries. What does the topology look like? T1? T2? OC-3? Which cities have the best connectivity, how are the countries connected etc. I am specifically looking for intra-South/Central America connectivity, e.g. Panama is well connected to Brazil, these cities have the best connectivity... these have the worst... Can anyone point me to some good starting spots to find this type of information? Does this information exist out there? Any help/pointers would be appreciated. thanks! -DAL- -- dylan(a)newdream.net

3 2

Recent issues surrounding g.root-servers.net
by Larson, Matt 04 Aug '00

04 Aug '00

Informational message--Recent issues surrounding g.root-servers.net: On Friday, July 28, g.root-servers.net, operated by DISA, started having trouble reliably loading the com zone. With ICANN's and the DOC's approval, the NSI Registry changed the root zone to replace g.root-servers.net with g.gtld-servers.net in the com, net and org NS RRsets. It was our goal for g.root-servers.net to be answering with current zone data for the full six-day TTL of the com, net and org NS records following the change. That has not proved possible; for example, on Friday morning, August 4, g.root-servers.net loaded and served up a truncated com zone for a few minutes. We have asked DISA to stop loading the com, net and org zones on this server: We believe that it is better for g.root-servers.net to be lame for com, net and org rather than to be giving out bad data. The change to the root zone reflected in serial number 2000080101 will not be fully seen until the end of the six-day TTL. Matt Larson <mlarson(a)netsol.com> DNS Platform Manager Network Solutions Registry / www.nsiregistry.com

1 0

mp3 effect on Internet traffic
by k claffy 04 Aug '00

04 Aug '00

dave plonka has done some outstanding analysis (as rigorous as you can get under the circumstances) on the effect of mp3 files (napster in particular) on the size of Internet flows, for traffic in/out of his university campus (which is a great snapshot to use) http://net.doit.wisc.edu/data/flow/size/ note heavy-tail phenomenon, similar to packet size distributions (where most packets are small but most traffic (bytes) is in huge packets), most flows are still small but most traffic (bytes) are in huge flows more so this year than last year (ymp3k effect) he plots both in terms of units of flows as well as payload, w and w/o napster, this year and last. and yes, he's doing it all using netflow! whee. :) (and publically available cflowd, flowscan, gnuplot, rrdtool, all detailed on the web page) very nice stuff k

1 0

The Cidr Report
by Tony Bates 04 Aug '00

04 Aug '00

This is an auto-generated mail on Fri Aug 4 12:00:00 PDT 2000 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 04Aug00 0) General Status Table History ------------- Date Prefixes 280700 82898 290700 83084 300700 83013 310700 83117 010800 83063 020800 83127 030800 83303 040800 83610 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 *** Bogus 217.8.32.0/20 from AS3220 AS Summary ---------- Number of ASes in routing system: 8086 Number of ASes announcing only one prefix: 4539 (2516 cidr, 2023 classful) Largest number of cidr routes: 929 announced by AS701 Largest number of classful routes: 1086 announced by AS701 1) Gains by aggregating at the origin AS level --- 04Aug00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 435 154 281 64.6% BCnet Backbone AS7046 559 368 191 34.2% COQUI-NET PRTC Internet AS1221 587 433 154 26.2% TELSTRA-AS AS9706 153 30 123 80.4% Pusan Metropolitan City Office of AS2609 128 8 120 93.8% EUnet-TN AS9304 125 16 109 87.2% Hutchcity AS7657 300 192 108 36.0% The Internet Group Limited AS9269 158 57 101 63.9% Hong Kong CTI AS7545 157 58 99 63.1% TPG Internet Pty Ltd AS6429 208 114 94 45.2% FirstCom Internet AS7496 126 38 88 69.8% Power Up AS174 553 467 86 15.6% Performance Systems International AS577 258 173 85 32.9% Bell Backbone AS4293 340 255 85 25.0% Internal ASN for C&W AS705 325 250 75 23.1% ALTERNET-AS AS724 214 146 68 31.8% DLA-ASNBLOCK-AS AS1727 158 90 68 43.0% MRMS-WEST AS6595 118 52 66 55.9% DODDSEUR AS3908 238 172 66 27.7% Supernet, Inc. AS701 1086 1022 64 5.9% Alternet AS4755 160 97 63 39.4% Videsh Sanchar Nigam Ltd. India AS7018 554 492 62 11.2% AT&T WorldNet Service Backbone AS5106 98 36 62 63.3% AADS-COLUMBUS AS816 335 275 60 17.9% UUNET Canada (ASN-UUNETCA-AS4) AS3749 120 61 59 49.2% TECNET AS7568 85 27 58 68.2% C.S. Communications Co., Ltd. AS3602 300 242 58 19.3% Sprint Canada Inc. AS4740 323 270 53 16.4% Ozemail Pty Ltd (ASN-OZEMAIL) AS11252 90 37 53 58.9% Idaho State University AS16758 62 10 52 83.9% UNKNOWN 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