|
|
The two main features of the gatekeeper that have been enhanced to support internetworking with the gateway are:
Brief descriptions of these features follow.
The gatekeeper manages H.323 endpoints in a consistent manner, allowing them to register with the gatekeeper and to locate another. The gatekeeper may instantiate proxies, or gateways, in a call path to provide connectivity with the PSTN (Public Switched Telephone Network), to improve QoS (Quality Of Service), or to enforce security policies. Multiple gatekeepers may be configured to communicate with one another, either by integrating their addressing into DNS (Domain Naming System), or via Cisco IOS configuration options.
In addition to the Cisco IOS Release 11.3NA functionality described in documentation in the above URL, the gatekeeper has been enhanced with two important new features:
The Cisco routers performing the access server functionality for the gatekeeper are:
Information on these routers is also available at the documentation URL on the previous page.
Gatekeeper HSRP (Hot Standby Router Protocol) support consists of elements in both the gateway and gatekeeper functions in the router. The gateway periodically retries its registration when it detects a possible gatekeeper failure, in order to register itself with the backup gatekeeper. Although it is a backup, the gatekeeper operates in a passive mode in which it does not accept registrations, and becomes active when it is notified by HSRP that it will become the primary gatekeeper.
Cisco gatekeepers can be configured to use HSRP so that when one gatekeeper fails, the standby gatekeeper assumes its role.
Step 1 Select one interface on each gatekeeper which will serve as the HSRP interface and configure these two interfaces so that they belong to the same HSRP group and have different priorities. The one with the higher priority will be the active gatekeeper, the other assumes the standby role.
Step 2 Make a note of the virtual HSRP IP address shared by both.
Step 3 Configure the gatekeepers so that this HSRP virtual IP address is the RAS address for all local zones.
Step 4 Ensure that the gatekeeper mode configurations on both routers are identical.
In this example, Ethernet 0 is used as the HSRP interface on both gatekeepers and the gatekeeper is configured using either a Cisco 3620 or Cisco 3640 modular access router. The three stages of the sample gatekeeper HSRP configuration are displayed in the proceeding tables:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| 36xx# config term | Enter configuration mode. | ||
| 36xx(config-if)# int e0 | Enter interface configuration mode for interface e0. | ||
| 36xx(config-if)# standby 1 ip 172.21.127.55 | Identify member of the HSRP standby group 1 sharing virtual address of 172.21.127.55. | ||
| 36xx(config-if)# standby 1 timers 5 15 | Set hello timers to 5 sec, hold timer to | ||
| 36xx(config-if)# standby 1 priority 110 | Sets standby priority to 110. | ||
| 36xx(config-if)# end | End the configuration of the the primary gatekeeper. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| 36xx# config term. | Enter configuration mode. | ||
| 36xx(config-if)# int e0 | Enter interface configuration mode for interface e0. | ||
| 36xx(config-if)# standby 1 ip 172.21.127.55 | Identify member of the HSRP standby group 1 sharing virtual address of 172.21.127.55. | ||
| 36xx(config-if)# standby 1 timers 5 15 | Set the hello timers for 5 sec and the hold timer for 15 sec. | ||
| 36xx(config-if)# end | End the configuration of the backup gatekeeper. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| On Gatekeeper gk1 |
| ||
| 36xx# config term | Enter configuration mode. | ||
| 36xx(config)# gatekeeper | Enter gatekeeper configuration mode. | ||
| 36xx(config-gk)# zone local gk-sj cisco.com 172.21.127.55 | Define local zone using HSRP virtual address as gatekeeper's RAS address. Note At this point, various other gatekeeper configuration are also performed which are not specific to the HSRP configuration. After all required gatekeeper tasks are performed, continue. | ||
| 36xx(config-gk)# no shut | Allow various other gatekeeper mode configurations to bring up the | ||
| On Gatekeeper gk2 |
| ||
| 36xx# config t | Enter configuration mode. | ||
| 36xx(config-gk)# gatekeeper | Enter gatekeeper config mode. | ||
| 36xx(confi-gk)# zone local gk-sj cisco.com 172.21.127.55 | Define local zone using HSRP virtual address as gatekeeper's RAS address. Note This uses the same gkname and address as on gk1. | ||
| 36xx(config-gk)# no shut | Allow various other gatekeeper mode configurations to bring up the |
Gatekeeper State: UP
Gatekeeper State: HSRP STANDBY
There are two types of addresses used in H.323 destination calls.
The Cisco IOS Release 11.3(2)NA software feature Multimedia Conference Manager dealt primarily with H.323-ID addressing in interzone calls. With the new prefix commands, the administrator can now also configure interzone routing when calls are made using E164 addresses.
When using H.323-ID addresses, interzone routing is handled through the use of domain names. For example, to resolve "bob@cisco.com," the source endpoint's gatekeeper finds the gatekeeper for "cisco.com," and sends it the Location Request (LRQ) for target address "bob@cisco.com." The destination gatekeeper looks in the registration database, sees "bob" registered, so returns the appropriate IP address to get to bob.
When using E164 addresses, call routing is handled through means of zone prefixes and "gateway-type" or technology prefixes.
The zone prefixes (typically area codes) serve the same purpose as the domain names in the H.323-ID address space.
For instance, if our local gatekeeper has been configured with the knowledge that zone prefix "212......." (that is, any address beginning "212" and followed by 7 arbitrary digits) is handled by gatekeeper "gk-ny":
router(config-gk)# zone prefix gk-ny 212.......
then when the local gatekeeper is asked to admit a call to destination address "2125551111", it knows to send the Location Request to gk-ny.
However, when the query gets to gk-ny, gk-ny still needs to resolve the address so that the call can be sent to its final destination. There may actually be an H.323 endpoint that has registered with gk-ny with that E.164 address, in which case gk-ny will return the IP address for that endpoint. However, the probability is that the E.164 address belongs to a non-H.323 device (for example, a telephone or an H.320 terminal). Because non-H.323 devices do not register with gatekeepers, gk-ny has no knowledge of whom the address belongs to. It needs to be able to select a gateway which can be used to reach the non-H.323 device. This is where the technology prefixes (or "gateway-type") becomes useful.
The network administrator selects technology prefixes (tech-prefixes) to denote different types or classes of gateways. The gateways are then configured to register with their gatekeepers with these prefixes. For example, voice gateways may register with tech-prefix "1xx," H.320-gateways with tech-prefix "2xx," voicemail-gateways with "3xx," and so on. More than one gateway may register with the same type prefix. When that happens, the gatekeeper makes a random selection among gateways of the same type.
The caller, who knows the type of device they are trying to reach, can now prepend a tech-prefix to the destination address to indicate the type of gateway to use to get to the destination.
The caller might ask for 1#2125551111 if they know that the address 2125551111 is for a telephone and the tech-prefix for voice gateways is "1xx." When the voice gateway receives the call for 1#2125551111, it strips off the tech-prefix and bridges the next leg of the call to the telephone at 2125551111.
In cases where the call scenario is:
telephone -----> voice-gw1 -----> voice-gw2 ----->telephone
(PSTN) (H.323) (PSTN)
voice-gw1 can be configured (using the dial-peer command) to prepend the voice tech-prefix "1," so that the use of technology prefixes is completely transparent to the caller.
There are a couple of interesting features in the implementation of the gw-type-prefix command.
If the majority of calls hop off on a particular type of gateway, the gatekeeper can be configured to use that type of gateway as the default type, so that callers no longer have to prepend a tech-prefix on the address. For example, if what you use in your network are mostly voice gateways, and you have configured all your voice gateways to register with tech-prefix 1, you can configure your gatekeeper to use "1xx" gateways as the default:
router(config-gk)# gw-type-prefix 1# default-technologyNow a caller no longer needs to prepend "1xx" to use a voice gateway. Any address that does not contain an explicit tech-prefix will be routed to one of the voice gateways which registered with "1xx."
With this default-technology definition, suppose a caller asks the gatekeeper for admission to 2125551111. If the local gatekeeper does not recognize the zone prefix as belonging to any remote zone, it will route the call to one of its local "1xx" voice gateways, so the call hops off locally. However, if it knows that gk-ny handles the 212 area code, it sends a Location Request for 2125551111 to gk-ny. This requires that gk-ny also be configured with some default gateway type prefix, and that its voice gateways be registered with that prefix.
The other gateway-type feature is the ability to force a hop-off to a particular zone. Normally, when an endpoint or gateway makes a call-admission request to its gatekeeper, the gatekeeper resolves the destination address by first looking for the tech-prefix. When that is matched, the remaining string is compared against known zone prefixes. If the address resolves to a remote zone, the entire address, including both technology and zone prefixes, is sent to the remote gatekeeper in a Location Request. That remote gatekeeper then uses the tech-prefix to decide which of its gateways to hop off.
The zone-prefix determines the routing to a zone, when there, the tech-prefix determines the gateway in that zone. See "zone prefix" for a description of the command.
This behavior can be overridden by associating a forced hop-off zone with a particular tech-prefix. What this does is force the call to the specified zone, regardless of what the zone-prefix in the address is. For instance, you are in the 408 area code, and normally, you want calls to the 212 area code to use H.323 over IP to get to New York, and then hop off there, because it saves on costs. However you only have an H.320 gateway in Denver and not in New York. So, all calls to H.320 endpoints need to hop-off in Denver, even if the destination H.320 endpoint is in the 212 area code. In that case you want to define the gateway-type prefix for H.320 gateways as one that is always forced to the Denver zone.
Technology prefixes are used to distinguish between gateways having specific capabilities within a given zone. They are handled specially because the technology prefix is ignored during the zone selection process and then examined for gateway selection within the zone. This requires that the prefix be ignored during the zone selection process. Technology prefixes have been designed to enable the use of E.164 address routing. E.164 is an International Telecommunications Union (ITU) specification for the ISDN international telephone numbering plan, which has traditionally only been used in telephone networks.
The gateway technology prefix is set up using the following new commands.
See "Command Reference" for a description of the technology prefix related commands. The technology prefixes are transmitted (as part of the called_number) to the destination gateway. Therefore, the customer must configure the dial-peers at the destination gateway to match on the technology prefix.
This sample configuration uses the E.164 address routing configuration and is based on the following assumptions:
The gatekeeper is enabled by entering the following commands:
Gatekeeper Configuration:
Step 1 Initiate configuration mode.
36xx# config term
Step 2 Enter gatekeeper configuration mode.
36xx(config)# gatekeeper
Step 3 Define a local zone (that is, managed by this gatekeeper), its gatekeeper id is "gk-sj" and the domain name is "cisco.com". Enter:
zone local gk-sj cisco.com
Step 4 Notify the gatekeeper that gatekeeper "gk-ny" manages the "212" area code so that calls to E.164 addresses beginning with 212 should be sent to "gk-ny" (at 172.21.127.27) Enter:
zone remote gk-ny cisco.com 172.21.127.27
Step 5 Define the accessibility for local zone "gk-sj." This states that the calls originating in any (default) zone, "gk-sj" should offer "direct" (unproxied) access to H.323 entities in its zone. If this command were not issued, the default gatekeeper behavior would have been to offer access through proxies, which introduces an extra call leg into the call. Enter:
zone access gk-sj default direct
Step 6 Configure the gatekeeper to handle the 408 area code. Enter:
zone prefix gk-sj 1408.......
Step 7 Notify the gatekeeper that gatekeeper "gk-ny" manages the 212 area code, so that calls to E.164 addresses beginning with 1212 should be sent to "gk-ny" (at 172.21.127.27). Enter:
zone prefix gk-ny 1212.......
Step 8 Define a gateway technology prefix "3xx" and stipulate that any calls to addresses beginning with this technology prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix is. Enter:
gw-type-prefix 3# hopoff gk-sj
Step 9 Define a gateway technology prefix "4xx". The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing unresolveable addresses. Enter:
gw-type-prefix 4# default-technology
Gatekeeper configuration
Step 1 To initiate the configuration mode, enter:
config term
Step 2 Enter the gatekeeper configuration mode:
gatekeeper
Step 3 Define a local zone (that is, managed by this gatekeeper), its gatekeeper id is "gk-ny" and the domain name is "cisco.com."
zone local gk-ny cisco.com
Step 4 Notify the gatekeeper about a remote gatekeeper called "gk-sj" which is located at IP address 172.21.1.48.
zone remote gk-sj cisco.com 172.21.1.48
Step 5 Define the accessibility for local zone "gk-ny." This states that the calls originating in any (default) zone, "gk-ny" should offer "direct" (that is, unproxied) access to H.323 entities in its zone. If this command were not issued, the default gatekeeper behavior would have been to offer access through proxies, which introduces an extra call leg into the call.
zone access gk-ny default direct
Step 6 Configure the gatekeeper to handle the 1212 area code.
zone prefix gk-ny 1212.......
Step 7 Notify the "gk-ny" gatekeeper that manages the 408 area code, so that calls to E.164 addresses beginning with 1408 should be sent to "gk-sj" (at 172.21.1.48).
zone prefix gk-sj1408......
Step 8 Define a gateway technology prefix "3xx" and stipulate that any calls to addresses beginning with this tech prefix should always be hopped-off locally (hairpinned), regardless of what the zone prefix.
gw-type-prefix 3# hopoff gk-ny
Step 9 Define a gateway technology prefix "4xx." The "default-technology" keyword specifies that any gateway registering with this prefix may be used as a default or last-resort gateway for routing otherwise, unresolveable addresses.
gw-type-prefix 4# default-technology
Continue with this example in San Jose suppose we have gateways registering with gk-sj as follows:
gw-sj2 configured to register with tech prefix 2#Similarly, in New York, gateways are configured to register with gk-ny as follows:
gw-ny2 configured to register with tech prefix 2#Given the above configuration, in San Jose, a call is presented to the gatekeeper (gk-sj) with the following target address:
gk-sj recognizes that 2xx is a tech prefix (it was not configured as such, but because gw-sj2 registered with it, the gatekeeper now treats 2xx as a tech prefix) strips that and is left with "12125551212." This is matched against the zone prefixes, and is a match for 1212......., so gk-sj knows that gk-ny handles this. It forwards the whole address "2#12125551212" over to gk-ny, who also looks at the tech prefix 2xx, and routes this to gw-ny2.
gk-sj checks this against known tech prefixes, no match. Checks against zone prefixes, matches on 1212....... for gk-ny, so routes this to gk-ny. gk-ny does not have any local registrations for this address, and there is no tech prefix on the address, but his default prefix is 4xx and gw-ny4 is registered with 4xx, so the call gets routed to gw-ny4.
Because this contains the tech prefix of 3xx and that is defined as a local-hopoff prefix, gk-sj just routes this to gw-sj3, despite the fact that it contains a zone-prefix for New York.
gk-sj looks for a technology prefix match, and fails. Looks for a zone-prefix match and fails again. But succeeds in finding a default gateway prefix of 4xx. And succeeds when gw-sj4 is registered with 4xx. So, the call gets sent routed out on gw-sj4.
This section contains the command reference pages for the new commands, and also commands which have changed since Cisco IOS Release 11.3(2)NA.
To configure a technology prefix in the gatekeeper, use the gw-type-prefix command. To remove the technology prefix, use the no form of the command.
gw-type-prefix type-prefix [hopoff gkid] [default-technology] [[gw ipaddr ipaddr
type-prefix | A technology prefix is recognized and is stripped before checking for the zone prefix. It is strongly recommended that you select technology prefixes that do not lead to ambiguity with zone prefixes. Do this by using the # character to |
hopoff gkid | (Optional) Use this option to specify the gatekeeper or zone where the call is to hop off, regardless of the zone prefix in the destination address. The gkid |
default-technology | (Optional) Gateways registering with this prefix option are used as the default for routing any addresses that are otherwise unresolved. |
gw ipaddr ipaddr [port] | (Optional) Use this option to indicate that the gateway is incapable of registering technology prefixes. When it registers, it adds the gateway to the group for this type-prefix, just as if it had sent the technology prefix in its registration. This parameter can be repeated to associate more than one gateway with a technology prefix. |
No technology prefix is defined.
Gatekeeper configuration
More than one gateway can register with the same technology prefix. In such cases, a random selection is made of one of them.
You do not have to define a technology prefix to a gatekeeper if there are gateways configured to register with that prefix, and if there are no special flags (hopoff gkid or default-technology) that you want to associate with that prefix.
zone prefix.
The following example specifies 4# as the default technology prefix:
gw-type-prefix 4# default-technology
The arq reject-unknown-prefix command is used to control the behavior of the gatekeeper when it receives an Admission Request (ARQ) which does not match any configured zone prefixes. Use this command to force the gatekeeper to reject such requests. If however, the desired behavior is for the gatekeeper to try to service such requests, then use the no form of this command.
arq reject-unknown-prefix
no arq reject-unknown-prefix
This command has no arguments or keywords.
no arq reject-unknown-prefix.
Gatekeeper configuration
This command first appeared in the Cisco IOS Release 11.3(6)NA.
You can use the arq reject-unknown-prefix command to control the behavior of the gatekeeper when it receives an Admission Request (ARQ) for a destination E.164 address which does not match any configured zone prefixes.
When an endpoint or gateway initiates an H.323 call, it sends an ARQ to its gatekeeper. The gatekeeper uses the configured list of zone prefixes to determine to which zone the call should be directed. If the called address does not match any known zone prefixes, the gatekeeper will attempt to hairpin the call out through a local gateway. If this is not the desired behavior, then use the arq reject-unknown-prefix command to mandate that such calls should be rejected.
This command is typically used either to restrict local gateway calls to a known set of prefixes, or to deliberately fail such calls so that an alternate choice on a gateway's rotary dial-peer can be selected.
The following example shows how this command affects the behavior of a gatekeeper. Consider a gatekeeper configured as follows:
zone local gk408 cisco.com
zone remote gk415 cisco.com 172.21.139.91
zone prefix gk408 1408.......
zone prefix gk415 1415.......
In the above example, the gatekeeper manages a zone containing gateways to the 408 area code, and it knows about a peer gatekeeper with gateways to the 415 area code. These zones are configured with the appropriate prefixes so that calls to those area codes hop off in the optimal zone.
If an endpoint wishes to make a call to the 408 area code, the call will be routed out through a local gateway. If the call is to the 415 area code, it will be directed to the gk415 zone and hop off on a gateway there. But if a call is made to, say, the 212 area code, it will also be directed to a local gateway in the gk408 zone.
Now if you add the command:
arq reject-unknown-prefix
when a call is made to the 212 area code, it is now rejected because the destination address does not match any configured prefixes.
The lrq reject-unknown-prefix command is used to control the behavior of the gatekeeper when it receives a Location Request (LRQ) which does not match any configured zone prefixes. Use this command to force the gatekeeper to reject such requests. If however, the desired behavior is for the gatekeeper to try to service such requests, then use the no form of this command.
lrq reject-unknown-prefix
no lrq reject-unknown-prefix
This command has no arguments or keywords.
No lrq reject-unknown-prefix.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3(6)NA.
You can use the lrq reject-unknown-prefix command to control the behavior of the gatekeeper when it receives a Location Request (LRQ) which does not match any configured zone prefixes.
When the gatekeeper receives a Location Request asking about an E.164 address, it matches the target address against the list of configured zone prefixes. If the address matches a zone prefix, the behavior is unambiguous and well-defined:
However. if the target address does not match any known local or remote zone prefixes, then the default behavior is to attempt to service the call using one of the local zones. This default behavior may not be suitable for all sites, so the lrq reject-unknown-prefix command allows you to force the gatekeeper to reject such requests.
The following example shows how this command affects the behavior of a gatekeeper. Consider a gatekeeper configured as follows:
zone local gk408 cisco.com
zone local gk415 cisco.com
zone prefix gk408 1408.......
zone prefix gk415 1415.......
lrq reject-unknown-prefix
In the above example, the gatekeeper manages two zones, one with gateways with interfaces in the 408 area code, and one with gateways in the 415 area code. These zones are configured with the appropriate prefixes so that calls to those area codes hop off in the optimal zone. Now say some other zone had been erroneously configured to route calls to the 212 area code to this gatekeeper. When the Location Request arrives, this gatekeeper fails to match the area code, and so the LRQ is rejected.
However, if this was your only site that had any gateways in it, and you wanted your other sites to route all calls requiring gateways to this gatekeeper, then you would undo the reject command:
no lrq reject-unknown-prefix
Now, with this command entered, when the gatekeeper receives an LRQ for the address 12125551234, it will attempt to find an appropriate gateway in either one of the zones gk408 or gk415 to service the call.
To display the gateway-type prefix table, use the show gatekeeper gw-type-prefix EXEC command.
show gatekeeper gw-type-prefixPrivileged EXEC (also known as Enable mode)
This command first appeared in the Cisco IOS Release 11.3 NA.
The following is sample output from the show gatekeeper gw-type-prefix command:
router# show gatekeeper gw-type-prefix
(GATEWAYS-TYPE PREFIX TABLE ================================ Prefix: 3#* (Hopoff- gk408) Prefix: 4#* (Default gateway-technology) Static Configured Gateways: Prefix: 7#* (Hopoff gk408) Static Configured Gateways: 1.1.1.1:1720 2.2.2.2:1720
| Field | Description |
|---|---|
Prefix: | The tech-prefix defined with the gw-type-prefix command. |
(Hopoff gk408) | Calls specifying tech-prefix 3# or 7# will always be routed to zone gk408, regardless of the actual zone-prefix in the destination address. |
(Default gateway-technology) | The address associated with the technology prefix is a gateway used as the default for routing any addresses that are otherwise unresolveable. |
Static Configured Gateways: | Lists all IP addresses and port numbers of statically configured gateways. |
To show overall gatekeeper status that includes authorization and authentication status, zone status, and so on, use the show gatekeeper status EXEC command.
show gatekeeper statusThis command has no arguments or keywords.
Privileged EXEC (also known as Enable mode)
This command first appeared in Cisco IOS Release 11.3 NA.
The following is sample output from the show gatekeeper status command:
router# show gatekeeper status
Gatekeeper State: UP Zone Name: gk-px4.cisco.com Accounting: DISABLED Security: DISABLED
| Field | Description |
|---|---|
Gatekeeper State |
|
Zone Name | Zone name. |
Accounting | Authorization and accounting status. |
Security | Security status. |
To display the zone prefix table, use the show gatekeeper zone prefix EXEC command.
show gatekeeper zone prefixPrivileged EXEC (also known as Enable mode)
This command first appeared in the Cisco IOS Release 11.3 NA.
The following is sample output from the show gatekeeper zone prefix command:
5300# show gatekeeper zone prefix
ZONE PREFIX TABLE ================= GK-NAME E164-PREFIX ------- ----------- gk.zone13 212....... gk.zone14 415.......
gk.zone14 408.......
| Field | Description |
|---|---|
GK-NAME | The gatekeeper name. |
E164-PREFIX | The E.164 prefix and a dot that acts as a wildcard for matching each remaining number in the telephone number. |
To specify a zone controlled by a gatekeeper, use the zone local gatekeeper configuration command. To remove a zone controlled by a gatekeeper, use the no form of this command. This command can also be used to change the IP address used by the gatekeeper.
zone local gatekeeper-name domain-name [rasIPaddress]
gatekeeper-name
| The gatekeeper's name or zone name. This is usually the fully domain-qualified host name of the gatekeeper. For example, if the domain-name is cisco.com, the gatekeeper-name might be gk1.cisco.com. However, if the gatekeeper is controlling multiple zones, the gatekeeper-name for each zone should be some unique string that has a mnemonic value. |
domain-name | The domain name served by this gatekeeper. |
rasIPaddress | The IP address of one of the interfaces on the gatekeeper. When the gatekeeper responds to gatekeeper discovery messages, it signals the endpoint or gateway to use this address in future communications. Setting this address for one local zone makes it the address used for all local zones. |
No local zone is defined.
Gatekeeper configuration.
This command first appeared in Cisco IOS Release 11.3 NA.
Multiple local zones can be defined. The gatekeeper manages all configured local zones. Intrazone and interzone behavior remains the same (zones are controlled by the same or different gatekeepers.)
Only one rasIPaddress argument can be defined for all local zones. You cannot configure each zone to use a different RAS IP address. If you define this in the first zone definition, you can omit it for all subsequent zones, which automatically pick up this address. If you set it in a subsequent zone local command, it also changes the RAS address of all previously configured local zones. After it is defined, you can change it by re-issuing any zone local command with a different rasIPaddress argument.
If the rasIPaddress argument is an HSRP virtual address, it automatically puts the gatekeeper into HSRP mode. In this mode, the gatekeeper assumes STANDBY or ACTIVE status according to whether the HSRP interface is on STANDBY or ACTIVE status.
You cannot remove a local zone if there are endpoints or gateways registered in it. To remove the local zone, shut down the gatekeeper first, which forces unregistration.
Multiple zones are controlled by multiple logical gatekeepers on the same Cisco IOS release.
The following example creates a zone controlled by a gatekeeper in the domain called cisco.com:
zone local gk1.cisco.com cisco.com show gatekeeper zone statue
zone remote
To configure the gatekeeper with knowledge of its own and any remote zone prefixes, use the zone prefix gatekeeper configuration command. To remove knowledge of zone prefixes, use the no form of this command.
zone prefix gatekeeper-name e164-prefix
gatekeeper-name
| The name of a local or remote gatekeeper, which must have been defined using the zone local or zone remote command. |
e164-prefix | An E.164 prefix in standard form followed by dots (.) that each represent a For example, 212....... is matched by 212 and any seven numbers. |
No knowledge of its own or any other zone prefix is defined.
Gatekeeper configuration.
Although a dot representing each digit in an E.164 address is the preferred configuration method, you may also enter an asterisk (*) to match any number of digits.
A gatekeeper can handle more than one zone prefix, but a zone prefix cannot be shared by more than one gatekeeper. If you have defined a zone prefix as being handled by a gatekeeper, and now define it as being handled by a second gatekeeper, the second assignment will cancel the first.
When a zone handles several prefixes, all gateways in that zone constitute a common pool which can be used to hop off to any of those prefixes. You may however wish to partition your gateways by prefix, for instance you have a gateway which interfaces to the 408 area code, and another which interfaces to the 415 area code, and for cost reasons you want each gateway only to be used for calls to its area code. In that case, you can define several local zones on the gatekeeper, each responsible for a prefix, and have each gateway register to the zone handling its prefix. For example, you can define local zone gk-408 handling prefix 408....... and local zone gk-415 handling 415....... and have the gateway interfacing to the 408 area code register with gk-408, and the gateway with the 415 interface register to gk-415."
zone local
zone remote.
The following example matches the 212 area code and any seven digits as the zone prefix for gk-ny:
zone prefix gk-ny 212.......
To statically specify a remote zone if DNS is unavailable or undesirable, use the zone remote gatekeeper configuration command. To remove the remote zone, use the no form of this command.
zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address
other-gatekeeper-name | Name of the remote gatekeeper. |
other-domain-name | Domain name of the remote gatekeeper. |
other-gatekeeper-ip-address | IP address of the remote gatekeeper. |
port-number | (Optional) RAS signaling port number for the remote zone. Value ranges from 1 to 65535. If this is not set, the default is the well-known RAS port number 1719. |
No remote zone is defined. DNS will locate the remote zone.
Gatekeeper configuration
This command first appeared in Cisco IOS Release 11.3 NA.
All gatekeepers do not have to be in DNS. For those that are not, use the zone remote command so that the local gatekeeper knows how to access them. In addition, you may wish to improve call response time slightly for frequently accessed zones. If the zone remote command is configured for a particular zone, you do not need to make a DNS lookup transaction.
The following example configures the local gatekeeper to reach targets of the form xxx.cisco.com by sending queries to the gatekeeper named sj3.cisco.com at IP address 1.2.3.4:
zone remote sj3.cisco.com cisco.com 1.2.3.4 show gatekeeper zone statue
zone local
|
|