IPv6: How GSLB can gain?

With advent of smartphones and intelligent house hold devices connecting to internet, the address space problem is going to blow up soon. IPv6 is soon to find its place in large extent in ADCs. In one of my articles, I have written the cons of DNS GSLB. It described how client proximity feature can help a client to reach nearest site. I was wondering if we can solve our GSLB problems with IPv6.

IPv6 provides anycast address. For quick reference, I pasted here few text.
An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to an
anycast address is delivered to one of the interfaces
identified by that address (the "nearest" one,
according to the routing protocol's measure of
distance).


As the above text explains router can find nearest host that listens on the anycast address. This can be used as advantage in GSLB. All the sites can have anycast address as a virtual IP. When the domain name resolves to this anycast address, V6 router can find a nearest site for the client.

Implementation must note the cases with site failover in which case the router will chose a different site and the existing connection will break. In order to maintain site stickiness I would leave to the implementation. One way is to redirect the client to an unicast address as soon a site is selected.

In summary, IPv6 brought in advantage with anycast address in GSLB. Soon, we will see this implementation in ADCs.

Guide to select best GSLB solution

There was a question to me
'Ok, If a XX ADC supports client proximity which is not based on DNS, is it best to go with. Do you suggest any other features to look for?'

As I see all the current ADCs do support most eye catching features, there are some things to check before selecting a GSLB equipped ADC.

Here is a check list
- Client proximity: Most LBs calculate Round Trip Time (RTT) by ICMP, TCP probe etc.,
But, think if this works in real time scenario.
a) RTT calculation should work with firewalls sitting at the client network
b) It should not add overhead in TCP communication with the client
c) Most importantly, RTT should be calculated to the real client. Assume a proxy between the client and ADC. If the ADC under consideration does ICMP or TCP probe, it may not reach the real client. So, the RTT is to the proxy but not the client.
d) VPN environment - If the client is behind a VPN gateway. The original location of the client is from private network. This private network can be geographically anywhere. But the source IP of the client NATs to a public IP of the VPN gateway that is connected to Internet. In this case, TCP probe or ICMP based RTT will go completely wrong. This is especially true with Hub and Spoke networks.
e) This solution should work for all protocols including HTTP, SIP, RTSP, SMTP etc.,
f) The client proximity solution should honor Layer 7 features like cookie persistency.
g) The client proximity information obtained must be in sync with all other sites.

- Site health checks- Health checks should be content aware and must be done to the remote server farms.

- system properties - The GSLB solution must consider system health properties like CPU, session utilization of all sites

- Persistency and Availability - GSLB persistency must be maintained. If a client connects to site B because site A is down. The next request should continue to go to Site B even when Site A comes back.
- Ask for throughput and connections per second with GSLB configured in the ADCs.
- Remote forward - When local servers are down, the client request must be proxied to remote site transparent to the client. Client should not even know that site is down.

Journey after DNS GSLB

It is interesting to see discussion in load balancing mailing list on GSLB and a popular URL on page of shame. I thought to share my thoughts how the GSLB has advanced to this time.

In the first article of “why DNS based GSLB does not work?” the emphasis is mostly on problems associated with DNS cache and layer7 cookie information. But, at the same time, given its advantage in providing services under site break down these were assumed to be fine.

Before we go into details of modern DNS GSLB, lets see what the second article on GSLB highlights

• Clients are often not topographically close to their caching servers

• calculation of proximity can itself significantly degrade the user experience

• problems with static proximity and Geo-targeting

These problems are very much relevant to DNS based GSLB implementations. There are some enhancements that went into GSLB devices in recent times. Remember, Alteon Content Director?

ACD implemented client proximity in way back in 2000.

From ACDs documentation

Site-Selection Proximity Methods in ACD

The site-selection methods, are:

! FastPath

! SmartPath

! DualPath

! DNS Round-Robin

! DNS FastPath

! MediaPath

The first three methods determine which local domain can provide the fastest route from its

server to the client. The DNS Round-Robin method uses round-robin selection to equalize

domain traffic across distributed sites instead of client proximity to the site. (DNS Round-

Robin does not require an ACD for each local domain.) DNS FastPath awards the connection

based on the fastest route from its server to the client’s DNS server. MediaPath is specifically

designed for MMS requests

True client proximity is achieved by first three methods listed above. Fast path for example, upon receiving the client request, searches its cache to find nearest site. If there is no entry it starts creating one by sending a redirect message to all the sites. Each site responds with REDIRECT packet to client by optional changes in the URL path. Client will open a connection to the first received REDIRECT packet. That ensures the site is closer to the client.

The above implementation carries a security drawback. The firewalls in all the sites should have rules to allow REDIRECT packets that would not look coming up from their internal networks.

In the recent GSLB implementations of some products like Alteon application Switch (NAS) , true client proximity is achieved by addressing the limitations in ACD.

“After receiving the client request, the GSLB device in that site, scans client proximity table. If it does not find entry, it goes on to calculate response time to the client from each site. It sends a response to the client with HTTP text data with the following information

(Assume there are three sites – A, B and C)

http:///cntpurl

http:///cntpurl

•http:///cntpurl

cntpurl—special type of url used by sites to compute RTT

Client X sends an HTTP request to Site A, Site B, and Site C. Client X establishes a TCP connection with Site B and Site C, and sends a cntpurl request. Site B and C respond with a dummy response and

in the process compute the RTT of their TCP connections with the Client X. Site B and Site C update the computed RTTs to Site A. On receiving RTT from Sites B and C, Site A sends the consolidated

RTT list to all sites.

- At this time, Site A serves the request from the client.

- During the next request from the Client X, Site A redirects the HTTP request to the closest RTT Site (Site C in this example).

- Client X opens a new connection with Site C.

- Site C serves the HTTP request.

If the best site is down, the client is given next best site based on RTT in the Client proximity table.

The client proximity table is a cache maintained in all the sites and is completely in sync.

This solution works for all HTTP traffic and works in hand with DNS GSLB. Now lets again go back and see what 2^nd article said. This solution

• Always calculates the true client proximity with a solution that works in hand with DNS GSLB.

• Does not depend on Geo location so no problem with VPN clients

• A little overhead in traffic only during first contact by the client.

I agree completely with the views mentioned in GSLB article and I thought to share the latest features that addressed those problems mentioned in that article.