- Test - lists.nanog.org

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

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

04 Aug '00

g.root-servers.net is returning NXDOMAIN for all .com domains, and in fact the com zone itself. This causes all access to all of .com to fail, mail to bounce, and much woe overall. Is there a more appropriate channel for reporting problems of this sort? If so, perhaps that information could be posted at http://www.root-servers.net or in another intuitive place. .net domains seems to be ok. ~$ host -t ns msrl.com 192.112.36.4 msrl.com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) ~$ host -t ns google.com 192.112.36.4 google.com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) ~$ host -t ns yahoo.com 192.112.36.4 yahoo.com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) ~$ host -t ns root-servers.net 192.112.36.4 root-servers.net NS ns.ripe.net root-servers.net NS ns-ext.vix.com !!! root-servers.net NS host ns-ext.vix.com does not exist root-servers.net NS rs0.internic.net ~$ host -t ns com. 192.112.36.4 com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) -- Shields.

8 9

UUNET DALLAS <-> HOUSTON fubar
by John M . Brown 04 Aug '00

04 Aug '00

from what I can tell it seems that UUNET in Dallas,Houston is not doing well today. Any other data points on the net ?? Via verio link to dallas traceroute to www.uunet.net (199.170.0.30), 30 hops max, 40 byte packets 1 abq-rtr-01 (206.29.128.1) 0.675 ms 0.571 ms 0.413 ms 2 209-75-129-189.verio-wan-abq.verio.net (209.75.129.189) 2.623 ms 2.446 ms 6.282 ms 3 d3-3-0.r00.dllstx01.us.bb.verio.net (129.250.16.97) 51.483 ms 50.206 ms 50.343 ms 4 ATM3-0.BR1.DFW9.ALTER.NET (137.39.23.221) 51.204 ms 51.148 ms 51.079 ms 5 140.at-5-0-0.XR1.DFW9.ALTER.NET (152.63.98.122) 64.602 ms 51.599 ms 51.360 ms 6 * * * 7 * 132.at-5-0-0.TR1.DCA6.ALTER.NET (152.63.2.173) 569.456 ms * 8 * * 287.at-4-0-0.XR1.DCA1.ALTER.NET (152.63.33.213) 565.894 ms 9 195.ATM8-0-0.GW2.DCA1.ALTER.NET (146.188.161.33) 549.414 ms * 486.788 ms 10 * mas2-gw.customer.alter.net (157.130.82.118) 532.248 ms 533.614 ms via CW link to bloomington (I re-pref'd our traffic) traceroute whois.arin.net traceroute to whois.arin.net (192.149.252.22), 30 hops max, 40 byte packets 1 abq-rtr-01 (206.29.128.1) 0.553 ms 0.413 ms 0.412 ms 2 bordercore2-serial5-0-0-6.Bloomington.cw.net (166.48.176.25) 33.267 ms 27.469 ms 27.404 ms 3 corerouter1.Bloomington.cw.net (204.70.9.147) 34.783 ms 28.046 ms 27.738 ms 4 ATM1-0.BR1.LAX9.ALTER.NET (137.39.23.213) 394.744 ms 368.382 ms 411.652 ms 5 154.at-5-0-0.XR2.LAX9.ALTER.NET (152.63.113.22) 63.784 ms 63.977 ms 72.872 ms 6 190.ATM2-0.TR2.LAX2.ALTER.NET (152.63.112.218) 85.574 ms 79.273 ms 57.300 ms 7 111.ATM7-0.TR2.DCA8.ALTER.NET (146.188.138.197) 96.181 ms 95.849 ms 95.805 ms 8 196.at-4-0-0.XR2.TCO1.ALTER.NET (152.63.32.209) 96.515 ms 95.716 ms 95.763 ms 9 192.ATM6-0.GW5.TCO1.ALTER.NET (146.188.162.165) 100.648 ms 96.039 ms 95.927 ms 10 arin-gw.customer.ALTER.NET (157.130.35.6) 100.158 ms 99.815 ms 99.580 ms 11 rs2.arin.net (192.149.252.22) 102.249 ms^C

1 0