Troubleshooting GSLB persistence with Fiddler

Troubleshooting GSLB persistence with Fiddler -

The purpose of this post is to show how to use Fiddler to troubleshoot HTTP Persistence problems with GSLB.

Fiddler is an amazing tool for troubleshooting. I will only scratch the surface of how the tool can be used. Fiddler download, use this link: http://www.telerik.com/download/fiddler

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

Below is the step-by-step, how I like to fix GSLB persistence with Fiddler.

1. Change the Hosts file, so that a static entry for the Web page exists, which will be examined. In my case, I'm going to test web.green.local.

2. Identify what are the GSLB cookie values ​​for GSLB services that are tied to the GSLB vServer. Use to find the "Show GSLB vServer " cookie information. The cookie information follows "Site Persistence Cookies" in the screen capture below. Note the cookie value for GSLB service that is not in the hosts file. For me, who, as I, the 10.1.1.235 entered as manually. 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 a proxy for web traffic.

4. Go to the Web page that uses the entry in the hosts file. For me, solves web.green.local for "Open city" by the hosts file entries.

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

6. Change, so that it now contains the HTTP GET request GSLB cookie for other GSLB service. I change the value of the cookie, the GSLB service at the 10.1.1.225 match. (As a tip, press F2 to unlock the request for processing within Fiddler.)

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

HTTP redirect

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

2. NetScaler will respond back to the request with a redirection to the site prefix on the GSLB service that corresponds to a 302 redirect to the GSLB service.

3. The user would see the URL change in their browser on . In the case of my lab, I used "blueredirect." As site prefix. The user will change the URL in the browser to see. A SAN or wildcard certificate for this approach highly recommended required certificate to avoid warnings.

Connection Proxy

1. On the NetScaler, which owns the IP within the modified hosts file. Use the nstcpdump.sh tool within the shell NetScaler. The way that I command structure is "nstcpdump.sh -n host "

2. By nstcpdump.sh tool runs, send the HTTP GET request with the cookie value GSLB changed. NetScaler will proxy the request of Fiddler on the GSLB service with the matching GSLB cookie value. The NetScaler at the other place, the request and proxy received the request to the back-end resource (in my case, the blue server.). You should see this communication with the nstcpdump.sh tool. Do not forget to nstcpdump process with "CTRL + C".

to 3 kill. The page that appears, should be submitted by the remote GSLB service. In my case, the blue side.

With Connection Proxy, the experience for the user is seamless because the URL does not change, but this solution can adversely affect the user experience when the RTT is very high between two data centers. This solution is not used in the client certificate authentication.

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

Thanks for reading,

Brooks

Tweet