Configuring Gatekeepers (Multimedia Conference Manager)

Multimedia Conference Manager provides a rich list of networking capability, including the following:

With Multimedia Conference Manager, you can do the following:

Proxy subsystems provide the following features:

These nodes attempt to register with a gatekeeper upon startup. When they wish to communicate with another endpoint, they request admission to the call, using a symbolic alias for the endpoint name such as an E.164 address or an e-mail ID. If the gatekeeper decides the call can proceed, it returns a destination IP address to the originating endpoint. This IP address cannot be the actual address of the target endpoint, but it can be an intermediate address. A gatekeeper and its registered endpoints then exchange status information.

Note Although the gatekeeper is an optional H.323 component, it must be included in the network if proxies are used.

A gatekeeper supports a broad variety of H.323 terminal implementations from many different vendors. These terminals must support the standard H.323 RAS protocol in order to function with the gatekeeper features.

There are three ways to set up calls between various endpoints, as described in the following sections:

1. TA1 asks GK1 for permission to call TB1.

2. GK1 returns the address of TB1 to TA1.

3. TA1 then calls TB1.

1. TA1 asks GK1 for permission to call TA2.

2. TA2 is not in the GK1 zone. GK1 locates GK2 as the TA2 gatekeeper. GK1 then asks GK2 for TA2 address.

3. GK2 returns TA2 address to GK1.

4. GK1 returns the address to TA1.

5. TA1 calls TA2.

If terminal TA1 in Zone 1 wants to call terminal TA3 in Zone 3, the following sequence of events occurs:

1. TA1 asks GK1 for permission to call TA3.

2. GK1 locates GK3 as the TA3 gatekeeper. GK1 asks GK3 for TA3 address.

3. GK3 responds with P3 address instead of TA3 address, to hide TA3 identity.

4. GK1 knows that to get to P3, the call must go through P1. So GK1 returns P1 address to TA1.

5. TA1 calls P1.

6. P1 consults GK1 to discover the true call's destination (which is TA3 in this example).

7. GK1 instructs P1 to call P3.

8. P1 calls P3.

9. P3 consults GK3 for the true destination, which is TA3.

10. GK3 gives TA3 address to P3.

11. P3 completes the call to TA3.

A call from TA1 to TA2 is set up as follows:

1. TA1 asks GK1 for permission to connect to TA2 E.164 address.

2. The gatekeeper looks through its local registrations and does not find any H.323 terminals registered with that E.164 address, so the gatekeeper assumes that it is an H.320 terminal outside the scope of H.323. The gatekeeper instructs TA1 to connect to the GW1 IP address.

3. TA1 connects to GW1.

4. GW1 completes the call to TA2.

A call from TA2 to TA1 is set up as follows:

1. TA2 calls GW1 and provides the TA1 E.164 address as the final destination.

2. GW1 sends a message to GK1 asking to connect to that address.

3. GK1 gives GW1 the address of TA1.

4. GW1 completes the call with TA1.

There are three ways to set up an MCU conference call, as described in the following sections:

1. TA1, TA2, and TA3 join the conference by asking GK1 for permission to call the given conference ID.

2. GK1 returns the address of the MCU to TA1, TB1, and TC1.

3. TA1, TA2, and TA3 then call the MCU.

1. TA1, TB1, and TC1 ask GK1 for permission to join the conference.

2. GK1 locates GK2 for the remote zone containing conference CompanyMeeting@zone2.com using DNS or information configured on GK1. GK1 sends a request to GK2 to recover the MCU address.

3. GK2 gives the MCU address to GK1.

4. GK1 gives the MCU address to TA1, TB1, and TC1, and instructs these endpoints to set up the call with the MCU.

5. TA1, TB1, and TC1 then call the MCU.

Endpoints attempt to discover a gatekeeper, and consequently which zone they are members of, by using the RAS message protocol. The protocol supports a discovery message that may be sent multicast or unicast.

If the message is sent multicast, the endpoint registers nondeterministically with the first gatekeeper to respond. To enforce predictable behavior, where endpoints on certain subnets are assigned to specific gatekeepers, you can use the zone subnet command to define the subnets that constitute a given gatekeeper zone. Any endpoint on a subnet that is not enabled for the gatekeeper will not be accepted as a member of that gatekeeper zone. If the gatekeeper receives a discovery message from such an endpoint, it will send an explicit reject message.

• H.323 IDs, which are arbitrary, case-sensitive text strings.

• E.164 addresses, which are telephone numbers.

If an H.323 network deploys interzone communication, each terminal should at least have a fully-qualified e-mail name as its H.323 ID, for example, bob@cisco.com. The domain name of the e-mail ID should be the same as the configured domain name for the gatekeeper of which it is to be a member. As in the previous example, the domain name would be cisco.com.

If you enable this feature, the gatekeeper attempts to use the registered aliases along with a password, and complete an authentication transaction to a RADIUS/TACACS+ server. The registration will only be accepted if RADIUS/TACACS+ successfully authenticates the name.

The gatekeeper can be configured to use a default password for all users. It can also be configured to recognize a password separator character that allows users to piggyback their passwords onto H.323-ID registrations by using it to separate the ID and password fields.

Note The names loaded into RADIUS/TACACS+ are probably not the same names provided for dial access, because they may all have the same password.

Additionally, the gw-type-prefix command can provide the ability to define a particular gateway-type prefix as being the default gateway type to be used for unresolveable addresses, and also to force 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 you use mostly voice gateways in your network, and you have configured all your voice gateways to register with technology prefix 1#, you can configure your gatekeeper to use 1# gateways as the default technology by entering the following command:

my-gatekeeper(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 will be 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 will route the call to one of its local (1#) voice gateways, so 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, we recommend that you use the same prefix type to denote the same gateway type in all zones under your administration. No more than 50 different technology prefixes should be registered per zone.

The gw-type-prefix command also provides the ability to force a hop-off to a particular zone. When an endpoint or gateway makes a call-admission request to its gatekeeper, the gatekeeper resolves 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 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 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. You can define the gateway type prefix for H.320 gateways as one that is always forced to the Denver zone. The forced hop-off zone can either be a local zone (that is, one that is managed by the local gatekeeper) or a remote zone.

There are several ways to use a proxy with a firewall to enhance your network security. The configuration that you choose depends on how capable your firewall is of handling the complex H.323 protocol suite. Each of the following sections describes a common configuration for using the proxy with a 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.

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

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

Table 9: Guidelines for Networks Using NAT

For Networks Using NAT	Firewall with H.323 NAT	Firewall Without H.323 NAT
Firewall with Dynamic Access Control	Gatekeeper and proxy inside the firewall.	Co-edge gatekeeper and proxy.
Firewall Without Dynamic Access Control	Gatekeeper and proxy inside the firewall with static access lists on the firewall.	Co-edge gatekeeper and proxy.

Table 10: Guidelines for Networks Not Using NAT

For Networks Not Using NAT	Firewall with H.323. NAT	Firewall Without H.323 NAT
Firewall with Dynamic Access Control	Gatekeeper and proxy inside the firewall. Gatekeeper and proxy outside the firewall.	Gatekeeper and proxy inside the firewall. Gatekeeper and proxy outside the firewall.
Firewall Without Dynamic Access Control	Gatekeeper and proxy inside the firewall with static access lists on the firewall.	Gatekeeper and proxy inside the firewall with static access lists on the firewall.

When two H.323 terminals communicate directly, the resulting call quality can range from good (for high-bandwidth intranets) to poor (for most calls over the public network). As a result, deployment of H.323 is almost always predicated on the availability of some high-bandwidth, low-delay, low-packet-loss network that is either separate from the public network or runs overlaid with the network as a premium service with adequate QoS.

Adequate QoS usually requires terminals that know how to signal such premium services. There are two major ways to achieve such signalling:

• RSVP to reserve flows with adequate QoS based on the media codecs of H.323 traffic.

• IP precedence bits to signal that the H.323 traffic is special and deserves higher priority.

Unfortunately, the vast majority of H.323 terminals cannot achieve signalling in either of these ways.

You can configure the proxy to use any combination of RSVP and IP precedence bits.

The proxy is not capable of modifying the QoS between the terminal and itself. To achieve the best overall QoS, you should ensure that terminals are connected to the proxy using a network that intrinsically has good QoS. In other words, you can 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.

Implementation of ASR ensures the following:

• Each time a connection is established with another proxy, the proxy automatically installs a host route pointing at the interface designated for ASR.

• The proxy is configured to use a loopback interface address. The proxy address is visible to both the ASR interface and all regular interfaces, but no routes are propagated to or from the ASR interface. This ensures that no non-H.323 traffic is routed through the ASR interface.

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

	Command	Purpose
Step 1	Router#configure terminal	Enters global configuration mode.
Step2	Router(config)#gatekeeper	Enters gatekeeper configuration mode.
Step3	Router(config-gk)#zone prefix gatekeeper-name e164-prefix [gw-priority pri-0-to-10 gw-alias [gw-alias, ...]]	Adds a prefix to the gatekeeper zone list.
Step4	Router(config-gk)#zone local gatekeeper-name domain-name	Creates the gatekeeper name.
Step5	Router(config-gk)#zone subnet local-gatekeeper-name subnet-address {/bits-in-mask | mask-address} enable Router(config-gk)#no zone subnet local-gatekeeper-name default enable or Router(config-gk)#no zone subnet local-gatekeeper-name subnet-address {/bits-in-mask | mask-address} enable or Router(config-gk)#zone subnet gatekeeper-name default enable	Defines a set of subnets that constitute the gatekeeper zone. Enables the gatekeeper for each of these subnets, and disables it for all other subnets.(Repeat for all subnets.) or Defines the zone as being all but a set of subnets by disabling a set of subnets and enabling all others. (Repeat for all subnets.) or Accepts the default behavior, which is that all subnets are enabled.
Step6	Router(config-gk)#no shutdown	Brings the gatekeeper online.

The local-gatekeeper-name argument should be a DNS host name if DNS is to be used to locate remote zones.

You can use the zone subnet command more than once to create a list of subnets controlled by a gatekeeper. The subnet masks need not match actual subnets in use at your site. For example, to specify a particular endpoint, you can supply its address with a 32-bit netmask.

If a local gatekeeper name is contained in the message, it must match the local-gatekeeper-name argument.

NoteIf you want to explicitly enable or disable a particular endpoint, specify its host address with a 32-bit subnet mask.

	Command	Purpose
Step1	Router#configure terminal	Enters global configuration mode.
Step2	Router(config)#ip name-server dns-server-name	Specifies the DNS server address.
Step3	Router(config)#ip domain-name domain name	Sets the default domain name for the Cisco IOS.

The gk-id argument is an optional gatekeeper ID. If the optional gatekeeper ID is not specified, host is used as the gatekeeper ID.

The host argument is either an IP address or the actual host name of the gatekeeper in the form host.some_domain.com.

The port argument, if specified, should be some port number other than RAS port 1719.

The priority argument specifies the order in which the listed gatekeepers should be searched for endpoints. Gatekeepers with lower priorities are searched before those with higher numbers.

zone1.com in txt "ras gk.zone1.com"
zone2.com in txt "ras gk2@gk.zone2.com"
zone3.com in txt "ras gk3@gk.zone3.com:1725"
zone4.com in txt "ras gk4@gk.zone4.com:1725 123"
zone5.com in txt "ras gk5@101.0.0.1:1725"

If you choose not to use DNS, or DNS is unavailable, you can configure intergatekeeper communication manually. To configure intergatekeeper manual communication, use the following commands beginning in gatekeeper configuration mode for every other gatekeeper in the network:

Command	Purpose
Router(config-gk)#zone remote other-gatekeeper-name other-domain-name other-gatekeeper-ip-address [port-number]	Configures inter-gatekeeper communication with other gatekeepers in your network. Enter this command for each gatekeeper.

NoteThe zone access command, configured on your local gatekeeper, only affects the use of proxies for incoming calls (that is, it does not affect the use of local proxies for outbound calls). When originating a call, a gatekeeper will use a proxy only if the remote gatekeeper offers a proxy at the remote end. A call between two endpoints in the same zone will always be a direct (nonproxied) call.

To make your local zone directly accessible to a small set of remote zones and accessible using proxies to all other remote zones, use the following commands in gatekeeper configuration mode:

	Command	Purpose
Step1	Router(config-gk)#zone access local-zone-name remote-zone remote-zone-name direct	Makes your local zone directly accessible to a remote zone (proxies not required). Repeat this command for each remote zone that you wish to give direct access to your local zone.
Step2	Router(config-gk)#zone access local-zone-name default proxied	Makes your local zone accessible via proxy to all other remote zones.

To make your local zone accessible using proxies to a small set of remote zones and directly accessible to all other remote zones, use the following commands in gatekeeper configuration mode:

	Command	Purpose
Step1	Router(config-gk)#zone access local-zone-name remote-zone remote-zone-name proxied	Makes your local zone accessible via proxies to a remote zone. Repeat this command for each remote zone that you wish to give proxied access to your local zone.
Step2	Router(config-gk)#zone access local-zone-name default direct	Makes your local zone directly accessible to all other remote zones.

	Command	Purpose
Step1	Router(config-gk)#zone local gatekeeper-name domain-name	Defines your local zone.
Step2	Router(config-gk)#alias static ip-signaling-addr port gkid gatekeeper-name terminal h323id h323-id	Creates a static entry in your local alias table for an H.323ID. Repeat this step for each H.323ID you want to add for the endpoint.
Step3	Router(config-gk)#alias static ip-signaling-addr port gkid gatekeeper-name terminal e164 e164-address	Creates a static entry in your local alias table for each E.164 address. Repeat this step for each E.164 address you want to add for the endpoint.

	Command	Purpose
Step1	Router(config)#aaa new-model	Enables AAA services.
Step2	Router(config)#aaa authentication login h323 radius	Enables login authentication for H.323 users via RADIUS.
Step3	Router(config)#radius-server host {hostname | ip-address}	Specifies the RADIUS server.
Step4	Router(config)#radius-server string keystring	Specifies the RADIUS server key.
Step5	Router(config)# gatekeeper	Enters gatekeeper configuration mode.
Step6	Router(config-gk)#security h323-id or Router(config-gk)#security e164 or Router(config-gk)#security any	Identifies users by their H.323 ID. or Identifies users by their E.164 address. or Identifies users by either their E.164 address or H.323 ID.
Step7	Router(config-gk)# security password default password or Router(config-gk)#security password separator character	Defines a default security password. or Identifies users by their H.323 ID.

After you complete the previous steps, enter each user into the RADIUS database, using either the default password if using the security password default command, or actual passwords if using the piggybacked password mechanism as the RADIUS authentication for that user. Enter either the user H.323-ID or E.164 address, depending on how you configured the gatekeeper.

For more information about configuring AAA services or RADIUS, refer to the Cisco IOS Security Configuration Guide.

	Command	Purpose
Step1	Router#gatekeeper	Enters gatekeeper configuration mode.
Step2	Router(config-gk)#zone local gatekeeper-name domain-name	Creates the local gatekeeper name.
Step3	Router(config-gk)#zone remote other-gatekeeper-name other-domain-name other-ip-address [port-number]	Creates the remote gatekeeper name.
Step4	Router(config-gk)#zone prefix gatekeeper-name e164-prefix	Configures knowledge of the zone prefixes.
Step5	Router(config-gk)#gw-type-prefix type-prefix [hopoff gkid] [default-technology] [[gwipaddr ipaddr [port]]] ...	Defines technology prefixes.

	Command	Purpose
Step1	Router(config)#proxy h323	Starts the proxy.
Step2	Router(config)#interface Loopback0	Enters loopback interface configuration mode.
Step3	Router(config-int)#ip address ipaddr subnet-mask or Router(config-int)#ip address ipaddr/subnet-mask-size	Defines the interface subnet.
Step4	Router(config-int)#h323 interface	Signals the proxy that this interface IP address is the one to use.
Step5	Router(config-int)#h323 h323-id h323-id	Configures the proxy name. (More than one name can be configured if necessary.)
Step6	Router(config-int)#h323 gatekeeper [id gatekeeper-id] ipaddr ipaddr or Router(config-int)#h323 gatekeeper [id gatekeeper-id] multicast	Sets up the zone in which the proxy will run unicast gatekeeper discovery. or Sets up the zone in which the proxy will run multicast gatekeeper discovery.
Step7	Router(config-int)#h323 qos ip-precedence value	Configures IP Precedence.
Step8	Router(config-int)#h323 qos rsvp controlled-load or Router(config-int)#h323 qos rsvp guaranteed-qos	Configures RSVP. Sets up RSVP with controlled-load class of service. or Sets up RSVP with guaranteed class of service.
Step9	Router(config-int)#interface type number	If ASR is to be used, enters interface configuration mode on the interface through which outbound H.323 traffic should be routed.
Step10	Router(config-int)#h323 asr or Router(config-int)#h323 asr bandwidth bandwidth	Enables ASR with no bandwidth limitations. or Enables ASR and limits the total bandwidth of H.323 traffic through the ASR interface.
Step11	Router(config-int)#ip address asr-addr asr-subnet-mask	Sets up the ASR interface network number.
Step12	Router(config-int)#exit (or press Ctrl-Z)	Returns to global configuration mode.
Step13	Router(config)#interface type number	Enters interface configuration mode on a non-ASR interface.
Step14	Router(config-int)#ip address non-asr-addr non-asr-subnet-mask	Sets up a non-ASR interface network number.
Step15	Router(config-int)#exit (or press Ctrl-Z)	Returns to global configuration mode.
Step16	Router(config)#router rip	Configures RIP for a non-ASR interface.
Step17	Router(config)#network non-asr-addr	Includes a non-ASR interface in RIP domain.
Step18	Router(config)#network loopback-addr	Includes a loopback interface in RIP domain.
Step19	Router(config)#router igrp asr-autonomous-system-number	Configures IGRP for an ASR interface.
Step20	Router(config)#network asr-addr	Includes an ASR interface in an IGRP domain.
Step21	Router(config)#network loopback-addr	Includes a loopback interface in an IGRP domain.
Step22	Router(config)#access-list access-list-number permit ip host loopback-address any Router(config)#access-list access-list-number permit ip any host loopback-address Router(config)#access-list access-list-number permit igrp any any1	Creates an access list.
Step23	Router(config)#interface type number	Enters interface configuration mode on an ASR interface.
Step24	Router(config-int)#ip access-group access-list-number out	Sets the outbound access group.
Step25	Router(config-int)#ip access-group access-list-number in	Sets the inbound access group.
Step26	Router(config-int)#exit (or press Ctrl-Z)	Leaves ASR interface configuration mode.

1You may replace igrp with the appropriate routing protocol in use on the ASR interface.

NoteASR is not supported on Frame Relay or ATM interfaces for the Cisco MC3810 platform.

	Command	Purpose
Step1	Router(config)#proxy h323	Starts the proxy.
Step2	Router(config)#interface Loopback0	Enters loopback interface configuration mode.
Step3	Router(config-int)#ip address ipaddr subnet-mask or Router(config-int)#ip address ipaddr/subnet-mask-size	Defines the interface subnet.
Step4	Router(config-int)#h323 interface	Signals the proxy that this interface IP address is the one to use.
Step5	Router(config-int)#h323 h323-id h323-id	Configures the proxy name. (More than one name can be configured if necessary.)
Step6	Router(config-int)#h323 gatekeeper [id gatekeeper-id] ipaddr ipaddr or Router(config-int)#h323 gatekeeper [id gatekeeper-id] multicast	Sets up the zone in which the proxy will run unicast gatekeeper discovery. or Sets up the zone in which the proxy will run multicast gatekeeper discovery.
Step7	Router(config-int)#h323 qos ip-precedence value	Configures IP Precedence.
Step8	Router(config-int)#h323 qos rsvp controlled-load or Router(config-int)#h323 qos rsvp guaranteed-qos	Configures RSVP. Sets up RSVP with controlled-load class of service. or Sets up RSVP with guaranteed class of service.
Step9	Router(config-int)#interface type number	If ASR is to be used, enters interface configuration mode on the interface through which outbound H.323 traffic should be routed.
Step10	Router(config-int)#h323 asr or Router(config-int)#h323 asr bandwidth bandwidth	Enables ASR with no bandwidth limitations. or Enables ASR and limits the total bandwidth of H.323 traffic through the ASR interface.
Step11	Router(config-int)#ip address asr-addr asr-subnet-mask	Sets up the ASR interface network number.
Step12	Router(config-int)#exit (or press Ctrl-Z)	Returns to global configuration mode.
Step13	Router(config)#interface type number	Enters interface configuration mode on a non-ASR interface.
Step14	Router(config-int)#ip address non-asr-addr non-asr-subnet-mask	Sets up a non-ASR interface network number.
Step15	Router(config-int)#exit (or press Ctrl-Z)	Returns to global configuration mode.
Step16	Router(config)#router igrp non-asr-autonomous-system-number	Configures IGRP for a non-ASR interface.
Step17	Router(config)#network non-asr-addr	Includes a non-ASR interface in an IGRP domain.
Step18	Router(config)#network loopback-addr	Includes a loopback interface in an IGRP domain.
Step19	Router(config)#router igrp asr-autonomous-system-number	Configures IGRP for an ASR interface.
Step20	Router(config)#network asr-addr	Includes an ASR interface in an IGRP domain.
Step21	Router(config)#network loopback-addr	Includes a loopback interface in an IGRP domain.
Step22	Router(config)#access-list access-list-number permit ip host loopback-address any Router(config)#access-list access-list-number permit ip any host loopback-address Router(config)#access-list access-list-number permit igrp any any1	Creates an access list.
Step23	Router(config)#interface type number	Enters interface configuration mode on an ASR interface.
Step24	Router(config-int)#ip access-group access-list-number out	Sets the outbound access group.
Step25	Router(config-int)#ip access-group access-list-number in	Sets the inbound access group.
Step26	Router(config-int)#exit (or press Ctrl-Z)	Leaves ASR interface configuration mode.

1You may replace the igrp keyword with the appropriate routing protocol in use on the ASR interface.

hostname gk-eng.xyz.com
! This router serves as the gatekeeper for the engineering community
! at xyz.com.
ip domain-name xyz.com
! domain name of this company
interface Ethernet0
 ip address 172.21.127.27 255.255.255.0
! This gatekeeper can be found at address 172.21.127.27
gatekeeper
! Enter gatekeeper config mode
 zone local gk-eng.xyz.com xyz.com
! Because a zone is, by definition, the area of control of a gatekeeper,
! we tend to use the terms "zone name" and "gatekeeper name" synonymously.
! Here we use the host name as the name of the gatekeeper and zone.
! This is not necessary, but does simplify administration.
 zone remote gk-mfg.xyz.com xyz.com 171.120.1.4 1719
 zone remote gk-corp.xyz.com xyz.com 170.124.3.80 1719
! A couple of other zones within xyz.com. We make lots of calls
! between these departments, so we just configure these so we save
! a little time bypassing DNS lookup to find their gatekeepers.
 zone access gk-eng.xyz.com remote-zone gk-mfg.xyz.com direct
 zone access gk-eng.xyz.com remote-zone gk-corp.xyz.com direct
 zone access gk-eng.xyz.com default proxied
! We have good QoS on our local network, so we don't need proxies when
! calling between the xyz.com zones. But for all other zones, we want
! to use proxies.
zone subnet gk-eng.xyz.com 172.21.127.0/24 enable
no zone subnet gk-eng.xyz.com default enable
! We will accept registrations from our local subnet as long as they
! do not specify some other gatekeeper name. We will not accept any
! registrations from any other subnet.
 zone bw gk-eng.xyz.com 2000
! Preserve our good QoS by not allowing excessive amounts of H.323 traffic
! on the local network. This restricts the traffic within our zone,
! for both intra-zone and interzone calls, to 2 kbps at any given time.
 alias static 172.21.127.49 gkid gk-eng.xyz.com terminal h323id joeblow ras
172.21.127.49 1719
! The "user" has an H.323 terminal, which does not support RAS. So we have
! to configure his alias manually so that callers can find him.

• gw-sj2 configured to register with technology prefix 2#

• gw-sj3 configured to register with technology prefix 3#

• gw-sj4 configured to register with technology prefix 4#

Similarly, in ny (New York in the 212 area code), gateways are configured to register with gk-ny as follows:

• gw-ny2 configured to register with technology prefix 2#

• gw-ny3 configured to register with technology prefix 3#

• gw-ny4 configured to register with technology prefix 4#

For the gatekeeper for San Jose, the configuration commands are as follows:

   gatekeeper
     zone local gk-sj cisco.com
     zone remote gk-ny cisco.com 172.21.127.27
     zone access gk-sj default direct
     zone prefix gk-sj 408.......
     zone prefix gk-ny 212.......
     gw-type-prefix 3# hopoff gk-sj
     gw-type-prefix 4# default-technology

For the gatekeeper for New York, the configuration commands are as follows:

   gatekeeper
     zone local gk-ny cisco.com
     zone remote gk-sj cisco.com 172.21.1.48
     zone access gk-ny default direct
     zone prefix gk-sj 408.......
     zone prefix gk-ny 212.......
     gw-type-prefix 3# hopoff gk-ny
     gw-type-prefix 4# default-technology

When a call is presented to gatekeeper gk-sj with the following target address in San Jose:

2#2125551212
 

Gatekeeper gk-sj recognizes that 2# is a technology prefix. It was not configured as such, but because gw-sj2 registered with it, the gatekeeper now treats 2# as a technology prefix. It strips the prefix, which leaves the telephone number 2125551212. This is matched against the zone prefixes that have been configured. It is a match for 212......., so gk-sj knows that gk-ny handles this call. gk-sj forwards the entire address 2#2125551212 over to gk-ny, which also looks at the technology prefix 2#, and routes it to gw-ny2.

When a call is presented to gatekeeper gk-sj with the following target address in San Jose:

2125551212
 

Gatekeeper gk-sj checks it against known technology prefixes, but finds no match. It then checks it against zone prefixes and matches on 212....... for gk-ny, and so routes this call to gk-ny. gk-ny does not have any local registrations for this address, and there is no technology prefix on the address, but the default prefix is 4#, and gw-ny4 is registered with 4#, so the call gets routed to gw-ny4.

Another call is presented to gatekeeper gk-sj with the following target address in San Jose:

3#2125551212
 

The call bears technology prefix 3#, which is defined as a local hopoff prefix, so gk-sj routes this call to gw-sj3, despite the fact that it bears a New York zone prefix.

In this last example, a call is presented to gatekeeper gk-sj with the following target address in San Jose:

6505551212
 

Gatekeeper gk-sj checks for a technology prefix match, but does not find one. It then searches for a zone prefix match, and fails again. But there is a match for default gateway prefix of 4#, and gw-sj4 is registered with 4#, so the call is routed out on gw-sj4.

• Select one interface on each gatekeeper to serve as the HSRP interface and configure these two interfaces so that they belong to the same HSRP group, but have different priorities. The one with the higher priority will be the active gatekeeper, the other assumes the standby role. Make a note of the virtual HSRP IP address shared by both these interfaces. (For details on HSRP and HSRP configuration, refer to the Cisco IOS IP and IP Routing Configuration Guide.)

• Configure the gatekeepers so that the HSRP virtual IP address is the RAS address for all local zones.

• Make sure that the gatekeeper-mode configurations on both routers are identical.

• If you configure your endpoints and gateways so that they use a specific gatekeeper address (rather than multicasting), use the HSRP virtual IP address as the gatekeeper's address. You can also leave the endpoints and gateways to find the gatekeeper by multicasting. As long as it is on standby status, the secondary gatekeeper neither receives nor responds to multicast or unicast requests.

As long as both gatekeepers are up, the one with the higher priority on its HSRP interface will be the active gatekeeper. If this active gatekeeper fails, or if its HSRP interface fails, the standby HSRP interface assumes the virtual HSRP address and, with it, the active gatekeeper role. When the gatekeeper with the higher HSRP priority comes back online, it reclaims the HSRP virtual address and the gatekeeper function, while the secondary gatekeeper goes back to standby status.

NoteGatekeeper failover will not be completely transparent to endpoints and gatekeepers. When the standby gatekeeper takes over, it does not have the state of the failed gatekeeper. If an endpoint that had registered with the failed gatekeeper now makes a request to the new gatekeeper, the gatekeeper responds with a reject, indicating that it does not recognize the endpoint. The endpoint must reregister with the new gatekeeper before it can continue H.323 operations.

Sample Commands for Configuring HSRP on the Gatekeeper

This sample configuration uses Ethernet 0 as the HSRP interface on both gatekeepers.

On the primary gatekeeper, enter these commands:

configure terminal 
 ! enter configuration mode
interface e0 
 ! enter interface configuration mode for interface e0
standby 1 ip 172.21.127.55
 ! member of standby group 1, sharing virtual address 172.21.127.55
standby 1 preempt
 ! claim active role when it has higher priority
standby 1 timers 5 15
 ! hello timers is 5 seconds, hold timer is 15 seconds
standby 1 priority 110
 ! priority is 110

On the backup gatekeeper, enter these commands:

configure terminal
int e0
standby 1 ip 172.21.127.55
standby 1 preempt
standby 1 timers 5 15

The configurations are identical except that gk2 has no standby priority configuration, so it assumes the default priority of 100---meaning that gk1 has a higher priority.

On both gk1 and gk2, set up identical gatekeeper mode configurations, as follows:

configure terminal
 ! enter config mode
gatekeeper
 ! enter gatekeeper config mode
zone local gk-sj cisco.com 172.21.127.55
 ! define local zone using HSRP virtual address as gatekeeper's RAS address.
...
 ! various other gk-mode configurations
no shut
 ! bring up the gatekeeper
 
configure terminal
 ! enter config mode
gatekeeper
 ! enter gatekeeper config mode
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.
...
 ! various other gk-mode configurations
no shut
 ! bring up the gatekeeper

NoteThe no shut command is issued on both gatekeepers, primary and secondary. If you issue the show gatekeeper status command on the two gatekeepers, you see on gk1: Gatekeeper State: UP but on gk2 you see: Gatekeeper State: HSRP STANDBY

• The proxy directs all inter-proxy H.323 traffic, including Q.931 signalling, H.245, and media streams, 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.

Because the proxy terminates two call legs of an H.323 call and bridges them, any H.323 packet traversing the proxy will have the proxy address either in its source field or in its destination field.

PX1 Configuration

!
proxy h323
!
interface Loopback0
 ip address 101.0.0.1 255.0.0.0
!Assume PX1 is in Zone 1, and the gatekeeper resides in the same routers as PX1:
 h323 interface
 h323 h323-id PX1@zone1.com
 h323 gatekeeper ipaddr 101.0.0.1
!
interface Ethernet0
 ip address 172.20.0.1 255.255.0.0
!
interface Ethernet1
 ip address 172.22.0.1 255.255.0.0
 ip access-group 101 in
 ip access-group 101 out
 h323 asr
!
router rip
 network 172.20.0.0
 network 101.0.0.0
!
router igrp 4000
 network 172.22.0.0
 network 101.0.0.0
!
access-list 101 permit ip any host 101.0.0.1
access-list 101 permit ip host 101.0.0.1 any
access-list 101 permit igrp any any

R1 Configuration

!
interface Ethernet0
 ip address 172.20.0.2 255.255.0.0
!
interface Ethernet1
 ip address 172.21.0.1 255.255.0.0
!
router rip
 redistribute igrp 5000 metric 1
 network 172.20.0.0
!
router igrp 5000
 redistribute rip metric 10000 10 255 255 65535
 network 172.21.0.0
 distribute-list 10 out
!
access-list 10 deny ip 101.0.0.0 0.255.255.255
access-list 10 permit any

NoteThe configuration for PX2 and R2 is the same as PX1 and R1.

PX1 Configuration

!
proxy h323
!
interface Loopback0
 ip address 172.21.10.1 255.255.255.192
 h323 interface
 h323 h323-id PX1@zone1.com
 h323 gatekeeper ipaddr 172.21.20.1
!
interface Ethernet0
 ip address 172.21.0.1 255.255.255.192
!
interface Ethernet1
 ip address 172.21.2.1 255.255.255.192
 ip access-group 101 in
 ip access-group 101 out
 h323 asr
!
router eigrp 4000
 redistribute connected metric 10000 10 255 255 65535
 passive-interface Ethernet1
 network 172.21.0.0
 distribute-list 10 out
 no auto-summary
!
router eigrp 5000
 redistribute connected metric 10000 10 255 255 65535
 passive-interface Ethernet0
 network 172.21.0.0
 distribute-list 11 out
 no auto-summary
!
access-list 10 deny 172.21.2.0 0.0.0.63
access-list 10 permit any
access-list 11 deny 172.21.0.0 0.0.0.63
access-list 11 permit any
access-list 101 permit ip any host 172.21.10.1
access-list 101 permit ip host 172.21.10.1 any
access-list 101 permit eigrp any any

R1 Configuration

!
interface Ethernet0
 ip address 172.21.0.2 255.255.255.192
!
interface Ethernet1
 ip address 172.21.1.1 255.255.255.192
!
router eigrp 4000
 redistribute eigrp 6000 metric 10000 10 255 255 65535
 passive-interface Ethernet1
 network 172.21.0.0
 no auto-summary
!
router eigrp 6000
 redistribute eigrp 4000 metric 10000 10 255 255 65535
 passive-interface Ethernet0
 network 172.21.0.0
 distribute-list 10 out
 no auto-summary
!
access-list 10 deny 172.21.10.0 0.0.0.63
access-list 10 permit any

NoteThe configuration for PX2 and R2 is the same as PX1 and R1.

PX2 Configuration

!
proxy h323
!
interface Ethernet0
 ip address 172.23.0.2 255.255.0.0
!
interface Serial0
 ip address 102.0.0.2 255.0.0.0
 ip access-group 101 in
 ip access-group 101 out
 h323 interface
 h323 asr
 h323 h323-id PX2@zone2.com
 h323 gatekeeper ipaddr 102.0.0.2
!
router rip
 redistribute connected metric 10000 10 255 255 65535
 network 172.23.0.0
!
access-list 101 permit ip any host 102.0.0.2
access-list 101 permit ip host 102.0.0.2 any

R2 Configuration

!
interface Ethernet0
 ip address 172.23.0.1 255.255.0.0
!
interface Ethernet1
 ip address 172.22.0.1 255.255.0.0
 ip access-group 101 in
 ip access-group 101 out
!
interface Ethernet2
 ip address 172.21.0.2 255.255.0.0
!
interface Serial0
 ip address 102.0.0.1 255.0.0.0
!
router rip
 redistribute igrp 5000 metric 1
 network 172.23.0.0
!
router igrp 4000
 network 102.0.0.0
 network 172.22.0.0
!
router igrp 5000
 redistribute rip metric 10000 10 255 255 65535
 network 172.21.0.0
 distribute-list 10 out
!
ip route 102.0.0.2 255.255.255.255 Serial0
access-list 10 deny ip 102.0.0.0 0.255.255.255
access-list 10 permit any
access-list 101 permit ip any host 102.0.0.2
access-list 101 permit ip host 102.0.0.2 any

NoteTo guarantee that all traffic between the proxy and other proxies is carried over the multimedia backbone, run IGRP 4000 on both the 102.0.0.0 network and the 172.22.0.0 network, and make sure that the H.323 proxy interface address (102.0.0.2) is not advertised over the data network (distribute list 10 in IGRP 5000). Doing this also eliminates the need to configure policy routes or static routes.

PX1 Configuration

!
version 11.3
no service password-encryption
service tcp-small-servers
!
hostname ExampleProxy
!
!
no ip domain-lookup
!
!
proxy h323
!
interface Ethernet0
 ip address 172.21.127.38 255.255.255.192
 no ip redirects
 ip rsvp bandwidth 7000 7000
 ip route-cache same-interface
 fair-queue 64 256 1000
 h323 interface
 h323 qos rsvp controlled-load
 h323 h323-id px1@zone1.com
 h323 gatekeeper ipaddr 172.21.127.39
!
interface Serial0
 no ip address
 shutdown
!
interface Serial1
 no ip address
 shutdown
!
router rip
 network 172.21.0.0
!
ip classless
!
!
line con 0
 exec-timeout 0 0
line aux 0
 transport input all
line vty 0 4
 password lab
 login
!
end

PX1 Configuration