CME 7 cm-closed-tcp

Unanswered Question
Jan 28th, 2009

Hello,

I have a cme 7 install at a customer that has been running great, until about 3 days ago. The only change that i know that has taken place is the customer piggybacked their PC to the phone PC port. Prior to this, they were all on seperate ports. I configured qos, wrr-pq, to only allow 5% to rogue applications, and 50% to voice. This seems to have sedated the issue a bit, but this may also be coincidence. Today, only a single phone has reset, prior to my config of qos, all phones reset. I cannot find any documentation on causes of this error. Has anyone experienced this or know where I should start looking?

Thank,

Mike

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Erick Bergquist Wed, 01/28/2009 - 23:48

That means the CME closed the TCP connection for whatever reason, could be keepalive, etc.

How is the processor usage on the CME router?

Seems like you found the issue for most part, which is network traffic effecting the phones.

Are the PCs and phones in the same vlan, and are the switch ports configured with the typical phone/PC setup these days?

interface ...

switchport mode access

switchport access vlan data#

switchport voice vlan voice#

etc..

Phones on latest phoneload?

Michael Mistretta Thu, 01/29/2009 - 05:11

The processor is fine, around 6%

The ports are clean, with the exception if higher traffic volumes, but I have seen the phones run fine with larger amounts of traffic. The other oddity I forgot to mention is this happens at the same time everyday, around 4PM. I've asked the customer if there is some sort of transaction that take place at that time and I am told there is not.

The ports are configured correctly, and different VLANs

Nicholas Matthews Thu, 01/29/2009 - 06:14

The IP phone will send SCCP keepalives every 30 seconds. The CME will ACK these.

If the CME doesn't receive these keepalives, the phone will unregister with TCP errors. I believe if it misses 3 keepalives it unregisters, but it could be up to 5.

You can start by getting a packet capture behind the IP phone and seeing what you see there. You could also do a SPAN session on the entire voice VLAN, and see what happens on the wire at 4pm, which is what I would suggest doing.

Check the CPU utilization of CME at 4pm 'show proc cpu history' is the best command to use for this.

hth,

nick

Michael Mistretta Fri, 02/13/2009 - 13:42

I am still not sure what the exact problem is, but they disconnected the PCs from the phones and now all seems to be well. Can only assume that the PCs were generating too much traffic, or their infected...

Actions

This Discussion