- NANOG - lists.nanog.org

Re: The Great Exchange
by Tom Walton 27 May '98

27 May '98

You're assuming that the internet will persist in its current form, and just "scale up". I'd argue that, as network technology becomes useful for non-nerds, consumers will pay for packaged data services and not just for "access" to an expanded version of today's web-morass. These information services, e.g., entertainment, news, etc., will be big bandwidth burners. Simple economics will drive the providers of these high-bandwidth services to the edges of the network, and hence to a regional model for content distribution. Thus, the majority of bits, if not the majority of net "accesses" (one ten minute video stream will likely dominate a residential consumer's daily consumption) reaching consumers will be delivered regionally. You can see the beginnings of this trend in the proliferation of www-caching research, products, and services (e.g., the nlanr caching studies, Inktomi and Skycache). ISPs are already finding it economical to set up ad hoc "tiered" content distribution schemes to reduce their backbone bandwidth requirements. Under this model, the ISPs are themselves regionalizing content distribution; what was global traffic, once cached, becomes local. As the data services industry matures, and exands to serve the enormous residential consumer market, large volume content providers will follow this model, locating servers at regional sites to minimize their backbone costs. Of course, this blue-sky-ish sort of argument depends on the widespread deployment of high-speed last-mile access technologies, and the development of worthwhile services offerings. This will occur at different paces in different locales; yet its hard (for me, at least) to see a much different outcome in the long run. Tom twalton(a)dimension.net > >"Pickett, David" writes: >> 1) More needs to be done to leverage locality of traffic > >In the long run, why are we assuming there will be locality of >traffic? > >It is true that the old PSTN has locality of traffic, but it doesn't >have flat rate pricing, or the usage patterns that the Internet has. I >argue that users are rarely more likely to be trying to download a web >page from near to their homes than from far away. If there is >locality, it is probably weak, and in the long run would only account >for a fraction of the traffic. > >Perry

2 1

Things I forgot
by Susan Rebecca Harris 27 May '98

27 May '98

Eek. In my 'draft NANOG agenda' message yesterday, I forgot to mention two activities scheduled for Sunday, June 7: - SUNDAY AFTERNOON TUTORIAL, 1-4pm: "Routing Coordination Through the Internet Routing Registry" (Cengiz Alaettinoglu, ISI, and Curtis Villamizar, ANS). Take this opportunity to find out about Routing Policy Specification Language, the new standard for expressing global routing policy. - SUNDAY EVENING TOOL DEMOS, 6:45-7:15pm: "Tools From the Internet Performance Measurement and Analysis Project" (Sushila Subramanian, University of Michigan/Merit). Introduces ASExplorer, NetNow, and other Java tools for diagnosing and troubleshooting network routing problems. For details, see http://www.nanog.org/mtg-9806/agen0698.html . --Susan

1 0

Re: different thinking on exchanging traffic
by Tim Salo 27 May '98

27 May '98

> Date: Fri, 22 May 1998 22:02:47 -0500 (CDT) > From: Tim Salo <salo(a)networkcs.com> > To: nanog(a)merit.edu > Subject: Re: different thinking on exchanging traffic > [...] > I believe that all four of the winning NSFNET NAP submissions proposed > nationwide "NAPs". I believe that the reason they didn't happen is that > the NSF asked for and assumed it would get four geographically-focused > solutions. I suspect that the notion of awarding four NAPs, all of which > covered all of the country, provided the NSF a certain amount of heartburn. > I believe that the nationwide NAP concept died, (or was killed), at the > time for administrative, not technical, reasons. But, this is all > speculation on my part... > [...] A presumably well informed observer sent me private e-mail that questioned my account. I read only one of the winning NAP proposals, the one I worked on. My speculation that all of the winning proposals talked about nationwide NAPs was based on conversations after the fact, including with authors of competing proposals. So, I believe that all of those who submitted winning NAP proposals were thinking about nationwide NAPs, but some may not have, based on the e-mail I received, included those thoughts in their proposals. At any rate, my thesis is that the concept of a nationwide layer-two solution has been around for several years, at least since the time that the NAP proposals were written. I might add, however, that we are collectively still learning about how best to make use of these very large layer-two services. -tjs

2 1

Re: different thinking on exchanging traffic
by Michael Gibson 27 May '98

27 May '98

CANIX is a co-operative peering point for National Canadian Traffic. Currently, they are seven national ISPs exchanging traffic at that point. Mike Gibson - Netcom Canada -----Original Message----- From: Damian O'Gorman <damian(a)cyberdude.com> To: Sean Donelan <SEAN(a)SDG.DRA.COM> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: 5/26/1998 17:31 Subject: Re: different thinking on exchanging traffic >> Of course, not every local ISP participates. The state subsidized >> education network doesn't connect, nor do some the dialup ISPs. But >> it gets a reasonable level of support from several of the larger >> area providers. >> > >The same type of project was attemted in Toronto. CANIX was essentially set >upto cross connect traffic rather than having to traverse the entire US >network to get >to the other side of Toronto. The problem was, it became an exclusive >bilateral peering >arrangemt with 6 players. That was 1 1/2 years ago. Currently only 2 are >peered. What in fact was the point. UUnet and Sprint were the big players up >here and nobody appears to want to cooperate. > >> But exchange points are one of those weird creatures. If I'm paying >> a big expensive backbone, why would I get anything from a local exchange >> point? And of course, the ever popular "What's the catch?" Since >> local exchange points are generally run on a non-profit basis, that >> means there isn't a large marketing organization, or a huge gaggle of >> salespeople trying to sell it. If you like, we can call it a "managed >> connection" and charge you $1,000/month. But that seems steep for >> essentially a port on a catalyst switch. >> >> > >Damian O'Gorman > >

2 1

Re: different thinking on exchanging traffic
by Sean Donelan 27 May '98

27 May '98

>Currently there are at least 60 ISPs serving the San Diego county >area. There are LOTS of packets from "home" to "office" that make a >round-trip via MAE-West. Some people have decided that this is >silly. Even if it is "cost-effective", it *squanders* bandwidth at >MAE-West that could best be used for other traffic. This is true in almost every major metro area. I help found an exchange point in St. Louis. Not MAE-East levels of traffic, the exchange peak at about 2.4 Mbps of traffic (more than a T1's worth). http://www.stlouix.net/ But that's 2.4Mbps of traffic that didn't travel 2,000 miles to get across town. Of course, not every local ISP participates. The state subsidized education network doesn't connect, nor do some the dialup ISPs. But it gets a reasonable level of support from several of the larger area providers. But exchange points are one of those weird creatures. If I'm paying a big expensive backbone, why would I get anything from a local exchange point? And of course, the ever popular "What's the catch?" Since local exchange points are generally run on a non-profit basis, that means there isn't a large marketing organization, or a huge gaggle of salespeople trying to sell it. If you like, we can call it a "managed connection" and charge you $1,000/month. But that seems steep for essentially a port on a catalyst switch. But we've found once an ISP connects, they generally keep it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Re: The questions stand
by John Fraizer - Administrator 27 May '98

27 May '98

>You're saying that you never experience packet loss to _any_ destination >unless it's some kind of emergency situation? I find that hard to >beleive. What if the destnation's network is chronically congested? Or >if the exchange point between your upstream provider and the destination's >provider is congested? Or some other fill_in_the_blank ongoing >non-emergency problem at the destiantion? No. I was referring to packet loss due to problems here at ENTERZONE or at FNSI.NET. God knows I we can't control what happens to a packet once it hits that VA based ISP. I would swear that they are releaving congestion on their internal network by load balancing between /dev/null and /dev/void at the MAEs. (grin) >I have no doubt that you maintain an excellent network, and that you have >an excellent working relationship with your upstream provider, but how are >they going to control what is occuring within {big Tier 1 provider}. They can't. But they can weight their session with "medium Tier 1 provider" as preferred if the agreement allows until "B.T.1.P" gets a clue or enough complaints from their peers and customers. ------- John Fraizer (tvo) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

different thinking on exchanging traffic
by Jonathan Arneault 27 May '98

27 May '98

A few days ago I posted a proposal for traffic exchange across an ATM backbone specifically designed for that purpose. I am suggesting an NxOC-48 network with peers purchasing DS3 connections at their various geographic locations, and establishing ATM PVCs with specified CBR's to their respective peers. Each DS3 connection would allow up to 5 PVCs, with over-subscription at a 2 to 1 maximum. In this scenario, a flat pricing for a port would be about 5K/month, and CBR's would be set at a maximum of 10K/mo for full DS3 bandwidth. Since the beginning of this thread, I have been in contact with several venture capital firms to feel out the support from the financial world about making this do-able. I have estimated the costs involved with the fiber and switch purchases at about US 691MM for sunk capital costs, and approximately 250K/mo for operating expenses. With strong indications of its fiscal viability, I am now asking you, the potential consumers of such a service, your distinct opinions, and whether or not you would purchase such a service if made available. Specifically, if I build it, will you come. Your response will determine whether or not I will proceed in my discussions with the VCs, and will probably be incorporated into a supporting document in the application for funding. It is understood that no statement you make in regard to this letter will be legally binding, and will in no wise obligate you to purchase this service if and when it becomes available. I'm really asking you all to do me a favor by letting me know if you'd like to see this or not. If so, great. If not, I'd rather spend my energy on something that'll be successful. Please respond to me directly, and include your name, title, your company's name, and a day-time telephone number. Thanks much, Jonathan Arneault jarneault(a)inet-solutions.net

5 4

Suggestion for improved identD
by Ehud Gavron 26 May '98

26 May '98

Suggestion: PPP access devices intercept identD requests and return the authenticated access string. Reasoning: Modern ``stacks'' used by end-users -- especially those on throwaway accounts, fake any identD response. This makes tracking those people tougher. Methods: 1: identD v2, new port, intercepted by access devices which support it. 2: modification to hosts requirement RFCs, making access devices responsible for intercepting identD requests to their PPP clients. 3: a security RFC ``suggesting'' 1 or 2 Thoughts appreciated, as are comments, flames, blames, and anything of some content. Ehud gavron(a)aces.com p.s. new beta traceroute at ftp.aces.com cd pub/software/traceroute/beta

19 30

Draft NANOG Agenda
by Susan Rebecca Harris 26 May '98

26 May '98

Greetings - here's a draft agenda for the June 1998 NANOG. On Monday evening, we'll also feature demos of freely available routing tools and other BOFs - stay tuned for more information. For meeting details, see http://www.nanog.org/mtg-9806/update.html . Looking forward to seeing you! ---------------------------------- SUNDAY, June 7: Evening Tutorials 7:15 p.m. Introduction to Multicast (Dave Meyer, Cisco Systems) 8:45 p.m. Interesting Things You Can Do With OSPF (Howard Berkowitz) MONDAY, June 8 9:00 a.m. Welcome, Introductions, Future Meetings (Bill Norton, Merit) 9:30 a.m. Recommendations on Queue Management and Congestion Avoidance in the Internet (Van Jacobson, Lawrence Berkeley National Laboratory) 10:00 a.m. QoS and Ebone: Issues and Potential Solutions (Sean Doran, Ebone) 10:30 a.m. BREAK 10:45 a.m. Differentiated Services Panel: Working Group Update and Viewpoints From the Community (Kathleen Nichols, Bay Networks, moderator) Priority Service for Internet Traffic (Van Jacobson, Lawrence Berkeley National Laboratory) Differentiated Services Support in Cisco Routers (Fred Baker. Cisco) TBA (Peter Ford, Microsoft) 12:15 p.m. - 1:45 p.m. LUNCH 1:45 p.m. Introduction to the NETPERF.NET Inter-Provider Network Performance Monitoring Project (Avi Freedman, Net Access) 2:00 p.m. Path and Round-Trip Time Measurements: a New Project at CAIDA (Daniel McRobb, CAIDA (Cooperative Association for Internet Data Analysis)) 2:30 p.m. Building Large-Scale Internet Measurement Infrastructure (Vern Paxson, Lawrence Berkeley National Laboratory) 3:00 p.m. Update from the IPMA Project (Craig Labovitz, Merit) 3:30 p.m. BREAK 3:45 p.m. Roadmap to a Distributed Registry: Transition to RPSL (Routing Policy Specification Language) (Cengiz Alaettinoglu, ISI, Curtis Villamizar, ANS) TUESDAY, June 9 9:00 a.m. Overview of FBI Computer Investigations (Scott Larson, FBI) 9:45 a.m. Network-based Denial of Service Attacks: Descriptions and How to Protect Your Network (Craig Heugen, Cisco) 10:15 a.m. What Is a VPN? (Paul Ferguson, Cisco) 10:45 a.m. BREAK 11:00 a.m. Dial-in VPN Using Layer 3 Tunneling (Gary Malkin, Bay Networks) 11:30 a.m. Broadband VPNs - Outsourcing ISP services to Cable TV and XDSL Providers (Bruce Perlmutter, Bay Networks) 12:00 p.m. LUNCH 1:30 p.m. Implementing Simplex IP Bandwidth Augmentation and IP-based News and HTTP Broadcast Services via Geosynchronous Satellite (Avi Freedman, Net Access) 2:00 p.m. Scaling and Other New BGP Features (Mark Turner, Cisco) 2:30 p.m. ARIN Update (Kim Hubbard, ARIN) 2:45 p.m. BREAK 3:00 p.m. InterNIC Update (Mark Kosters, InterNIC) 3:30 p.m. Update on UCAID, Internet2, and the Abiline Project (Guy Almes, UCAID) 4:00 p.m. Closing Remarks (Bill Norton, Merit)

1 0

Re: The questions stand
by John Fraizer - Administrator 26 May '98

26 May '98

At 04:12 PM 5/21/98 -0400, you wrote: >Seems to depend on where you sit. John is only a few hops away (on the >same 'Tier 1' provider?) as Karl, so traffic is dependant on only three >parties maintaining a clean network. Across another backbone (via public >view sage.aspire.net) it's not so clean, probably due to packet loss No webserver active on common ports at sage.aspire.net, so I traced from here to there: [OverKill]:~$ traceroute sage.aspire.net traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0 traceroute to sage.aspire.net (207.233.170.6), 30 hops max, 40 byte packets 1 eth1-core0.Columbus.EnterZone.Net (209.41.244.1) 0.464 ms 0.402 ms 0.378 ms 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 4.123 ms 2.925 ms 1.905 ms 3 border1-atm6.Vienna.fnsi.net (206.183.239.90) 31.108 ms 28.097 ms 34.240 ms 4 br1.tco1.alter.net (192.41.177.248) 44.899 ms 30.415 ms 31.101 ms 5 335.ATM2-0-0.CR2.TCO1.Alter.Net (137.39.74.73) 44.533 ms 46.970 ms 46.335 ms 6 412.atm11-0-0.gw2.tco1.alter.net (137.39.22.13) 35.126 ms 50.597 ms 29.909 ms 7 diginetusa-gw.customer.ALTER.NET (157.130.34.26) 52.351 ms 51.069 ms 29.571 ms 8 rt1b-ser0-VA001.diginetusa.net (207.233.201.22) 59.098 ms 60.608 ms 57.744 ms 9 sage.aspire.net (207.233.170.6) 42.377 ms 48.387 ms 46.359 ms --- sage.aspire.net ping statistics --- 64 packets transmitted, 64 packets received, 0% packet loss round-trip min/avg/max = 44.1/50.0/67.9 ms Looks clean to me. >across the Tier 1 provider that they use (UUNet) or loss at an exchange >point between UUNet and Napnet to get to Karl's network. Oh, Gawd! I have never, in my most bizzare nightmares contemplated obtaining bandwidth from UUNet. They don't even have a POP in Columbus according to the Worldcomm/UUNet sales puke who approached me at our co-lo facility last week. We obtain our bandwidth from Fiber Network Solutions, Inc. (FNSI.NET) Karl from what I see is getting bandwidth or transit at least from GOOD.NET: [OverKill]:~$ traceroute www.mcs.net traceroute: Warning: Multiple interfaces found; using 209.41.244.2 @ eth0 traceroute to www.mcs.net (205.164.8.12), 30 hops max, 40 byte packets 1 eth1-core0.Columbus.EnterZone.Net (209.41.244.1) 0.478 ms 0.400 ms 0.381 ms 2 core1-eth0-ENTERZONE.Columbus.fnsi.net (209.115.127.21) 1.522 ms 1.454 ms 1.367 ms 3 aads.good.net (198.32.130.49) 13.534 ms 13.805 ms 13.705 ms 4 mcsnet.chicago.good.net (207.98.189.130) 14.305 ms 16.059 ms 14.862 ms 5 www.mcs.net (205.164.8.12) 14.279 ms 13.941 ms 14.021 ms Pings: --- www.mcs.net ping statistics --- 52 packets transmitted, 52 packets received, 0% packet loss round-trip min/avg/max = 13.6/15.2/23.4 ms >From an OAR.NET connected machine, it looks like it transits through NAP.NET: [tvo@noldor tvo]$ traceroute www.mcs.net ...blah blah blah... 7 oeb3-atm6-0.columbus.oar.net (199.18.202.13) 37.002 ms 38.028 ms 37.028 ms 8 tlp3-atm1-0.toledo.oar.net (199.18.202.53) 45.021 ms aads.nap.net (198.32.130.39) 49.466 ms 50.494 ms 9 chi-h0.mcs.net (206.54.225.150) 50.948 ms 57.74 ms 51.727 ms 10 www.mcs.net (205.164.8.12) 50.387 ms 50.473 ms 50.216 ms [tvo@noldor tvo]$ Pings: --- www.mcs.net ping statistics --- 67 packets transmitted, 67 packets received, 0% packet loss round-trip min/avg/max = 58.5/62.2/81.6 ms (Note: The above connection is via ISDN so, I'll be nice and attribute the latency to that VS OAR.NET's architecture.) >Despite our best intentions, packet loss and delay will always exists from >our networks to certain destinations, no matter whether we use 'Tier 1' >providers or companies that are creating private NAPs of their own. And >how it looks from me to you doesn't mean much, in the long run - how it >looks across the board from you to your customer's destinations is what >makes a difference. If that's accomplished with a small backbone >provider, a big player like MCI, or some local 'private nap' company >shouldn't make any difference to anyone but yourself. In all honesty, the only time I have experienced packet loss to any destination, it has been isolated and attributed to (heat/cold/incompetence/emergency, unscheduled maintenance - PICK ONE, seems like the MAE operators do) at one of the MAEs or some idiot with too much backhoe and too little clue. If you are accepting packet loss as "normal and unavoidable", your provider is making excuses vs isolating and eliminating problems in their network or in their interconnect at the MAEs. If, on the other hand, you expect to get what you pay for and deliver it to your customers without having to make excuses for problems in your upstreams network, perhaps I can interest you in a circuit or co-location. If you're one of the folks who is caught up on the Tier issue, I can sell you a circuit from FNSI.NET as well. As for how we look from the "outside": MAE-East Looking Glass Results 1 mae-east.fnsi.net (192.41.177.11) 0 msec 0 msec 4 msec 2 core1-hssi7.Columbus.fnsi.net (206.183.239.89) [AS 6259] 28 msec 28 msec 32 msec 3 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 28 msec 76 msec 36 msec 4 www.enterzone.net (209.41.244.11) [AS 6259] 28 msec 36 msec 32 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/36/48 ms Sprintnap Looking Glass Results 1 phl2-core2-f4-0.atlas.digex.net (165.117.51.37) 0 msec 0 msec 0 msec 2 dca1-cpe2-h10-0-0.atlas.digex.net (165.117.52.121) 8 msec 4 msec 4 msec 3 dca1-cpe1-fa4-0-0.atlas.digex.net (165.117.224.10) 8 msec 8 msec 4 msec 4 iad1-core1-p5-0.atlas.digex.net (165.117.52.230) 8 msec 4 msec 4 msec 5 mae-east.fnsi.net (192.41.177.11) 16 msec 12 msec 4 msec 6 core1-hssi7.Columbus.fnsi.net (206.183.239.89) [AS 6259] 36 msec 40 msec 44 msec 7 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 36 msec 32 msec 44 msec 8 www.enterzone.net (209.41.244.11) [AS 6259] 48 msec 44 msec 48 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms MAE-West Looking Glass Results 1 mae-west.fnsi.net (198.32.136.111) 0 msec 4 msec 0 msec 2 core1-hssi8.Columbus.fnsi.net (206.183.239.93) [AS 6259] 66 msec 68 msec 66 msec 3 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 64 msec 60 msec 60 msec 4 www.enterzone.net (209.41.244.11) [AS 6259] 60 msec 60 msec 64 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/60 ms PAIX Looking Glass Results 1 sjc3-core2-fa0-0-0.atlas.digex.net (165.117.53.194) 4 msec 0 msec 0 msec 2 sjc1-core2-h5-0.atlas.digex.net (165.117.50.121) 4 msec 4 msec 0 msec 3 sjc1-core1-fa3-0-0.atlas.digex.net (165.117.50.145) 4 msec 4 msec 4 msec 4 pacbell.fnsi.net (198.32.128.5) 4 msec 8 msec 4 msec 5 core1-hssi8.Columbus.fnsi.net (206.183.239.93) [AS 6259] 72 msec 78 msec 70 msec 6 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 72 msec 70 msec 74 msec 7 www.enterzone.net (209.41.244.11) [AS 6259] 70 msec 70 msec 70 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/80/84 ms ROUTE-SERVER.CERF.NET Looking Glass Results 1 h1-0.san-hq3.cerf.net (192.215.254.1) [AS 1740] 4 msec 4 msec 4 msec 2 h1-0.san-hq3.cerf.net (192.215.254.1) [AS 1740] 0 msec 0 msec 0 msec 3 h2-0-0.san-bb3.cerf.net (134.24.29.61) [AS 1740] 0 msec 4 msec 4 msec 4 atm1-0-155M.san-bb1.cerf.net (134.24.32.6) [AS 1740] 4 msec atm6-0-1-155M.sjc-bb2.cerf.net (134.24.29.94) [AS 1740] 16 msec 16 msec 5 mae-west.nap.net (198.32.136.13) 20 msec 20 msec 20 msec 6 core0-a0-7.chi1.nap.net (207.112.247.146) [AS 5646] 100 msec 92 msec 92 msec 7 core0-fe8-1.chi1.nap.net (207.112.247.153) [AS 5646] 108 msec 96 msec 108 msec 8 aads.fnsi.net (198.32.130.64) [AS 6196] 208 msec 116 msec 104 msec 9 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 100 msec 116 msec 116 msec 10 www.enterzone.net (209.41.244.11) [AS 6259] 104 msec 104 msec 120 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 100/105/120 ms And from (http://zeus.lyceum.com/cgi-bin/nph-bgp-routes) 1 Serial0.BR1.ATL2.lyceum.net (206.71.7.18) 8 msec 4 msec 4 msec 2 ge001.rt1.ATL.netrail.net (207.153.92.1) [AS 4006] 8 msec 8 msec 8 msec 3 gs012.rt1.DCA.netrail.net (205.215.63.13) [AS 4006] 44 msec 40 msec 44 msec 4 gf020.rt2.DCA.netrail.net (205.215.4.2) [AS 4006] 44 msec 40 msec 40 msec 5 mae-east.fnsi.net (192.41.177.11) [AS 701] 44 msec 52 msec 48 msec 6 core1-hssi7.Columbus.fnsi.net (206.183.239.89) [AS 6259] 84 msec 80 msec 80 msec 7 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 72 msec 72 msec 76 msec 8 www.enterzone.net (209.41.244.11) [AS 6259] 72 msec 76 msec 72 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 72/74/76 ms And just for grins and giggles, lets look from a few more countries: CSL GmbH 1 csl.D.net.DTAG.DE (194.245.101.62) 4 msec 4 msec 4 msec 2 D-ag1.D.net.DTAG.DE (194.25.7.77) 4 msec 4 msec 4 msec 3 D-gw1.D.net.DTAG.DE (194.25.122.118) [AS 3320] 8 msec 8 msec 8 msec 4 K-gw1.K.net.DTAG.DE (194.25.120.150) [AS 3320] 8 msec 8 msec 8 msec 5 F-gw3.F.net.DTAG.DE (194.25.120.229) [AS 3320] 12 msec 12 msec 12 msec 6 TysonsC-gw1.USA.net.DTAG.DE (194.25.6.186) [AS 3320] 120 msec 108 msec 112 msec 7 Penns-gw1.USA.net.DTAG.DE (194.25.6.193) [AS 3320] 108 msec 116 msec 108 msec 8 sl-bb1-pen-2-0.sprintlink.net (207.143.32.174) [AS 4999] 116 msec 116 msec 116 msec 9 sl-bb11-pen-0-1.sprintlink.net (144.232.5.9) [AS 1239] 116 msec 116 msec 116 msec 10 sl-bb7-pen-4-0-0.sprintlink.net (144.232.5.58) [AS 1239] 116 msec 116 msec 116 msec 11 sl-bb5-chi-1-0-0.sprintlink.net (144.228.10.38) [AS 1239] 136 msec 136 msec 136 msec 12 sl-bb11-chi-0-2.sprintlink.net (144.232.0.173) [AS 1239] 132 msec 132 msec 132 msec 13 sl-gw14-chi-8-0-0.sprintlink.net (144.232.0.194) [AS 1239] 140 msec 136 msec 136 msec 14 sl-napnet-2--T3.sprintlink.net (144.228.159.18) [AS 1239] 176 msec 176 msec 180 msec 15 aads.fnsi.net (198.32.130.64) [AS 6196] 388 msec 300 msec 336 msec 16 ENTERZONE.Columbus.fnsi.net (209.115.127.22) [AS 6259] 288 msec 184 msec 192 msec 17 www.enterzone.net (209.41.244.11) [AS 6259] 188 msec 188 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 184/190/196 ms AMS-IX Looking Glass Results 1 Amsterdam1.cistron.net (195.64.68.4) 4 msec 4 msec 4 msec 2 jedi-s0-5.amsterdam.wirehub.net (195.86.26.2) 4 msec 4 msec 8 msec 3 ajani-s0.1.washington.wirehub.net (194.165.94.149) 108 msec 92 msec 92 msec 4 mae-east.fnsi.net (192.41.177.11) 108 msec 100 msec 100 msec 5 core1-hssi7.Columbus.fnsi.net (206.183.239.89) 136 msec 124 msec 136 msec 6 ENTERZONE.Columbus.fnsi.net (209.115.127.22) 124 msec 120 msec 124 msec 7 www.enterzone.net (209.41.244.11) 160 msec 124 msec 156 msec Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 124/140/152 ms DTI Japan: DTI NSPIXP-2 Router (http://neptune.dti.ad.jp/routechk-ixp2.html) Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 220/224/228 ms IMNET Japan: IMNET/NSPIXP2 Looking Glass (http://www.inoc.imnet.ad.jp/lg/ix-lg.html) Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 180/194/204 ms LINX London: LINX Looking Glass (http://www.linx.net/cgi-bin/lg.pl) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 209.41.244.11, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 120/120/124 ms I guess again, for some reason, things are fast and clean from my network. They always have been since our move to Fiber Network Solutions, Inc (FNSI.NET) for our bandwidth. Then again, I guess not all Tier 1's are alike. ------- John Fraizer (tvo) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1