Simplifying Local Traffic Policies In BIG-IP 12.1
Following up on yesterday’s Introduction to Local Traffic Policies (really a rehash of Steve McCarthy’s article from 11.4), we’ll look at improvements made to local traffic policies interfaces and logic in BIG-IP 12.1. Local traffic policies are sets of rules defined and published to various virtual servers across your BIG-IP. Major interface and workflow improvements in 12.1 ease administration of existing and new local traffic policies. 12.1’s goal is to make your local traffic processing easy to implement and reduce the need for those pesky 5 line iRules that can quietly breed like vermin across your BIG-IP ecosystem. I’m lookin’ at you citizenelah! Workflow The pseudo-process for building local traffic policies hasn’t changed since inception in 11.4. Policies are defined in the centralized policy manager interface located within the Local Traffic menu of BIG-IP. Creating policies consist of: A policy name and strategy A rule matching condition A processing action for the condition Publishing the completed policy (new in 12.1) A a virtual server for policy assignment BIG-IP version 12.1 adds the concept of publishing rules prior to applying them. This removes the possibility for a developer/orchestration admin to enumerate and apply incomplete policies still under development. Prior versions allowed in-progress policies to be available for selection within a virtual server and if a user accidentally enabled it, your traffic would be bound for darkness. Adding this publication steps gives the admin or developer a little breathing room during policy creation. Upgrades from previous versions will place the pre-existing policies into the published category. Building a Policy The Local Traffic Policy management interface is located under the Local Traffic menu within BIG-IP 11.4 through current releases. Building a policy is quite simple now but let’s check out the not-so subtle differences. I think you’ll agree this is a much easier way to implement conditional rules over the older HTTP Class, iRules, or older traffic policy builders. That’s right, if you haven’t used them before, local traffic policies have been sitting there all along since 11.4. However I personally cannot blame you if you ignored them. They were a bit intimidating as the comparison below shows. BIG-IP 11.6 BIG-IP 12.1 In version 12.1, you can change the operands within the strategy, still using: first-match: starts the actions for the first rule in the rules list that matches the connection conditions best-match: selects and stars the actions of the rule in the rules list with the best match. For expanded focus on best match, see the 12.1 LTM LTM Guide all-match: stars the actions for all rules int eh rules match list. When multiple rules match, the best match method is then applied. Lowest ordinal, highest priority, or first rule matches all fall into “all-match. Local Traffic Policy Rule Improvements Customer feedback gave us a lot to work with to fix the rule interface and it shows here. Previous versions blasted the user with a large and complicated screen that required a lot of examination and experimentation. Version 12.1 brought the rule creation back to a purist IF/THEN logical workflow as show below. BIG-IP 11.6 BIG-IP 12.1 Seriously… that’s a HUGE difference. Additional rules and actions can be added to a policy by clicking a plus sign on the right side (cut out of screenshot). Suddenly adding a URI redirect or weak cipher use logging statement becomes a lot easier to implement. Once complete, publishing the local traffic policy completes the processing making it available to all virtual servers. Recycling one of Steve McCarthy’s recipes for selective compression is quite easy to implement shown below. BIG-IP 12.1 Compression Rule Configuration (via bigip.conf) ltm policy /Common/Drafts/selective_compression { controls { compression } requires { http } rules { rule-1 { actions { 0 { compress response enable } } conditions { 0 { http-header name Content-type starts-with values { text/ } } 1 { cpu-usage last-1min less-or-equal values { 5 } } } } } strategy /Common/first-match } You’re starting to get the idea of how easy it is to buildlocal traffic policies in 12.1’s new centralized Local Traffic Policy interface. Maybe you already have a few iRules slated for retirement in lieu of the improved ease local policies provide. The performance gains are definitely worth taking a closer look. For detailed information on local traffic policies and methods behindcreating and management please review the support documentation BIG-IP Local Traffic Management: Getting Started with Policies. We encourage sharing what iRules you can decommission with local traffic policies, drop us a line or even post your config in codeshare.To iRule, or not to iRule: Introduction to Local Traffic Policies
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 Unmatched flexibility Easy to understand for application developers Developers can manage and manipulate their application traffic, let the network admins do other stuff Band-aid application limitations and failures iRules Cons Band-aid application limitations and failures (which should be fixed at the application layer, yea I know it’s also a pro) Accessing the TCL handler causes performance drops in traffic processing (sometimes significant depending on volume and iRule complexity) Troubleshooting traffic through multiple iRules can be daunting (especially if an upgrade deprecates an old command/event) Creates unneeded application complexity (if overused and/or undocumented) Local Traffic Policy Pros Nominal performance overhead for traffic processing 12.1 interface provides massively simplified management of policies and rules Upgrades will not break local traffic rules Local Traffic Policy Cons Prior to 12.1, management and policy building was complex and daunting, iRules were actually easier to implement Moves traffic policies outside of iRules, which COULD split-brain your traffic processing if you’re not careful Limited to static condition sets which may not meet all of your traffic manipulation requirements 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. LTM Policy by Steve McCarthy LTM Policy Recipes by Steve McCarthy BIG-IP Local Traffic Management: Getting Started with Policies on support.f5.com (updated for version 12.1)
