Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Ask the Expert: Global Site Selector Configuration and Troubleshooting

Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about configuring and troubleshooting the Global Site Selector (GSS) with expert Swati Chopra.

GSS devices represent the next generation of application switches and global server load balancing (GSLB) appliances. Working together with the Cisco ACE Module and Cisco ACE 4710 appliance, these devices form an application-fluent networking solution that improves availability, acceleration, and security for data center applications.

The primary role of Cisco GSS is to implement the business continuance and disaster recovery policies of a business by optimizing and securing the Domain Name System (DNS) infrastructure of the data center. It does this by integrating with the DNS infrastructure and responding to the client DNS requests, thereby directing the client to the site that is best able to serve its needs.

Swati Chopra is a CCNA, CCNP, and VCP certified customer support engineer for content switching, covering technologies such as Cisco Application Control Engine, Cisco Wide Area Application Services, Global Site Selector, Cisco Content Services Switches, and Digital Media Suite. She has been with Cisco for more than three years and has worked with most of the high-end customers on content-related complex cases. She completed her master’s degree in finance, was heading an online education project in collaboration with e-Sylvan, and later moved to technical services because of her love for technology. She is actively involved with diverse Cisco initiatives such as Connected Women, WISE, and Cisco Career Connections and recently hosted a “Birds of Feather” table at Cisco’s Women of Impact conference.

Remember to use the rating system to let Swati know if you have received an adequate response. 

Because of the volume expected during this event, Swati might not be able to answer every question. Remember that you can continue the conversation in the Data Center community under subcommunity Application Networking shortly after the event. This event lasts through April 25, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

Cisco Employee

Hi Swati,Glad to know you

Hi Swati,

Glad to know you doing this for GSS. Good luck!



New Member

Hello Swati,Thank you very

Hello Swati,

Thank you very much for covering this topic.  My question is how do different load balance predictors work on GSS?


New Member

Hi Sarah,The load balancing

Hi Sarah,

The load balancing mechanism for GSS requests is done via different methods. We can use these methods to define how the load is shared for different balance clauses within the same rule. The 6 methods we use are:

round-robin—The GSS cycles through the list of answers that are available as requests are received. Each resource within an answer group is tried in turn. The GSS cycles through the list of answers, selecting the next answer in line for each request. This is the default.

eg: if we have 2 answers in answer group then GSS will provide them alternatively.


least-loaded—The GSS selects an answer based on the load reported by each VIP in the answer group. The answer reporting the lightest load is chosen to respond to the request.The least-loaded option is available only for VIP-type answer groups that use a KAL-AP or Scripted keepalive, as they provide the GSS with detailed information on the SLB load and availability.

eg: if one answer has higher load than the other, than first answer will not be provided until its load goes down the other answers

ordered—The GSS selects an answer from the list based on precedence; answers with a lower order number are tried first, while answers further down the list are tried only if preceding answers are unavailable to respond to the request.

for eg: answer with ordered number 1 will be provided first till it becomes unavailable. Once it is unavailable then answer with ordered list number 2 will be provided


weighted-round-robin—The GSS cycles through the list of answers that are available as the requests are received, but sends requests to favored answers in a ratio determined by the weight value assigned to that resource.

eg: if one answer has more weight(80%) than the other answer(20%), then it will be used 8 times out of 10.

hashed— When the GSS uses the hashed balance method, elements of the client's DNS proxy IP address and the requesting client's domain are extracted to create a unique value, referred to as a hash value. The unique hash value is attached to and used to identify a VIP that is chosen to serve the DNS query.

The use of hash values makes it possible to "stick" traffic from a particular requesting client to a specific VIP, ensuring that future requests from that client are routed to the same VIP. This type of continuity can be used to facilitate features, such as online shopping baskets, in which client-specific data is expected to persist even when client connectivity to a site is terminated or interrupted.

The GSS supports the following two hashed balance methods. You can apply one or both hashed balance methods to the specified answer group.

By Source Address—The GSS selects the answer based on a hash value created from the source address of the request.

By Domain Name—The GSS selects the answer based on a hash value created from the requested domain name.

for eg: a user using same source ip will get the same answer from GSS if we do source address hashing.

-DNS Race (Boomerang) Method-The GSS supports the DNS race (boomerang) method of proximity routing, which is a type of DNS resolution initiated by the GSS to load balance 2 to 20 sites.

The boomerang method is based on the concept that instantaneous proximity can be determined if a CRA within each data center sends an A-record (IP address) at the exact same time to the client's D-proxy. The DNS race method of DNS resolution gives all CRAs (Cisco content engines or content services switches) a chance at resolving a client request and allows for proximity to be determined without probing the client's D-proxy. The first A-record received by the D-proxy is, by default, considered to be the most proximate.

Use case is mainly with CRA's.


Hope this helps. Please feel free to revert if you have follow-up questions.






New Member

This is very helpful Swati.

This is very helpful Swati.  I really appreciate the detailed information.  There is another question I had.  My server is up but GSS shows that the answer is offline. How can we make it online?


New Member

Hi Sarah,Thanks for getting

Hi Sarah,

Thanks for getting back!

If GSS shows an answer as offline but server is up then it is an issue related to keepalives configured on GSS for that particular answer. There could be several reasons for this:

1. the GSS keepalive is not working properly. Maybe GSS is not sending the keepalive to server.

2. server is up but the port being probed by GSS keepalive might be restricted on upstream device

3. The port being probed might be down on server itself.

You can check it using following:

1. Go to cli for GSS and type command:

"sh statistics keepalive answer type vip <answer-name". Answer-name refers to the server which is shown unavailable.

In this output if you see negative probes increasing that means that we are not getting a valid keepalive to make this answer online.

2. Check the keepalive for this server on GSS. Try to make it a simple tcp port 80 keepalive on GSS. Make sure port 80 is reachable on the server. You can check this via doing a telnet to server ip on port 80. Command: "telnet <server_ip> 80". If port 80 is up, then we should get the server available on GSS.

3. To find further details on why original probe is failing, take packet traces on server and gss to find if valid request and response is seen on both sides. If not, then check which side is causing the issue.

To take packet trace on GSS you can use:

tcpdump interface {any | eth0 | eth1} | protocol {any| icmp|tcp|udp} | host {any | ip_or_host} | port {any | port} | network {any | ip-address ip-subnet} | file {filename}

Choose one option from options given in {}

In packet traces if we see request going from GSS and no response coming back then please check on upstream devices and the server. If server is sending response then issue should be on upstream device.

In case GSS gets a response and still marks answer as offline then please open a TAC case or send me details and we can check further.

Hope this helps!


New Member

Hi Swati,How do primary,

Hi Swati,

How do primary, standby and other GSS work in a cluster? And how would I go about forming a cluster? thanks for your time.



New Member

Hi John,Thanks for your

Hi John,

Thanks for your question!

In simple terms:

Primary GSS: It performs content routing as well as centralized management functions for the GSS network. It is the GSS which will deploy config to other GSS devices in the cluster. Most of config related commands and GUI is accessible on Primary GSS.

Standby GSS: Any configuration or network changes affecting the GSS network are synchronized between the primary and the standby GSSM. This device will keep a copy of all the data from Primary GSS and can be promoted as Primary GSS if the actual Primary GSS goes down.

GSS: These are just normal GSS devices in the cluster and will get config deployed from Primary GSS.


All these devices, irrespective of their role, will perform routing of DNS queries based on DNS rules and conditions configured using the primary GSSM. Each GSS is known to and synchronized with the GSSM, but individual GSS devices do not report their presence or status to the other.

GSS devices in cluster will keep on functioning even if Primary or Standby GSS goes down. We need Primary and Standby GSS only for config and GUI related tasks. So even if Primary is down, other GSS devices including Standby GSS will still keep on resolving queries at their end.

A typical GSS cluster may contain a maximum of 16 GSS devices on a corporate intranet or the Internet. At least one GSS—and no more than two GSS devices—must be configured as the primary GSSM and standby GSSM.

1. To setup a cluster, first configure and enable a primary GSSM on its CLI:

gss enable gssm-primary

2. Then configure the standby GSS on Standby CLI:

gss enable gssm-standby primary_GSSM_hostname | primary_GSSM_IP_address

3. Lastly configure the GSS devices on their respective CLI:

gss enable gss primary_GSSM_hostname | primary_GSSM_IP_address

4. Once done, Login to Primary GSS GUI and go to Resources tab-->Global Site Selectors-->Activate all the GSS devices here.

Now the cluster is deployed.


Let me know if you have any followup questions.




CreatePlease login to create content