Why do we assign CallManager groups to Route Lists? To phrase it differently, why is there a place for CallManager Group on the Route List configuration page? I don't understand why a route list would need to register (or be controlled by) a particular CallManager server.
This worries me. What happens if all the CallManager servers in the designated group are done. Does that mean the route list will stop working? That's kinda dumb, if you ask me, but then again I'm new here. What do I know. :-)
This is particularly strange because you can only have three servers in a CallManager group but you can have 8 or 9 servers in a cluster. Let's assume that all three servers in one CCM Group are unavailable. Would that mean that all route lists assigned to that group would stop functioning even though several other servers are available?
I don't get it. This is very confusing to me. I can understand why phones and gateways need to register to a CallManager, but I don't understand why a route list needs to.
The reason is the same, for redundancy and load balancing purposes. Just like a phone and a gateway, the route list also need to talk to the Callmanager service. The Callmanager group setting defines which Callmanager service a route list can register with.
In the earlier versions of Callmanager, each route list would talk to only the local Callmanager service. But in the newer releases, because of the Callmanager group feature, each route list can talk to 3 Callmanager services. Better redundancy.
Yes, you are right. If all the CCM servers are down, then that route list is not available for service. But what are the chances of all 3 servers to go down. Also if that happens, then most of your phones and gateways will also be down, as their CCM group also has only 3 CCM's.
Hope that helps.
I appreciate the response but I still don't understand why a route list would need to "talk" to the CallManager service. Isn't this just part of the dial plan? Aren't all CCMs aware of the dial plan? Why would a portion of the dial plan stop working on one server just because some other servers went down? That seems really weird to me and it adds a layer of complexity that I wasn't counting on in our upcoming IPT roll-out.
I guess that the best practice is to make sure that all the devices at a remote site use the same CallManager group as any route lists associated with that site. Otherwise, it would be possible for the devices to still be registered to a CallManager--and therefore still able to function--but they'd be locked out from dialing anything because their route plan has disappeared.
I really don't like this. I'm looking over CCO to find something that explains this in more detail but I'm not having much luck.
I've been thinking about this some more and I'm still confused. :-( I just don't understand why an element of the dial plan would need to register with a particular CallManager.
It seems to me that the dial plan is just a collection of pointers. In other words, a route pattern points to a route list, which points to a route group, which points to a gateway or trunk. These are just lists. Why would a list need to register with a server?
If anyone can explain this to me, I'd really appreciate it. I've sent an email off to some Cisco engineers about it but I haven't received a response yet.
Okay, I'm beginning to get a little frustrated. I've spoken with several Cisco engineers and two very experienced engineers from a Cisco Gold partner, and no one understands why we have to associate a CallManager Group with a Route List.
I'm beginning to suspect there's a reason why I'm not getting a straight answer. The answer is probably one of the following:
1. Even we don't know. Sorry.
2. We know the answer, but you're really not going to like it so we're not going to tell you.
I have received some input from Cisco under NDA (which I obviously won't share here) but it still didn't answer my actual question.
So, I'm still confused. Do any of you know the answer to this question?
This started in 4.0(2). I did verify this in my lab (2 servers). If the CM group includes one CM, when that CM goes down, route list unreg's.
This is from 4.0(2) release notes:
Route List Redundancy Configuration
With Cisco CallManager release 4.0(2), route list handling and redundancy change to improve performance. Pre-4.0(2) implementations included route lists on every server in a cluster. After upgrade to release 4.0(2), only one instance of the active route list configuration associates with a Cisco CallManager group. This change requires that you configure the Cisco CallManager Group(s) to maintain load balancing and redundancy.
After you upgrade the Cisco CallManager servers to 4.0(2), and if two or more primary CallManager servers exist in the cluster, the system creates new CallManager Group(s) with a default name of "RLCMG_
One instance of the active route list configuration then attaches to the primary Cisco CallManager server in the first CallManager Group. New CallManager Groups get assigned to the existing route list configuration by using a round-robin algorithm to ensure redundancy.
To complete the upgrade, you must perform the following tasks:
1. Create new CallManager Group(s) to replace the default CallManager Group(s) that are named "RLCMG_
2. Evaluate the CallManager Group and route list configuration for load balancing and redundancy.
3. Reconfigure the route list(s) to the user-created CallManager Group(s).
4. Delete the default CallManager Group(s).
Caution These activities drop all dependent active calls and cause significant overhead while you perform the reconfiguration.
For more information, refer to http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee30571.
I believe that the idea behind this is that this reduces bursts of signaling around route list coordination in larger clusters, increasing the number of outbound calls in heavy traffic. So it seems that some redundancy was sacrificed in the name of performance.
adignan - berbee
Hmm...I'm beginning to think a little bit less of Cisco's redundancy. They make a big deal out of the fact that you can have 8 or 9 servers (can't remember which) in a cluster, but it seems like that's misleading.
CallManager Groups can only have three servers in them. That's something else that I don't understand because it's very limiting. That means that if three particular servers go down, a remote site might fall back into SRST mode even if there are 4 or 5 other servers that could potentially be used.
Now I hear that not only does the CM group limit the number of servers available to endpoints, it also applies the same limitation to your route lists. I'm still trying to understand why a route list needs to register to a server in the first place.
This seems like a pretty big deal to me. It's somewhat avoidable by making sure that any route lists for a location use the same CM group as the devices at that location, but it again points out the illusion that a CallManager system can be redudant across an entire cluster. This obviously isn't true if you can't even maintain your dial plan if certain servers go down.
I'm a little frustrated by this. We spent 18 months going through an RFP with multiple vendors. We eventually selected Cisco, but this is the something I wish we had discovered prior to purchasing the system so I could have explored the ramifications a bit more.
I feel like I was sold a car that supposedly has 350 horsepower only to find out that I can only really use 150 at any given time.
Thanks for your help!
I can understand your frustration but I think you will find that as you go through the design phase of your project benefits will outweigh the caveats.
The fact that eight servers is supported in a cluster is great, but you are correct there are limitations. I think its a bit misleading in that most people with an implementation that consists of 8 servers will have the cluster split into different servers providing different services. Rarely will you find a cluster of 8 with one publisher and 7 call processing servers.
In a larger cluster like this you will most likely have a publisher, tftp server, mtp resource, and call processing servers.
The reason eight servers is supported and marketed is really to increase performance by allowing you to split up services and not necessarilly to mean that you have 8 completely redundant servers. The SRND does a good job showing this design but I think people can be mis-lead.
Again, I am glad you chose to go with Cisco and if your implementation follows the SRND and you have a good partner doing the implementation I think you will be satisfied with the outcome.
Keep posting as there is a great community out here on NetPro that is always here to help. :)
adignan - berbee
This must not be a big issue in practice or we probably would have heard about it before now. Now that I understand these issues a bit better, I'm of the opinion that a CallManager cluster is designed to have no more than three servers for call processing. Issues such as this route list problem--and the fact that you can only have three servers in a CM group--indicate to me that you run the risk of running into some weirdness if you have more than three call processing servers.
I think Cisco is to blame for this marketing issue, though. They claim 60,000 phones per cluster, right? That's eight MCS-7845 servers, all doing call processing. I think a non-marketing answer might be that you're better off keeping the maximum phones per cluster to 22,500 if you're using MCS 7845 servers.
You can support more than that, obviously. I just think that it should be more clear what risks you run when you go beyond three call processing servers.
Thanks for your help!
I've been thinking about this some more and I think I understand why the route list has to be affiliated with a CM group. I was thinking about what CallManager really does. One of the most important things it does is manage resources: gateways, trunks, interfaces, CTI resources, DSP resources, MoH, etc. All of those things must be actively controlled. Elements of the dial plan depend on these resources, i.e. route patterns depends on route lists, route lists depend on route groups, and route groups depend on gateways, etc. Gateways are real resources, unlike route lists and route groups which are simply virtual entities that depend on real resources. In order for a route group or route list to function properly, something must be keeping track of the status of all the related elements. Therefore, CallManager must treat a route list as simply another device with physical resources that must be managed. And, as a device, the route list must register to a CallManager.
This actually makes a lot of sense when I think of it this way. If someone dials a number that matches a pattern that points to a route list, the IPT system must have a way to know the status of all the gateways within the related route groups in order to route (or block) the call. It makes a lot of sense to place that responsibility on a single CallManager that is treating the route list as a device. It could turn into an absolute mess if that responsibility were distributed.
Does that sound plausible? It makes sense to me. If that's not right, I don't want to know because I'm tired of thinking about it. :-)