August 2001 - Test - lists.nanog.org

RE: CR2 question
by Smith, Rick 25 Aug '01

25 Aug '01

I'm actually seeing several thousand port 80 scans per hour ! Code Red Log Checker Beginning Time... 20:00:01 Ending Time: 21:00:00 Number of attacks... 3137 Number of unique addresses... 287 -----Original Message----- From: Todd Suiter To: nanog(a)merit.edu Sent: 8/25/01 4:34 PM Subject: CR2 question Folks, Its been almost a month, and my IDS is still picking up several hundred CodeRed 2 attacks a day. Is anyone else seeing this same level of continued activity of this worm? I personally am somewhat at a loss as to how to contact people who are affected, as automated broadcasts to people, in my opinion, are NOT the way to go. BUT, going through several hundred IPs, a day, and trying to find someone at those organizations to speak to is A LOT of work. Any ideas? Thanks! todd

1 0

CR2 question
by Todd Suiter 25 Aug '01

25 Aug '01

Folks, Its been almost a month, and my IDS is still picking up several hundred CodeRed 2 attacks a day. Is anyone else seeing this same level of continued activity of this worm? I personally am somewhat at a loss as to how to contact people who are affected, as automated broadcasts to people, in my opinion, are NOT the way to go. BUT, going through several hundred IPs, a day, and trying to find someone at those organizations to speak to is A LOT of work. Any ideas? Thanks! todd

1 0

Re: multi-homing fixes
by Larry Sheldon 25 Aug '01

25 Aug '01

> > Do you *really* want your DNS TTL set down in the same range as > > the time for a BGP route fall-over? > > Ever read RFC1123? > > It states: > 2.3 Applications on Multihomed hosts > > When the remote host is multihomed, the name-to-address > translation will return a list of alternative IP addresses. As > specified in Section 6.1.3.4, this list should be in order of > decreasing preference. Application protocol implementations > SHOULD be prepared to try multiple addresses from the list until > success is obtained. More specific requirements for SMTP are > given in Section 5.3.4. > > When the local host is multihomed, a UDP-based request/response > application SHOULD send the response with an IP source address > that is the same as the specific destination address of the UDP > request datagram. The "specific destination address" is defined > in the "IP Addressing" section of the companion RFC [INTRO:1]. > > Similarly, a server application that opens multiple TCP > connections to the same client SHOULD use the same local IP > address for all. > > Unfortunately, many programs have chosen not to do this. Well, yes. But I thought the thread was talking about multi-homed _networks_, which I take to be a different problem from multi-homed _hosts_. Am I in over my head again?

2 1

The Cidr Report
by CIDR Report 25 Aug '01

25 Aug '01

This is an auto-generated mail on Fri Aug 24 23:00:01 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 24Aug01 0) General Status Table History ------------- Date Prefixes 170801 102866 180801 102777 190801 102782 200801 102807 210801 102870 220801 102815 230801 103148 240801 103170 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11439 Number of ASes announcing only one prefix: 6806 (3880 cidr, 2926 classful) Largest number of cidr routes: 843 announced by AS701 Largest number of classful routes: 1396 announced by AS701 1) Gains by aggregating at the origin AS level --- 24Aug01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1251 964 287 22.9% Telstra Pty Ltd AS701 1396 1184 212 15.2% UUNET Technologies, Inc. AS2551 797 636 161 20.2% ICG NetAhead, Inc AS4151 289 164 125 43.3% USDA AS4293 383 274 109 28.5% Cable & Wireless USA AS6595 168 60 108 64.3% DoD Education Activity Network As AS577 294 188 106 36.1% Bell Advanced Communications Inc. AS16473 177 74 103 58.2% Bell South AS705 243 144 99 40.7% UUNET Technologies, Inc. AS6429 199 103 96 48.2% AT&T Chile Internet S.A. AS7018 746 656 90 12.1% AT&T AS4755 215 128 87 40.5% Videsh Sanchar Nigam Ltd. Autonom AS7046 339 260 79 23.3% UUNET Technologies, Inc. AS13999 103 25 78 75.7% Mega Cable S.A. de C.V. AS4200 139 73 66 47.5% Apex Global Information Services, AS12302 95 30 65 68.4% MobiFon S.A. AS1239 462 398 64 13.9% Sprint AS724 218 155 63 28.9% DLA Systems Automation Center AS6471 123 61 62 50.4% ENTEL CHILE S.A. AS3464 149 91 58 38.9% Alabama SuperComputer Network AS16758 63 6 57 90.5% IKON Office Solutions AS703 309 254 55 17.8% UUNET Technologies, Inc. AS3908 332 277 55 16.6% Supernet, Inc. AS226 147 94 53 36.1% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS209 282 230 52 18.4% Qwest AS1 548 496 52 9.5% BBN Planet AS17561 113 62 51 45.1% Internet service provision to Wes AS855 145 95 50 34.5% Canadian Research Network AS852 214 164 50 23.4% Telus Advanced Communications For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: multi-homing fixes
by John Fraizer 24 Aug '01

24 Aug '01

On Fri, 24 Aug 2001 jlewis(a)lewis.org wrote: > On Thu, 23 Aug 2001, Brian Whalen wrote: > > > Well I remember seeing a message on groupstudy where somone from the tac > > came on and made a statement along the lines that a substantial quantity > > of cases they get are a result of non Cisco memory. > > Maybe there are people out there who regularly throw just any memory in > their Cisco and wonder why it's not recognized on boot up...but I can say > I've never called TAC for that...and generally if I call TAC, it's because > IOS is buggy. > It saw the memory. (Real cisco RSP4 memory, just in an RSP8) It booted. It was REAL flakey though. It didn't see anything in the Y bus on boot but, if you removed the card and put it back in, it would see it. Very funky. --- John Fraizer EnterZone, Inc

1 0

RE: multi-homing fixes
by Roeland Meyer 24 Aug '01

24 Aug '01

|> From: Adam Rothschild [mailto:asr@latency.net] |> Sent: Thursday, August 23, 2001 10:36 PM |> |> On Thu, Aug 23, 2001 at 03:23:24PM -0700, Roeland Meyer wrote: |> > At $99US for 512MB of PC133 RAM (the point is, RAM is disgustingly |> > cheap and getting cheaper), more RAM in the routers is a quick |> > answer. Router clusters are another answer, and faster CPUs are yet |> > another. |> |> Throwing more RAM and CPU into our routers (assuming for a |> moment that |> they're most certainly all Linux PC's running Zebra) is not the |> solution you're looking for; the problem of RIB processing still |> remains. |> |> Getting a forwarding table requires extracting data from the RIB, and |> this is the problem, because RIBs are very large and active, and are |> being accessed by lots of reading and writing processes. RIB |> processing is substantial, and is only getting worse. SMP systems and multi-ported RAM is a good enough stop-gap. If I didn't like non-deterministic systems, I might suggest Echelon technologies (hardware-based neural nets). |> > If the IETF is being at all effective, that should start now and |> > finish sometime next year, so that we can start the 5-year |> > technology roll-out cycle. |> |> Roeland, The IETF is eagerly awaiting your solution. Send code. See |> Tony Li's presentation at the Atlanta NANOG on why this solution of |> jamming RAM and CPU into boxes is not a long term viable answer: |> |> <http://www.nanog.org/mtg-0102/witt.html> I've read that and largely agree. The hardware approach was only meant to buy time, while the geniuses at the IETF find a better approach. What I don't agree on, and am amazed to see, the admission that they don't know at what point the convergeince problem becomes intractible. Or even, if it does... that sounds more like a fundimental lack of understanding of the algorithm itself. |> In short, state growth at each level must be constrained and must not |> outstrip Moore's law, and to be viable in an economic sense, it must |> lag behind Moore's law. In the mid-80's, I worked on an OCR problem, involving a add-on 80186 processor card. We used a brute-force solution. It as too slow on the 8 MHz CPU. Years later, with the advent of faster hardware, the product was released. It's funny that the market timing was just about perfect. It gave that company a huge head start, when the market turned hot. It is alright to target performance/capacity solutions expected to be present at the time of product release (about 5-years from now). In fact, that's about the only way I see the problem getting solved.

4 3

OT: HELP!!!!
by Rich Sena 24 Aug '01

24 Aug '01

A while back there was a direct number to a reliable Network Solutions contact published here - can someone forward me that info... -- Richard Sena The Mitre Corporation e: rsena(a)mitre.org Lead Engineer 202 Burlington Road v: +1-781-271-3712 Dept: R10N; MS C020 Bedford, MA 01730-1420 f: +1-781-271-2600

1 0

RE: multi-homing fixes
by Martin, Christian 24 Aug '01

24 Aug '01

> | They can use standard PC133 DIMMs, if they want to. > > With ECC please. > > Sean. Amen to that. Unless the vendors are interested in rad-hardening the chassis... chris >

1 0

RE: multi-homing fixes
by smd＠clock.org 24 Aug '01

24 Aug '01

| They can use standard PC133 DIMMs, if they want to. With ECC please. Sean.

1 0

Re: multi-homing fixes
by Vijay Gill 24 Aug '01

24 Aug '01

Roeland Meyer <rmeyer(a)mhsc.com> writes: > |> From: Adam Rothschild [mailto:asr@latency.net] > |> being accessed by lots of reading and writing processes. RIB > |> processing is substantial, and is only getting worse. > > SMP systems and multi-ported RAM is a good enough stop-gap. If I didn't like > non-deterministic systems, I might suggest Echelon technologies > (hardware-based neural nets). Roeland, what I believe Dr. Rothschild was alluding to is that the underlying problem here is is more of fundamental database managment problem. Key issues are concurrency controls involved in operating on data that must be accessed by multiple readers and writers, among other things. > don't agree on, and am amazed to see, the admission that they don't > know at what point the convergeince problem becomes intractible. Or > even, if it does... that sounds more like a fundimental lack of > understanding of the algorithm itself. Large, distributed database systems are annoying and hard to deal with, there is no silver bullet yet. This is something the DB folks have been working on for years and since AS's can be viewed as a distributed multiversion databases, no doubt there is much to be learned from the research in the DB field. /vijay

1 0