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.

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.

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 ------------- ----------- --- ------ ------ ------ --------- ------ ny ny_GKA 7 0 0 0 20s CONNECTED boise boise_GKA 7 0 0 0 20s CONNECTED miami_GKA miami 7 0 0 0 20s CONNECTED REGISTERED ENDPOINTS GK_B#show gatekeeper endpoint GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags -------------- ----- -------------- ----- --------- ---- ----- 10.1.5.2 61817 10.1.5.2 61819 ny VOIP-GW H323-ID: GK_Trunk_1 Voice Capacity Max.= Avail.= Current.= 0 10.12.1.2 1720 10.12.1.2 52237 miami_GKA VOIP-GW A H323-ID: [e-mail] 10.1.5.200 1720 10.1.5.200 50240 boise VOIP-GW E164-ID: 0100 E164-ID: 0101 H323-ID: [e-mail] Voice Capacity Max.= Avail.= Current.= 0 Total number of active registrations = 3  

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 callCapacity 24284 hostName '474B5F42'H percentMemory 71 percentCPU 1 currentCalls 1 ## 1 call in progress currentEndpoints 1 zoneInformation { { gatekeeperIdentifier {"ny"} altGKIdentifier {"ny_GKA"} totalBandwidth 0 un interzoneBandwidth 0 remoteBandwidth 0 }, { gatekeeperIdentifier {"boise"} altGKIdentifier {"boise_GKA"} totalBandwidth 160 interzoneBandwidth 160 ## 16Kb Bandwidth Currently in Use remoteBandwidth 0 }, { gatekeeperIdentifier {"miami_GKA"} altGKIdentifier {"miami"} totalBandwidth 0 interzoneBandwidth 0 remoteBandwidth 0 } } } } *Aug 6 08:31:40.123: Received GUP ANNOUNCEMENT INDICATION from 10.100 .101.1  

Configuring Resource Availability Indicator