High CPU for CTS v1.9.1 Endpoints once migrated to TMS

[MARK BEDWANI]

Hi Everyone,

Since migrating all endpoints over to TMS 14.2.1 from CTSman, we are randomly getting the follwing SNMP traps from the CTS endpoints.

XYZ@ABC.com.au - SEV:1 - Broken - HIGH CPU UTILIZATION - Fri 16 Aug, 2013 - 09:26:23 - High CPU Utilization. The utilization of 86% for CPU instance 768 named CPU: 768 has exceeded the 85% threshold on model XYZ@ABC.com.au.
for more than the acceptable time period. (event [0x00010f03]) - SpectrumRouter

&

XYZ@ABC.com.au - SEV:1 - Broken - No Associated Text - Fri 16 Aug, 2013 - 09:25:52 - High Aggregate CPU Utilization. The average CPU Utilization of 86% for all CPU instances exceeds the 85% threshold on model XYZ@ABC.com.au (event [0x00010f07]) - SpectrumRouter

Does anyone know what CPU 768 means & why this would be happening ? CTS v 1.9.1.

Regs Mark.

[Danny Meyer]

Mark.

I have not a direct solution for you, but I heard through TAC about such an issue in the 1.9er version.

Had a very bad behaving TX9000 and one of the questions was, if I manage it with TMS. To my question the answer was that they know about high CPU issues when TMS is involved and 1.9.x

Seems to fit your picture.

Not sure, but with anything higher than 1.9.3 it should be better.

Regards

Danny

[Marius Nedregaard]

Hi,

Please have a look at the following PSIRT notice,

http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-1246

It refers to bug: CSCug77610

From the bug: ( subject to have changed since i pulled the data, please use the bug toolkit to get the latest update )

Symptoms:

The CTS unit become unresponsive and active calls are dropped. The unit is left without available memory

Conditions:

The issue is seen when the unit is managed by a TMS system.

Due to the nature of this issue this could be exploited to create a denial of service

This issue is affecting software version 1.9 and higher

1st Found-In

1.10(0)

1.9(0)

1.9(1)

1.9(2)

1.9(3)

1.9(4)

1.9(5)

Fixed-In

1.10(1)

1.9(6)

1.10(2)

6.0(2)

6.0(3)

Please upgrade your endpoints to 1.9.(6) and see if the issue is mitigated.

//Marius