- Test - lists.nanog.org

Cogent / AOL peering issues
by Gil Cohen 19 Dec '02

19 Dec '02

Some possibly good information about what's going on: Cogent had a "test" peering arrangement with AOL. That means that it was just a test to see what the ratio of cogent/aol traffic is to see whether or not they qualify for a real peering arrangement. Cogent did not meet that requirement, so AOL terminated the agreement. AOL offered Cogent a purchased peering program, but Cogent does not want to take it, because it costs money. Cogent purchases transit from another provider, MFN, that as a peering arrangement with AOL, but Cogent has chosen not to allow traffic to/from AOL to go through MFN. I would imagine this is because it'd cost Cogent money, whereas if it went through the L(3) peering arrangement, it won't. So Cogent is now pushing all the traffic over through their L(3) pipes, therefore, congesting them. That's the reason for all the high latency. Cogent, several months ago started the process to get more pipes into L(3) for peering. Now they're trying to make the process go a lot faster. The following is going to be my interpretation: I think AOL purchases transit from L(3), so by Cogent pushing all their AOL-bound traffic through their L(3) peering pipes, they're hoping that it'll push AOL's transit bill up. This is going to be their playing card. I think. Phew. That's about it. Signed, Gil -- Gil Cohen <gcohen(a)saturnbandwidth.net> | SENIOR NETWORK ENGINEER | SATURN BANDWIDTH & FIBER, INC. | (o) 954-438-7000x124 (c) 954-347-0615 |

2 1

Cogent
by Ringdahl, Dwight (WebUseNet) 19 Dec '02

19 Dec '02

>> But they let them >> all go. So ones the chef(s) were out the door, who maintains it? >> It's not exactly a status quo situation. It was treated in house as, >> well we have the peering so why do we need all these pain in the butt >> expensive guys? We could use another one or two of these expensive guys... Send them my way. Do you think this will hurt them and their other peers? I know L3 has been trimming peers down and if they are filling up their pipes now might cause problems.

2 1

Any good fiber cuts today?
by Sean Donelan 19 Dec '02

19 Dec '02

So what is the story on fiber cuts today? Several people asked me, but I didn't have anything.

1 0

NANOG 27 Information
by Carol Wadsworth 18 Dec '02

18 Dec '02

Meeting registration for NANOG 27, February 9-11, 2003, in Phoenix will open on January 2. Hotel information is now posted at: http://www.nanog.org/mtg-0302/hotel.html Call for Presentations: http://www.nanog.org/mtg-0302/call27.html (Note: deadline for proposals is January 6.)

1 0

IWon/Excite mail admin...
by Gabriel 18 Dec '02

18 Dec '02

Hello all, I've been trying (rather unsuccessfully) to get a hold of iwon/excite. They're blocking my mail servers (safepages.com domain), and I'd like to talk to them about it. My question: Does anyone have a NOC or mail admin contact for Excite/Iwon that they would be willing to share? (And to reciprocate, if anyone has been getting spam from my domain, I'd love to talk about it so I can shut down offending user.) Thanks. -- Gabriel Cain www.dialupusa.net Unix Systems Administrator gabriel(a)dialupusa.net Dialup USA, Inc. 888-460-2286 ext 208

1 0

Change of dates for Nordnog-2
by Kurt Erik Lindqvist 18 Dec '02

18 Dec '02

Due to announcement of the NANOG dates that collides with NordNOG, NordNOG will change the dates. NordNOG-2 will be held at 13-14 February 2002. The change of dates also means that we will change the venue. The venue for the conference will be : Marievik Konferens Årstaängsvägen 1 B Information on the venue can be found at : http://www.lunchinfo.com/5/restaurang_detail/part/2/id/5953 For more information on NordNOG please see : http://www.nordnog.org Best regards, - kurtis -

1 0

misc cisco parts
by Andrew Brown 18 Dec '02

18 Dec '02

does anyone know of a place where a non-cisco customer could pick up a few rack mount kits for small cisco routers (eg, 25xx or 26xx series)? -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" werdna(a)squooshy.com * "information is power -- share the wealth."

6 5

Fwd: Alternative to NetFlow for Measuring Traffic flows
by Sean M.Doran 18 Dec '02

18 Dec '02

> I have found peering to have additive value; a lot of 1-2 Mbps peering > sessions can save as much money for you as a single large traffic > peer. The more traffic, the stronger the case for peering. Sadly, this completely ignores the cost of implementing and maintaining peerings. BGP does not exactly configure itself, and current routing technology is somewhat frail -- if it breaks, somebody has to pick up the pieces; if suboptimal routing results from a peering, somebody will have to go and tweak things. Since the Internet is not exactly static, these things creep up from time to time even after a peering is established. An exhaustive itemization of the costs of any given peering is a of vital component of a cost-benefit analysis, particularly where much of the benefit is a reduction in monthly usage based billing costs, or a deferral of an upgrade of a flat rate contract, rather than installing new parallel connectivity to meet the demands of traffic growth. While such a list will vary from organization to organization, and some organizations may be tricky to complete, one can consider the primitive case of a transition from being singly homed to a transit provider to bring up an initial peering. Among the things to be considered: PA address space, BGP (and making sure that the routers can handle the load, and so can the people operating them), avoidance of accidental transit, what happens to the peering traffic when the peering fails from time to time (or fills up with growth traffic over time), NOC-to-NOC coordination, impact on actual and potential SLA offerings, and so on. The immediately subsequent peering may not make much of an impact on many of these however there are real incremental costs. Some of these may not rise linearly in proportion to the number of peers (e.g. there may be a step change), but rather may be a function of that number, the number of your routers which talk eBGP, and your overall traffic load. I know a handful of cases where a broad peering strategy had a fairly clear negative impact on the bottom line even though the saving in transit fees was both directly measurable and large. Anecdotes are not general proofs, but do underline the uncertainty in your statement: "a lot of ... peering sessions CAN save as much money ... as a single large traffic peer". [emphasis mine] Unfortunately, discussions here seem to focus mostly on measuring the reduction in transit fees. Wouldn't it be nice if this could be coupled with reasonable discussion about the increase in other costs, and how for some networks these costs are much higher than for others? Sean.

2 1

EIGRP / OSPF dampening
by Donn Lasher 18 Dec '02

18 Dec '02

I'm looking for a way to way to either dampen, penalize, or otherwise slow down a flapping interface, when the router has no "link state" information about the Layer 2 connection, which is itself causing the flap... Example... Dec 17 08:23:50 xxx.xxx.xxx.xxx 2106: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is down: peer restarted Dec 17 08:23:52 xxx.xxx.xxx.xxx 2107: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is up: new adjacency Dec 17 08:24:09 xxx.xxx.xxx.xxx 2108: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is down: peer restarted Dec 17 08:24:11 xxx.xxx.xxx.xxx 2109: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is up: new adjacency Dec 17 08:24:42 xxx.xxx.xxx.xxx 2110: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is down: peer restarted Dec 17 08:24:43 xxx.xxx.xxx.xxx 2111: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is up: new adjacency Dec 17 08:25:18 xxx.xxx.xxx.xxx 2112: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is down: peer restarted Dec 17 08:25:20 xxx.xxx.xxx.xxx 2113: 15w5d: %DUAL-5-NBRCHANGE: IP-EIGRP 10: Neighbor xxx.xxx.xxx.xxx (FastEthernet2/0.3) is up: new adjacency This type of flapping yields an effectively down interface, yet, appears "up" so data gets blackholed while dead timers expire, etc. I'm very familar with doing this via BGP, but haven't found any good way yet to do this with either EIGRP or OSPF. Any ideas? Feel free to either reply to the list, or privately. Thanks in advance..

2 1

Phoenix Topics So Far
by Susan Harris 17 Dec '02

17 Dec '02

Many thanks to everyone who sent in topic suggestions for the upcoming NANOG (Feb. 9-11). Here's what we've lined up so far: -- Experiences with deploying large-scale wireless LANs -- BGP4 Anycast for Root Name Service -- Threat or Menace? -- Why don't people aggregate more? (CIDR report analysis) -- Time lapse between IP allocation and appearance in routing table -- Joint Regional Internet Registry Report -- "The BGP TTL Security Hack," Internet-draft, www.ietf.org/internet-drafts/draft-gill-btsh-01.txt -- Achieving Near-Optimal Traffic Engineering Solutions for Current OSPF/IS-IS Networks (Research Forum) Further suggestions welcome, and the CFP is here: http://www.nanog.org/mtg-0302/call27.html See you soon.

1 0