cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
356
Views
0
Helpful
1
Replies

CUCM 10.5 unexpected de-registration issues

_Job3836_
Level 1
Level 1

Hello!

 

We have a CUCM 10.5 Cluster consisting of PUB and 3 SUBS. 

 

PUB and SUB 1 are at site A, SUB 2 at site B, SUB 3 at site C.  We have a CM Group (CMG3) with SUB 3, SUB 1, SUB 2 - in that order. The Device Pool that is assigned to all the devices (gateways and end-points) at site C is associated to CMG3 and all the devices are successfully registered to SUB 3, which as stated above, is local at site C. 

 

The problem we are having is that whenever the WAN goes down (or utilization is peaking) at site A, site C's PSTN call processing goes down.  The PSTN gateway at site C is confirmed to be registered to SUB 3 so there is a lack of understanding as to why a WAN problem at site A would impact site C.  There have been a few times when the WAN utilization has pegged at site A, and IP phones de-register from SUB 3.  This is completely unexpected behavior since site C's LAN is stable and the on-site SUB 3 has no connectivity issues to the devices registered to it, as they are on the same subnet.

Any ideas on what could cause this abnormal behavior and what we can do to correct it?

 

Many thanks!

1 Accepted Solution

Accepted Solutions

_Job3836_
Level 1
Level 1

Just wanted to drop in an update in case someone encounters similar behavior.

 

As eluded to in the original post, the issue impacting Site C's call processing was apparently caused by WAN link saturation at Site A, where the PUB is deployed.  Although, Site C's Device Pool was assigned to CMG3 which specified SUB 3 as primary (SUB 3 local to Site C), the TFTP server referenced by the devices in this DP was the PUB (sitting behind the intermittently saturated link).  Once the primary TFTP server was changed to reference another SUB, call processing stabilized. 

 

View solution in original post

1 Reply 1

_Job3836_
Level 1
Level 1

Just wanted to drop in an update in case someone encounters similar behavior.

 

As eluded to in the original post, the issue impacting Site C's call processing was apparently caused by WAN link saturation at Site A, where the PUB is deployed.  Although, Site C's Device Pool was assigned to CMG3 which specified SUB 3 as primary (SUB 3 local to Site C), the TFTP server referenced by the devices in this DP was the PUB (sitting behind the intermittently saturated link).  Once the primary TFTP server was changed to reference another SUB, call processing stabilized.