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.