December 2002 - Test - lists.nanog.org

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 17 Dec '02

17 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

Slightly OT: Hosting Providers in Hong Kong
by Damian Gerow 17 Dec '02

17 Dec '02

Can anyone recommend a good hosting company located in Hong Kong? One of our clients needs to host some files overseas, and we've had some troubles actually getting in touch with someone to get some stable pricing. We're only looking for 50-100 MB of space to store some files, but like I said, we've had problems getting people to call us back. (Responses would probably be better off-list. Thanks.) - Damian

2 1

Alternative to NetFlow for Measuring Traffic flows
by William B. Norton 17 Dec '02

17 Dec '02

Hi all - Here is the problem: Everyone wants to know how much traffic would ultimately be passed in peering relationships at an IX before signing up/building into an IX. I heard an interesting solution recently to estimating the traffic volume destined to an AS in the absence of NetFlow or the like. The ability to measure traffic via sampling has been difficult for a variety of reasons (lack of staff resources, capabilities of the interface cards, expensive SW, etc.) and I found from talking to Peering Coordinators that less than 1 in 20 ISPs actually do the traffic measurements. In the absence of data, ISPs are often left to intuition, guessing that a particular AS would be a good peering candidate. Here is the Solution: Assuming that: 1) You are multi-homed 2) You have some ideas of who you would want to peer with 3) <more assumptions here I'm sure> 1) You adjust routing to prefer one transit provider or the other for the AS 2) Shift traffic to the particular AS from one transit provider to the other, noting the change in the loads on the transit providers. If you do this at peak time you can get a rough estimate of the peak traffic to this AS, and therefore a rough order of magnitude estimate of the amount of traffic that would go to this AS in a peering relationship. (Rough Estimate means determining if the traffic volume is likely to be 2 Mbps vs. 20 Mbps vs. 200Mbps) Interesting idea. Comments? The other approach some ISPs use is to set up a "trial" peering session, usually using a private cross connect to measure the traffic volume and relative traffic ratios. Then both side can get an idea of the traffic before engaging in a contractual Settlement-Free Peering relationship. Bill

8 17

RE: Identifying DoS-attacked IP address(es) Sniffer
by alex＠yuriev.com 17 Dec '02

17 Dec '02

> The Sniffer and other tools like it are meant to drink from a fire hose. > So, is it far fetched to analyze a dozen or more OC-12's other than from a > router?? No. In fact carriers should embrace a different approach to > further understand and analyze their backbone. Analyzers' with filters of > attack/virus definitions can play a key role in fast, efficient response in > the fight against distributed attacks. Should the sales people trying to peddle their wares learn a bit about underlying technologies and be forced to take Algebra 101 before be let lose on NANOG? So your SONET sniffer decodes STS->[other stuff]->IP->[other-stuff]->app-layer and matches against definitions that you have, and does it all in real-time, does not fall over due to load, deals with fragmentation and assymetic routing and so on. Oh, and then of course it does it all in a secure manner since the traffic should not be exposed to 3rd parties. Yeah, right. Alex

1 0

RE: Identifying DoS-attacked IP address(es) Sniffer
by Brennan_Murphy＠NAI.com 17 Dec '02

17 Dec '02

Even though you are asking this question with regard to what can be done on the router itself, it's worth mentioning, if only for the archives, a non-router approach to the problem...especially if you are an enterprise network manager. It's even worth mentioning despite the fact that I work for a company that provides said approach. Some of our enterprise customers place distributed Sniffers on their internet links themselves. Upon receiving an alert, they connect to the Sniffer and click on Top Ten talkers by bytes (presented in pie/bar chart). On the left side of the screen are the source/destination pairs generating the most traffic. Typically, top talkers are the culprits but sometimes weak DOS attacks can hide among legitimate traffic, which is why it's occasionally useful to check the Protocol Distribution window. More sophisticated attacks sometimes require that you take a capture of traffic and analyse packet level data. If it's a simple DOS, jot down the IP's involved and call your ISP or upstream provider with a filter request. Near future versions of Sniffer will have IDS capabilities built in. I've also seen a proof of concept tool that automates the filtering process based on DDOS data and network thresholds. Obviously, there's lots of cases where this is a problematic approach but I was impressed with the tool's current intelligence...especially traceback analysis and filtering at ingress. In any case, Sniffer isn't the only protocol analysis tool. Shop around if a non-router approach interests you. -----Original Message----- From: Andre Chapuis [mailto:chapuis@ip-plus.net] Sent: Monday, December 16, 2002 9:12 AM To: nanog(a)nanog.org Subject: Identifying DoS-attacked IP address(es) Hi, How do you identify a DoS-attacked IP address(es) on your ingress border router, assuming the latter is a Cisco 12000 ? I used to use ip accounting but they removed it from the S-code. Thanks, André --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ----------------------

3 2