- Test - lists.nanog.org

Re: open relays at Earthlink
by Dean Anderson 28 Aug '98

28 Aug '98

At 02:04 AM 8/26/98 +1000, Adam Todd wrote: >>ISPs sell customers a TCP/IP connection to the Internet. To me that means >>taking my IP datagrams and delivering them to where I address them. I > >UUNET sells connections to users that allows them to deliver packets? Only >problem is so many places block more and more UUNET traffic every day. >Eventually UUNET will have to do something about it's inability to transit >anything except the backbones and it's a pretty lonely world out there on >your own. Yes, it certainly is lonely. You isolate yourselves, too. From purely that point of view, it is the smaller group that harmed the most by isolation. So, are you larger or smaller than UUnet? As I have pointed out numerous times previously, your tactics are fatally flawed and damage the cause more than help it. You're losing your battles, pretty much as I expected, for pretty much the reasons I explained previously. It's too bad. Some spam regulation would be a good thing, I think, but the radicals are making that impossible. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 3

STATUS: Hurricane Bonnie
by Sean Donelan 27 Aug '98

27 Aug '98

I seem to have become the unofficial outage reporter for the Internet. Now that Hurricane Bonnie has been downgraded to a tropical storm, how did the net fair? First things first. So far no reported deaths or serious injuries. There was some rain-fade on microwave and vsat circuits, and a few individual local loop circuits to end-users are down. But no reported backbone or regional affecting outages. The bulk of site outages seems to be related to loss of electrical power at the end-user site, not in the Internet facilities. Bell South had pre-positioned generators at their major central offices. One emergency management agency did loose both commercial power and their backup generator at one point during the storm. During a hurricane, backhoe activity slows down :-) The dangerous time will be during the cleanup efforts as flooding may have unearthed facilities throughout the eastern part of the state. The National Hurricane Center took their web site off the net due to the load it was putting on the rest of their network. This seemed to be a deliberate mitigation act rather than a failure. During the last 24 hours, the only major carrier outage I've seen was on the other coast of the united states. MCI lost a number of circuits in southern California (San Diego/Los Angeles) this morning due to equipment failure. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

SMURF at 203/10
by Terence C. Giufre-Sweetser 27 Aug '98

27 Aug '98

Someone is selectively smurfing 204.70.166.66, by hitting 203.xx.xx.255 where xx.xx is just about every routed piece of 203/10... If you have time, check it, log it, and point a finger at them! TERRY | Terence C. Giufre-Sweetser | 24x7 LINKS : AusBONE | | TereDonn Computer Engineering | ISDN/DDS/PAPL/HDSL/UWAVE | | PO BOX 1054, Spring Hill, QLD 4004 | Phone +61-[0]7-32369366 | | terry(a)tdce.com.au | FAX +61-[0]7-32369930 | | http://www.tdce.com.au | Mobile +61-[0]414-663053 | There is something fascinating about science. One gets such wholesale returns of conjecture out of such a trifling investment of fact. -- Mark Twain

1 0

What is APOPS?
by Barry Raveendran Greene 27 Aug '98

27 Aug '98

Hello Everyone, Got several questions about the APOPS list. It's a mailing list similar to NANOG - but focusing on Asia and Pacific. It's sponsored by APNIC (similar to EOF in Europe). To subscribe - apops-request(a)apnic.net It's majordomo, so do the usually. Barry ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Help Map the Internet - RFC 1876 - http://www.caida.org/Tools/iptll.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Barry Raveendran Greene | || || | Senior Consultant | || || | Corporate Consulting | |||| |||| | Office of the CTO | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | C i s c o S y s t e m s | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PGP Public Key is registered at http://pgp5.ai.mit.edu/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Per-AS average packet sizes.
by Bradley Reynolds 27 Aug '98

27 Aug '98

I was fooling around with low cost (and functional) alternatives to netflow. Using some of the cef per-prefix accounting, I came up with some average packet sizes per-as. I do not know if other pieces of software provide this, but it was interesting to me given the recent debate over traffic/political network engineering. Note: These ASs were chosen because I was looking at aads. Also, some of the average packet sizes (specifically for the universities) are skewed because of small sample size. This data was taken over ~ 3 week period. Report for AS4200 Average Packet Size=207.337627328432 bytes Report for AS6081 Average Packet Size=91.0894051393711 bytes Report for AS4908 Average Packet Size=163.0295230081 bytes Report for AS600 Average Packet Size=185.555733807033 bytes Report for AS3491 Average Packet Size=122.656178436359 bytes Report for AS6172 Average Packet Size=119.599522802812 bytes Report for AS4565 Average Packet Size=101.694844850921 bytes Report for AS3967 Average Packet Size=100.630045695107 bytes Report for AS6502 Average Packet Size=86.1414993563231 bytes Report for AS5696 Average Packet Size=129.799373074708 bytes Report for AS5000 Average Packet Size=815.050455624583 bytes Report for AS3951 Average Packet Size=242.941615947634 bytes Report for AS5646 Average Packet Size=152.496173302478 bytes Report for AS2551 Average Packet Size=230.438698353958 bytes Report for AS4006 Average Packet Size=102.0254851338 bytes Report for AS6402 Average Packet Size=180.478647376678 bytes Report for AS3549 Average Packet Size=78.548229806905 bytes Report for AS10303 Average Packet Size=69.6246769007691 bytes Report for AS6259 Average Packet Size=124.865566859912 bytes Report for AS87 Average Packet Size=295.944768380059 bytes Report for AS3847 Average Packet Size=85.967930320445 bytes Report for AS5762 Average Packet Size=104.255525645514 bytes Report for AS693 Average Packet Size=205.356601218687 bytes Report for AS103 Average Packet Size=451.407999388192 bytes Report for AS160 Average Packet Size=225.945025341309 bytes Report for AS1746 Average Packet Size=354.80284738041 bytes BR

1 0

RE: UUNET Outage in Portland OR
by Kevin Brown 27 Aug '98

27 Aug '98

At 01:47 PM 8/26/98 -0700, Chad Skidmore wrote: >Kind of hard to get accurate and timely information out with that kind of delay! Surely not due to the overwhelming volumes of messages dealing with BBN/Exodus which have suffiently confirmed that many members are email cranks expressing opinions and concepts to which they have little or no facts/involvement. Sure BGP is a relative issue, but the topic of late has dealt with payoffs and billing... not a nanog-ish item. Tis about time for a filter to deal with the BBN/Exodus thread direct to /dev/null.

1 0

Sprint/HiNet
by william＠pacific.net.ph 27 Aug '98

27 Aug '98

Hi all! Whenever we do a traceroute from our Sprint connection to a host in the HiNet network, we get timed out in the Sprint/HiNet link, as follows: Tracing route to w3.hinet.net [168.95.1.82] over a maximum of 30 hops: 1 138 ms 116 ms 113 ms pi-ph-ts01.pacific.net.ph [210.23.234.128] 2 142 ms 111 ms 116 ms pi-ph-gw01.pacific.net.ph [210.23.234.1] 3 332 ms 330 ms 340 ms 204.59.178.25 4 375 ms 324 ms 328 ms 204.59.120.198 5 323 ms 322 ms 339 ms 144.232.1.153 6 380 ms 366 ms 365 ms 144.232.8.70 7 347 ms 373 ms 374 ms 144.232.4.142 8 * * * Request timed out. 9 546 ms 529 ms 523 ms 168.95.253.126 10 540 ms 532 ms 540 ms 168.95.253.189 11 547 ms 556 ms 547 ms w3.hinet.net [168.95.1.82] Trace complete. Line 8 is always like this and a customer of ours is complaining about it. Is this a time out or congestion or something else? William

4 3

Settlements, etc., etc.
by Derek Elder 27 Aug '98

27 Aug '98

I really wanted to stay out of this one, but something that I remembered from a speech made by an FCC bigwig at ISPCON a couple years ago has pushed me over the edge. His (close enough) statement was "At the FCC, the words "regulation" and "Internet" are not allowed in the same sentence of a document." Their word processors were (supposedly) setup as to not allow it. He stated that the FCC intended to use new IP services (VoIP, etc) to help break up foreign communications monopolies. That is why they were keeping their hands off. So the question that I pose is: Do we actually think that if our greed or inability to find a good peering model, forces us into a "pay for what you use" model, the FCC won't change their minds very quickly and decide that they want their piece of the pie after all? Deciding who is more important - the sender or receiver - is worse than maddening. It's impossible. That's why caller pays in the Telco world and they have alot more infrastructure to track those things than we do. Unfortunatly, I think that this is a train out of control and keeping the regulators out at this point is impossible. Knowing GTE's history (i.e., a company that would never have survived without access charges), who's to say that the BBN movements are not a precisely calculated move to -force- regulators to step in? > Derek Elder > US Web Corporation > Senior Engineer > 212-548-7468 > Pager - 888-232-5028 > delder(a)usweb.com > http://www.usweb.com > A Strategic Partner for the > Information Age. > >

2 1

RE: Urrr... A-root server foul ?
by Dave Van Allen 26 Aug '98

26 Aug '98

! ip subnet-zero ! maybe? Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions > -----Original Message----- > From: Havard.Eidnes(a)runit.sintef.no > [mailto:Havard.Eidnes@runit.sintef.no] > Sent: Wednesday, August 26, 1998 3:49 PM > To: rirving(a)onecall.net > Cc: nanog(a)merit.edu > Subject: Re: Urrr... A-root server foul ? > > > > Is anyone else seeing this? > > Yep, once you point us in that direction. > > > really *cool* udp trick, or is bcast space now DNS capable? > > What am I missing? > > 198.41.0.4 can as far as I can see not be a broadcast address > under any left-contiguous netmask, unless it's the 0'th address > on some subnet and the router sitting on the net has the really- > old-style-and-now-deprecated directed broadcast address > forwarding enabled (not likely). > > A DNS query to 198.41.0.4 does however only elicit a single > response, so I doubt this is much to worry about. (My guess: > they have 4 machines sharing the load via some form of load- > sharing setup.) > > - Håvard >

1 0

Urrr... A-root server foul ?
by Richard Irving 26 Aug '98

26 Aug '98

Is anyone else seeing this ? really *cool* udp trick, or is bcast space now DNS capable ? What am I missing ? Server: ns2.mci.net Address: 204.70.57.242 Non-authoritative answer: Name: A.ROOT-SERVERS.NET Address: 198.41.0.4 And a ping yields ? 64 bytes from 198.41.0.4: icmp_seq=16 ttl=250 time=59 ms 64 bytes from 198.41.0.4: icmp_seq=16 ttl=249 time=76 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=16 ttl=250 time=77 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=17 ttl=250 time=57 ms 64 bytes from 198.41.0.4: icmp_seq=17 ttl=250 time=64 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=17 ttl=249 time=73 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=18 ttl=250 time=71 ms 64 bytes from 198.41.0.4: icmp_seq=19 ttl=250 time=53 ms 64 bytes from 198.41.0.4: icmp_seq=19 ttl=249 time=57 ms (DUP!) 64 bytes from 198.41.0.4: icmp_seq=19 ttl=249 time=73 ms (DUP!)

4 3