Long-lived transactions from clients in a GSLB application can be configured to persist to the sites where 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 fails, negatively impacting the client. This is accomplished by activating GSLB site cookie persistence, which takes precedence over the configured GSLB algorithm.

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

How Cookie-Based Site Persistence Works

Figure 1. 1. Phase 1 of GSLB Cookie-based Site Persistence

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

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

  2. The corporate DNS determines two authoritative DNS (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 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 until the SEs in the group see this cookie.

Figure 2. 2. Phase 2 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 3. 3. Phase 3 of GSLB Cookie-based Site Persistence

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

  1. An SE at Site2 receives the request along with the site cookie. It decrypts the cookie and instantly recognizes that this request is a continuation of a conversation that did not start on its site. Instead, 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.


NSX Advanced Load Balancer checks for the below-listed conditions and will emit appropriate error messages if violations are attempted.

  • 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 activated 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.


    Starting from 22.1.3, this restriction is not applicable anymore. An NSX Advanced Load Balancer GS member can be part of multiple GSLB services as explained in Associating a Virtual Service (Configured with Site Persistence) with Multiple GSLB Services.

  • A site-persistence pool is an internal pool construct created by the Controller and associated with GSLB virtual service members when site persistence is enabled. Users cannot perform or change this association. The NSX Advanced Load Balancer 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 enabled.