The purpose of this post is to demonstrate how to use Fiddler to troubleshoot HTTP persistence issues with GSLB.

Fiddler is an amazing tool for troubleshooting. I am only going to scratch the surface for how the tool may be used. To download fiddler, use the following link: http://www.telerik.com/download/fiddler

As a note, there are many other tools that can be used to accomplish the same goal. Other tools on my list include, Firefox developer tools, Firefox Cookie Manager +, and Chrome Developer tools.

Below is the step-by-step on how I like to troubleshoot GSLB persistence using Fiddler.

1. Modify the Hosts file so that a static entry exists for the webpage that will be tested. In my case I am going to test web.green.local.

2. Identify what the GSLB cookie values are for the GSLB services that are bound to the GSLB vServer. Use the “show gslb vServer <gslb vServer>” to find the cookie information. The cookie information follows “Site Persistence Cookie” in the screen capture below. Make a note of the cookie value for the GSLB service that is NOT in the hosts file. For me, since I have the 10.1.1.235 as manually entered. I want to note the value of the cookie for web_blue_gslb_svc, which is at 10.1.1.225.

3. StartFiddler and make sure Fiddler is used as the proxy for web traffic.

4. Browse to the web page that utilizes the entry in the hosts file. For me, web.green.local resolves to the “Green site” due to the hosts file entry.

5. Find an HTTP GET request that contains a GSLB cookie. Highlighted is the unmodified cookie.

 

6. Modify the HTTP GET request so that it now contains the GSLB cookie for the other GSLB service. I am changing the cookie value to match the GSLB service at the 10.1.1.225. (As a tip press F2 to unlock the request for editing within Fiddler.)

7. What happens next is based on whether HTTP Redirect or connection proxy is used for the HTTP mechanism for persistence.

HTTP Redirect

1. Submit the HTTP GET request with the modified GSLB cookie value.

2. NetScaler will reply back to the request with a redirect containing the site prefix on the GSLB service that corresponds to the GSLB service via a 302 redirect.

3.  The user would see the URL change in their browser to <siteprefix><original_hostname><URL_Path_and_Query>. In the case of my lab, I used “blueredirect.” As the site prefix. The user will see the URL in the browser change. A SAN or wildcard certificate is highly recommended required for this approach to avoid certificate warnings.

Connection Proxy

1. On the NetScaler that owns the IP within the modified hosts file. Use the nstcpdump.sh tool within the NetScaler shell. The way that I structure the command is “nstcpdump.sh –n host <IP of the remote GSLB service>”

2. With the nstcpdump.sh tool running, submit the HTTP GET request with the modified GSLB cookie value. NetScaler will proxy the request from Fiddler to the GSLB service with the matching GSLB cookie value. The NetScaler at the other location will receive the request and proxy the request to the backend resource (in my case, the blue server.). You should see this communication with the nstcpdump.sh tool. Don’t forget to kill the nstcpdump process with “CTRL + C”.

3. The page that is displayed should be originating from the remote GSLB service. In my case, the Blue site.

With Connection Proxy, the experience is seamless to the user since the URL will not change, however this solution may degrade the user experience if the RTT is very high between the two Datacenters. Also, this solution will not work where client certificate authentication is used.

I hope you enjoy this post. Please let me know if you have questions in the comments below.

Thanks for reading,

Brooks