Hi CPU and IO utilization

[dfoss]

I have a 3640 router where the CPU and IO utilization are very high. Process utilization was 21 percent and interrupt utilization is 49%. Turning on CEF has helped quite a bit with the process utilization for the interrupts are still quite high. Could this case significant framing errors and CRC errors on serial links? I have several T1's coming into this router where I'm seeing errors but other T1's coming into another router sitting right next to it are running quite clean.

Thanks for your consideration.

[murphyj]

Hi, i know for sure the cpu on the 3640 is weak... my recomendation is any interface that has high errors on it are causing the high high i/o. the errors on the T1's may be due to clock drift, clock source or other carrier related issues.

can you post a sh service-module.

thanks

[dfoss]

Unfortunately this box crashed while I was working on it so I lost a bunch of stats but here is the output from the past 45 minutes or so:

Module type is T1/fractional

Hardware revision is 0.80, Software revision is 0.2,

Image checksum is 0x73D70058, Protocol revision is 0.1

Receiver has no alarms.

Framing is ESF, Line Code is B8ZS, Current clock source is line,

Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.

Last module self-test (done at startup): Passed

Last clearing of alarm counters 00:43:31

loss of signal : 0,

loss of frame : 0,

AIS alarm : 0,

Remote alarm : 0,

Module access errors : 0,

Total Data (last 3 15 minute intervals):

0 Line Code Violations, 6 Path Code Violations

0 Slip Secs, 1 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 1 Severely Err Secs, 0 Unavail Secs

Data in current interval (760 seconds elapsed):

0 Line Code Violations, 0 Path Code Violations

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Module type is T1/fractional

Hardware revision is 0.96, Software revision is 0.2,

Image checksum is 0x73D70058, Protocol revision is 0.1

Receiver has no alarms.

Framing is ESF, Line Code is B8ZS, Current clock source is line,

Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.

Last module self-test (done at startup): Passed

Last clearing of alarm counters 00:43:31

loss of signal : 0,

loss of frame : 0,

AIS alarm : 0,

Remote alarm : 0,

Module access errors : 0,

Total Data (last 3 15 minute intervals):

0 Line Code Violations, 0 Path Code Violations

1 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Data in current interval (761 seconds elapsed):

0 Line Code Violations, 0 Path Code Violations

0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Thanks,

Daniel

[murphyj]

ok i see there are some slips, this can be caused if both sides of the circuit are set to line. please set on side to internal.

"service-module t1 clock source internal"

then do a clear "service-module x/x" which will force a reset of the card. then please check and see if the slips go away.

p.s. a slip can also cause frame errors.

one other note. follow the advice of the other poster who said to harden against worms. there was a recent one that used a sasser varient. look for port scanning on 445

MURF

[spremkumar]

hi

in addition to the previous posters msg do enable cache flow under tht particular interface which ur suspecting to be the culprit and chek up the flow stats also the geninuity of traffic being pumped to ur box.

Do try to harden ur box from the several well known worms,attacks which might also help u out...

regds