Sie sind auf Seite 1von 13

ACE GSS Basics – Part I

The Cisco Application Control Engine Global Site Selector (ACE GSS) is a network service that
provides global server load balancing for geographically dispersed servers. It relies on Domain
Name System (DNS) requests from application clients to direct them to the IP address from a
host or to a server load balancer´s virtual IP (VIP) address.

ACE GSS integrates to a company network through the use of Name Server (NS) records
inserted into its DNS. Adversely from Address (A) records, which provides a destination server
IP address in a DNS lookup, a NS entry informs the IP address of an ACE GSS appliance where
another request should be forwarded. In this way, a DNS request for a URL such as ends up being resolved by an appliance that can apply intelligence to its

Figure 1 represents the main components of an ACE GSS implementation.

In the figure, you can notice:

 Two dispersed sites (Site 1 and 2) with separate infrastructure (data center networks are
not depicted).
 An ACE virtual context at each site representing a “local” server load balance (ACE1 and
ACE2). Each virtual context has a VIP (VIP1 and VIP2, respectively) that can receive
user sessions that will be load balanced to the application servers.
 Each ACE virtual context test the application availability in each server through health
 GSS1 also sends probes to verify the state of VIP1 and VIP2. If at least one server is
available, its virtual context will receive sessions on its VIP.
 GSS1 resides on Site 1 but it is part of a cluster with GSS2, which is located at Site 2.

When a customer device wants to establish a session with the geographically dispersed
application, it sends a DNS request to a server that is inserted in its TCP/IP stack (statically or
through DHCP). Generically speaking, this server usually is a D-proxy that issues iterative DNS
queries on behalf of the client.

Looking for , the D-proxy queries the DNS server responsible
(“authoritative”) for the .com domain. It contains a NS record that points to the server that is
responsible for Such a server is usually present at a customer premises, for
instance Site 1.

Luckily, this server was prepared with a NS record that characterizes GSS1 as the responsible for
domain . Now, GSS1 can forward VIP1 or VIP2 as a response to the D-
proxy depending on multiple factors, such as:

 Application state
 Number of active servers per site
 Server load
 D-proxy IP address
 … and many others

That explanation summarizes the most usual design for ACE GSS. In the next post, I will show
you how to perform a basic configuration on an appliance. Stay tuned!

ACE GSS Basics – Part II

[Data Center Virtualization Fundamentals: Deleted Scene 162]

As promised in my last post, I will proceed with a very simple configuration of an ACE GSS
device to explore its core concepts. Therefore, Figure 1 shows how a single ACE GSS 4492R
appliance can be inserted in an ACE topology.

As Figure 1 depicts, CLIENT can reach the same application that is installed on real servers on
two sites: A and B. Each site has an ACE virtual context that load balances requests from
customers if they are directed to VIP1 ( and VIP2 (,
Figure 1: ACE GSS Topology

Before accessing the application, the client host will send a request for one of the DNS servers to
find the IP address it will forward its application connection (an HTTP session, in our scenario).
As explained in the post “ACE GSS Basics – Part I”, both DNS servers must have NS records
that can direct the customer to the GSS IP address (

Note As you can see, in this simple scenario, CLIENT does not employ a D-proxy, sending its
requests directly to the DNS servers.

The ACE GSS 4492R appliance has two interfaces, which can be used for different purposes. In
this example, interface eth0 will be used for management and eth1 will receive the DNS

Example 1 shows the setup configuration of an ACE GSS 4492R that has been turned on for the
first time (or had its configuration erased through the restore-factory-defaults command). This
CLI access was performed on the ACE GSS appliance console.

Example 1: ACE GSS Appliance Setup

! Using the default credentials

localhost.localdomain login: admin

Password: default

This GSS does not seem to be configured, would you like to

run the initial system setup script? (y/n) [n]: y


## GSS Initial Setup Script ##


This setup utility will help guide you through the basic configuration

necessary to get a GSS up and running. The script will not make any

modifications on the running system. At the end you will be able to

review and edit the new configuration and before applying it to the

running system.

Typing CTRL-C at any prompt quits the script immediately.

The values in brackets ‘[]‘ are the defaults, and can be selected

by simply hitting <CR>.

This setup script will help with only the basic GSS and GSSM configuration.

To configure DNS rules, it will be necessary to log into the Primary GSSM

Admin Webpage.

Do you want to continue? (y/n) [no]: y

! Configuring the appliance identification parameters

Enter the Hostname of this device:

* Interface eth0 (Inactive)

Do you want to change this? (y/n): y

Do you want to activate this interface? (y/n): y

Enter the IP address:

* Interface eth1 (Inactive)

Do you want to change this? (y/n): y

Do you want to activate this interface? (y/n): y

Enter the IP address:

Enter the netmask:

Do you want to configure a default gateway? (y/n) [n]: y

Enter the default gateway:

! Identifying Name Servers

Enter the IP addresses for up to 8 Name Servers.

Enter a dash (‘-’) at a blank entry to stop entering Name Servers.

At least one Name Server is required for this setup script.

Enter Name Server 1:

Enter Name Server 2:

Enter Name Server 3: -

! Enabling file exchange and management access

* Remote Access

Do you want to enable FTP access? (y/n): y

Do you want to enable SSH access? (y/n): y

Do you want to enable Telnet access? (y/n): y

! Defining this appliance as the GSS Manager of the cluster

Do you want to configure this GSS as a Manager (gssm)? (y/n): y

Do you want to configure this GSSM as the Primary? (y/n): y

! Visualizing the final configuration script

The following configuration command script was created:

interface ethernet 0
ip address

interface ethernet 1

ip address


ip default-gateway

ip name-server

ip name-server

ssh enable

no ssh keys

no ssh protocol version 1

telnet enable

ftp enable

snmp-server trap-source ethernet 0

no cnr enable


no enable

gss enable gssm-primary

What would you like to do?

1) Apply as the Running Configuration

2) Edit this configuration

3) Discard Configuration and Quit Setup

Choice: 1

Activating your configuration (this may take a few minutes)

Activating network configuration…done

Note: GSSM database is required only on the primary GSSM and the

standby GSSM.

Creating database. This may take a few minutes…

Generating certificates

Deploying certificates for interbox communications.

Mon Oct 11 17:54:31 2010 waiting for postmaster to start…done

Mon Oct 11 17:54:31 2010 postmaster successfully started


Enabling GSS as Primary GSSM…Generating certificates


Setup Script Complete. System is enabled and running.

To complete configuration you should now log into the administrative Webpage

for this box and configure DNS Rules:

As you can observe in Example 1, the appliance:

 Was configured with the hostname

 Received IP address and for its eth0 and eth1 interfaces,
 Will use IP address as its default gateway
 Will send DNS requests to servers and
 Can be access through FTP, Telnet, SSH, and HTTPS
 Is the manager of a GSS cluster (GSSM), meaning that it will be responsible for the
Global Server Load Balance (GSLB) rules in an ACE GSS cluster

Note In a future post, I will show examine how an GSS cluster brings high availability on a
GSLB scenario. For now, I will focus on a single device to explain its basic concepts.
As expected, ACE GSS employs an IOS-like command-line interface.

As a natural next step, the appliance must be configured to process DNS requests that are
forwarded to it accordingly. In this configuration, you should define the following parameters:

 Keepalives: these are synthetic sessions that GSS sends to test if a VIP or a real server is
capable to respond to application requests. The current GSS software version permits the
creation of the following types: ICMP, TCP, HTTP HEAD (which is identical to HTTP
GET except that the server must not return a message-body in the response), HTTPS
HEAD, KAL-AP (KeepAlive-Appliance Protocol, which is a proprietary communication
protocol between ACE GSS and other Cisco local server load balancers such as ACE
4710 and ACE module), SNMP, and CRA (Content Routing Agents that use a resolution
process called DNS race to send identical and simultaneous responses back to a user´s D-
 Owner: configuration entity that permits that a single GSS appliance is portioned among
multiple administrative domains. Consequently, it contains all global server load-
balancing settings that belong to a single domain.
 Source Address List: specifies the source IP addresses from DNS queries that are
received by the GSS (client or D-proxy).
 Domain List: contains the domains (or subdomains) that are under the responsibility of
the GSS.
 Answer VIPs: correspond to the virtual IP addresses that are configured on the local
server load balancers that are installed on each site. For GSS, these are the IP addresses
that will be included in the DNS responses.
 Answer Group: contains multiple Answer VIPs to where the clients will be load
 DNS Rule: defines how the GSS will respond to each DNS query. It uses all the
parameters above for this decision and others such as load-balancing method (round-
robin, least-loaded, ordered, weighted-round-robin, fair-weighted-round-robin, hashed
[domain name and/or source-address], among others).

Proceeding with the configuration, Example 2 changes the TCP keepalive global behavior (for
the appliance) so we can have a faster reaction to a VIP failure (which can represent that an
entire site is unavailable or all of the application servers are).

Example 2: Changing the TCP probe t tcp fast

retries 3 successful-probes 3 port 80 termination reset

Different clients can receive different DNS responses from an appliance if they are classified in
different source address lists. In this way, ACE GSS can perform different GSLB actions for
clients in distinct networks. Nonetheless, for the sake of simplicity, Example 3 exhibits a list that
treats every client equally.

Example 3: Configuring a Source Address List for Any IP Address LABSP ANY owner

LABSP address

Next, Example 4 configures a list of a single domain that the ACE GSS is authoritative.

Example 4: Defining the Domains this Appliance is Responsible for DOMAINS owner LABSP

Per definition, an ACE GSS appliance must identify the state of the locally load-balanced VIPs
on each site. As a result, the appliance will only send DNS responses containing the IP addresses
of active VIPs. Example 5 shows the definition of both VIPs.

Example 5: ACE VIP Inclusion

! Here you define the IP address that will be inside the DNS responses vip name VIP-A activate

! In this command you can use the IP address that will actually receive the probe type tcp ip-address vip name VIP-B activate type tcp ip-address
As you can notice on Example 5, ACE GSS can also send DNS responses for different IP
addresses if the VIPs are, for instance, hidden behind a device performing Network Address
Translation (NAT).

After creating the answer vips, Example 6 aggregates them in the same answer group so they can
receive a similar treatment by ACE GSS.

Example 6: Creating an Answer Group GRP-WEB owner LABSP type vip name VIP-A weight 1

order 0 load-threshold 254 activate name VIP-B weight 1

order 0 load-threshold 254 activate

Please observe that in the answer group GRP-WEB, each answer vip received a weight, an
order, and a load-threshold. Depending on the configured GSLB load balance algorithm, ACE
GSS will use a different parameter to define where the next client will be forwarded.

Finally, Example 7 creates a dns rule. In it, you can notice how all other parameters are linked in
this configuration entity.

Example 7: rule RULE-WEB owner LABSP source-address-list ANY

domain-list DOMAINS query a 1 vip-group GRP-WEB method round-robin

ttl 0 count 1 sticky disable

Additionally to the inclusion of parameters defined on previous examples, Example 7 exposes

the following elements:

 This rule will respond with an A-record

 It only contains a single clause (others can be defined to include backup answer groups if
all VIPs in a group are offline, for example)
 The rule is using the default round-robin GSLB algorithm
 The client is advised not to cache ACE GSS´ response (DNS time-to-live [TTL] is zero)
 The appliance will only forward one A-record in its DNS responses (count 1)
 Stickiness is disabled, meaning that ACE GSS will not cache the response sent to a client.
Therefore, a client will be load balanced again each time it sends a DNS request to the
To check if the ACE GSS site load balancing is working correctly, I have accessed from CLIENT several times. As I was using Firefow, I´ve pressed
CTRL+F5 several times to refresh the page completely.

Unfortunately, some browsers cache DNS responses anyway. Consequently, I advise you to
install add-ons in your browser to verify if ACE GSS is sending DNS responses accordingly to
its configuration.

Figure 2 exhibits some Firefox add-ons that might help this task.

Figure 2: DNS Flush Add-ons

Example 8 depicts some useful show commands that can assist you in the verification of a dns

Example 8: GSLB Checking

! Verifying if the VIPs are operational for this appliance statistics keepalive answer type vip


Status: ONLINE

No of Keepalives Configured: 1

Keepalive =>

Termination Method: Reset

Status: ONLINE

Keepalive Type: tcp, Fast

Destination Port: 80

Packets Sent: 320596

Packets Received: 49996

Positive Probe: 49993

Negative Probe: 34040

Transitions: 5

VIP GID: 91 LID: 1

Keepalive GID: 100


Status: ONLINE

No of Keepalives Configured: 1

Keepalive =>

Termination Method: Reset

Status: ONLINE

Keepalive Type: tcp, Fast

Destination Port: 80

Packets Sent: 314547

Packets Received: 58900

Positive Probe: 58900

Negative Probe: 27567

Transitions: 5

VIP GID: 93 LID: 2

Keepalive GID: 101

! Verifying the answers sent by this appliance statistics dns answer

Answer Type Total Hits 1-Min 5-Min 30-Min 4-Hr

—————————————————————– VIP 33 0 0 0 0 VIP 47 0 0 0 0

In the case of a VIP failure, GSS will simply forward the IP addresses defined on the remaining
answer VIPs to the clients guaranteeing application continuity for them (VIP
was sent more times than because I´ve put the latter offline to test such

In summation, this relatively old solution remains a crucial piece on active-active data center
designs that employ geoclusters and long distance virtual machine online migrations (as
explained in Chapter 16 from the Data Center Virtualization Fundamentals book). I hope this
has helped you to better understand ACE GSS mechanics and evaluate if it is a useful solution
for your environment.