- NANOG - lists.nanog.org

RE: Cisco introduced 'warm' reload...
by Michel Py 13 Sep '03

13 Sep '03

> Pascal Gloor wrote: > Cisco inroduced 'warm' reload > http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_ > feature_guide09186a00801a755a.html > 12.3(2)T This feature was introduced. > 12.2(18)S This feature was integrated into Cisco IOS Release 12.2(18)S. > Did anyone test this yet? It's not available on all platforms, at least not on my test one. When doing "reload warm" it does a cold one and takes "warm" as the reason for reload. Michel. cisco7507#sh ver Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-JK9O3SV-M), Version 12.3(2)T, RELEASE SOFTWARE (fc1) Synched to technology version 12.3(1.9) cisco7507#warm? % Unrecognized command cisco7507#warm-reload Translating "warm-reload"...domain server (192.168.222.4) % Unknown command or computer name, or unable to find computer address cisco7507#reload ? LINE Reason for reload at Reload at a specific time/date cancel Cancel pending reload in Reload after a time interval <cr>

2 1

Re: More on the DDoS Attack
by Eric Gauthier 13 Sep '03

13 Sep '03

Hello, Ok - I know I said I'd have something for the list on Monday. Unforunately, work kept getting in the way :( Yesterday, I sent our this URL to the people who replied to me privately. It is a general overview (with a few details) of how various schools have been dealing with the recent RPC vulnerabilities and the associated Blaster/Welchia worms. http://www.roxanne.org/~eric/blaster.html Take a look and let me know what you think. Any question or comments - editorial or otherwise - would be greatly appreciated. Eric :)

2 1

Cisco introduced 'warm' reload...
by Pascal Gloor 13 Sep '03

13 Sep '03

Cisco inroduced 'warm' reload http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guid e09186a00801a755a.html 12.3(2)T This feature was introduced. 12.2(18)S This feature was integrated into Cisco IOS Release 12.2(18)S. Did anyone test this yet? Pascal

2 1

Re: 92 Byte ICMP Blocking Problem
by Mark Vevers 13 Sep '03

13 Sep '03

Steve Carter said: > > I believe it to be true that all policy route traffic is processor switched rather than CEF on the 75xx platform. If so, the 75xx might not be handling all it's being asked to and dropping stuff in a > non-deterministic way. > In my experience you can do the 92 byte blocking on 75's with dCEF provided you are *very* careful about exactly what policy based routes you set up ... Try the following: On the interfaces make sure you have: ip route-cache policy Then apply your PBR the inbound interface: ip policy route-map block92 which looks like: route-map block92 permit 10 match ip address 121 match length 92 92 set interface Null0 route-map block92 permit 20 With access-list 121 looking like access-list 121 permit icmp any any echo The route-map is exteremly critial because some can be done in dCEF and some can't - and you must have the extra permit as well (sorry if I'm teaching grandma to suck eggs) but this seems to work for us.(12.2.15T5) Be sure to check the vip cpu .... and show cef drop and show cef not-cef-switched for the linecard involved ... BTW we also found that in an earlier release of IOS we needed to reboot the router to get this to work properly. Regards Mark -- Mark Vevers. mark(a)ifl.net / mark(a)vevers.net Principal Internet Engineer, Internet for Learning, Research Machines Plc. (AS5503)

1 0

Cisco IOS 12.3(2)T1 and warm-reload
by Timo Mohre 12 Sep '03

12 Sep '03

Is it just me or is the warm-reload feature not includet in 12.3(2)T1? As seen on Cisco CCO 12.3T Release Notes: Warm-Reload 12.3(2)T This feature was introduced. ^--- !!! 12.2(18)S This feature was integrated into Cisco IOS Release 12.2(18)S. Some Output: ip6.of#sh ver Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-JK9O3S-M), Version 12.3(2)T1, RELEASE SOFTWARE (fc2) ^--- !!!!! ip6.of#conf t Enter configuration commands, one per line. End with CNTL/Z. ip6.of(config)#w? % Unrecognized command Cisco CCO Release Notes: SUMMARY STEPS 1. enable 2. configure terminal 3. warm-reboot [count number] [uptime minutes] ^---- !!!!!!!!!!! 4. exit 5. show warm-reboot Kind Regards, Timo -- Timo Mohre / Network Engineer / Tiscali Germany Business Division / Robert-Bosch-Strasse 32 / D-63303 Dreieich Fon: +49(0)6103-916 930 / Fax: +49(0)6103-916 099 www.tiscali.de / www.tiscali-business.de / timo.mohre(a)de.tiscali.com

1 0

RE: What were we saying about edge filtering?
by Christopher L. Morrow 12 Sep '03

12 Sep '03

On Thu, 4 Sep 2003, Matt Ploessel wrote: > With the exception of RPC1918 reserved address space (note the previous > rootserver query problem), what amount of bogus sourced traffic is > stopped by bogons on a major backbone? I would say _alot_ of DDoS > traffic, however how hard is it for a DDoS client to know the bogon ip > ranges and skip them? I'm a very strong supporter of the bogons and > especially the bogons route servers without a doubt, but possibly null > route RFC1918 traffic to loopbackX(no ip unreachable, ACL etc.) and the > rest of the bogons to null0 just to so a general consensus/statistics of > hits on major backbones can be compiled. keep in mind its not destination addresses that are the problem here, BUT if it was, on an experiment (not a very smart one) we routed 0/1 to a lab system inside 701 once in 2001 (as I recall, so before nimda/code-red/blaster) and recieved +600kpps of garbage traffic as a result. Trying to acl/analyze/deal-with that flow was almost impossible... I'm not sure what you want to do with it today when our 'sinkhole' network is consistently handling +20kpps (5x previous) MORE of random garbage than 3 weeks ago, before blaster/nachi started to cause more pain :(

4 5

Cyber World Internet Services
by Hermann Wecke 12 Sep '03

12 Sep '03

I need a contact inside Cyber World Internet Services to report a security issue. The WHOIS reported phone number is an answering machine... NetRange: 66.206.0.0 - 66.206.31.255 TechHandle: AS1239-ARIN TechName: Slocombe, Alvin TechPhone: +1-509-343-2100 TechEmail: alvins(a)cwiservices.com TIA

1 0

Re: 92 Byte ICMP Blocking Problem
by Richard J.Sears 12 Sep '03

12 Sep '03

So, the choice is to go from dCEF to CEF or to not block the 92 byte packets at all....anyone have an idea as to which is the better route to take..? - Richard On Fri, 12 Sep 2003 10:59:54 -0700 "Matt Ploessel" <matt.ploessel(a)foundstone.com> wrote: > > >See http://www.cisco.com/warp/public/707/cisco-sn-20030820-nachi.shtml > >> > >>The policy-routing solutions works great in small routers (26xx, 17xx) > > >>and in 7200s. In 7500s it seems OK *UNLESS* dCEF is enabled, then it > >>does what you saw. I'm assuming it's dropping 92-byte TCP packets as > >>well as the ICMP echoes. You can see 1-packet flows of mail getting > >>dropped. > >> > >>Notice that the workaround cannot be used on GSRs because it causes > >>packets to be punted to the CPU... this is as bad a news as that it > >>doesn't work right on dCEF because we use GSRs or 7500s with dCEF > >>where the network is really busy. > > - Matt Ploessel > > > -----Original Message----- > > From: Richard J.Sears [mailto:rsears@adnc.com] > > Sent: Friday, September 12, 2003 10:43 AM > > To: Nanog > > Subject: 92 Byte ICMP Blocking Problem > > > > > > > > We started blocking 92 Byte ICMP packets on our ingress points on our > > core backbone routers. > > > > This was a recommendation from Cisco to help mitigate the > > effects of the > > Nachi worm. > > > > Since then, we have been hammered with customer complaints concerning > > the inability to talk to mail servers and ssh to their > > servers, as well > > as other weird network issues, all centering around the time > > we started > > blocking 92 Byte ICMP packets. > > > > Has anyone else seen this, and if so, is the only resolution > > to stop the > > blockage of 92 Byte ICMP Packets..? > > > > Thanks > > > > Richard > > > > > > > > ****************************************** Richard J. Sears Vice President American Digital Network ---------------------------------------------------- rsears(a)adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."

1 0

New prefix
by Stefan Baltus 12 Sep '03

12 Sep '03

Collegues, We've just been allocated a new RIPE block in the 82/8 range. This block has only been removed from the bogon list since november last year. It has been advertised from our AS a couple of hours now, but I still lack reachability through some networks. I can be wrong, but do some networks still filter on this range? It looks like either a bogonfilter, or a specific AS/prefix filter, but that seems a bit unlikely. Regards, Stefan -- Stefan Baltus <stefan.baltus(a)xbn.nl> XB Networks B.V. Manager Engineering Televisieweg 2 telefoon: +31 36 5462400 1322 AC Almere fax: +31 36 5462424 The Netherlands

4 3

Alert to Phone/Pager System
by Allan Liska 12 Sep '03

12 Sep '03

I am looking for a hardware/software solution to a problem and I am hoping someone has implemented something similar: A monitoring system notices an error and sends an alert to a system (the alert can be sent over POTS or SMTP). The system recevies the alert and sends out a message (Pager/POTS/SMTP/SMS) to a group of people in a pager rotation. The 1st person is paged, if no response is received the second person is paged and so on down the line until someone responds. I looked at the Dialogic's The Communicator: http://www.dccusa.com/products.html But, it is a little pricey. I also looked at VOCP System: http://www.vocpsystem.com/ But, the desision maker is a little skittish about open source projects. Does anyone know of a happy medium between these two systems that will fill the requirements outlined above? Thanks! allan -- Allan Liska allan(a)allan.org http://www.allan.org

3 2