Multiple Gatekeeper Configurations

Sometimes you might want to be able to route calls between zones that different gatekeepers control. An example of this might be in a large enterprise that has multiple business units. Each business unit might have a gatekeeper that is controlling its sites. This lets each business unit manage its own bandwidth and dial plans. The corporation as a whole needs to be able to route calls between all locations. A subset of the company location is shown in Figure 17-2. Each gatekeeper also controls additional locations that are not shown in the diagram. In addition, there is PSTN connectivity at every location.

Figure 17-2. Multiple Gatekeeper Network

A zone that a different gatekeeper controls is known as a remote zone. Setting up call routing to a remote zone is similar to the basic configuration discussed in the previous section. To begin, use the zone remote zonename domainname ip-address command. The zonename and domainname must match the names that are defined on the remote gatekeeper. The ip-address is the IP address of the remote gatekeeper.

The next things to configure are the zone prefixes for the zones in the remote gatekeeper. You do this in the same manner as the basic configuration. For remote zones, you must manually configure prefixes. Prefixes cannot be learned dynamically from the remote gatekeeper. You can still use dynamic prefix registration for local zones.

Optionally, you can code the lrq reject-unknown-prefix command. This command causes the gatekeeper to reject a Location Request (LRQ) message if no matching local zone prefix is coded.

Overall, the process of configuring call routing with multiple gatekeepers is similar to configuring call routing with a single gatekeeper. The difference is the use of remote zone definitions. Example 17-7 shows the configuration of the two gatekeepers in the sample network.

CORPORATE GATEKEEPER

GK_Corp#show running-config
Building configuration...
!
! Unnecessary output deleted
!
interface Loopback0
 description Gatekeeper interface
 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 remote miami cisco.com 10.100.100.1 1719 
 zone prefix miami 130555501.. 
 zone prefix boise 120855501.. 
 zone prefix ny 1212555....
 gw-type-prefix 1#* default-technology
 rrq dynamic-prefixes-accept
 arq reject-unknown-prefix
 lrq reject-unknown-prefix
 no shutdown
!
end

 

NEW DIVISION GATEKEEPER

GK_NewCo#show running-config
Building configuration...
!
! Unnecessary output deleted
!
interface Loopback0
 description Gatekeeper interface
 ip address 10.100.100.1 255.255.255.255
!
gatekeeper
 zone local miami cisco.com 10.100.100.1
 zone remote ny cisco.com 10.100.101.1 1719 
 zone remote boise cisco.com 10.100.101.1 1719 
 zone prefix miami 130555501.. 
 zone prefix boise 120855501.. 
 zone prefix ny 1212555.... 
 gw-type-prefix 1#* default-technology
 rrq dynamic-prefixes-accept
 arq reject-unknown-prefix
 lrq reject-unknown-prefix 
 no shutdown
!
end

 

The signaling is quite different when an ARQ is received for a prefix in a remote zone from one that exists in a local zone. The local gatekeeper must issue an LRQ to the remote gatekeeper to attempt to resolve the IP address of the destination. For more information, see the "H.323 Call Flows Using Gatekeepers" section in Chapter 16.