- Test - lists.nanog.org

NY ranks #1 in Internet b/w
by Hank Nussbacher 05 Nov '01

05 Nov '01

Perhaps Sept 11 was no coincidence and perhaps they knew of these numbers as well. -Hank http://www.totaltele.com/view.asp?ArticleID=45236&pub=tt&categoryid=626 New York is the Internet capital - TeleGeography By Total Telecom staff 30 October 2001 New York is the world's Internet capital in terms of bandwidth connectivity, according to Washington DC-based research group TeleGeography Inc. With almost 150 Gbps of region-to-region bandwidth connectivity, the Big Apple is hooked up to more than two-thirds of all interregional Internet capacity worldwide. London comes a long way second, with just over 85 Gbps. According to the TeleGeography report, Packet Geography 2002, New York has direct connections into 71 other countries, 10 more than London. The report ranks global Internet cities according to their roles as "interregional hub cities," measuring how much Internet capacity links them to other world regions. After NY and London, Amsterdam, Paris, and San Francisco complete the Internet global city top five. In all, five of the top 10 cities are in the U.S., four are in Europe, and one, Tokyo, is in Asia. Although Europe and Asia each have major hub locations, most Internet traffic between Asia and Europe still traverses U.S. coast-to-coast routes. Indeed, according to the report, 13 of the top 25 companies providing international Internet connections in the U.S. are based outside of North America. The Top 10 in full is: 1. New York (149,989.5 Mbps of Internet bandwidth) 2. London (85,518.7 Mbps) 3. Amsterdam (24,479.6 Mbps) 4. Paris (22,551.8 Mbps) 5. San Francisco (20,813.6 Mbps) 6. Tokyo (16,745.5 Mbps) 7. Washington DC (13,261.2 Mbps) 8. Miami (11,912.4 Mbps) 9. Los Angeles (11,227.0 Mbps) 10. Copenhagen (10,417.0 Mbps) Note: Figures represent Internet bandwidth connected across international borders to Consolidated Metropolitan Statistical Areas or equivalents. Domestic routes are omitted. Data as of mid-2001. This report can be purchased through Total Telecom's 'Reports and Research' resource. Click here for more details.

19 26

Re: NY ranks #1 in Internet b/w
by Alex Rubenstein 04 Nov '01

04 Nov '01

On Sun, 4 Nov 2001, Iljitsch van Beijnum wrote: > > 90,000 / 186,000 miles/sec = 483 milliseconds, which, or course, due to > > I'm afraid you're right. 240 ms is firmly burned into my mind, but this is > the ONE WAY delay. You said: > > > Over 300 ms for less than 10000 km (6000 miles) is not great. Even a good > > > satellite should be able to provide better round trip times... "round trip times" > > But, to make my point, Geosync orbit could never, ever be less than 483 > > milliseconds, ever. > > Well, actually there is a caveat: the distance to the satellite is never > exactly 22500 miles. Depending on whether the orbit is measured from the > surface of the earth (which is obviously the case for regular > non-geosynchronous satellites) or the center of the earth (which I think > is done with the 22500 mi figure) the satellite is either farther away or > closer, depending on the location of the observer and the orbit of the > satellite. The difference is substantial: up to 4000 miles. Negatory. Per my sources, geosync is 22,500 miles from mean sea level, or somehwat synonymously, from the surface of the earth. Agreed, there could be variations if the earth station is in the Alps, but even if it were on Mt. Everest at 29,035 feet (5.499 miles high), that would remove perhaps up to 21.996 miles from the round-trip path (thus assuming both earth stations are on Mt. Everest), which would remove 0.182 milliseconds from the RTT delay. Even with all the above content, this horse has just called me and asked me to stop beating him. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

1 0

Re: NY ranks #1 in Internet b/w
by Alex Rubenstein 04 Nov '01

04 Nov '01

On Sun, 4 Nov 2001, Iljitsch van Beijnum wrote: > > 90,000 / 186,000 miles/sec = 483 milliseconds, which, or course, due to > > I'm afraid you're right. 240 ms is firmly burned into my mind, but this is > the ONE WAY delay. You said: > > > Over 300 ms for less than 10000 km (6000 miles) is not great. Even a good > > > satellite should be able to provide better round trip times... "round trip times" > > But, to make my point, Geosync orbit could never, ever be less than 483 > > milliseconds, ever. > > Well, actually there is a caveat: the distance to the satellite is never > exactly 22500 miles. Depending on whether the orbit is measured from the > surface of the earth (which is obviously the case for regular > non-geosynchronous satellites) or the center of the earth (which I think > is done with the 22500 mi figure) the satellite is either farther away or > closer, depending on the location of the observer and the orbit of the > satellite. The difference is substantial: up to 4000 miles. Negatory. Per my sources, geosync is 22,500 miles from mean sea level, or somehwat synonymously, from the surface of the earth. Agreed, there could be variations if the earth station is in the Alps, but even if it were on Mt. Everest at 29,035 feet (5.499 miles high), that would remove perhaps up to 21.996 miles from the round-trip path (thus assuming both earth stations are on Mt. Everest), which would remove 0.182 milliseconds from the RTT delay. Even with all the above content, this horse has just called me and asked me to stop beating him. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --

1 0

IP allocations...
by Rich Sena 04 Nov '01

04 Nov '01

What is everyone using for subdelegating IPv4 space internally - looking for an *ease of use* tool - something that would require low maintenance and can be delegated to entry-level NOC staff... Please respond privately... -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

3 2

bandwidth prices
by allan＠alum.mit.edu 04 Nov '01

04 Nov '01

So what have people been getting for prices for CO to CO bandwidth per DS0 mile? allan

1 0

Fwd: Q: Sizes of Existing and Planned Fully Meshed IPSEC VPN (Tunnel Mode)
by Rodney Thayer 04 Nov '01

04 Nov '01

I assume "fully meshed" means each node connects to each other node, so each node has 109 tunnels (110 total). I also assume "Cisco IPSEC based VPN" means IPsec (rfc 2401/2411/etc.) and not MPLS-only. In that case, 120 is not 'large' according to the vendor community -- 'large' starts at around 5000 tunnels. I suspect that, in nature (or in the land of the Nanogians) that under 1000 is more like a 'large' one. On the other hand, drop one box with 119 tunnels set up and restart it and time how long it takes to re-initiate all 119 tunnels, and you may very well be unhappy. >From: "Tim Bass" <bass(a)silkroad.com> >We have a Cisco IPSEC based VPN with over 110 edge routers >in a full tunnel-mode mesh, mostly 'big hunking routers' with >average CPU utilization under 15 percent. The VPN is >controlled by a single organization, under centralized admin.

3 2

Q: Sizes of Existing and Planned Fully Meshed IPSEC VPN (Tunnel Mode)
by Tim Bass 04 Nov '01

04 Nov '01

Lots of old and dear friends in NANOG to say HELLO!, it has been many, many years since I've posted here. Hopefully this very simply question will not be very controversial :) I did a search of the archives on VPN with keywords 'size' and 'mesh' only to find a thread debating the merits of MPLS. This was an interested thread and some of my old and dear friends were active in that discussion. Please allow me to ask a simple less-technical question. My apologies if this has been discussed and I missed it in the archives. We have a Cisco IPSEC based VPN with over 110 edge routers in a full tunnel-mode mesh, mostly 'big hunking routers' with average CPU utilization under 15 percent. The VPN is controlled by a single organization, under centralized admin. Are there larger fully meshed VPNs out there in ISP land? Are there any 'real-tangible issues' with a fully meshed VPN at the size we are talking (around 120 sites fully meshed)? The marketing hype tends to be great. I like -vadim's closing comments in: http://www.merit.edu/mail.archives/nanog/2001-08/msg00311.html as follows: "Sometimes older ways are simply better." --vadim This seems to be true regarding a simple fully-meshed IPSEC VPN in tunnel-mode, right NANOG geniuses? Is 110 fulled meshed edge routers considered big?? Finest Regards, Tim www.silkroad.com

2 1

slightly OT : versign complaint department
by beldridg＠best.com 04 Nov '01

04 Nov '01

i've been trying to add a pgp key to the verisign/netsol database for the past two weeks. i've sent four messages, opened three web help requests, and spent three hours on the phone with their helpdesk. they know less than their customers about their own procedures and web documentation for adding keys for PGP guardian auth. i guess this is the problem with government sanctioned monopolies. i'd like to do something about it. does anybody know if there is a formal board or governing group that i can send my grievances to? - brett

10 11

(no subject)
by Zhao, Xingguo 03 Nov '01

03 Nov '01

Hi, all I have a question regarding to redistribute IGR routes into BGP. Currently both Cisco and Juniper support it. Here I don't understand what is the advantage of this redistribution? Because BGP is potentially injecting information into the IGP and then sending such information back into BGP. Could anybody provide more description regarding the advantage and the disadvantage of redistribuing IGP routes into BGP? Do people use this in real life? Thanks a lot, Xingguo

7 12

Confidential outage Saturday October 20 2001
by Sean Donelan 03 Nov '01

03 Nov '01

The first one I've seen. A carrier filed a confidential outage report with the FCC for an outage on Saturday October 20. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/20… So, did any customers of the unknown carrier notice an outage?

1 0