- NANOG - lists.nanog.org

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

Re: Pinging routers for network status
by Paul Vixie 18 Dec '00

18 Dec '00

sean(a)donelan.com (Sean Donelan) writes: > 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. Similarly, long or deviant ping times against a router can just indicate that it was processing a routing update when it got your ICMP_ECHO request. Therefore the RTT isn't nec'ily indicative of link latency. (SNMP is worse.) If you want to know how fast your network is, send a normal payload. Even source routing will variously have to be "processor switched" or otherwise escape the "fast path" on many modern routers. Ping and Traceroute are for when you already know you're screwed, but you're trying to prove it to other people or you're trying to draw finer distinctions. When the network isn't failing, Ping and Traceroute tell you pretty much nothing. Of course, using normal payloads to measure network health requires agents on the far side, and thus, is a more difficult design and deployment problem. (If you don't think of this as a hard problem, you're not doing it right.)

3 3

Alter.net and Verio peering in Sacramento?
by Mathew Butler 17 Dec '00

17 Dec '00

Heya, I'm getting a huge jump in ping times from alter.net to Verio in what appears to be Sacramento: Type escape sequence to abort. Tracing the route to 198.107.19.34 1 border7.s4-2.tonbu-1.sfj.pnap.net (216.52.2.25) 0 msec 4 msec 0 msec 2 core2.ge0-1-bbnet2.sfj.pnap.net (216.52.0.66) 0 msec 0 msec 4 msec 3 POS3-0.GW2.SJC2.ALTER.NET (157.130.235.65) 4 msec 4 msec 0 msec 4 146.ATM2-0.XR2.SFO4.ALTER.NET (152.63.53.110) 12 msec 4 msec 4 msec 5 190.at-2-0-0.XR2.SAC1.ALTER.NET (152.63.50.49) 8 msec 8 msec 4 msec 6 184.ATM6-0.BR2.SAC1.ALTER.NET (152.63.52.85) 4 msec 4 msec 8 msec 7 a3-1-0-0c1.r00.scrmca01.us.bb.verio.net (129.250.9.97) 368 msec 368 msec 380 msec 8 p4-1-1-0.r01.scrmca01.us.bb.verio.net (129.250.3.18) 368 msec 368 msec 372 m sec 9 p4-1-1-0.r02.ptldor01.us.bb.verio.net (129.250.2.33) 368 msec 376 msec 372 m sec 10 ge-1-0-0.r01.ptldor01.us.ra.verio.net (129.250.31.197) 360 msec 360 msec 364 msec 11 hs-0-1-0.a01.smrwor01.us.ra.verio.net (129.250.55.122) 360 msec 356 msec 344 msec 12 199.238.235.2 344 msec 380 msec 496 msec 13 10.20.1.15 372 msec * 400 msec 14 198.107.19.34 392 msec * 400 msec Any idea what's causing that? (Or is Alter.net just not on Verio's list of preferred peers?) -Mat Butler Systems Engineer Tonbu, Inc

10 10

multi-homing without the BGP (was RE: Packet Loss)
by Jade E. Deane 17 Dec '00

17 Dec '00

I will spare everyone my own personal experiences as of late in dealing with ARIN for a /20. How about some talk on this topic, multi-homing without the application of the BGP, a pressing concern amongst mid-level ISPs and small dot com's. Jade P.S. Mr. Jimmerson... I want a /20, and a pony. Give me a /20 and a pony, I want a pony!!!! Jade E. Deane Network Engineer helloNetwork.com Las Vegas, Nevada Office: +1 (702) 938-9267 Cell: +1 (702) 604-4759 Fax: +1 (702) 456-1471 email: jade.deane(a)helloNetwork.com urgent epage: 7026044759(a)page.nextel.com

7 9

Touch America?
by BillT＠Mahagonny.com 16 Dec '00

16 Dec '00

Has anyone had any experience with Touch America? Was it a good touch or a bad touch? I'm thinking about moving a number of my data circuits to them, but would like to hear if anyone has had experience with them either as a customer or a peer. The company is the network arm of Montana power and light who are breaking off as a separate tier 1 provider. Thanx, -- BillT(a)Mahagonny.com | PGP KeyID#: 0xECB1EE6F -By the year 2019, one third of the worlds population will be Elvis impersonators.

1 0

Re: Packet Loss
by Valdis.Kletnieks＠vt.edu 16 Dec '00

16 Dec '00

On Fri, 15 Dec 2000 09:24:04 CST, "John R. Grant" said: > <cringe> > that would be 9600 bit per inch GCR format 9-track tape, don't you think? > </cringe> At least in the IBM world, the options for 7-track were 200/556/800 bpi with even or odd parity, and mode=normal/data converter/translator. For 9-track the options are 800 NRZI, 1600 PE, and 6250 GCR. I still have 21 9-track tapes in my office that I need to do something with, as our last system with 3420-style round tapes is being decomissioned in the next few months. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

5 5

Cogent Communications?
by Bill Petrisko 16 Dec '00

16 Dec '00

Has anyone heard anything about Cogent Communications (www.cogentco.com) or done business with them? Their product is a dedicated 100Mbps of transit for $1000/month. Quick rundown: Metropolitan OC-48 rings, with no more than (24) 100Mbit customers on each. Nationwide OC-192 rings between the MAN rings with extensive private peering. Any feedback would be appreciated. thanks bill -- William J. Petrisko (WP5) Network Engineering bill(a)axient.com Axient Communications

11 11

Re: Packet Loss
by Steven M. Bellovin 16 Dec '00

16 Dec '00

In message <200012151551.eBFFpKCW23482(a)black-ice.cc.vt.edu>, Valdis.Kletnieks@v t.edu writes: > >--==_Exmh_-322173952P >Content-Type: text/plain; charset=us-ascii > >On Fri, 15 Dec 2000 09:24:04 CST, "John R. Grant" said: >> <cringe> >> that would be 9600 bit per inch GCR format 9-track tape, don't you think? >> </cringe> > >At least in the IBM world, the options for 7-track were 200/556/800 bpi >with even or odd parity, and mode=normal/data converter/translator. For >9-track the options are 800 NRZI, 1600 PE, and 6250 GCR. > >I still have 21 9-track tapes in my office that I need to do something with, >as our last system with 3420-style round tapes is being decomissioned in >the next few months. Let's see... 6250 bpi * 12 in/ft * 1600 ft == 120M, if I haven't miscounted decimal places. So you can fit 5 tapes per CD-ROM, and save a lot of space. --Steve Bellovin

1 0