- NANOG - lists.nanog.org

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 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