CUCM Load Balancing Problem

Answered Question
Feb 9th, 2010
User Badges:

Hi All, I have two CUCM 6.1.3 ( I Pub & 1 Sub). All phones registers with sub and all phones use pub for tftp. I am trying to force some phones to register with pub but have no success even new CM group created has pub as first choice & sub as second choice. For your information during Failover in the past phones used to register with publisher and currently there are some ATA devices registered with pub for some reason. Any Ideas ???

Correct Answer by Rob Huffman about 7 years 1 month ago

Hey Mike,


You are always welcome my friend


The fact that these phones do not see CUCM1- Pub as "standby" is really the key

here it seems. I would take a WAG here that something in the network is preventing

these phones from reaching the publisher. If you are able I would try to "sniff" the

registration process on one of the affected phones.


Cheers!

Rob

Correct Answer by Rob Huffman about 7 years 1 month ago

Hi Mike,


Hope all is well my friend!


Just a note here, did you change the reference to the CCM Group in the Device Pool that phones in question are using? After changing the reference you will reset all the phones to push them over to the Pub



You should keep in mind that in the SRND for CUCM the recommendation is that IP Phones are not registered on the Publisher. The Publisher should be kept for dB processing etc. It is a "best practice" to have at least 3 servers in your cluster (1 Pub and 2 Subs).  When you define your Calmanager Groups you might setup Group 1 as;




Sub-1 (Primary)


Pub




And Group 2 as;




Pub (Primary)


Sub-1






In Group 1 the Pimary Callmanager is Sub-1 and in Group 2 the Primary Callmanager is the Pub. This is in reference to the phones registered with each Callmanager Group (with the highest one listed being the Primary or "First choice")




**This is not related to the Publisher (Primary Node) and its functionality in any way The wording can be a tad confusing at times.






This relationship is built via the Callmanager Group and Device Pool that the phones belong to.




You can specify where a phone registers by assigning it to a specific Device Pool this in turn will look at a Callmanager Group that lists a Primary, Secondary and Tertiary Callmanager server.




Here is some related info;




Cisco Unified CallManager groups and device pools represent logical groupings of devices that you can arrange in any way that you want. For ease of administration, make sure that all the devices in a group or pool share a common and easily identified characteristic, such as their physical location on the network.




You can also use Cisco Unified CallManager groups to establish redundancy (backup call processors) for the primary Cisco Unified CallManager in the group. A Cisco Unified CallManager group comprises an ordered list of up to three Cisco Unified CallManager servers. During normal operation, the first (primary) Cisco Unified CallManager in the group controls all device pools and devices that are assigned to that group. If the primary Cisco Unified CallManager in a group fails, control of the device pools and devices that are registered with the primary Cisco Unified CallManager transfers to the next Cisco Unified CallManager in the group list.








Cisco Unified CallManager Groups




A Cisco Unified CallManager group comprises a prioritized list of up to three Cisco Unified CallManagers. The first Cisco Unified CallManager in the list serves as the primary Cisco Unified CallManager for that group, and the other members of the group serve as secondary (backup) Cisco Unified CallManagers.




Cisco Unified CallManager groups associate with devices through device pools. Each device belongs to a device pool, and each device pool specifies the Cisco Unified CallManager group for all of its devices.




Cisco Unified CallManager Groups:


Call processing load balancing You can configure device pools and Cisco Unified CallManager groups to distribute the control of devices across multiple Cisco Unified CallManagers. These should be Subscriber servers






Device Pools


Device pools provide a convenient way to define a set of common characteristics that can be assigned to devices.






Hope this helps!
Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Rob Huffman Tue, 02/09/2010 - 05:59
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hi Mike,


Hope all is well my friend!


Just a note here, did you change the reference to the CCM Group in the Device Pool that phones in question are using? After changing the reference you will reset all the phones to push them over to the Pub



You should keep in mind that in the SRND for CUCM the recommendation is that IP Phones are not registered on the Publisher. The Publisher should be kept for dB processing etc. It is a "best practice" to have at least 3 servers in your cluster (1 Pub and 2 Subs).  When you define your Calmanager Groups you might setup Group 1 as;




Sub-1 (Primary)


Pub




And Group 2 as;




Pub (Primary)


Sub-1






In Group 1 the Pimary Callmanager is Sub-1 and in Group 2 the Primary Callmanager is the Pub. This is in reference to the phones registered with each Callmanager Group (with the highest one listed being the Primary or "First choice")




**This is not related to the Publisher (Primary Node) and its functionality in any way The wording can be a tad confusing at times.






This relationship is built via the Callmanager Group and Device Pool that the phones belong to.




You can specify where a phone registers by assigning it to a specific Device Pool this in turn will look at a Callmanager Group that lists a Primary, Secondary and Tertiary Callmanager server.




Here is some related info;




Cisco Unified CallManager groups and device pools represent logical groupings of devices that you can arrange in any way that you want. For ease of administration, make sure that all the devices in a group or pool share a common and easily identified characteristic, such as their physical location on the network.




You can also use Cisco Unified CallManager groups to establish redundancy (backup call processors) for the primary Cisco Unified CallManager in the group. A Cisco Unified CallManager group comprises an ordered list of up to three Cisco Unified CallManager servers. During normal operation, the first (primary) Cisco Unified CallManager in the group controls all device pools and devices that are assigned to that group. If the primary Cisco Unified CallManager in a group fails, control of the device pools and devices that are registered with the primary Cisco Unified CallManager transfers to the next Cisco Unified CallManager in the group list.








Cisco Unified CallManager Groups




A Cisco Unified CallManager group comprises a prioritized list of up to three Cisco Unified CallManagers. The first Cisco Unified CallManager in the list serves as the primary Cisco Unified CallManager for that group, and the other members of the group serve as secondary (backup) Cisco Unified CallManagers.




Cisco Unified CallManager groups associate with devices through device pools. Each device belongs to a device pool, and each device pool specifies the Cisco Unified CallManager group for all of its devices.




Cisco Unified CallManager Groups:


Call processing load balancing You can configure device pools and Cisco Unified CallManager groups to distribute the control of devices across multiple Cisco Unified CallManagers. These should be Subscriber servers






Device Pools


Device pools provide a convenient way to define a set of common characteristics that can be assigned to devices.






Hope this helps!
Rob

tcb_tcb_1975 Tue, 02/09/2010 - 16:06
User Badges:

Hi Rob,


All is well on my end and hope you are doing well !


Thanks for the information and I really appreciate your assistance.


I wanted to see if phone can register with publisher or not. As you suggested and I am aware that it's not a best practice to register phones with Publisher but during failover there were number of phones couldn't register with publisher when subscriber went down. So I am working on resolving that issue.


I created new CM group for this testing and put publisher at the top of the list & subscriber as the second choice as we have only 2 CUCM (will be installing another subscriber soon hopefully). I did create a new device pool and configure it to use new CM group. I defined a new phone and configure it to use new device pool but phone registers with subscriber for some reason but not publisher.


I checked the phone settings --> device configuration and see CM2 (subscriber) as "active" but CM1 shows IP address of Publisher but doesn't show "standby" word. I am not sure if this information helps

Correct Answer
Rob Huffman Thu, 02/11/2010 - 06:11
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hey Mike,


You are always welcome my friend


The fact that these phones do not see CUCM1- Pub as "standby" is really the key

here it seems. I would take a WAG here that something in the network is preventing

these phones from reaching the publisher. If you are able I would try to "sniff" the

registration process on one of the affected phones.


Cheers!

Rob

tcb_tcb_1975 Thu, 02/11/2010 - 19:20
User Badges:

Hi Rob,


Thanks for your assistance on the matter. Issue is resolved now by restarting the CM Service.Just for my knowledge I would mind learning the process you use to sniff packets going in and out from phone. I am aware of setting which needs to be enabled on phone using the device settings etc. but thats it. I am familar with enabling span on switch port and familiar with Local span & R Span.


Looking forward to your suggestioon which is easy to use tool and phone span process..


Regards,


Mike

Actions

This Discussion