- Test - lists.nanog.org

Re: Where are ATM NAPs going?
by Richard A. Steenbergen 19 Dec '00

19 Dec '00

On Tue, 19 Dec 2000, John Fraizer wrote: > After I long search, I can not find any exchange point operated by > Richard "unhealthy fascination with gerbils" Steenbergen. > > Until you build an exchange point yourself, don't belittle ours. Ouch, I sense some serious hostility here. I guess your long search didn't turn up my involvement with some of the lesser known exchanges like MAE-Compton or THIMBLE-IIX (Packet over String exchange), but thats understandable. Yes I will kindly let this thread die. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

RE: Qwest yesterday?
by Steve Riley (MCS) 19 Dec '00

19 Dec '00

There have been some very high winds here in the last couple days -- upwards of 90 MPH. Knocked out some of AT&T @Home, too. Wouldn't surprise me if it also ripped off a few roofs in Boulder; that happens just about every winter. _______________________________________________________ Steve Riley Microsoft Communications Consulting in Denver, Colorado steriley(a)microsoft.com +1 720 320-7889 (NEW mobile) www.microsoft.com/isn/ Applying computer technology is simply finding the right wrench to pound in the correct screw. -----Original Message----- From: Ralph Forsythe [mailto:ralph@centerone.com] Sent: Tuesday, December 19, 2000 9:36 AM To: nanog-digest(a)merit.edu Subject: Qwest yesterday? Anybody know what happened to Qwest yesterday? I had access down in Denver for several hours, and the best they could tell me was "it's a big outage, yeah they're down hard". Since my circuit was fine I assume a router failure of some type vs a major cut, but you never know... Thanks, Ralph Forsythe ralph(a)centerone.com

1 0

Qwest yesterday?
by Ralph Forsythe 19 Dec '00

19 Dec '00

Anybody know what happened to Qwest yesterday? I had access down in Denver for several hours, and the best they could tell me was "it's a big outage, yeah they're down hard". Since my circuit was fine I assume a router failure of some type vs a major cut, but you never know... Thanks, Ralph Forsythe ralph(a)centerone.com

1 0

RE: Port scanning legal
by Mark Borchers 19 Dec '00

19 Dec '00

The gray area of port-scanning legality came up at Usenix's conference earlier this month. I believe the consensus was that you are on firmer ground when organizations who own machines that attackers might perform port scans FROM have AUP's that prohibit such activity. Nothing in this court case would seem to prevent an organization from disciplining individuals for using a system for an administratively prohibited purpose. > -----Original Message----- > From: Edward S. Marshall [mailto:emarshal@logic.net] > Sent: Tuesday, December 19, 2000 9:43 AM > To: nanog(a)merit.edu > Subject: Port scanning legal > > > http://www.securityfocus.com/templates/article.html?id=126 > > A quick quote from the article: > > A tiff between two IT contractors that spiraled into federal court > ended last month with a U.S. district court ruling in Georgia that > port scanning a network does not damage it, under a section of the > anti-hacking laws that allows victims of cyber attack to sue an > attacker.

1 0

Pinging routers for network status
by Sean Donelan 19 Dec '00

19 Dec '00

On Sun, 17 December 2000, John Fraizer wrote: > On Sat, 16 Dec 2000 nanog(a)rmrf.net wrote: > > We at SAVVIS run continous pings to every backbone router that we > > own. (John - this does not include our ATM switches, we have no way to > > monitor latency between them). But if, say, our connection to Sprint or > > Um, sure you do. You know your atm mesh and (hopefully) you have an IP > address bound up on the switch itself so you can gather snmp statistics > from the box. Most network providers ping their routers for network status. Several providers even track RTT to detect changes. But very few customers connect to routers. Comparing the performance you see with HP Openview or similar products with the performance customers see remains an interesting question. Sometimes C&W's or AT&T's traffic web site does show a problem. But there are also problems that don't show up in intra-network pings. In particular IGP/BGP routing issues can result in severe access network problems, but no problem with the internal provider network mesh used for pings.

5 5

RE: Where are ATM NAPs going?
by Roeland Meyer 19 Dec '00

19 Dec '00

> So, should CMH-IX go ATM? Well, given the traffic > levels I don't > think you could collect enough in fees to pay for an ATM > switch. On that > basis, ATM is a poor choice. Again, it's a poor choice not > because of the > technology, but because of the price points and products available. > > -- > Leo Bicknell - bicknell(a)ufp.org > Systems Engineer - Internetworking Engineer - CCIE 3440 > Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org If I have this correctly; You are saying that ATM is neither cost-effective or cost-competitive with Gig-E?

2 1

political ramifcations of internet power use
by michael thomas guldan 18 Dec '00

18 Dec '00

i'm actually a bit surprised that this didn't show up here first. http://dailynews.yahoo.com/h/zd/20001218/tc/power_struggle_1.html basically there are competing views on how much energy the internet and it industries use. a choice quote: "Moving 2 megabytes of data on the Net, they said, requires the energy equivalent of 1 pound of coal. And with hundreds of millions of new digital devices, ranging from digital X-ray machines to Palm handheld computers, getting plugged in, the future of our economy depends on burning more fossil fuels, including coal, which produces 56 percent of the electricity used in America. All those Net-related electronics consume "up to 290 billion kWh [kilowatt-hours] of demand. That's about 8 percent of total U.S. demand," they wrote. "Add in the electric power used to build and operate stand-alone [unnetworked] chips and computers, and the total jumps to about 13 percent. It's now reasonable to project that half of the electric grid will be powering the digital Internet economy within the next decade." -- e: michael(a)ele-mental.org c: +1.614.260.6716 u: www.ele-mental.org Wir fahr'n fahr'n fahr'n auf der Autobahn

2 1

Re: Where are ATM NAPs going?
by Sean Donelan 18 Dec '00

18 Dec '00

ATM is just a technology. Over the last decade, depending on who had the faster chipset, folks have chosen an ATM chipset, an Ethernet or even a Frame-Relay chipset for their NAPs/Exchange Points. At one point in time, the Gigaswitch was the fastest available. Then ATM switches could do 155Mbps and OC12. GigEthernet and 10 GigEthernet appeared, and folks went the other way. Both ATM and Ethernet exchange points have route-servers. Equinix, PAIX, SBC, and Worldcom have route-servers at their exchange points in the USA. LINX and other have route-servers at exchange points outside the US. Fully filtering your peering sessions with route-servers is relatively simple. ATM has PVCs, Ethernet has VLANs. Ethernet interface cards tend to be less inexpensive than ATM interface cards. ATM is a natural wide-area technology, Ethernet is a natural local-area technology. Frame-relay tends to be used for smaller exchange points, although it could also work in a mid-sized exchange points. The reliability between ATM and Ethernet isn't that different over the long term. Most of the problems tend to be with the end-connections (congestion and broadcast loops), and not the fabric itself. But there have been notable outages with atm switches and ethernet switches at exchange points. Multicast is an interesting problem in itself. None of the ATM switches handle multicast very well, and even the ethernet switches have problems. On Mon, 18 December 2000, Jay Ford wrote: > On Mon, 18 Dec 2000, Ben Buxton wrote: > > I'm interested in peoples thoughts as to what is happening with the > > future of ATM NAPs. Are people moving away from them or are they > > still quite popular? Downsides or upsides? > > I'm trying to gauge whether they are worthy of investing equipment > > and hassle into for peering... > > From a research university perspective, the AADS NAP is a cool thing. It > lets me do peering & various types of transit on a single circuit, & the > availability of the route servers is nice. The full mesh of PVCs removes > most of the layer 1-2 pain involved with firing up new interactions. The > circuit to get there isn't cheap, but it seems worth it based on my > experience.

2 1

Re: looking glass resources, as promised :)
by Kevin_Badeen＠harte-hanks.com 18 Dec '00

18 Dec '00

This ones nice too http://nitrous.digex.net/ Kevin Badeen Unix Administrator Harte-Hanks Response Management 512.434.5999 Tel 877.446.5548 Pag |--------+--------------------------> | | Ariel Biener | | | <ariel(a)fireball.| | | tau.ac.il> | | | Sent by: | | | owner-nanog@meri| | | t.edu | | | | | | | | | 11/29/2000 06:05| | | PM | | | | |--------+--------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: nanog(a)merit.edu | | cc: | | Subject: looking glass resources, as promised :) | >---------------------------------------------------------------------------------------------------------------------------------------------| Ok, this is what I gathered: Looking Glass locations: http://www.caida.org/analysis/routing/reversetrace/ http://www.traceroute.org Looking glass software: http://net.doit.wisc.edu/~plonka/FlowScan/ http://www.paranode.com/lg/ http://nitrous.digex.net/source/source.html ftp://ftp.enterzone.net/looking-glass/mrlg-3.0/ ftp://ftp.shrubbery.net/rancid/rancid-2.1b.tar.gz Charles Sprickman <spork(a)inch.com> also mentioned that some of the sites that offer LG service also have a link to the source they use, so, you can also try that, YMMV. again, thanks for the input, --Ariel -- Ariel Biener e-mail: ariel(a)post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

1 0

RE: Pinging routers for network status
by Blaine Christian 18 Dec '00

18 Dec '00

Hello, One thing to keep in mind is that even if you escape being process switched you still have ECMP and variants to contend with. Some vendors reliably switch packets through certain paths based on source/destination hashes. This means a probe THROUGH a router using a single source address could well report good things while an adjacent source prefix could be screwed by riding a congested path. The only way to be absolutely sure is to either stop using ECMP or run your tests from enough devices to be hashed over all possible paths. All the above in mind, ICMP is quite useful and while it is not 100% accurate it is a pretty good way to identify possible issues. Regards, Blaine

1 0