Router CPU at 95%

[smuneio]

I've been having issues with my router since the W32/Blaster. The CPU will sit at about 90% throughout the day. I have about 50 out of 1000 customers infected with the virus. I have implemented the access lists on the ingress of each interface but that doesn’t seem to help. We are in the process of turning customers off but does anyone know what I can do right now. I have 4 Serials ports pointed to the internet and all customers feed off fastethernet0/0. Right now I'm running 12.2(6j). The problem is the fast Ethernet interface. I'm getting about 11 MB worth of traffic but 7 MB is W32 which is being blocked. Here is my config:

Building configuration...

Current configuration : 2652 bytes

!

version 12.2

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

!

memory-size iomem 10

ip subnet-zero

ip icmp rate-limit unreachable 5

!

!

call rsvp-sync

!

!

interface FastEthernet0/0

description LAN side JPI

ip address 10.1.0.1 255.255.252.0

ip access-group 115 in

ip helper-address 10.1.0.3

no ip unreachables

ip nat inside

speed auto

full-duplex

!

interface Serial0/0

ip address 172.16.10.2 255.255.255.252

no ip unreachables

ip nat outside

encapsulation ppp

no ip mroute-cache

no fair-queue

!

interface Serial0/1

ip address 172.16.11.2 255.255.255.252

no ip unreachables

ip nat outside

encapsulation ppp

no ip mroute-cache

!

interface Serial1/0

ip address 172.16.12.2 255.255.255.252

no ip unreachables

ip nat outside

encapsulation ppp

no ip mroute-cache

!

interface Ethernet1/1

no ip address

shutdown

half-duplex

!

interface Serial1/1

ip address 172.16.13.2 255.255.255.252

no ip unreachables

ip nat outside

encapsulation ppp

no ip mroute-cache

!

ip nat translation timeout 900

ip nat translation tcp-timeout 3600

ip nat translation icmp-timeout 100

ip nat pool JPI 66.193.237.25 66.193.237.26 netmask 255.255.255.252

ip nat inside source list 7 pool JPI overload

ip classless

ip route 0.0.0.0 0.0.0.0 Serial0/0

ip route 0.0.0.0 0.0.0.0 Serial0/1

ip route 0.0.0.0 0.0.0.0 Serial1/0

ip route 0.0.0.0 0.0.0.0 Serial1/1

no ip http server

ip pim bidir-enable

!

access-list 7 permit 10.1.0.0 0.0.3.255

access-list 115 deny icmp any any echo

access-list 115 deny icmp any any echo-reply

access-list 115 deny udp any any eq 135

access-list 115 deny tcp any any eq 135

access-list 115 deny udp any any eq tftp

access-list 115 deny udp any any eq netbios-ns

access-list 115 deny udp any any eq netbios-dgm

access-list 115 deny tcp any any eq 139

access-list 115 deny udp any any eq netbios-ss

access-list 115 deny tcp any any eq 445

access-list 115 deny tcp any any eq 593

access-list 115 deny tcp any any eq 5678

access-list 115 deny tcp any any eq 4444

access-list 115 deny icmp any any

access-list 115 permit ip any any

dialer-list 1 protocol ip permit

dialer-list 1 protocol ipx permit

!

dial-peer cor custom

!

!

Here is my Fastethernet int:

FastEthernet0/0 is up, line protocol is up

Hardware is AmdFE, address is 0010.7bfe.0f81 (bia 0010.7bfe.0f8

Description: LAN side JPI

Internet address is 10.1.0.1/22

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 7/255, rxload 25/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Half-duplex, 100Mb/s, 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 74/75, 1416069 drops

5 minute input rate 10122000 bits/sec, 8659 packets/sec

5 minute output rate 3087000 bits/sec, 555 packets/sec

207961875 packets input, 1438543581 bytes

Received 159241 broadcasts, 0 runts, 0 giants, 0 throttles

1134 input errors, 1118 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog

0 input packets with dribble condition detected

14195917 packets output, 985709767 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Has anyone else encountered this??

[milan.kulik]

Hi,

I don't know what else could you do while filtering the Blaster traffic in the ingress port.

I'd just tune your access-list 115 a little:

It starts with

access-list 115 deny icmp any any echo

access-list 115 deny icmp any any echo-reply

and there is another line

access-list 115 deny icmp any any

near the bottom.

So I'd remove the initial two lines and move the bottom line to the beginning of the ACL. This might make the ACL a little more efficient and maybe decrease the CPU load a little.

Regards,

Milan

[rabeder]

hi,

you should configure "ip cef"

this should decrease your cpu-load

[glen.grant]

What are you running on your FE that you have to run it in half duplex . Looks like you configured it for auto but it came in at half duplex instead of full . To me it just looks strange on a half duplex line that has no collisions at all , if all possible I would change this to full on both sides .

[prafuljaded]

You can enable CEF as told before.

ip cef

int fa0/0

ip route cache flow

Issue the command "show ip cache flow"

to check the Source IP address and Protocol (ICMP-0800 & 0000), you can identify the PCs causing high ICMP traffic pointing to Null 0.

[olorunloba]

Well, you should also tweak the access list that defines your NAT translations. Most likely, you are having the high CPU traffic due to some of the W32 traffic being translated. My advice will be to use an extended access-lists instead of the standard (7), and to deny the all possible W32 traffic from being translated.

[thisisshanky]

Be careful before enabling route cache flow, coz it can increase the load on the router.

[godlam]

I have same case with you attrack by Virus. Do you feel that also apply ACL on the serial interface too? It will block the virus from the outside. Thanks.

Regards

Godwin

[rehan]

Filter both incomming and outgoing traffic.

your access list shows that you have read the following white paper at cisco.com for MS-Blast

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801aedd6.shtml

Asim Khan

[monta001]

I have also encountered the effects of this worm. What this does is send a huge number of small packets which overfills your interface buffers. You can check this with "show buffers" and have a look at the small buffers. There are a number of trims which causes the router to drop packets and increase CPU utilisation to about 95 % or even more. You can tweak the size of the buffers, however I would find the source and block traffic at source.

[mark.withington]

I had major problems on our network and found blocking the ports never helped so i setup and access-list to filter the packets and log the IP where they came from, this helped as we could find the infected machines faster and shut them off the network. (This also helps with Nachi)

Here's a copy of the simply access list -

ip access-list extended blaster

permit icmp any any echo log

permit icmp any any echo-reply log

permit icmp 0.0.0.0 255.255.255.0 any echo log

!

logging trap debugging

!

route-map blaster permit 10

match ip address blaster

match length 92 92

set interface Null0

Also on your interfaces add this command -

ip policy route-map blaster

[smuneio]

So if I allow the ICMP packetes to come in and then route them to Null0, will this increse the CPU of the router?

[mark.withington]

No it won't increase the CPU but if you do 'show log' then it will give you the IP of the machines that are infected with either blaster or nachi then you can trace the MAC of the machines to switch ports and lock down the ports. This was the only effective way i found of reducing the cpu load.

[prafuljaded]

I think the CPU utilization of the router increases when the ICMP traffic hits it and the router drops it(Null 0),its better you identify the machines that are affected by enabling access-list logs as said above and shut them off the network