on 02-Jun-2016 04:00
Take arms against a sea of iRules… you get the idea. Programmability month is underway and DevCentral will demonstrate a lot of new and exciting ways to control your BIG-IP platform via iRules, iControlREST, and other fun developer oriented methods. But to paraphrase Jurassic Park’s Dr. Ian Malcom, our developers were so preoccupied with whether or not they could that they didn’t stop to think if they should. Many of the iRules we implement solve some very basic problems like URI redirects, HTTP traffic blocking, or even simple logging statements. STOP IT! Replace your commonly used and repetitive iRules with local traffic policies and reduce traffic processing overhead. F5’s BIG-IP version 12.1 makes local traffic policies easy to manage and implement even for the brand new administrator and the performance gains alone make implementing local traffic policies a no-brainer.
Why Centralized Local Traffic Policies
Introduced in BIG-IP 11.4 and redesigned for 12.1 (now a thing of beauty), local traffic policies replaced the HTTP Class (protocol) profiles used for conditional traffic processing. Previous to 11.4, using pattern strings or regex, an HTTP Class profile could match hosts, URIs, headers, or cookies and run basic pool or URI redirections. This alleviated the need for one-off iRules to complete common redirect tasks. The drawback to HTTP Class profiles were the performance limitations of pattern strings and regex requirements; performance suffered as the patterns increased in depth and complexity.
To resolve the performance impacts, the HTTP Class protocol profile feature was removed and replaced with local traffic policies. Traffic profiles replaces pattern and regex strings with predefined condition sets allowing rules to be compiled into high performance decision trees, evaluating and executing traffic conditions much faster than the equivalent iRule or HTTP Class profile. Version 12.1 greatly simplifies the interface and deployment learning curve needed to create and publish traffic policies.
Figure 1. Simplified Local traffic rules in BIG-IP 12.1
When iRules Make Sense
The ease of use with local traffic profiles in 12.1 re-raises the question, where and when do you need iRules? Local traffic polices can replace a majority of IF => THEN type iRules, but the advanced needs of customized applications or complex environments, iRules are an amazing way to manipulate and distribute (or drop) traffic. I’ve used iRules to sort out problematic users within ActiveSync policies, or generated custom logging data when complex conditions are met. iRules are an appropriate method to manage the various requirements each application potentially requires and they allow developers to implement solutions the original application designer may have failed to anticipate. For troubleshooting and preventative management, they’re invaluable for identifying and resolving problematic traffic which may require conditions that live outside local traffic policy capabilities. iRules flexibility and quick deployment make it a crucial tool for any BIG-IP admin to have.
iRules Versus Local Traffic Policies
Now we’re entering a religious battlefield similar to the CAPEX vs. OPEX warfare most IT departments engage in. People engrossed in the world of automation and development may scoff at idea of using a GUI to centralize conditional rules; your local network admin may shriek in terror at the idea of using a layer 7 “scripting” solution to define real-time traffic decisions. For an iRule to fire, the TCL handler must be accessed and then the iRule(s) is parsed and processed in serial. Just accessing an iRule creates a performance drop, usually nominal but they can exacerbate performance thresholds on taxed virtual IPs. From discussions and real world performance evaluations we can identify several benefits and drawbacks of for iRules and local traffic policies.
iRules Pros
iRules Cons
Local Traffic Policy Pros
Local Traffic Policy Cons
Coexisting iRules, Local Traffic Policies and the Future
Local traffic policies from 11.4 to 12.0 were the first step to creating easier and faster conditional traffic flow options to alleviate the performance limitations iRules can present. For some of us, this isn’t a big deal, but if you’re talking about millions of hits per vIP per day it’s a day for celebration. Take a look at the iRules you have defined and running at your site(s) and see if you can replace one or more with a local traffic policy. If you’re concerned about performance, this is definitely your first step to improving application response while still maintain control over your traffic. Our next article on local traffic policies will focus specifically on improvements made in 12.1 and show some examples of rule sets that could replace your most common iRules.
Previously we had fantastic coverage of local traffic policies when we released 11.4 so please check out the resources below and get more detail into the wonderful world of local traffic policies.