Quick Overview: Cisco GSS 4492R Global Site Selector GSLB DNS Appliance


Global Server Load Balancing (GSLB) refers to the munging of DNS answers such that a client is directed to a server that will result in the best experience for them. The answer munging can be based on a variety of criteria, including server availability, server load, and client location, among other things as configured by the administrator. The Cisco Global Site Selector (GSS) is a GSLB DNS appliance. The GSS is a part of the Cisco ACE family of load-balancers. As an ACE family member, the GSS has the ability to closely monitor Cisco load-balancers via the KAL-AP (keepalive appliance protocol). Other, more generic, keepalives include ICMP, TCP, HTTP(S) HEAD, and Scripted (allowing for SNMP monitoring). In this way, the GSS can be plausibly deployed in any shop.

In short, the GSS can be deployed in a vendor agnostic way, but will integrate most tightly in a shop already using Cisco load-balancers. This is similar to how the F5 Global Traffic Manager (GTM) works. You can deploy a GTM in a vendor-agnostic way, but the GTM is at its most capable when talking to fellow F5 Local Traffic Managers.


I spent a couple of days working with the GSS and reading significant portions of the GSS Getting Started, Administration, and GUI GSLB Configuration guides, as well as the Command Reference, all for version 4.1. This allowed me to get a feel for what the device could do. Although I spent some time both at the CLI and the GUI, I did very little in the way of actual deployment, because I discovered that the GSS can’t do everything we had been told that it could before we ordered it. That said, this is not a full-on review of the GSS. You can hammer through the documentation I linked to for more details on whether or not the GSS could fulfill your GSLB needs.

  • The GSS is not a DNS server. To qualify that statement, yes, the GSS responds to DNS queries as its core function, but a GSS is not a DNS server as such. A full-blown DNS server that is used as an authoritative device for domains you are managing allows you to build zones, configure SOA records, etc. If you’re a Windows sysadmin, you’ve most likely worked with DNS services (probably quite a bit). If you’re on the UNIX side of life, you probably run BIND or some variation. Do not make the mistake of believing that the GSS appliance can take the place of BIND, Windows DNS, or any other full-blown DNS server. The GSS serves A records. That’s it. Additional DNS infrastructure has to exist in addition to the GSS to handle records you aren’t doing GSLB with.
  • Set up is typical Cisco. This a 1U appliance on rails. There’s a console port fed by a rollover cable. You’ve got “enable” and “conf t”. And you can forget most of the rest of what you know about configuring Cisco kit after that. Which, ironically, is also typical Cisco. You never know what you’re going to get at a Cisco command line, and the GSS is no exception. There is little in your existing template arsenal that will work at the GSS CLI. That’s due in no small part to the fact that the GSS is a unique box with a very specific purpose. As a result, the commands used to configure GSLB will probably be unfamiliar to you. But even beyond that, I found the GSS CLI to be a bit of an alien place.
  • SNMPv3 is missing. As I’ve converted almost all of network infrastructure devices to use SNMPv3 at this point, I found this troubling at best, and an egregious oversight at worst. Sensitive data in cleartext is so 5,000 years ago…and even then, they probably had cryptography when they needed it. Okay, not a huge deal perhaps, but omissions like this are just tiresome. Really? 2012 and no SNMPv3 support? So…I take it Cisco’s not really committed to the product? GSS looks like it’s based off of some sort of UNIX variant. How hard could it be to add SNMPv3?
  • If you want clicks, you got ’em. If you use the GUI, that is. To configure a GSS to respond to a DNS query, you need to configure what Cisco terms a “DNS rule”. To configure a DNS rule, you need to have previously defined a goodly number of other things, including source address lists, domain lists, answer groups, and a balance method…each of which require their own series of clicks. There is exactly zero chance you’ll ever get a natural sense of flow out of this GUI – it’s just brutal. That said, once you have a good bit of the background objects set up, you’re probably not going to have to go back there very often. You’ll just re-use certain objects over and over when building DNS rules. But still…you’re jumping all around to a number of different screens before you can actually build a DNS rule in many cases. I think the GUI is best looked at as a way to template the CLI for you. Build something you want in the GUI, then go to the CLI to read the pretty paragraphs the GUI made for you. Then never go back to the GUI again, at least not for configuration purposes.
  • The GSS limits are in the < 10,000 object range. Domain lists, DNS rules, etc. are all under 10,000 objects. I don’t recall all the specific limits without looking them up, but I do recall reading about them. Those limits are probably fine for most organizations. If you needed to scale your GSLB infrastructure beyond that, you would add more GSS servers and then tier by domain or subdomain as appropriate.
  • You can build GSS sync groups. I didn’t try this, but effectively you build one GSS as the “primary Global Site Selector Manager (GSSM)”. Then add other GSS units into the group, installing them in subservient roles – either as a boring-old “GSS” or as a “standby GSSM”. Only the primary GSSM is to be used for configuration. All configuration is mirrored to the other members of the group. Only a standby GSSM is eligible to be promoted to the role of primary, which is a manual process. It’s a rather draconian arrangement, which you can read more about here.

    TAC warned me that if you build a GSS as the  primary GSSM, you should plan on sticking with that decision. While you can promote a standby GSSM to the primary GSSM role, this is only intended as a temporary thing while you perform maintenance on, or perhaps recover, the original primary GSSM. TAC didn’t get into all the details of why this is, but assured me that selecting the proper primary GSSM was really important to a successful GSS deployment. Your primary GSSM should reside on a part of your network that has the most bandwidth, redundancy, and resiliency.

  • The GSS has a DDoS module option. I priced the DDoS module, and as I recall, it was a very pricey add-on to license. I don’t remember the $ figure, but I do remember heart palpitations. In any case, if such a thing interests you, you can feed all your inbound DNS traffic to the GSS, and allow the DDoS module to help keep your DNS infrastructure available when under attack. To me, it seems that most organizations would have this functionality tied to an IPS device, and not embedded in the GSS. However, if the feature is there, I’m guessing that Cisco baked it in at the request of a customer or two. So, someone must have a need for it. Maybe it’s you.
  • Cisco has mixed opinions on GSS deployment design. There’s two schools of thought that I ran into when thinking through how to deploy the GSS. The first, which mirrored my intent, was to deploy it as an authoritative name server – which you can only sort of do. Yes, you could point the world to your GSS box, as long as you’ve set your GSS to proxy to another DNS server for records it doesn’t have in a particular zone. So, in that sense, it can act as the authoritative name server. Philosophically, it isn’t *really* authoritative for a given domain, but the world would never know that. If you deploy the GSS this way, you’d also be able to leverage the DDoS module, if you were so well-funded as to have licensed it. This is the way the documentation directs you, and what the marketing literature for the GSS implies that you are going to do – GSS “out front,” so to speak.

    The second approach was the one I heard from a very nice TAC engineer, who reviewed a few things with me. His take was that the GSS should not be “out front”. Rather, a different DNS server would be authoritative and handle all inbound queries. This server would delegate to the GSS only those records for which the GSS was to apply GSLB logic to. This struck me as a more complex arrangement, unless you were very particular about putting all of your GSLB records into a subdomain such that you could delegate for the subdomain, instead of for individual records. Imagine how ugly your zone file would look if you were delegating to every GSS you had out there for every individual GSLB-capable A records. That’s a lot of delegation, caching, and other nonsense, all of which is circumvented if you just pump all inbound queries to the GSS directly. In your GSS DNS rules, you can let all non-matching queries fall through to a *.domainname.blah rule that directs the GSS to go pull the answer from the other DNS servers in your infrastructure – and the querier will never know the difference. No delegation or additional cached records to worry about.


My gut feeling is that the GSS is a “me too” GSLB product from Cisco. I didn’t love the interface. I hate the fact that it can’t be a simple DNS server with a few GLSB-enabled record turned on if that’s all I need it to be. It seems expensive for what it is, listing at roughly $18K last I knew. I’ve done years worth of work with F5’s competing Global Traffic Manager product, and at this point I’d take a GTM every day over a GSS. Yes, GTMs are obscenely reassuringly expensive also, I know. And they work best with F5 LTMs, I know that too. Still.

Another point that I agree with was raised by @cloudtoad in the IRC channel. That is…isn’t there an open source alternative for GSLB? I don’t know, but that’s certainly an interesting idea worth exploring.

Yet another point to ponder…do we really need and/or sufficiently benefit from GSLB as a load-balancing methodology? DNS is so abused out there on the Internet, that GSLB-manipulated DNS records are hardly a reliable way to direct traffic. TTLs are often ignored; I’ve seen this many times – incredibly frustrating. What about GeoIP calculations (i.e. the GSLB server figures out which server you’re “closer to” and sends you there)? Those computations can be rendered nonsense, as a GSLB server can only compute a GeoIP decision based on the performance of the DNS server asking the recursive question. The GSLB server doesn’t really know anything about *you* as the actual client that’s going to nail up a socket to the server. There’s a built-in assumption to GeoIP calculations that you’re going to be using a DNS server in close proximity to where you’re jacked into the Internet…which might be true, but could just as easily not be.

My parting opinion is that you want a GSS if you’re a committed ACE shop – maybe. Other than that, this is not the GSLB server you’re looking for.


  1. says

    Sorry, I can’t get on board with putting a GSLB device at the edge. Only grownup DNS servers belong there. The delegation isn’t really a pain, you just need some good DNS admins who understand how it’s supposed to work. Yes, name caching can create problems with GSLB, but traffic engineering with BGP RHI can be just as painful. So do you get the Batman BIND expert or the Spiderman BGP traffic engineer?

    Great overview though with thoughtful analysis. You bring up some really good points for discussion.

    • says

      So, your take is to go with Cisco recommendation #2 – to delegate GSLB records, but let the main BIND (or whatever) server be the daemon that accepts incoming traffic?

  2. Dave Caplinger says

    because I discovered that the [Cisco Product] can’t do everything we had been told that it could before we ordered it.”

    This is the same problem we are dealing with post-install on a Unified Communications (CallManager, Unity, Presence) upgrade.  And then there are the bugs in the features that are actually implemented.

Leave a Reply

Your email address will not be published. Required fields are marked *