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.
|
GATEKEEPER A GK_A#show running-config Building configuration... ! ! Unnecessary output deleted ! interface FastEthernet0/0 ip address 10.100.100.2 255.255.255.240 standby ip 10.100.100.1 ! gatekeeper zone local ny cisco.com 10.100.100.1 zone local boise cisco.com zone local miami cisco.com zone prefix ny 2... gw-type-prefix 1#* default-technology rrq dynamic-prefixes-accept arq reject-unknown-prefix bandwidth interzone zone boise 16 no shutdown ! end GK_A#show gatekeeper status Gatekeeper State: UP Load Balancing: DISABLED Flow Control: DISABLED Zone Name: ny Zone Name: boise Zone Name: miami Accounting: DISABLED Endpoint Throttling: DISABLED Security: DISABLED Maximum Remote Bandwidth: unlimited Current Remote Bandwidth: 0 kbps Current Remote Bandwidth (w/ Alt GKs): 0 kbps GK_A#show standby FastEthernet0/0 - Group 0 State is Active 5 state changes, last state change 00:03:08 Virtual IP address is 10.100.100.1 Active virtual MAC address is 0000.0c07.ac00 Local virtual MAC address is 0000.0c07.ac00 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 0.816 secs Preemption disabled Active router is local Standby router is 10.100.100.3, priority 100 (expires in 8.924 sec) Priority 100 (Default 100) IP redundancy name is "hsrp-Fa0/0-0" (default) |
|
GATEKEEPER B GK_B#show running-config Building configuration... ! ! Unnecessary output deleted ! interface FastEthernet0/0 ip address 10.100.100.3 255.255.255.240 standby ip 10.100.100.1 ! gatekeeper zone local ny cisco.com 10.100.100.1 zone local boise cisco.com zone local miami cisco.com zone prefix ny 2... gw-type-prefix 1#* default-technology rrq dynamic-prefixes-accept arq reject-unknown-prefix bandwidth interzone zone boise 16 no shutdown ! end GK_B#show gatekeeper status Gatekeeper State: HSRP STANDBY Load Balancing: DISABLED Flow Control: DISABLED Zone Name: ny Zone Name: boise Zone Name: miami Accounting: DISABLED Endpoint Throttling: DISABLED Security: DISABLED Maximum Remote Bandwidth: unlimited Current Remote Bandwidth: 0 kbps Current Remote Bandwidth (w/ Alt GKs): 0 kbps GK_B#show standby FastEthernet0/0 - Group 0 State is Standby 4 state changes, last state change 00:06:04 Virtual IP address is 10.100.100.1 Active virtual MAC address is 0000.0c07.ac00 Local virtual MAC address is 0000.0c07.ac00 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 1.880 secs Preemption disabled Active router is 10.100.100.2, priority 110 (expires in 8.020 sec) Standby router is local Priority 100 (default 100) IP redundancy name is "hsrp-Fa0/0-0" (default) |
Gatekeeper Clustering
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.
|
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.
|
GATEKEEPER A GK_A#show running-config Building configuration... ! ! Unnecessary output deleted ! interface Loopback0 description Gatekeeper A ip address 10.100.100.1 255.255.255.255 ! gatekeeper zone local miami cisco.com 10.100.100.1 zone local boise_GKA cisco.com zone local ny_GKA cisco.com zone cluster local miami_cluster miami element miami_GKA 10.100.101.1 1719 ! zone cluster local boise_cluster boise_GKA element boise 10.100.101.1 1719 ! zone cluster local ny_cluster ny_GKA element ny 10.100.101.1 1719 ! zone prefix ny_GKA 2... gw-type-prefix 1#* default-technology rrq dynamic-prefixes-accept arq reject-unknown-prefix bandwidth interzone zone boise_GKA 16 no shutdown ! end |
|
GATEKEEPER B GK_B#show running-config Building configuration... ! ! Unnecessary output deleted ! interface Loopback0 description Gatekeeper B ip address 10.100.101.1 255.255.255.255 ! gatekeeper zone local ny cisco.com 10.100.101.1 zone local boise cisco.com zone local miami_GKA cisco.com zone cluster local ny_cluster ny element ny_GKA 10.100.100.1 1719 ! zone cluster local boise_cluster boise element boise_GKA 10.100.100.1 1719 ! zone cluster local miami_cluster miami_GKA element miami 10.100.100.1 1719 ! zone prefix ny 2... gw-type-prefix 1#* default-technology rrq dynamic-prefixes-accept arq reject-unknown-prefix bandwidth interzone zone boise 16 no shutdown ! end |
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.
Example 17-16 demonstrates output from each of these commands.
|
[View full width] DEFINED CLUSTERS AND THEIR ELEMENTS GK_B#show gatekeeper clusters CONFIGURED CLUSTERS =================== Cluster Name Type Local Zone Elements IP ------------ ---- ---------- -------- -- ny_cluster Local ny ny_GKA 10.100.100.1 1719 boise_cluster Local boise boise_GKA 10.100.100.1 1719 miami_cluster Local miami_GKA miami 10.100.100.1 1719 CURRENT STATUS OF THE CLUSTER GK_B#show gatekeeper status cluster CLUSTER INFORMATION =================== Active Endpoint Last Hostname %Mem %CPU Calls Count Announce -------- ----- ---- ----- ----- -------- GK_B 71 1 0 2 Local Host GK_A 19 0 0 1 5s CLUSTER INFORMATION BY ZONE GK_B#show gatekeeper zone cluster LOCAL CLUSTER INFORMATION ========================= TOT BW INT BW REM BW LAST ALT GK LOCAL GK NAME ALT GK NAME PRI (kbps) (kbps) (kbps) ANNOUNCE STATUS ------------- ----------- --- ------ ------ ------ --------- |
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.
|
GK_A#show gatekeeper status Gatekeeper State: UP Load Balancing: ENABLED Flow Control: DISABLED Zone Name: miami Zone Name: boise_GKA Zone Name: ny_GKA Accounting: DISABLED Endpoint Throttling: DISABLED Security: DISABLED Maximum Remote Bandwidth: unlimited Current Remote Bandwidth: 0 kbps Current Remote Bandwidth (w/ Alt GKs): 0 kbps Call Capacity: 0 / 100 Endpoint Capacity: 1 / 100 Memory Utilization: 19% / 70% CPU Utilization: 0% / 80% |
Troubleshooting Gatekeeper Clustering
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.
|
[View full width] GK_A#debug gatekeeper gup asn1 *Aug 6 08:31:40.103: GUP INCOMING PDU ::= value GUP_Information ::= { protocolIdentifier { 1 2 840 113548 10 0 0 4 } message announcementIndication : { announcementInterval 30 endpointCapacity 24658 |
Configuring Resource Availability Indicator
|