Gatekeeper Redundancy

A gatekeeper is a critical network component. It is responsible for most or all of the call routing, bandwidth management, and CAC. Because the gatekeeper centrally controls the dial plan, a failure can cause disruptions across the entire voice network under its control. Because of this criticality, it is advisable to implement gatekeeper redundancy to reduce the possibility of service interruptions.

Hot Standby Routing Protocol

One method of gatekeeper redundancy is the use of the Hot Standby Routing Protocol (HSRP). Following are the guidelines and caveats for implementing HSRP on a Cisco IOS gatekeeper:

Only one gatekeeper is active at any given time.

- The standby gatekeeper does not process calls unless the primary gatekeeper fails.

- No load balancing is supported.

All gatekeepers must reside on the same subnet.

No state information is maintained between the gatekeepers, and current state information (calls in progress, bandwidth in use) is lost in the event of a failover. Oversubscription of bandwidth and call degradation is possible immediately after failover.

Outage duration during a failover might be substantial because the endpoints have to reregister with the standby gatekeeper before calls can be placed. Active calls are not affected.

Gatekeeper configurations must match exactly between the primary and standby gatekeepers. You must manually replicate any changes or updates to the standby. This adds administrative overhead and increases the chance of errors being introduced into the configuration.

Configuration of HSRP on a gatekeeper is straightforward. HSRP is not supported on a loopback interface, so it is necessary to use a physical interface as the gatekeeper interface. It is preferable to use a LAN interface for this, because LAN interfaces are more reliable than WAN interfaces.

Step 1.

Configure IP addresses belonging to the same subnet on the LAN interfaces of both routers.

For example, you could configure FastEthernet0/0 on gatekeeper GK_A as 10.100.100.2, and you could configure FastEthernet0/1 on gatekeeper GK_B as 10.100.100.3.

Step 2.

Add a standby address to both interfaces using the standby ip ip-address command.

This address is active on only one of the two gateways at a time. This is the address you should use as the gatekeeper address. Endpoints use this address to register to the gatekeeper. The example uses 10.100.100.1 as the standby IP address.

Step 3.

Copy the gatekeeper configuration from the primary to the standby gatekeeper.

After you set up HSRP redundancy, it is imperative that you keep the gatekeeper configuration on both gatekeepers the same. If you make a change on the active router, you should also make it on the standby. Put procedures in place to ensure that the configurations remain synchronized.

If the primary gatekeeper fails or becomes unreachable, the standby gatekeeper assumes the gatekeeper address, and the endpoints reregister to it. This can take up to a couple of minutes. You cannot place calls until the endpoints have reregistered.

HSRP provides an option to force a switch back to the primary after it returns to service. This option is typically not used for gatekeepers, because a switch back causes an unnecessary service interruption.

You can verify the status of each of the gatekeepers using the show standby and show gatekeeper status commands. Example 17-14 shows a dual gatekeeper HSRP redundancy configuration.

The gatekeeper cluster feature allows multiple gatekeepers to control one zone. When an endpoint, such as a voice gateway, registers with a gatekeeper, it is provided with a list of alternate gatekeepers for the zone in which it registers. These alternates were specified in the gatekeeper configuration. If the gatekeeper fails, the endpoint can use the alternate gatekeepers to continue operation.

Note

Use of the alternate gatekeeper features requires Cisco IOS Software Release 12.2(1)T or later. CallManager Version 3.3 or later is required for redundancy on gatekeeper-controlled trunks.

Configuring gatekeeper clusters can be confusing. Each local zone is represented by a different name on each cluster member. It can help clarify if you think of a zone as having a "base name" and then an alias on the other cluster members. The gateways use the "base name" when they register to the gatekeeper zone.

For example, if a local zone base name is boise, and it is in a cluster with two alternate gatekeepers, you could use the names boise_gka and boise_gkb for the alternates. This could represent gatekeeper alternative A (gka) and gatekeeper alternative B (gkb) for the zone. In reality, the actual names used on the alternates can be anything as long as they are unique. Developing a naming scheme that has some meaning can help you to keep everything straight as you build the configuration.

Zone configuration is done in gatekeeper configuration mode. When you are configuring the gatekeeper, every local zone is listed with a zone local command and a zone cluster command. The zone local command defines the zone as it is known to the local gatekeeper. The zone cluster command identifies aliases for the zone and the IP addresses of the alternate gatekeepers that can process requests for that zone. The command format is zone cluster local cluster-name zone-name. The zone-name must match what is defined in the zone local statement. Aliases for the zones (names of the zones as they are known on alternate gatekeepers) are defined using the element zone-alias ip-address command. The IP address is that of the gatekeeper interface on the alternate gatekeeper where that zone alias is defined.

You might also find occasions where you want one gatekeeper to be primary for some zones and other gatekeepers as primary for other zones. This might be because of network topology, proximity, or other factors.

The following shows how a simple cluster can be built, based on the sample network. The sample network contains three local zones: ny, boise, and miami. GK_A is the primary gatekeeper for zone miami, and it is the alternate for ny and boise. GK_B is the primary for zones ny and boise, and it is the alternate for zone miami. Table 17-1 lists the names and aliases that are used to build the cluster.

Table 17-1. Example Gatekeeper Cluster Zone Names

Gatekeeper GK_A

Gatekeeper GK_B

Zone Names

miami

ny_GKA

boise_GKA

miami_GKA

ny

boise

Cluster/Elements

miami_cluster

miami_GKA

miami_cluster

miami

Cluster/Elements

ny_cluster

ny

ny_cluster

ny_GKA

Cluster/Elements

boise_cluster

boise

boise_cluster

boise_GKA

After you have determined all the names, you can begin to configure the gatekeepers in the cluster. The configuration that you can apply for Gatekeeper GK_A and GK_B is shown in Example 17-15.

Several tools are available to verify the setup and status of the cluster. These tools include the show gatekeeper endpoint, show gatekeeper status cluster, show gatekeeper cluster, and show gatekeeper zone cluster commands.

In the show gatekeeper endpoint output, the A flag listed after the miami_GKA zone indicates that this gatekeeper is currently alternate for that zone. Absence of the A flag means that this is the active gatekeeper for the zone.

Load Balancing

Load balancing allows the gatekeeper to move registered endpoints to an alternate gatekeeper or to reject new calls and registrations after a threshold is met. Load balancing requires that alternate gatekeepers be configured.

The syntax for the command to set up load balancing is load-balance [endpoints max-endpoints] [calls max-calls] [cpu max-cpu] [memory max-memory-used]. You apply this in gatekeeper configuration mode on each gatekeeper in the cluster where you want to load-balance. You can concatenate the parameters together to allow monitoring of multiple thresholds.

To verify that load balancing is enabled, use the show gatekeeper status command, as demonstrated in Example 17-17. The last four lines are displayed only when load balancing is enabled.

Gatekeepers that are members of a cluster communicate with each other to update their status by using GUP. GUP messages are sent between cluster members periodically or when the status has changed. Each member gatekeeper in the cluster maintains the state information about activity on all the other gatekeepers. With that state information, failover to an alternate gatekeeper can be seamlessly completed. For more information on the GUP protocol, see the "Gatekeeper Update Protocol" section in Chapter 16.

You can use the debug gatekeeper gup asn1 command to determine if the proper information is being passed in the GUP messages. The output of this trace allows you to easily determine if the updates are occurring and if they contain valid information. The number of calls by zone, the bandwidth used, and the load balancing information are included in the GUP announcement messages. You can use this information in addition to the troubleshooting tools previously discussed to help isolate problems with the gatekeepers.

Example 17-18 shows GUP messages that are sent to alternate gatekeepers within the cluster when a call is placed from Boise to Miami.