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)
Local traffic policies and irules together
Problem this snippet solves: Local traffic policies are very useful to define URL-based redirection, virtual servers and pool assignments, host header rewriting... But some actions can't be done with Local traffic policies and there are some deployments with both Policies and irules applied on the same VS. for HTTP_REQUEST event, Policies are executed before irules. If Policy action is http-reply redirect, the irule is executed but all HTTP changes raise TCL error (insert header, modify cookies, URI rewriting) This code allow to detect this policy action and disable event and exit irule. How to use this snippet: import this irule on the appliance and enable it on the VS (to disable irule event) or insert following line on top of each irule assigned to the VS (to exit the current irule): if {[POLICY::targets http-reply] } {return} As http-reply respond with HTTP/1.0 version, the TCP connection will be closed after the reply and no other request will be sent to the F5, the event can be disabled. Code : when HTTP_REQUEST priority 1 { if {[POLICY::targets http-reply] } { log local0. "LTM Policy action contains redirect. Disabling event" event disable return } } Tested this on version: 11.6Simplifying 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.URL Rewrite using local traffic policy
I am looking to use a local traffic policy instead of a iRule (if possible). We want to rewrite the URI portion of incoming requests as they are presented to the inside web host. Outside: https://www.domain.com/something/prod/something/something Inside: https://www.domain.com/something/something I see the action when creating a policy to REPLACE a portion of the URI. I set it to match "/prod" and replace "" blank field. I also tried to match "/something/prod" and replace with "/something". Neither option seems to work. Is this the correct way to handle this? What is the best way to see how it is getting rewritten if you do not have direct access to web server? Thanks!
LTM policies only works with http profile?
Hi all, Today I found a limit when needed the following config: A tcp-only service on one VS which does listen to any. About 60 tcp-only listener ports which should be load balanced to two backends. We need to monitor each of the tcp-ports of the backends, therefore we need about 60 pools for this. I created the following objects: 1 VS ANY TCP listener 60 pools, one for each tcp listener with two backend members. 1 LTM policy with 60 rules like the following: rule_AQ { actions { 0 { forward select pool /Common/pool_AQ_8137 } } conditions { 0 { tcp port values { 8137 } } } } When I try to add the LTM policy to the VS I get the error: 010716d9:3: Virtual server /Common/AQ-domain.com_any requires a profile of type http for ltm policy /Common/pol_AQ_8137. Since this config would be used as a tcp-only service, I cannot add a http profile to the VS. So are LTM policies only usable for HTTP traffic? Thanks, Peter
Configuring LTM policies with request and response conditions
BIG IP VERSION 13.1.0.6 Afternoon. The following LTM policy exists to insert security headers into responses when missing. The LTM policy is attached to a VS which performs virtual hosting using another LTM policy to switch the back-end pools depending on incoming header. A new requirement to remove the X-Content-Type-Options nosniff header for specific sites hosted on this virtual server exists and the LTM policy was adjusted as below to include a request condition against the host isnot header, this however has resulted in unexpected behaviour where-by the header is no longer inserted regardless of whatever site is being requested. Any ideas? Code ltm policy pol-tp-http-header-apply-security-controls-inc-exclusions { description "Edit headers on response to enable security controls" last-modified 2019-01-10:14:09:44 requires { http } rules { rl-tp-header-insert-x-content-type-options { actions { 0 { http-header response insert name X-Content-Type-Options value nosniff } } conditions { 0 { http-host host not values { site1.example.com site2.example.com } } 1 { http-header response name X-Content-Type-Options not values { nosniff } } } description "Insert the x-content-type-options header set to no sniff" ordinal 2 }
Using F5 instead of nginx for reverse proxy
Hello All, We're doing an implementation of a product and the vendor has a deployment guide for using nginx however I've been asked to convert the nginx configuration to the F5 instead. I'm not entirely familiar with nginx so I want to make sure that I understand how to do this properly based on the configuration they've given. I've taken parts of the configuration guide they've provided and attached them below as well as my interpretation of the instructions as to how the F5 will handle it. For example, a request to <>/Portal/Guest/Login.htm is sent to the backend as a request for http://<>/Guest/Login.htm. The header "Host: Portal" is added to the backend request replacing the original “Host: www.<>" header. I believe that much of this behaviour is accomplished by default on the F5. For example converting from https to http can be done with ssl offloading and a client-ssl profile. The forwarding to the internal web server name is simply the way the f5 forwards traffic to the appropriate pool I think? The part that I'm not sure how best to implement is the removing of /Portal/ from the URI and replacing the host header with Portal (there are also about 10 other applications that I will need to do this for. My initial thought is to use a Policy to match the host header and uri path and rewrite them? For example : Will this work? Or do I need to add more info to remove /Portal/ from the path in the actions section?
LTM Policy with HTTP_REQUEST and HTTP_PROXY_REQUEST
Hello, I try to create ltm Policy Rule to forward traffic to different virtual IP with check http host. BIG IP version: 13.1.08 I created a first Policy with two rules: Policy name: TEST2 First Rule to match HTTP PROXY REQUEST And When attempting to create a second rule to match HTTP REQUEST , the system displays an error message that appears similar to the following example: An error occurred: transaction failed:010716e2:3: Policy '//Drafts/', rule ''; an action precedes its conditions. The same configuration with an irule works. Thank you for your return. Guillaume
