You are currently browsing the tag archive for the ‘strategic point of control’ tag.

It shouldn’t surprise anyone that I enjoy new technical challenges. While I think I’ve become pretty decent at writing iRules, I’m constantly reminded of how much more I have to learn.

Yesterday, someone posted a question on DevCentral that I couldn’t initially answer. They were running an online forum and wanted to keep a user from posting spam. Their idea was to search the post when it was submitted and if it contained a “blocked word,” prevent the post from being made. Unfortunately, the vast majority of my experience with iRules has been around inspecting HTTP GET requests and responses. In order to accomplish what this user wanted, the iRule would have to search the Payload of an HTTP POST which was new to me.


Fortunately, there were plenty of examples on DevCentral where people did something similar.  One of the most popular examples is for Sanitizing Credit Card Numbers. That iRule searches the response payload for strings that match credit card patterns. In this case, we’re searching the request data instead.


While the vast majority of rules I’ve seen only care about requests and responses, this was such an awesome reason to look at the payload, I thought I had to learn and also had to share it. Thanks to DevCentral user Hoolio’s posts as well as the awesome wiki, I had a relatively easy time learning. Yet another great reason for leveraging your “Strategic Points of Control” I’m curious to know what other uses for inspecting request/response data people could think of.


Here’s the code I ended up recommending.



   # Only check POST requests
   if { [HTTP::method] eq "POST" } {

      # Default amount of request payload to collect (in bytes)
      set collect_length 2048

      # Check for a non-existent Content-Length header
      if {[HTTP::header Content-Length] eq ""}{

         # Use default collect length of 2k for POSTs without a Content-Length header
         set collect_length $collect_length

      } elseif {[HTTP::header Content-Length] == 0}{

         # Don't try collect a payload if there isn't one
         unset collect_length

      } elseif {[HTTP::header Content-Length] > $collect_length}{

         # Use default collect length
         set collect_length $collect_length

      } else {

         # Collect the actual payload length
         set collect_length [HTTP::header Content-Length]


      # If the POST Content-Length isn't 0, collect (a portion of) the payload
      if {[info exists collect_length]}{

         # Trigger collection of the request payload
         HTTP::collect $collect_length

# Define a string-type datagroup called dg_blocked containing words to be blocked
   if { [matchclass [HTTP::payload] contains dg_blocked] }{
      HTTP::respond 403 "Blocked"



As I discussed in my post about “Strategic Points of Control,” F5 LTMs are in a great position to capture and report on information. I’ve recently encountered several issues where I needed to log the systems sending HTTP 404/500 responses and the URLs for which they were triggered. While this information can be obtained from a packet capture, I find it much easier to simply leverage iRules to log the information.


If you don’t know too much about iRules, I’d encourage you to head over to DevCentral and do some reading. One of the first things you’ll learn is that there are several “events” in which an iRule can inspect and react to traffic. Each event has different commands that can be used. While some commands can be used in multiple events, some may not.


As an example, HTTP::host and HTTP::uri can be used in the HTTP_REQUEST event, but not in the HTTP_RESPONSE event. Since an HTTP Error Response sent by a server would occur in the HTTP_RESPONSE event (between server and LTM,) we can’t simply log the value of HTTP::host or HTTP::uri as those commands aren’t usable in the HTTP_RESPONSE context. Fortunately, variables can be set in one event and referenced in another which allows us to still access the proper information.


Here’s an overview of what we’re trying to accomplish:


1. A client makes a request to a Virtual Server on the LTM.

2. The LTM sends this request to a pool member.

3. If the pool member (server) responds with an HTTP Status code of 500, we want to log the Pool Member’s IP, the requested HTTP Host and URI, and the Client’s IP address.


We’ll be using the “HTTP::status” command to check for 500s. Since this command needs to be executed within the HTTP_RESPONSE event which doesn’t have access to HTTP::host or HTTP::uri, we’ll need to use variables.

From the HTTP_REQUEST event, we’ll utilize said variables to track the value of HTTP::host, HTTP::uri, and IP::client_addr.

The HTTP_REQUEST event in our iRule will look something like this:


set hostvar [HTTP::host]

set urivar [HTTP::uri]

set ipvar [IP::client_addr] }

Now, we’ll check the HTTP status code from within the HTTP_RESPONSE event and if it’s a 500, we’ll log the value of the variables above.


if { [HTTP::status] eq 500 } {

log local0. “$ipvar requested $hostvar $urivar and received a 500 from [IP::server_addr]” }}


Now, whenever a 500 is sent, you can simply check your LTM logs and you’ll see the client who received it, the server that sent it, and the URL that caused it. This is a fairly vanilla implementation. I’ve had several situations in which I needed to also report on the value of a JSESSIONID cookie so our app folks could also check their logs. In a situation like that, you’d simply set and call another variable.


set appvar [HTTP::cookie JSESSIONID]


log local0. “session id was $appvar”


This was a good example of how easily iRules can be leveraged to report on issues. Unfortunately though, this isn’t always a scalable option which is why I thought I’d talk about a product I’ve really enjoyed using.

The folks behind Extrahop call it an “Application Delivery Assurance” product. Since both co-founders came from F5, they have a great handle on Application Delivery and the challenges involved. Since I’m typically only concerned with HTTP traffic nowadays, I use Extrahop to track response times, alert on error responses, and also to baseline our environment. As an F5 user, I’m very pleased to see the product’s help section making recommendations on BIG-IP settings to tune if certain issues are seen.

I’d definitely encourage you to go check out some product literature. Since it’s not always fun to arrange a demo and talk to sales folks, they offer free analysis via Simply upload a packet capture, it’ll be run through an Extrahop unit, and you can see the technology in action.



For awhile now, F5 has been referring to their BIG-IP products as “Strategic Points of Control.” When I first heard that phrase, I didn’t really understand what they were trying to say and assumed it was “marketing speak.” As I’ve gotten better at leveraging F5 technologies to solve my very complicated requirements, I’ve begun understanding what they meant.

I was going to write a blog post about “Strategic Points of Control” a couple months ago, but Lori MacVittie had already beaten me to it.

She defines Strategic Points of Control as “Locations within the data center architecture at which traffic (data) is aggregated, forcing all data to traverse the point of control.”

I think that’s a great definition so I’ll happily use it here.  For our example, let’s assume we’re hosting an E-Commerce site. Naturally, traffic traverses our F5 LTMs on its way to our application instances. This means the F5s are not only a point of failure, but also a point of control. They see all inbound and outgoing content for this application. Since F5 does a wonderful job of building L7 visibility into their devices, LTM becomes a great candidate for altering or reporting on the traffic flowing through it. Of course, just because it can, doesn’t mean it should.

Someone posted a question on DevCentral (F5’s User Community) wondering when it was prudent to use iRules. Naturally, most of us answered “it depends.”

While almost everyone appreciates the flexibility of iRules, some fear that might be used when they shouldn’t be.

I recently worked on a project that required us to ensure an HTTP application only used HTTPS. Since this application was being fronted by an F5 LTM pair, it made sense to terminate the SSL there and send cleartext between the F5 and application.  While sometimes, it’s as easy as making an HTTPS Virtual Server and applying an SSL profile containing the proper cert, I wasn’t that lucky. This particular application sent redirects to the user based on how it was being accessed. If it was being hit over HTTP, it sent redirects specifying http. If it was being hit over HTTPS, it sent redirects specifying https. In this case, even though we were using HTTPS between the client and LTM, the application would still see traffic over HTTP since we weren’t re-encrypting the data between LTM and the application. Naturally, this would cause a user to stop using SSL as soon as they clicked a link.

Fortunately, since LTM sees the traffic between itself and the application, it can see these redirects and rewrite them. By using “redirect rewrite,” I was able to rewrite the redirects sent by the application to use https. Unfortunately, this application also had javascript buttons that when clicked, would cause the user to send a GET request specifying HTTP. Again, since LTM is a “strategic point of control” and sees the traffic, I simply wrote an iRule to redirect all HTTP requests for this Virtual Server to HTTPS.

After creating the iRule for the redirect, I let the application team know that we were ready for them to start testing. They were somewhat surprised that I was able to make the application use HTTPS without them making any changes. One of them actually said, “awesome, I like when it’s easy like this and we don’t have to hack crap together.” With a huge smile on my face, I said, “that’s pretty much exactly what I just did.”

It only took me about 10 minutes to brush up on “redirect rewrites” and since I had written plenty of “http-to-https” iRules, this was extremely easy. At the end of the day though, I used iRules to fix an application “issue.” While this is one of the best features of iRules, it demonstrates their potential use as a mitigation tool. What if I was the only person to have a good understanding of iRules or how we were using LTM to handle the redirects for this application? If someone accidentally altered or removed that iRule, the application would start having issues. If the application code was rewritten to only use HTTPS, there really wouldn’t be any concerns. Of course, there are a ton of application instances and by making the change on the F5s, we keep traffic from having to get to the apps just to be redirected and also are able to make a change in only one place.

One of the most enjoyable posts I’ve made dealt with using iRules to generate Heatmaps to illustrate site visitors. Even though I tested this iRule and got it working well, I ended up choosing not to use it. Because my site leverages Akamai’s DSA product, we have access to very similar information through their portals. By using their site to track this info, I essentially traded one Strategic Point of Control for another. Obviously I saved myself a performance hit on our F5s, but it really came down to whether tracking users like this was a proper use of my LTMs.  The answer, as always, is that “it depends.” For sites that don’t have Akamai or some other product that also has visibility into information like this, F5 might be your best option.

Assuming you’re using Akamai and have an F5 deployment, you’ll run into several areas of overlapping technologies:

1. Using Context to handle different users…differently.

2. Protecting application resources by throttling users based on whether cookies exist.

3. Web Application Firewalling

4. Redirects

5. Limiting access to a site to certain geographic areas/types of users

6. Compression, Caching, Acceleration

The list could easily go on, but it demonstrates some potential challengers an architect might face. Since both Akamai and F5s are strategic points of control, which should you use? I think the most accepted rule is “the closer to the user, the better.” In reality, it comes down to a cost/benefit comparison. While making these decisions in Akamai-land both limit traffic to your infrastructure and also accelerate the user experience, there’s a price for that. Assuming you already have capacity on your LTM, it would be free (save labor) to use it instead whereas Akamai would likely charge for each feature.