Making the most of your IP address space with layer 7 switching

Organizations trying to make their presence known on the Internet today run into an interesting dilemma - there's just not enough IP addresses to go around. Long gone are the days when any old organization could nab a huge chunk of a Class A or even Class B network. Today they're relegated to a small piece of a Class C, which is often barely enough to run their business. This is especially true for smaller businesses who are lucky if they can get a /29 at a reasonable rate.

While we wait for IPv6 to be fully adopted and solve most of this problem (a solution that seems to always be on the horizon but never fully realized) there is something you can do to resolve this situation, right now. That something is layer 7 - or URI - switching, which is the topic on which a reader wrote for help this morning.

A reader asks...

Using the iRule we can choose the pool based on the URI, but how to choose the pool based on URL.

It's a great question! Choosing pools based on URI, i.e. URI switching, is something we talk a lot about, but we don't always talk about the other, less exciting HTTP headers upon which you can base your request routing decisions.

Basically, we're talking about hosting support.example.com and sales.example.com on the same IP address (as far as the outside world is concerned) but physically deploying them on separate  servers inside the organization/data center. Because both hosts appear in DNS entries to be the same IP address, we can use layer 7 switching to get the requests to the right host inside the organization. (On a side note this is a function made possible by "server virtualization", one of the umpteen types of virtualization out there today and supported by application delivery controllers and load balancers since, oh, the mid 1990s.)

Using iRules you can route requests based on any HTTP header. You can also route requests based on anything in the payload, i.e. the application message/request, but right now we're just going to look at the HTTP header options, as there are more than enough to fill up this post today.

What's cool about iRules is that you can switch on any HTTP header, and that includes custom headers, cookies, and even the HTTP version. If it's a header, you can choose a pool based on the value of the header. Here's a quick iRule solution to the problem of switching based on the host portion of a URL.

The general flow of this iRule is:

when HTTP_REQUEST { switch [string tolower [HTTP::host]] {

"support" { pool pool_1 } "sales" { pool pool_2 } }}

If you'd like to switch on, say, the HTTP request method, you could just replace the HTTP::host portion with HTTP::method and adjust the values upon which you are switching to "get" and "post" and "delete".

iRules includes an HTTP class that makes it easy to retrieve the value of the most commonly accessed HTTP headers, such as host, path, method, and version. But you can use the HTTP::header method to extract any HTTP header you'd like.

• HTTP::host - Returns the value of the HTTP Host header.
• HTTP::cookie - Queries for or manipulates cookies in HTTP requests and responses.
• HTTP::is_keepalive - Returns a true value if this is a Keep-Alive connection.
• HTTP::is_redirect - Returns a true value if the response is a redirect.
• HTTP::method - Returns the type of HTTP request method.
• HTTP::password - Returns the password part of HTTP basic authentication.
• HTTP::path - Returns or sets the path part of the HTTP request.
• HTTP::payload - Queries for or manipulates HTTP payload information.
• HTTP::query - Returns the query part of the HTTP request.
• HTTP::uri - Returns or sets the URI part of the HTTP request.
• HTTP::username - Returns the username part of HTTP basic authentication.
• HTTP::version - Returns or sets the HTTP version of the request or response.

Even if you have a plethora of IP addresses available, the ability to architect your application infrastructure is made even easier if you have the capability to perform layer 7 switching on HTTP requests. It allows you to make better use of resources and to optimize servers for specific type of content. A server serving up only images can be specifically configured for binary image content, while other servers can be better optimized to serve up HTML and other types of content.

Whether you have enough IP addresses or not, there's something to be gained in the areas of efficiency and simplification of your application infrastructure using layer 7 switching.

For a deeper dive into HTTP headers (and HTTP in general) check out the HTTP RFC specification

Imbibing: Coffee