• The gateway can register with only one gatekeeper at a time.
• Only E.164 address resolution is supported.
• Because the gateway can register with only one gatekeeper at a time, redundant H.323 zone support provides only redundancy and does not provide any load balancing.
• Although redundant H.323 zone support allows you to configure alternate gatekeepers, it does not insert information in the alternate gatekeeper field of some RAS messages.

• Zone and Subnet Configuration
• Gateway Selection Process
• Redundant H.323 Zone Support

1.    gatekeeper

2.    zone local zone-name domain-name [ ras-ip-address ] [ port ]

3.    zone remote zone-name domain-name ip-address [port] [cost cost [priority priority]]

4.    zone prefix gatekeeper-name e164-prefix [blast | seq] [gw-priority priority gw-alias [gw-alias, ...]]

5.    use-proxy local-zone remote-zone zone-name outbound-from gateway

6.    zone subnet local-gatekeeper-name [ default | subnet-address {/ bits-in-mask |mask} enable ]

7.    Repeat Step 6 for each subnet.

8.    no shutdown

9.    exit

When a gatekeeper receives an admission request (ARQ) message from a local zone gateway, if bandwidth management is enabled in the gatekeeper checks the bandwidth. The gatekeeper sends an admission reject (ARJ) message to the local zone gateway if the local zone is out of bandwidth and if no remote zone has been configured. The ARJ reject reason is set to "resource unavailable."

If a remote zone has been configured, the gatekeeper sends a location request (LRQ) message to that zone. A check is made of the total, interzone, and session bandwidth limits of the remote zone. If no remote zone has been defined or if the gatekeeper receives location request reject (LRJ) messages from all the remote gateways to which it has sent LRQ messages, the gatekeeper sends an ARJ message (with the reject reason set to "resource unavailable") to the requesting gateway.

Note	The ARJ message functionality is available for only tech and zone prefix routing. By default, this functionality is not enabled.

In addition to the gatekeeper maintaining concurrent call counts per zone, after receiving ARQ and LRQ messages from a requesting gateway, the gatekeeper can also check the concurrent call count of the destination zone. If the call count exceeds a preconfigured maximum threshold and if no other remote zone has been configured, the gatekeeper sends an ARJ or LRJ message to the requesting gateway. The ARJ reject reason is shown as "resource unavailable" and the LRJ reject reason is shown as "undefined reason."

If a remote zone has been configured, the gatekeeper sends LRQ messages to the remote zones. If no remote zone has been defined or if the gatekeeper receives LRJ messages from all the remote gateways to which it has sent LRQ messages, the gatekeeper sends an ARJ message (with the reject reason set to "resource unavailable") and an LRJ message (with the reject reason set to "undefined reason") to the requesting gateway.

After receiving an ARQ message from a requesting gateway and if the destination is a local zone, the gatekeeper sends an ACF message to the requesting gateway only if the local destination gateway has resources.

If the local destination gateway is out of resources, the gatekeeper tries to send an LRQ message to remote destination zones until it receives a location confirmation (LCF) message or until no remote zones remain. If no remote zone has been defined or if the gatekeeper receives LRJ messages from remote destinations for all the LRQ messages sent, the gatekeeper sends an ARJ message to the requesting gateway. The reject reason in the ARJ message to the requesting gateway is set to "resource unavailable."

To configure session bandwidth limits of the destination zones and how the gateway should handle requests if resources run low, use the following commands beginning in global configuration mode.

1.    gatekeeper

2.    bandwidth check-destination

3.    arq reject-resource-low

4.    exit

1.    ip name-server dns-servername [ server-address2...server-address6 ]

2.    ip domain-name name

3.    ras [gk-id@] host [:port] [priority]

How you enter the text record for a particular domain depends on the DNS implementation. The following examples are for the Berkeley Internet Name Domain (BIND). These records are typically entered into the "hosts" database:

zone1.comintxt"ras gk.zone1.com"
zone2.comintxt"ras gk2@gk.zone2.com"
zone3.comintxt"ras gk.3@gk.zone3.com:1725"
zone4.comintxt"ras gk4@gk.zone4.com:1725 123"
zone5.comintxt"ras gk5@101.0.0.1:1725"

1.    gatekeeper

2.    zone remote other-gatekeeper-name other-domain-name other-gatekeeper-address [port]

3.    exit

When a gatekeeper receives an RRQ message from a gateway with a Foreign Exchange Station (FXS) port configured to register its E.164 address, it performs either of the following steps:

• If the E.164 alias is prefix-qualified, the gatekeeper tries to match the prefix with the zone prefixes it has defined. If a prefix is found, the gatekeeper searches its E.164 alias table with the exact alias from the RRQ message, including the prepended prefix, to make sure the alias is unique.
• If no zone prefix is found, the gatekeeper searches its E.164 alias table with the exact alias from the RRQ message:
  • If the alias does exist and it is not owned by the same endpoint, the gatekeeper sends a registration reject (RRJ) message.
  • If the alias does not exist, the gatekeeper creates an entry in the table for the exact alias name from the RRQ message, with or without the prefix qualifier, and sends a registration confirm (RCF) message.

Note	With the Gatekeeper Alias Registration and Address Resolution Enhancements feature, the gatekeeper creates an entry in its E.164 alias table for the exact alias name from the RRQ message. It does not strip off the prefix before creating the entry.

A gatekeeper with the Gatekeeper Alias Registration and Address Resolution Enhancements feature processes requests in a new way, as showing in the following examples. The gatekeeper is configured with two local zones, zone1 and zone2, and three prefixes, as follows:

Router(config-gk)#zone local zone1 domain.com 
Router(config-gk)#zone local zone2 domain.com 
Router(config-gk)#zone prefix zone2 407 ....... 
Router(config-gk)#zone prefix zone1 408 ....... 
Router(config-gk)#zone prefix zone1 409 .......

The table below shows various E.164 alias registration requests and the resulting gatekeeper actions.

To allow endpoints to communicate between zones, gatekeepers must be able to determine which zone an endpoint is in and be able to locate the gatekeeper responsible for that zone. If the Domain Name System (DNS) mechanism is available, a DNS domain name can be associated with each gatekeeper.

Note	For more information on DNS, see the "Configuring Intergatekeeper Communication" section.

• The gatekeeper-to-gatekeeper redundancy and load-sharing mechanism requires the Cisco H.323 VoIP Gatekeeper for Cisco Access Platforms feature.
• The order in which LRQs are sent to the gatekeepers is based on the order in which the gatekeepers are listed. You cannot specify a priority number for a gatekeeper.
• Regardless of the order in which the LRQs are sent, the gateway still uses the first gatekeeper that sends an LCF.
• The settings for delay between LRQs and the LRQ window are global and cannot be set on a per-zone or technology-prefix basis.
• The number of remote gatekeepers multiplied by the delay per LRQ cannot exceed the Routing Information Protocol (RIP) timeout. Therefore, we recommend that you limit your list of remote gatekeepers to two or three.
• If LRQ forwarding is enabled on the directory gatekeeper, the sequential setting for LRQs is ignored.
• Only E.164 address resolution is supported.
• Using redundant H.323 zone support in the "directory gatekeeper" can generate extra RAS messages. Therefore, the number of "directory gatekeeper" levels should be kept to a minimum (two or three at the maximum).
• If a gatekeeper fails, the endpoint might use alternate gatekeepers to continue operation. The example below creates a local cluster associated with a local zone and defines an alternate gatekeeper within the cluster.

Load balancing allows the gatekeeper to move registered H.323 endpoints to an alternate gatekeeper or to reject new calls and registrations once a certain threshold is met.

If a gatekeeper fails, the endpoint might use alternate gatekeepers to continue operation.

The gatekeeper-to-gatekeeper redundancy and load-sharing mechanism expands the capability that is provided by the redundant H.323 zone support feature. Redundant H.323 zone support allows you to configure multiple gatekeepers to service the same zone or technology prefix by sending LRQs to two or more gatekeepers.

With the redundant H.323 zone support feature, the LRQs are sent simultaneously (in a "blast" fashion) to all of the gatekeepers in the list. The gateway registers with the gatekeeper that responds first. Then, if that gatekeeper becomes unavailable, the gateway registers with another gatekeeper from the list.

The gatekeeper-to-gatekeeper redundancy and load-sharing mechanism allows you to configure gatekeeper support and to give preference to specific gatekeepers. You may choose whether the LRQs are sent simultaneously or sequentially (one at a time) to the remote gatekeepers in the list. If the LRQs are sent sequentially, a delay is inserted after the first LRQ and before the next LRQ is sent. This delay allows the first gatekeeper to respond before the LRQ is sent to the next gatekeeper. The order in which LRQs are sent to the gatekeepers is based on the order in which the gatekeepers are listed (using either the zone prefix command or the gw-type-prefix command).

Once the local gatekeeper has sent LRQs to all the remote gatekeepers in the list (either simultaneously or sequentially), if it has not yet received a location confirmation (LCF), it opens a "window." During this window, the local gatekeeper waits to see whether a LCF is subsequently received from any of the remote gatekeepers. If no LCF is received from any of the remote gatekeepers while the window is open, the call is rejected.

1.    gatekeeper

2.    zone local local-zone-name domain-name [ras-ip-address]

3.    zone cluster local cluster-name local-zone-name

4.    element alternateGK ip-address [port]

5.    exit

6.    load-balance [endpoints max-endpoints] [calls max-calls] [cpu max-%cpu] [memory max-%mem-used]

7.    exit

1.    show gatekeeper status

2.    show gatekeeper performance statistics

Router# show gatekeeper status
Gatekeeper State: UP
Load Balancing: ENABLED
Zone Name: RoseGK
Zone Name: PurpleGK
Accounting: DISABLED
Security: DISABLED
Maximum Remote Bandwidth: unlimited
Current Remote Bandwidth: 0 kbps
Current Remote Bandwidth (w/Alt GKs): 0 kbps
Load Balance Count: 0
Calls: 0/unlimited
Endpoints: 0/unlimited
Memory: 0%/90%
CPU: 0%/80%

Router# show gatekeeper performance statistics
Performance statistics captured since:19:00:12 EST Sun Feb 28 1993
RAS inbound message counters:
        Originating ARQ:426    Terminating ARQ:306    LRQ:154
RAS outbound message counters:
        ACF:731        ARJ:1  LCF:154        LRJ:0
        ARJ due to overload:0
        LRJ due to overload:0
Load balancing events:0
Real endpoints:5

1.    gatekeeper

2.    zone local zonename domainname [ras-ip-address] [port]

3.    zone cluster remote remote-cluster-name domainname [cost cost [priority priority]]

4.    element alternateGK IP-address [port]

5.    exit

6.    zone prefix remote-clustername e164-prefix

7.    exit

1.    show gatekeeper status cluster

2.    show gatekeeper zone status

3.    show gatekeeper zone cluster

4.    show proxy h323 status

5.    show gatekeeper cluster

Router# show gatekeeper status cluster
CLUSTER INFORMATION
                   ===================
                             Active   Endpoint   Last
Hostname       %Mem   %CPU   Calls    Count      Announce
--------       ----   ----   ------   --------   --------
MsPacman       17     2      0        1          Local Host
LavenderGK     30     1      0        4          14s

Router# show gatekeeper zone status
                         GATEKEEPER ZONES
                         ================
GK name      Domain Name   RAS Address     PORT  FLAGS
-------      -----------   -----------     ----- -----
RoseGK       cisco.com     209.165.201.30  1719  LS
  BANDWIDTH INFORMATION (kbps) :
    Maximum interzone bandwidth :unlimited
    Current interzone bandwidth :0
    Current interzone bandwidth (w/ Alt GKs) :0
    Maximum total bandwidth :unlimited
    Current total bandwidth :0
    Current total bandwidth (w/ Alt GKs) :0
    Maximum session bandwidth :unlimited
  SUBNET ATTRIBUTES :
    All Other Subnets :(Enabled)
  PROXY USAGE CONFIGURATION :
    Inbound Calls from all other zones :
      to terminals in local zone RoseGK :use proxy
      to gateways in local zone RoseGK  :do not use proxy
    Outbound Calls to all other zones :
      from terminals in local zone RoseGK :use proxy
      from gateways in local zone RoseGK  :do not use proxy

Router# show gatekeeper zone cluster
ALTERNATE GATEKEEPER INFORMATION
================================
                                TOT BW   INT BW   REM BW   LAST      ALT GK
LOCAL GK NAME ALT GK NAME   PRI (kbps)   (kbps)   (kbps)   ANNOUNCE  STATUS
------------- -----------   --- ------   ------   ------   --------  ------
RoseGK        LilacGK       120   0        0        0        7s      CONNECTED

Router# show proxy h323 status
        H.323 Proxy Status
        ==================
    H.323 Proxy Feature:Enabled
    Proxy interface = Ethernet0:UP
    Proxy IP address = 209.165.200.254
    Proxy IP port = 11720
    Application Specific Routing:Disabled
    RAS Initialization:Complete
    Proxy aliases configured:
      H323_ID:PROXY
    Proxy aliases assigned by Gatekeeper:
      H323_ID:PROXY
    Gatekeeper multicast discovery:Disabled
    Gatekeeper:
        Gatekeeper ID:DVM1
        IP address:209.165.200.254
    Gatekeeper registration succeeded
    T.120 Mode:PROXY
    RTP Statistics:OFF
    Number of calls in progress:0

Router# show gatekeeper cluster
gatekeeper
    zone local RTPGK1cisco.com
    zone cluster local RTPCluster RTPGK1
        element RTPGK2 209.165.200 1719
        element RTPGK3 209.165.200 1719
    zone cluster remote SJCluster cisco.com
        element SJGK1 209.18.79.23 1719
        element SJGK2 209.18.79.24 1719
        element SJGK3 209.18.79.25 1719
no shutdown
Router# show gatekeeper cluster
                    CONFIGURED CLUSTERS
                    ===================
Cluster Name    Type     Local Zone   Elements    IP
------------    ----     ----------   --------    --
RTPCluster      Local    RTPGK1       RTPGK2       209.165.200.254 1719
                                       RTPGK3      209.165.200.223 1719
SJCluster       Remote                SJGK1        209.165.200.257 1719
                                       SJGK2       209.165.200.258 1719
                                       SJGK3       209.165.200.259 1719

Note	For more information about configuring AAA services or RADIUS, see the Cisco IOS Security Configuration Guide at http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/15_0/sec_user_services_15_0_book.html .

To authenticate H.323 users via RADIUS, use the following commands beginning in global configuration mode.

1.    aaa new-model

2.    aaa authentication login {default | listname} method1 [method2...]

3.    radius-server host {hostname | ip-address}[auth-port port] [acct-port port] [timeout seconds] [retransmit retries] [key string]

4.    radius-server key { 0 string | 7 string | string }

5.    gatekeeper

6.    security {any | h323-id | e164} {password default password | password separator character}

7.    exit

8.    Enter each user into the RADIUS database.

1.    aaa new-model

2.    aaa authentication login { default | listname } method1 [ method2... ]

3.    radius-server deadtime minutes

4.    radius-server host { hostname | ip-address } [ auth-port port ] [ acct-port port ] [ timeout seconds ] [ retransmit retries ] [ key string ]

5.    radius-server key { 0 string | 7 string | string }

6.    Configure the CiscoSecure AAA server.

#Client Name       Key
#--------------    ----------
gk215.cisco.com    testing123

h323id@cisco.com  Password = "password"
User-Service-Type = Framed-User,
Login-Service = Telnet

1.    aaa accounting connection h323 { stop-only | start-stop | wait-start | none } [ broadcast ] group groupname

2.    gatekeeper

3.    accounting

4.    exit

Note	For more information about AAA connection accounting services, see the Cisco IOS Security Configuration Guide at http://www.cisco.com/en/US/docs/ios/sec_user_services/configuration/guide/15_0/sec_user_services_15_0_book.html .

• CAT is a Cisco-proprietary security mechanism and requires a Cisco solution to receive the full end-to-end benefits of the Gatekeeper-to-Gatekeeper Authentication feature.
• LRQ message authentication is done on a hop-by-hop basis. Because a non-Cisco gatekeeper does not support CATs, authentication stops at the non-Cisco gatekeeper. If a non-Cisco gatekeeper can support LRQ forwarding, end-to-end authentication is achieved. However, LRQ message authentication is performed only at the Cisco gatekeepers.
• If IZCT is used for Clustered Gatekeepers, the same IZCT password should be used on all the Gatekeepers belonging to the same cluster

This section contains the following information:

• Interzone ClearTokens
• Cisco Access Tokens
• Tokenless Call Authorization

1.    gatekeeper

2.    security izct password password

3.    no shutdown

4.    exit

1.    show running-config

Router# show running-config
gatekeeper
 zone local 35_dirgk cisco.com 172.18.198.196
 zone remote 40_gatekeeper cisco.com 172.18.198.91 1719
 zone remote 34_dirgk cisco.com 172.18.198.197 1719 foreign-domain
 zone prefix 40_gatekeeper 408*
 zone prefix 34_dirgk *
 security izct password ABCDEF
 lrq forward-queries
 no shutdown

1.    gatekeeper

2.    security password-group groupname lrq {receive password [encrypted] [effective hh:mm day month year] | send password [encrypted]}

3.    security zone {zonename | *} password-group groupname

4.    exit

%GK-5-RX_LRQ_PASSWORD_UPDATED:LRQ receive password for security password-group 'china' has been updated.

1.    show running-config

Router# show running-config
gatekeeper
 zone local tsunamiGK cisco 172.18.195.138
 zone remote laharGK cisco 172.18.195.139 1719
 zone prefix laharGK 987*
 security izct password 123456
 security password-group 1 lrq receive 0257550A5A57 encrypted
 security password-group 1 lrq send 144540595E56 encrypted
 security password-group 2 lrq receive 091F1D5A4A56 encrypted
 security password-group 2 lrq send 135143465F58 encrypted
 security zone larharGK password-group 1
 no shutdown

• Configuring the IP Access List
• Configuring IP-Access-List Security on the Gatekeeper

You can configure interzone routing using E.164 addresses.

Two types of address destinations are used in H.323 calls. You can specify a destination using either an H.323-ID address (a character string) or an E.164 address (a string that contains telephone keypad characters). The way in which interzone calls are routed depends on the type of address being used.

When using H.323-ID addresses, interzone routing is handled through the use of domain names. For example, to resolve the domain name bob@cisco.com, the source endpoint gatekeeper finds the gatekeeper for cisco.com and sends it the location request for the target address bob@cisco.com. The destination gatekeeper looks in its registration database, sees bob registered, and returns the appropriate IP address to get to bob.

When using E.164 addresses, call routing is handled through zone prefixes and gateway-type prefixes, also referred to as technology prefixes. The zone prefixes, which are typically area codes, serve the same purpose as domain names in H.323-ID address routing. Unlike domain names, however, more than one zone prefix can be assigned to one gatekeeper, but the same prefix cannot be shared by more than one gatekeeper.

Use the zone prefix command to define gatekeeper responsibilities for area codes. The command can also be used to tell the gatekeeper which prefixes are in its own zones and which remote gatekeepers are responsible for other prefixes.

Note	Area codes are used as an example in this section, but a zone prefix need not be an area code. It can be a country code, an area code plus local exchange (NPA-NXX), or any other logical hierarchical partition.

The following sample command shows how to configure a gatekeeper with the knowledge that zone prefix 212....... (that is, any address beginning with area code 212 and followed by seven arbitrary digits) is handled by gatekeeper gk-ny:

my-gatekeeper(config-gk)# zone prefix gk-ny 212.......

When my-gatekeeper is asked to admit a call to destination address 2125551111, it knows to send the location request to gk-ny.

However, once 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 could be an H.323 endpoint that has registered with gk-ny with that E.164 address, in which case gk-ny would return the IP address for that endpoint. However, it is more likely that the E.164 address belongs to a non-H.323 device, such as a telephone or an H.320 terminal.

Because non-H.323 devices do not register with gatekeepers, gk-ny has no knowledge of which device the address belongs to or which type of device it is, so the gatekeeper cannot decide which gateway should be used for the hop off to the non-H.323 device. (The term hop off refers to the point at which the call leaves the H.323 network and is destined for a non-H.323 device.)

Note

The number of zone prefixes defined for a directory gatekeeper that is dedicated to forwarding LRQs, and not for handling local registrations and calls, should not exceed 10,000; 4 MB of memory must be dedicated to describing zones and zone prefixes to support this maximum number of zone prefixes. The number of zone prefixes defined for a gatekeeper that handles local registrations and calls should not exceed 2000.

To enable the gatekeeper to select the appropriate hop-off gateway, use the gw-type-prefix command to configure technology or gateway-type prefixes. Select technology prefixes to denote different types or classes of gateways. The gateways are then configured to register with their gatekeepers using these technology prefixes.

For example, voice gateways might register with technology prefix 1#, and H.320 gateways might register with technology prefix 2#. If there are several gateways of the same type, configure them to register with the same prefix type. By having them register with the same prefix type, the gatekeeper treats the gateways as a pool out of which a random selection is made whenever a call for that prefix type arrives. If a gateway can serve more than one type of hop-off technology, it can register more than one prefix type with the gatekeeper.

Callers must identify the type of gateway by prepending the appropriate technology prefix for that gateway type to the destination address. For example, callers might request 1#2125551111 if they know that address 2125551111 is for a telephone and that the technology prefix for voice gateways is 1#. The voice gateway is configured with a dial peer (using the dial-peer command) so that when the gateway receives the call for 1#2125551111, it strips off the technology prefix 1# and bridges the next leg of the call to the telephone at 2125551111.

In cases in which the call scenario is as shown in the figure below, voice-gw1 can be configured to prepend the voice technology prefix 1# so that the use of technology prefixes is completely transparent to the caller.

Figure 4

Call Scenario

Additionally, in using the gw-type-prefix command, a particular gateway-type prefix can be defined as the default gateway type to be used for addresses that cannot be resolved. It also forces a technology prefix to always hop off in a particular zone.

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 technology prefix on the address. For example, if voice gateways are mostly used in a network, and all voice gateways have been configured to register with technology prefix 1#, the gatekeeper can be configured to use 1# gateways as the default technology if the following command is entered:

Router(config-gk)# gw-type-prefix 1# default-technology

Now a caller no longer needs to prepend 1# to use a voice gateway. Any address that does not contain an explicit technology prefix is routed to one of the voice gateways that registered with 1#.

With this default technology definition, a caller could ask the gatekeeper for admission to 2125551111. If the local gatekeeper does not recognize the zone prefix as belonging to any remote zone, it routes the call to one of its local (1#) voice gateways so that the call hops off locally. However, if it knows that gk-ny handles the 212 area code, it can send 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 type.

Note	For ease of maintenance, the same prefix type should be used to denote the same gateway type in all zones under your administration.

Also, with the gw-type-prefix command, a hop off can be forced to a particular zone. When an endpoint or gateway makes a call-admission request to its gatekeeper, the gatekeeper determines the destination address by first looking for the technology prefix. When that is matched, the remaining string is compared against known zone prefixes. If the address is determined to be a remote zone, the entire address, including technology and zone prefixes, is sent to the remote gatekeeper in a location request. That remote gatekeeper then uses the technology prefix to decide on which of its gateways to hop off. In other words, the zone prefix (defined using the zone prefix command) determines the routing to a zone, and once there, the technology prefix (defined using the gw-type-prefix command) determines the gateway to be used in that zone. The zone prefix takes precedence over the technology prefix.

This behavior can be overridden by associating a forced hop-off zone with a particular technology prefix. Associating a forced hop-off zone with a particular technology prefix forces the call to the specified zone, regardless of what the zone prefix in the address is. As an example, you are in the 408 area code and want callers to the 212 area code in New York to use H.323-over-IP and hop off there because it saves on costs. However, the only H.320 gateway is in Denver. In this example, calls to H.320 endpoints must be forced to hop off in Denver, even if the destination H.320 endpoint is in the 212 area code. The forced hop-off zone can be either a local zone (that is, one that is managed by the local gatekeeper) or a remote zone.

1.    gatekeeper

2.    zone local gatekeeper-name domain-name [ ras-ip-address ]

3.    zone prefix gatekeeper-name e164-prefix [ gw-priority pri-0-to-10 gw-alias [ gw-alias, ... ]]

4.    exit

To put all of your gateways in the same zone, use the gw-priority keyword and specify which gateways are used for calling different area codes. For example:

        
          zone local localgk xyz.com
        
          zone prefix localgk 408.......
        
          zone prefix localgk 415....... gw-priority 10 gw1 gw2
        
          zone prefix localgk 650....... gw-priority 0 gw1
      

The above commands accomplish the following:

• Domain xyz.com is assigned to gatekeeper localgk.
• Prefix 408 is assigned to gatekeeper localgk, and no gateway priorities are defined for it; therefore, all gateways registering to localgk can be used equally for calls to the 408 area code. No special gateway lists are built for the 408 prefix; a selection is made from the master list for the zone.
• The prefix 415 is added to gatekeeper localgk, and priority 10 is assigned to gateways gw1 and gw2.
• Prefix 650 is added to gatekeeper localgk, and priority 0 is assigned to gateway gw1.
• A priority 0 is assigned to gateway gw1 to exclude it from the gateway pool for prefix 650. When gw2 registers with gatekeeper localgk, it is added to the gateway pool for each prefix as follows:
  • For gateway pool for 415, gateway gw2 is set to priority 10.
  • For gateway pool for 650, gateway gw2 is set to priority 5.

1.    gatekeeper

2.    server flow-control [onset value] [abatement value] [qcount value]

3.    exit

1.    show running-config

2.    show gatekeeper status

3.    show gatekeeper servers

Router# show running-config
Building configuration...
Current configuration : 1055 bytes
!
version 12.2
no service single-slot-reload-enable
service timestamps debug datetime msec
service timestamps log uptime
no service password-encryption
!
hostname snet-3660-3
!
.
.
.
gatekeeper
 zone local snet-3660-3 cisco.com
 zone remote snet-3660-2 cisco.com 209.165.200.225 1719
 zone prefix snet-3660-2 408*
 lrq forward-queries
 no use-proxy snet-3660-3 default inbound-to terminal
 no use-proxy snet-3660-3 default outbound-from terminal
 no shutdown
 server registration-port 8000
 server flow-control
!
.
.
.

Router# show gatekeeper status
Gatekeeper State: UP
    Load Balancing:   DISABLED
    Flow Control:     ENABLED
    Zone Name:        snet-3660-3
    Accounting:       DISABLED
    Endpoint Throttling:        DISABLED
    Security:         DISABLED
    Maximum Remote Bandwidth:              unlimited
    Current Remote Bandwidth:              0 kbps
    Current Remote Bandwidth (w/ Alt GKs): 0 kbps

Router# show gatekeeper servers
            GATEKEEPER SERVERS STATUS
            =========================
Gatekeeper Server listening port: 8250
Gatekeeper Server timeout value: 30 (100ms)
GateKeeper GKTMP version: 3.1
Gatekeeper-ID: Gatekeeper1
------------------------
  RRQ  Priority: 5
    Server-ID: Server43
    Server IP address: 209.165.200.254:40118
    Server type: dynamically registered
    Connection Status: active
    Trigger Information:
      Trigger unconditionally
    Server Statistics:
    REQUEST RRQ Sent=0
    RESPONSE RRQ Received = 0
    RESPONSE RCF Received = 0
    RESPONSE RRJ Received = 0
    Timeout encountered=0
    Average response time(ms)=0
    Server Usable=TRUE

1.    gatekeeper

2.    timer server retry seconds

3.    exit

1.    show gatekeeper servers

Router# show gatekeeper servers
            GATEKEEPER SERVERS STATUS
            =========================
Gatekeeper Server listening port:0
Gatekeeper Server response timeout value:30 (100ms)
Gatekeeper Server connection retry timer value:30 (sec)
Gatekeeper GKTMP version:4.1

1.    gatekeeper

2.    server absent reject {rrq | arq}

3.    exit

1.    show running-config

Router# show running-config
.
.
.
gw-type-prefix 1#* default-technology
gw-type-prefix 9#* gw ipaddr 1.1.1.1 1720
no shutdown
server absent reject rrq
.
.
.

Router# show running-config
.
.
.
gw-type-prefix 1#* default-technology
gw-type-prefix 9#* gw ipaddr 1.1.1.1 1720
no shutdown
server absent reject arq
.
.
.

H.323 is a complex, dynamic protocol that consists of several interrelated subprotocols. During H.323 call setup, the ports and addresses released with this protocol require a detailed inspection as the setup progresses. If the firewall does not support this dynamic access control based on the inspection, a proxy can be used just inside the firewall. The proxy provides a simple access control scheme, as illustrated in the figure below.

Figure 5

Proxy Inside the Firewall

Because the gatekeeper (using RAS) and the proxy (using call setup protocols) are the only endpoints that communicate with other devices outside the firewall, it is simple to set up a tunnel through the firewall to allow traffic destined for either of these two endpoints to pass through.

If H.323 terminals exist in an area with local interior addresses that must be translated to valid exterior addresses, the firewall must be capable of decoding and translating all addresses passed in the various H.323 protocols. If the firewall is not capable of this translation task, a proxy may be placed next to the firewall in a co-edge mode. In this configuration, interfaces lead to both inside and outside networks. (See the figure below.)

Figure 6

Proxy in Co-Edge Mode

In co-edge mode, the proxy can present a security risk. To avoid exposing a network to unsolicited traffic, configure the proxy to route only proxied traffic. In other words, the proxy routes only H.323 protocol traffic that is terminated on the inside and then repeated to the outside. Traffic that moves in the opposite direction can be configured this way as well.

To place the proxy and gatekeeper outside the firewall, two conditions must exist. First, the firewall must support H.323 dynamic access control. Second, Network Address Translation (NAT) must not be in use.

If NAT is in use, each endpoint must register with the gatekeeper for the duration of the time it is online. This quickly overwhelms the firewall because a large number of relatively static, internal-to-external address mappings need to be maintained.

If the firewall does not support H.323 dynamic access control, the firewall can be configured with static access lists that allow traffic from the proxy or gatekeeper through the firewall. This can present a security risk if an attacker can spoof, or simulate, the IP addresses of the gatekeeper or proxy and use them to attack the network. The figure below illustrates proxy outside the firewall.

Figure 7

Proxy Outside the Firewall

When a firewall is providing NAT between an internal and an external network, proxies may allow H.323 traffic to be handled properly, even in the absence of a firewall that can translate addresses for H.323 traffic. The tables below provide guidelines for proxy deployment for networks that use NAT.

• The proxy is not capable of modifying the Quality of Service (QoS) between the terminal and itself. To achieve the best overall QoS, ensure that terminals are connected to the proxy using a network that intrinsically has good QoS. In other words, configure a path between a terminal and proxy that provides good bandwidth, delay, and packet-loss characteristics without the terminal needing to request special QoS. A high-bandwidth LAN works well for this.

QoS enables complex networks to control and predictably service a variety of applications. QoS expedites the handling of mission-critical applications while sharing network resources with noncritical applications. QoS also ensures available bandwidth and minimum delays required by time-sensitive multimedia and voice applications. In addition, QoS gives network managers control over network applications, improves cost-efficiency of WAN connections, and enables advanced differentiated services. QoS technologies are elemental building blocks for other Cisco IOS-enabling services such as its H.323-compliant gatekeeper. Overall call quality can be improved dramatically in the multimedia network by using pairs of proxies between regions of the network where QoS can be requested.

• RSVP and IP Precedence
• Application-Specific Routing

The examples in this section illustrate a separate multimedia backbone network dedicated to transporting only H.323 traffic. The closed functionality of the H.323 proxy is necessary for creating this type of backbone. Place a closed H.323 proxy on each edge of the multimedia backbone to achieve the following goals:

• The proxy directs all inter-proxy H.323 traffic, including Q.931 signaling, H.245, and media stream, to the multimedia backbone.
• The proxy shields the multimedia backbone so that routers on edge networks and other backbone networks are not aware of its existence. In this way, only H.323-compliant packets can access or traverse the multimedia backbone.
• The proxy drops any unintended non-H.323 packets that attempt to access the multimedia backbone.

The figure below illustrates a network that has a multimedia backbone. A gatekeeper (not shown) in the edge network (zone) directs all out-of-zone H.323 calls to the closed proxy on the edge of that network. The closed proxy forwards this traffic to the remote zone through the multimedia backbone. A closed proxy and the edge router may reside in the same router or they may be in separate routers, as shown in the figure.

Figure 8

Sample Network with Multimedia Backbone

• Enabling the Proxy to Forward H.323 Packets
• Isolating the Multimedia Network

1.    proxy h323

2.    interface type number [nametag]

3.    h323 interface [ port ]

4.    h323 h323-id h323-id

5.    h323 gatekeeper [ id gatekeeper-id ] { ipaddr ip-address [ port ] | multicast }

6.    h323 qos {ip-precedence | rsvp {controlled-load | guaranteed-qos}}

7.    ip route-cache [ cbus ] same-interface [ flow ] distributed

8.    exit

To enable ASR on the proxy, start the proxy and then define the H.323 name, zone, and QoS parameters on the loopback interface. Next, determine which interface is used to route the H.323 traffic and configure ASR on it. The ASR interface and all other interfaces must be separated so that routing information never travels from one to the other. There are two different ways to separate the ASR interface and all other interfaces:

• Use one type of routing protocol on the ASR interface and another on all the non-ASR interfaces. Include the loopback subnet in both routing domains.
• Set up two different autonomous systems, one that contains the ASR network and the loopback network and another that contains the other non-ASR networks and loopback network.

To ensure that the ASR interface and all other interfaces never route packets between each other, configure an access control list. (The proxy traffic is routed specially because it is always addressed to the loopback interface first and then translated by the proxy subsystem.)

Note	ASR is not supported on Frame Relay or ATM interfaces for the Cisco MC3810.

1.    proxy h323

2.    interface type number [ nametag ]

3.    ip address ip-address mask [ secondary ]

4.    h323 interface [ port ]

5.    h323 h323-id h323-id

6.    h323 gatekeeper [ id gatekeeper-id ] { ipaddr ip-address [ port ] | multicast }

7.    h323 qos {ip-precedence | rsvp {controlled-load | guaranteed-qos}}

8.    interface type number [ nametag ]

9.    h323 asr [bandwidth max-bandwidth]

10.    ip address ip-address mask [ secondary ]

11.    exit

12.    interface type number [ nametag ]

13.    ip address ip-address mask [ secondary ]

14.    exit

15.    router rip

16.    network network-number

17.    router igrp autonomous-system

18.    network network-number

19.    network loopback-addr

20.    access-list access-list-number { permit | deny } source source-mask [ destination destination-mask ] { eq | neq } [[ source-object ] [ destination-object ] [ identification ] any ]

21.   

22.    interface type number [ nametag ]

23.    ip access-group { access-list-number | access-list-name } { in | out }

24.    exit