High CPU process Cisco 1760

[e-alvarez]

Hi, all.

Before getting into the subject, I wish all of you a happy new year.

We have about 1,500 Cisco 1760 routers running IOS 12.3(9) (c1700-bnr2sy7-mz.123-9.bin), although specific hardware varies. The problem we´re having is with only one that has a very high cpu process usage.

The log is full of the following messages:

Dec 26 11:30:05.094 CST: %PQUICC-1-LINEFLAP: PQUICC(0/1), Excessive modem control changes

Dec 26 11:30:45.030 CST: %PQUICC-1-LINEFLAP: PQUICC(0/1), Excessive modem control changes

We have:

a) unconfigured DDR, unconfigured the async line and even discconected the DDR modem

and still are having the above messages, which rules out a problem with a bad cable/modem combination

b) checked the "Troubleshooting high Ip Input" page at Cisco. (CEF seems to be working ok)

c) changed the router (along with its memories)

d) compared the router config. with at least six other routers, checking ok.

However, we have not been able to lower the cpu process usage.

Any ideas as to what might be causing the problem?

More info on attached file.

[spremkumar]

Hi

i would prefer changing the cable or swapping the modem which may be also a potential reason for the above mentioned error.

do refer the following note taken out from cisco..

%PQUICC-1-LINEFLAP: PQUICC([dec]/[dec]), Excessive modem control changes

The system has received too many modem control signal interrupts. Modem control signals are hardware handshake signals between DTE and DCE. The signals include either a DCD or a DSR, or both a DCD and a DSR.

Recommended Action:

Check the serial interface cable. The error can occur if the cable is disconnected or has come loose and is picking up noise. If the cable appears to be connected correctly, check the equipment connected to the cable.

Also can u confirm the ios code being run in other routers ? is it similat to the one being run in this hardware ??

Again u do have EIGRP and EBGP configured in ur 1700 tht will also have its own toll on the CPU.

BTW is it a CCV error representing 2 EBGP process in ur attachment ??

regds

[e-alvarez]

Thanks for your answer.

As I said, the cable that goes to the DDR modem has been disconnected from the router for more than 15minutes and I still got the same errors. That´s why I changed the router, thinking that it might be a problem with the AUX port.

The IOS version is the same throughout our network, with the same topology in all of our branch offices. (We are one of the two largest banks in Mexico), and the config has been standarized as well. I had read the above recomendation from Cisco, but the thing that baffled me is that even with the modem cable disconnected, two different routers, with the same config as many other routers are doing the same thing.

We are running EBP with the primary link and EIGRP only when the backup (Async Int) comes up.

The average cpu process for our routers is about 2-3%

More ideas?

Regards,

[sarbjeet-dhillon]

Seems like an interesting problem you have there.

Have you tried swapping out with a higher performance router?

Are there any other symptoms like slow telnet sessions, performance slow?

Sounds like you may have to raise a case with Cisco TAC, might be a bug!

[e-alvarez]

Thank you for your answer Sarbjeet.

The contract we have with our provider allows only to swap only same-model boxes or other hardware, Funny thing is, we have the same topoloy as this one replicated over 1500 times (same model boxes IOS etc.,).

Oh well, we´ll just have to open a case with Cisco (through our provider, of course :-( )

Happy new year to all!

Regards,

Eduardo Alvarez

[e-alvarez]

Eureka! We found the problem.

It seems that Serial 0/1 had a cable attached, but no end device on the other end. It was used for a couple of ATM`s using SDLC. We had the office disconnect everything and reconnect cable by cable. The WAN link was never diconnected. When we asked why there was no ATM on the other side, we were told that those ATM had been migrated from SDLC to TCP (Ethernet NIC), but they had not removed the cable.

Maybe the problem was with some of the signals not been properly grounded. Anyway, Cisco could also update this info. Could have saved some days and many headaches!

Regards,

Eduardo.