Long-lived transactions from clients in a GSLB application can be configured to persist to the sites in which their transactions were initiated. This feature is implemented using HTTP site cookies created by NSX Advanced Load Balancer SEs.


Some applications require stickiness between a client and a server. In other words, all requests in a long-lived transaction from a client must be sent to the same server; otherwise, the application session may be broken, with a negative impact on the client. This is accomplished by turning on GSLB site cookie persistence, which takes precedence over the configured GSLB algorithm.

In an active-active GSLB deployment, site persistence is extremely important. Typically, site persistence is not an issue in active-standby deployments.


NSX Advanced Load Balancer checks for the below-listed conditions and will emit appropriate error messages if violations are attempted. The need for these restrictions is better understood after reading this entire section.

  • Site persistence applies only to NSX Advanced Load Balancer VIPs; non-NSX Advanced Load Balancer (aka the third party) VIPs cannot participate.

  • Site persistence across multiple virtual services within the same Controller cluster is not supported.

  • For site persistence to be turned ON for a global application, all of its individual members must run on active sites. Conversely, a site cannot transite from active to passive if an NSX Advanced Load Balancer Global Service (GS) member participating in a site-persistent GSLB service runs on it.

  • For site persistence to work, an NSX Advanced Load Balancer GS member must be unique across all GSLB services. In other words, it cannot be a GSLB pool member in more than one GSLB service.

  • A site-persistence pool is an internal pool construct created by the Controller and associated with GSLB virtual service members when site persistence is turned ON. Users may not perform or change this association. NSX Advanced Load Balancer’s pool group feature cannot be configured for site-persistence pools.

  • The is_federated option is added to the required PKI profile to ensure it can be replicated across all GSLB members. There can be only one is_federated PKI profile defined. Because there is only one, there is no need to explicitly associate the federated PKI profile with any GSLB service.

  • Federated PKI and application persistence profiles cannot be

    • Associated with unfederated profiles.

    • Created if GSLB is not turned ON.

How Cookie-Based Site Persistence Works

Figure 1 shows the phase 1 in the life of a long-lived transaction.

  1. The client asks its DNS resolver to resolve x.foo.com.

  2. The corporate DNS determines two authoritative DNSs (at Site1 and Site2), and recommends the DNS resolver to try the Site1 DNS.

  3. The DNS at Site1 receives the DNS resolver’s query and it uses any global load-balancing algorithm which is in force. Also, it recommends VS1 at Site1 to the DNS resolver and sets the TTL.

  4. In turn, the DNS resolver passes the recommendation and TTL on to the client.

  5. Each SE in the group implementing VS1 is aware that site persistence is ON. The client’s first request contains no site cookie, so the SE creates one and passes it back. The cookie is AES-256-encrypted and based on the cluster_uuid and vs_uuid strings. Below is an example of such a cookie:

Set-Cookie: FOO=1S509ceebd-0913-4aomuTiRccdU0ujbfY6eCVkL9muOBwIsnT5fhrMTMMM4-fapeQ2SEGb3ny69-iJQYG6Xg6SmLq9x7crxFEZbZVsCNDYdqXSwx5GIiuEJqlXFbehC2obJUDbYBciac; path=/

The two-way dialog indicated by the double-ended blue arrow continues as long as SEs in the group see this cookie.

Figure 1. 1. Phase 1 of GSLB cookie-based site persistence

Figure 2 shows what happens sometime, later, after the TTL has expired.

  1. That expiration forces the client to once again ask the DNS resolver to provide an IP address for x.foo.com.

  2. The DNS resolver once again requests the corporate DNS to provide an authoritative DNS. From its cache, the corporate DNS happens to recommend Site2’s DNS.

  3. The client queries the Site2 DNS and it provides VIP2, the local IP address of VS2.

Figure 2. 2. Phase 2 of GSLB cookie-based site persistence

Figure 3 shows the client initiating a dialog with VS2 at Site2. Unbeknownst to it, the cookie previously obtained accompanies that request.

  1. An SE at Site2 receives the request along with the site cookie. It decrypts the cookie and instantly recognises that this request is a continuation of a conversation that did not start on its site. Rather, the conversation needs to be proxied to VS1 at Site1.

  2. In proxying the request to VS1, VS2 passes the request to VS1, making sure to set the return address to itself.

  3. The SE responds to the client, using content provided by VS1 at Site1.

Figure 3. 3. Phase 3 of GSLB cookie-based site persistence