Several IP phones unregistered per day

Unanswered Question
Aug 1st, 2006
User Badges:

Hi to all,


I know that few similar errors has been reported in this forum but I didn't find any usefull answer. In our CCM setup (two CCM servers v. 4.1 (3) SR1; arround 600 phones )we have daily reported problems with IP phone resets. Error in event log of CCM is known:


Error: DeviceUnregistered - Device unregistered.

Device name.: SEP00179529558B

Device IP address.: 10.X.X.X

Device type. [Optional]: 30007

Device description [Optional].: Dejan Bobicanec 532

Reason Code [Optional].: 8

App ID: Cisco CallManager

Cluster ID: CCM1-Cluster

Node ID: CCM1

Explanation: A device that has previously registered with Cisco CallManager has unregistered. This event may be issued as part of normal unregistration event or due to some other reason such as loss of keepalives.

Recommended Action: No action is required if unregistration of this device was expected..


I activated tracing on publisher and didn't find any usefull entries like:


08/01/2006 14:32:03.959 CCM|Closing Station connection DeviceName=SEP00179529558B, TCPPid = [1.100.132.2069], IPAddr=10.x.x.x, Port=0, Device Controller=[1,118,349]|<CLID::CCM1-Cluster><NID::CCM1><CT::1,100,132,2069.1><IP::><DEV::>

08/01/2006 14:32:03.959 CCM|DeviceUnregistered - Device unregistered. Device name.:SEP00179529558B Device IP address.:10.x.x.x Device type. [Optional]:30007 Device description [Optional].:Dejan Bobicanec 532 Reason Code [Optional].:8 App ID:Cisco CallManager Cluster ID:CCM1-Cluster Node ID:CCM1|<CLID::CCM1-Cluster><NID::CCM1><CT::AlarmSEP00179529558B><DEV::SEP00179529558B>

08/01/2006 14:32:03.959 CCM|DeviceManager:initialized_DeviceStop Name=SEP00179529558B Key={B2E94DEE-D482-4FD8-925C-D8C12250FD31}|<CLID::CCM1-Cluster><NID::CCM1><CT::1,100,132,2069.1><IP::><DEV::>



KeepAlive messages has been sent properly every 30 sec. After phone reset, I can find log entry for "device" like "Last=Initialized".


I've read, that some of you already opened a TAC case for this problem and I'm interested if you got some usefull hints. Is it maybe BUG in v. 4.1 (3) SR1?



Many thanks for answers



Andrej

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
dgahm Tue, 08/01/2006 - 06:36
User Badges:
  • Blue, 1500 points or more

We are on 4.1(3) SR3a and had similar symptoms until we changed our QOS config to use IP precedence 3 and AF31 for control traffic. Cisco changed this with 4.1.


Please rate helpful posts.

jcustard Tue, 08/01/2006 - 10:32
User Badges:

Any correlation to high switch traffic determined for the phone resets noted?


After going to CCM4.1.3sr3a, we made the QoS changes noted below.


--Jeff


-----


Before the CCM4.1 upgrade, we had:


switch> (enable) show qos maps runtime ipprec-dscp-map

IP-Precedence - DSCP map:

IP-Prec DSCP

------- ----

0 0

1 8

2 16

3 26

4 32

5 46

6 48

7 56

-----------------------------------

switch> (enable) show qos maps runtime cos-dscp-map

CoS - DSCP map:

CoS DSCP

--- ----

0 0

1 8

2 16

3 26

4 32

5 46

6 48

7 56

-----------------------------------


but after the change they look like this now:


switch> (enable) set qos cos-dscp-map 0 8 16 24 32 46 48 56

QoS cos-dscp-map set successfully.

switch> (enable) show qos maps runtime cos-dscp-map

CoS - DSCP map:

CoS DSCP

--- ----

0 0

1 8

2 16

3 24

4 32

5 46

6 48

7 56


-----------


set qos ipprec-dscp-map 0 8 16 24 32 46 48 56


now they all have:


switch> (enable) set qos ipprec-dscp-map 0 8 16 24 32 46 48 56

QoS ipprec-dscp-map set successfully.

ml-16c-c1-gs> (enable) show qos maps runtime ipprec-dscp-map

IP-Precedence - DSCP map:

IP-Prec DSCP

------- ----

0 0

1 8

2 16

3 24

4 32

5 46

6 48

7 56


------------


this one is ok as it encompasses both:


show qos maps runtime dscp-cos-map

DSCP - CoS map:

DSCP CoS

-------------------------------- ---

0-7 0

8-15 1

16-23 2

24-31 3

32-39 4

40-47 5

48-55 6

56-63 7

----------------


From my notes from our pre-upgrade checklist:


We used to base our QoS configs on:


*Voice bearer traffic (RTP) is marked with DSCP=EF(46) and CoS=5

*Voice signaling traffic is marked with DSCP=AF31(26) and CoS=3


But now that Cisco has moved toword not assigning a drop

priority at all for call signaling (i.e., from AF31 to CS3),

we need to update our assumptions and configs as well to:


*Voice bearer traffic (RTP) is marked with DSCP=EF(46) and CoS=5 [no change]

*Voice signaling traffic is marked with DSCP=CS3(24) and CoS=3 [CS3 now]


So, put another way, we used to have:


DSCP value=26 (011010) and DSCP class name=af31 [and map that to our CoS 3 value]


but we now have:


DSCP value=24 (011000) and DSCP class name=cs3 [and that is now mapped to our CoS 3

value]


So our new Catalyst standard should be:


set qos cos-dscp-map 0 8 16 24 32 46 48 56

set qos ipprec-dscp-map 0 8 16 24 32 46 48 56


which makes the change from 26 to 24 accordingly (i.e.,

from what we've done in the past).


We also changed all the VG248s to use 24 instead of 26 for their "Control traffic"

DSCP QoS value (under Configure->Network Interface->Set DSCP QoS values; "media

traffic" remains unchanged at 46).

8a.skamen Tue, 08/01/2006 - 23:16
User Badges:

Hi,


thank you for all answers. I will perform deep reserch on this problem next days:

- sniff traffic on both CCM and IP phones subnet

- check debug logs in CCM servers

- check influence of DHCP lease / release process

- enable QoS on L2 following recommendations from Mr. Jeff.


I will keep informed you about results.


I was trying to find explanation about technical reasons for automatic Phone resets. As I understand correctly if everything is OK with switch port an power supply, only keep alive messages could be a reason. CCM is sending KA packets every 30 sec. If phone doesn't receive them, it will reset itself.


Are there any other possible reasons beside human activities on equipment?



Thank you for answers again and best regards



Andrej

thardyanto Tue, 09/26/2006 - 15:08
User Badges:

Hi Andre


Did you find any usefull finding ?


Cisco seems doesn't much about this issue


Regards,


Tony

gpulos Tue, 08/01/2006 - 06:47
User Badges:
  • Blue, 1500 points or more

not heard of any bug lin 4.13 that causes this.


many reasons can contribute to why a device unregisters.


most phone unregisters are the result of a network connectivity issue between the ccm and the phone but not always.


search the SDL traces for more alarms to hopefully narrow down the scope of the problem.


verify whether or not more than one phone affected. if so, try to see if these devices are isolated to one part of the network. or perhaps all the problematic phones are registered to a specific call manager, if so, check that system for connectivity or delay issues.

jcustard Tue, 08/01/2006 - 11:22
User Badges:

Andrej:


Did you check to see if these phone resets correlate to DHCP lease expirations?


Jeff

Actions

This Discussion