- Test - lists.nanog.org

Re: DC power versus AC power
by David Lesher 02 Jan '03

02 Jan '03

Unnamed Administration sources reported that Charles Sprickman said: > Additionally I wonder why non-conductive tools wouldn't be the norm in an > environment where there's an "open" power grid? :) "Fools rush in where....." It was in years past. I recall how excited the power room guys were over TI's first all-plastic watches. They simply did not ever wear same until then. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

4 5

Nanog broken?
by Ejay Hire 02 Jan '03

02 Jan '03

Hi all. I haven't seen any posts this morning, is the list broken or did everyone take a day off?

3 2

Re: AOL & Cogent
by Paul Vixie 02 Jan '03

02 Jan '03

> The perceived "money on the table" frequently doesn't exist and attempts > to get it may produce the opposite result. well, yeah, sure, but... > * Who they shift the traffic to may be your competitor. ...at least you know they are paying SOMEBODY, thus supporting the market you want to be in. you can then compete in that market. if everybody who could peer in N places worldwide could just get peering, then all kinds of per-bit revenue for "high tier" network owners would turn into per-port revenue for exchange point operators. where's the market in that? how could a "high tier" even exist in those conditions? > If you assume the above three cases are costs and you add that to the cost > of the decreased efficiency of traffic to the target network you can > compare it to the probability that you can sell service to the former > peer. Depending on the relationship, you can guess the likelyhood. well, that's a technical consideration, and as such won't matter until we've burned through some of the overcapacity from the dot-bomb era. right now it's possible to do gaming and voip and other isochronous applications via a transit provider who can backhaul your traffic 1500 miles (or 6000 miles) to some centralised peering point and still have reasonable performance. we will need to 1000X the traffic volume again before this stops working again. which should take about a year.

5 4

NANOG registration
by Susan Harris 02 Jan '03

02 Jan '03

We've now opened registration for NANOG 27, to be held February 9-11 in Phoenix, Arizona: https://www.merit.edu/nanog/registration.form.html General meeting info and the Call for Presentations are here: http://www.nanog.org/mtg-0302/ Hotel information (special NANOG rate expires Jan. 18): http://www.nanog.org/mtg-0302/hotel.html See you soon, and many thanks to Rodney Joffe and UltraDNS for hosting the meeting!

1 0

The Bogon Reference Page
by Rob Thomas 02 Jan '03

02 Jan '03

Hi, NANOGers. [ Apologies to those of you who have seen this post in other fora. ] Many of you have requested a variety of methods for obtaining a list of the bogon prefixes. I have added several additional methods of tracking the bogon prefixes, and I'm also happy to add that two folks have volunteered to be part of the effort. Thanks to Dave Deitrich (bigdave(a)cymru.com) and Steve Gill (gillsr(a)cymru.com) for the assistance! You can now track the bogons through HTTP, e-mail (here and elsewhere), DNS, RADb, and BGP. Feel free to use some or all of these options. They are all detailed in the Bogon Reference Page found here: http://www.cymru.com/Bogons/ Thanks to John Payne, Jared Mauch, Boyan Krosnov, Eddy Dreger, Hank Nussbacher, and Rafi Sadowsky for the feedback and ideas! Comments and feedback are always welcome. Help stamp out bogons and bogus ASNs! :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

attbi security contact?
by Avleen Vig 02 Jan '03

02 Jan '03

I know the holidays are still upon us, but if anyone from attbi.com is listening who can deal with a security matter I would appreciate an email. Or indeed if anyone has contact with such a person. A little more detail, this regards a user who may be about to start a large scale DDoS on an popular IRC network :-(

1 0

DDos syn attack
by Mike Hyde 02 Jan '03

02 Jan '03

Just wondering how people have delt with DDOS syn attacks on port 80 of a customers server? We had an attack a couple of days ago, and it overwelmed both the customers firewall and, when we tried to turn up filtering on a 7600 cisco router, the router also. We ended up having the customer change his IP for the site under attack. We were lucky in that the attack was against an IP and not the DNS name. -- Mike Hyde <mhyde(a)escape.ca>

9 10

Re: Dutch translation needed
by bdragon＠gweep.net 02 Jan '03

02 Jan '03

> I am not getting through to speed.planet.nl in English, can anyone give > me > a decent translation of in Dutch (The Netherlands): > > "Here are our logs, indicating your host is attempting to access > formmail on our web servers. We have been seeing at least 1,000 attempts > a day > for weeks from this host. Please look into this matter. The logs > are in Mountain US time zone and sync'ed to NTP. Thank you > for your attention to this matter" > > > James Edwards > Routing and Security > noc(a)cybermesa.com You may want to start with mentioning UTC-7 rather than Mountain, as outside of the Americas, probably only EST and PST are memorable (if that). Heck, even living in the US, I have to think about Central vs. Mountain and fallback to old network programming messages like "ER, at 10pm Eastern 9pm Central and Pacific" although these days, they've even shortened that to just mention Eastern and Pacific.. Not to mention even in the US we're quirky about when we observe (if we do) Daylight Saving Time, and how our observance matches that of the rest of the world, which makes using UTC offsets that much more important. "Time is relative. Lunchtime, doubly so" -- Douglas Adams, HHGttG

1 0

Re: AOL & Cogent
by Paul Vixie 30 Dec '02

30 Dec '02

> > ... if everybody who could peer in N places worldwide could just get > > peering, then all kinds of per-bit revenue for "high tier" network > > owners would turn into per-port revenue for exchange point > > operators. ... > Well, I think as a local operator you can not expect to be able to > peer with everyone to receive global routes but theres no reason not > to exchange local routes comparable to the area your own network > covers, this wont affect transit sales and wont cost you in backhaul > either. Thats a slightly different perspective than assuming you can > get a providers to exchange all their network with you in a settlement > free bilateral. there we go again, talking technology and making the technological kind of sense. peering isn't a technology decision, it's a business decision. as a local operator myself (ISC), i know that i should not expect peering other than if someone wants their customers to have better access to the f-root server or the kernel.org ftp server or whatever. it's actually easier for me, as a nonprofit, to attract what mr. bill calls 'content peering' relationships, since i don't compete with the folks i peer with. however, in a former job, i took the reins of abovenet and used a lot of mfn fiber and mfn resources (back when they had resources to use, that is) and built a network that touched down in more places with more gigawhuppas and more bit-miles and so on than about half of the current so called "top tier" networks had then (or indeed have now). i surrounded PSI on all sides, with a network that carried more actual traffic and had more provable headroom, and more endpoints. yet they still insisted on playing peering games. (perhaps if they'd won those games they would still exist today?) peering is not about equity, or ratios, or technology. it's about money. sadly, too many people are focusing on their share of the current market rather than on the size of the eventual market, so, short-term thinking pervades the space, and the actual customers who source and sink all this traffic don't ride a curve that looks anything like moore's law. try a thought experiment. take about $450M in vee cee money, buy up a lot of bankrupt capital and routes, hire a bunch of starving backbone engineers and sales/marketing/finance/etc people at downsized salaries, and build a network that attends about 40 major carrier interconnect locations (some internet exchanges, some carrier motels). document the hell out of it, so that when you enter peering negotiations with the current "top tier" networks you've got "attachment A" already done and audited. now ask yourself the chances of becoming defaultless and settlement free before you run out of cash. (now, does anybody still think peering is a technology issue?) > And definitely to your gamers and possibly your VoIP folks to > (depending on details) they will be very fickle on your network > connectivity and the quality of local peerings is crucial to these > applications, gaming is growing very quickly as more people get flat > fee broadband and to a residential access provider I wouldnt > underestimate how much it could hurt to increase the path to the > servers by a couple of hops. like i said, we're living in the shadow of bankrupt overcapacity, and until we burn it off, "cost per bit-mile" is going to be too low to measure when compared with "cost per peering edge". the next six to twelve months will favour the "small number of large peering edges" model. once the capital and routes are rightpriced, and transit contracts are rightpriced, and we reach some kind of equilibrium between the value and cost of traffic, then some kind of technological argument about peering might hold some sway.

5 5

AOL & Cogent
by Andrew Partan 30 Dec '02

30 Dec '02

I was poking around to see what was happening with Cogent and AOL and ran into some interesting info. The test that Cogent failed was a 2:1 ratio; Cogent was at 3:1 and AOL insisted they be at no more than 2:1 for free peering. AOL wants Cogent to pay for peering - the pricing I've heard is $50-/meg for paid peering - which I think is more than street price for transit... Hmm; I wonder if this change in policy has anything to do with John Schanz's recent move from Sprint to AOL? --asp

16 22