One thing I haven’t covered much on ISAserver.org are the updates and changes included in the ISA 2004 firewall’s Service Pack 2. Some of it has been laziness on my part and some of it is that I’m just too darned busy these days. However, I figured that since all the ISA 2004 SP2 features will be included in ISA 2006, I might as well kill two birds with one stone and start discussing these issues with you.
One of the big changes included in ISA 2004 SP2 and carried forward with the ISA 2006 firewall are those involving the Cache Array Routing Protocol or CARP. CARP is a method designed allow caching arrays to automatically load balance connections across a Web caching array. The CARP algorithm assigns connections automatically to specific servers in the caching array and does this on a predetermined basis (that is to say, a certain destination URL will always go through the same array member.
The assignment of connections to a specific array member is often referred to as routing the request to the specific caching array member server. The routing decision can be made in one of two ways:
- Client side routing In client side routing the client system has an autoconfiguration script (or .pac file) that enables the Web client (browser) to perform the calculations required to determine which caching array member is responsible for a particular URL. After the calculation is finished, the connection for the specific URL is forwarded to a specific server in the caching array. The caching array member server requests the content from the destination Web server. When the Web sends its response, the array member caches it and returns the result to the client.
- Server side routing In server side routing, the client systems are unaware of the CARP algorithm and are only assigned the IP address of the Web proxy array, or the clients might even be completely unaware of the Web proxy array and other mechanisms such as Policy Based Routing are used to direct requests to the caching array. In both cases, one of the array members receives the connection request from the client and then the array member receiving the request determines if its responsible for that particular URL. If that array member is responsible for that URL, then it fetches the information from the destination Web server, cached the content, and then returns the content to the client. If the array member receiving the request is not responsible for the content, then it forwards the request to the array member that is responsible for that particular URL. The array member responsible for that particular URL then fetches the content, caches it, forwards the response to the array member that received the request from the client, and then that array member that received the request from the client returns the result to the client. Note that the array member that returned the content to the client (but was not responsible for the URL) does not cache the content.
The advantage of client side routing is that there is a lot less intra-array traffic being passed, since the client has already determined which array member was responsible for the particular URL. This ends up providing a higher performance solution and better response times, which leads to higher user satisfaction. On the other hand, the advantage of server side routing is that there is no administrative overhead in provisioning the clients with the autoconfiguration script or .pac file, which leads to better administrator satisfaction.
With that background in mind, we can address the changes to CARP included in SP2. Perhaps the best thing to do is to quote the SP2 White Paper:
“In Service Pack 2, the CARP hash-based routing uses the host name to determine which array member handles the request. CARP therefore assigns all of the requests for a particular host, such as www.fabrikam.com, to a specific array member. This also maintains the context of the session, as the requests and responses are handled by a single array member. CARP exceptions are the sites that you want to be distributed to all array members, because they generate too much traffic to be handled by a single array member. For example, you may want all Microsoft update requests to be distributed, and not assigned to a single array member. You would therefore add the Microsoft Update site to the list of CARP exceptions.”
So what happens with SP2 is that instead of the entire URL being included in the CARP algorithm, only the destination host name is included. The prevents problems with requests to a single destination being handled by multiple caching array members. It also means the mechanism of CARP exceptions is handled in a directly opposite fashion as how they were handled before SP2. Exceptions now represent sites that you want load balanced across the array, where before SP2 CARP exceptions were for sites that you do not want load balanced across an array.
Examples of sites that you might want to include in your exceptions list are the microsoft.com sites, and all the sites involved with Windows Update.
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP — ISA Firewalls