August 1998 - Test - lists.nanog.org

The Cidr Report
by Tony Bates 28 Aug '98

28 Aug '98

This is an auto-generated mail on Fri Aug 28 12:00:00 PDT 1998 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 28Aug98 0) General Status Table History ------------- Date Prefixes 210898 52842 220898 52964 230898 52773 240898 53047 250898 53127 260898 53242 270898 53089 280898 53151 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: 3922 Number of ASes announcing only one prefix: 1901 (987 cidr, 914 classful) Largest number of cidr routes: 346 announced by AS3561 Largest number of classful routes: 1175 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Aug98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS3602 552 320 232 42.0% Sprint Canada Inc. AS701 1175 949 226 19.2% Alternet AS271 351 153 198 56.4% BCnet Backbone AS4293 444 258 186 41.9% IMCI AS2493 384 227 157 40.9% iSTAR Internet, Inc. AS3749 223 67 156 70.0% TECNET AS174 701 576 125 17.8% Performance Systems International AS4200 193 99 94 48.7% AGIS (Apex Global Information Ser AS5668 131 42 89 67.9% Century Telephone Inc. AS2685 242 161 81 33.5% IBM Global Network - US AS4755 124 47 77 62.1% Videsh Sanchar Nigam Ltd. India AS4740 421 346 75 17.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS3221 112 42 70 62.5% EENet Autonomous System AS7046 234 168 66 28.2% UUNET-CUSTOMER AS3493 242 176 66 27.3% INTERLINK AS3804 215 157 58 27.0% Bell Solutions AS3403 182 127 55 30.2% TIAC AS10928 101 46 55 54.5% UNKNOWN AS549 205 151 54 26.3% ONet Backbone AS8517 124 72 52 41.9% ULAKNET-ASN AS719 464 415 49 10.6% LANLINK autonomous system AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 551 503 48 8.7% SprintLink Backbone AS803 78 34 44 56.4% SaskNet Backbone AS4539 68 27 41 60.3% NETROPOLIS AS852 158 118 40 25.3% AGT Advance Communication AS6181 66 26 40 60.6% FUSE-NET AS7122 119 80 39 32.8% MTS ADVANCED Network Policy AS4614 68 32 36 52.9% Asiaonline Hong Kong 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

Re: Using NAT for best-exit routing
by Jeff Mayzurk 28 Aug '98

28 Aug '98

Brian Dickson wrote: > such peer networks). Ingress traffic to the web farm provider has it's > *source* address NAT'd, and internal routing points return traffic to > the *same* NAT through which the request traffic came. > Thus, return (data) traffic is best-exit. > Side benefits are that the unique address pools allow for much easier > per-peer and per-region collection of stats, eg netflow (at some place > other than NATs). As you point out, stats collection is easier--but only from a network ops point of view, and even then, only if you're simply concerned with symmetric flow of traffic to your upstreams/peers. However, your web server logs are now useless, because all the requests come from a static pool of local addresses. If you're a big web farm like Exodus, your customers aren't going to buy this. -Jeff -- Jeff Mayzurk Manager, Systems/Network Engineering <jeffm(a)eonline.com> E! Online 150 Chestnut Street 415.772.3555 x4496 San Francisco, CA 94111 415.984.0322 FAX

1 0

Re: Generation of traffic in "settled" peering arrangement
by Brett_Watson＠enron.net 28 Aug '98

28 Aug '98

On 08/25/98 03:05:40 PM steve wrote: >On Tue, Aug 25, 1998 at 03:50:37PM -0400, Alec H. Peterson wrote: >> Owen DeLong wrote: >> > >> > Where do you get your data? It seems to me that the bulk of the largest web >> > sites with which I am familiar are located in at least two datacenters. >> >> Most of the busy sites I frequent are hosted on the west coast (not just >> Exodus-hosted sites, but sites in general). > > That's just how the internet plays, there are probably more sights >phisically in the silicon valley then anywhere else on the west coast. It's >where the busniness's are, and since they want to have their machines as >close to them as possible, they put them here. in my opinion, if hosting is done correctly, and managed with the right tools, the hosting provider should be able to dictate where the servers are placed (which city or data center) to balance load in the network (thus balancing some of the load offered to the external peers). while i was at genuity, the distribution of servers was very skewed. most customers were either in the bay area or phoenix, and thus wanted their servers placed there. engineering wanted to decide where servers were placed but sales always said "no no, the customer wants the server in city X" thus we had terrible traffic distribution and serverely overloaded routers and circuits between phoenix, san jose, and mae-west. -brett

1 0

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

27 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 26 Aug '98

26 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 26 Aug '98

26 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