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 (, respectively.

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 requests.

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, respectively
  • 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-proxy).
  • 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 balanced.
  • 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 appliance.

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 rule.

Example 8: GSLB Checking

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


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 behavior).

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.

See you next time!