TMOS is gaining a wealth of new functionality with each release and word of what you can achieve through using iRules is spreading even to those unfamiliar with the BIG-IP product line.  I have personally seen this discussion pop up more than once and we even grappled with it at the MVP Summit in Chicago. 

I can’t help but reflect back on the book “The Art of War” by Sun Tzu when thinking about this subject.  During the summit I realized that we were pretty much attempting to do the same thing that Sun Tzu did.  To come up with tactics and lay out truths that could be relied upon to come to a logical decision about how to proceed.

With Sun Tzu, his end goal was to win the battle or war that he was fighting.  He wrote roughly 80 pages of tactics and guidelines for fighting war.  I think the same thing could be done simply to answer the question to use an iRule or to not.  The problem is that for those of us in the F5 community, is that generally speaking, we all have our own goals.

That makes setting guidelines to follow a little harder unless you first define two very important aspects.  I think the first question you should ask yourself is what is your role in your organization?  Secondly, what is the role of the F5 BIG-IP device(s) in your organization?

Something that I know without a doubt is that we all fill different roles in our respective companies and so do our BIG-IP devices.  There is no one size fits all answer to this unfortunately.  For those of you who are new to working the BIG-IP product line and those of you who have yet to set any real company policies regarding your use of iRules I have one small word of advice.  I urge you to sit down with your boss and talk about what you stance will be regarding iRules moving forward.  If you ARE the boss then I suggest thinking about this matter in depth and reflect not just on how it effects you but also your team.  I have no doubt that doing this in advance will save you a lot of trouble.

What are the topics you should think about?  What are all the possible gotchas that might come up?  It is again different for us all.  After having pondered this question myself, here are a few things I think one should keep in mind and discuss with their peers/boss:

1.  K.I.S.S. – That’s right, keep it simple stupid.  It’s a best practice that we should all follow.  The question though is this, will using an iRule make something simpler for you or more complex?  If it makes something simple it’s a no-brainer right?  It it makes things more complex?  Where do you draw the line?

2.  If you do use an iRule and you decide to do some complex logic in it, are you legally required to keep track of that code in an application code repository?  Different regulatory items will obviously apply depending on the nature of your business.  I know that in a lot of places that if one were to write complex iRules that changed the data that a customer see’s, then they would most certainly have to keep track of that.  Sometimes though, it is not external regulatory compliance but INTERNAL regulatory compliance that you have to think about.

3.  Who will support it?  If you write a really complex iRule who will support it in the future?  Are you prepared to redo an iRule at two o’clock in the morning because of a production update that a developer pushed out changed the code that your iRule relies upon?

4.  Let’s say that an opportunity to use an iRule has already presented itself.  Is it more cost productive for the business for the iRule writer to craft an iRule to fix the problem or to have the application programmers fix the problem in the code?

5.  What about your physical environment variables?  Can you implement this new iRule code without slowing down everyone else’s application traffic (provided you delivering multiple apps through it of course)?

6.  Perhaps it will come down to your boss looking at you and saying, “How comfortable are you writing an iRule to try to do this?”.  If that is the case and you are uncertain, then by all means head on over to the DevCentral forums and create a post about it!  You would be AMAZED at the things that people have done with iRules and AMAZED at how simple some of those things are to pull off!  iRules, it slices, it dices, it… well you get the idea.  Use the community to bounce ideas around because it can definitely help make that decision much easier for you to make.

7.  What approach should you take in general to iRule or not to iRule?  Should you take the look before you leap approach, always say yes or always say no?  I am sure that most will pick the look before you leap approach just to make certain they can do what they need to do using an iRule programmatically, that they can do it efficiently and that doing so meets their other preset criteria.  It also may be that your role in the company and the role of your F5 BIG-IP device is strictly that of a networking device and iRules are not to be used or developed.  If that is the case, I would urge you to reconsider that stance and at least consider using some of the simpler iRules… please see comment #6 above.

I am sure there are a million more questions you can think of to ask that might be relevant to your current working conditions, this post is by no means a definitive guide.  Please feel free to add a comment to this post regarding things that may have helped you and your organization define your policy towards using or not using iRules.  I really would love to hear them.

It is wise to remember what Sun Tzu said of laying plans, “The general who wins a battle makes many calculations in his temple before the battle is fought.  The general who loses a battle makes but few calculations beforehand.  Thus do many calculations lead to victory, and few calculations to defeat; how much more no calculation at all.”

One way to do this is called transparent header modification. How it works is a user will enter a URL in their browser such as “www.mycompany.com/bus/”, the request will come in to your BIG-IP and the information sent to your web servers can be redirected or rewritten to whatever you like. Here is an example:


when HTTP_REQUEST {
switch -glob [string tolower [HTTP::uri] ] {
"/bus/*" {
HTTP::uri "/greyhound/bus"
}
}
}


Using the iRule above, this is what happens to your incoming HTTP request. The request comes in and the URI is converted to lower case and then inspected to see if it begins with “/bus/”. The asterisk indicates a wildcard, so anything could come after “/bus/”. If it does begin with “/bus/” then the URI will be transparently modified or changed to “/greyhound/bus”. The clients browser will not be updated, but the URI that the BIG-IP passes on to the server will be “/greyhound/bus”. Basically it turns a request for this “www.mycompany.com/bus/myrequest” INTO “www.mycompany.com/greyhound/bus” Pretty cool huh?

Now lets say you want to do something a little more exotic. Lets use the iRule from above in a different way.


when HTTP_REQUEST {
set uri [HTTP::uri]
switch -glob [string tolower [HTTP::uri] ] {
"/bus/*" {
HTTP::uri "/greyhound/searchBus.do?stationName=[string range $uri 5 end]"
}
}
}


What is this one doing? Let say an HTTP request comes in for “www.mycompany.com/bus/texas”. Using the iRule above the web server would actually receive a request for “www.mycompany.com/greyhound/searchBus.do?stationName=texas”. The clients browser would still read “www.mycompany.com/bus/texas”. Like I said powerful and flexible.

If you are interested in more content regarding transparent header modifications a.k.a. redirecting users without changing their URL, then I recommend reading this article by Joe Pruitt on the DevCentral website http://devcentral.f5.com/weblogs/Joe/archive/2005/07/27/ModifyingUriWithoutRedirect.aspx

So that got me to thinking… how can someone do this in an iRule?  I have to admit I haven’t really looked into it that much previously because we utilize an ASM module running on a 4100 unit.  The 4100 can do a lot of different things regarding cookies such as checking if a cookie has been modified and if the cookie was obtained in a previous session.  I figured I would hit the AskF5 database to see what I could turn up and I uncovered this little gem:

when RULE_INIT {
set ::key [AES::key 128]
}
when HTTP_RESPONSE {
set decrypted [HTTP::cookie "MyCookie"]
HTTP::cookie remove "MyCookie"
set encrypted [b64encode [AES::encrypt $::key $decrypted]]
HTTP::cookie insert name "MyCookie" value $encrypted
}
when HTTP_REQUEST {
set encrypted [HTTP::cookie "MyCookie"]
HTTP::cookie remove "MyCookie"
set decrypted [AES::decrypt $::key [b64decode $encrypted]]
HTTP::cookie insert name "MyCookie" value $decrypted
}

There is definitely more to this, so you may want to go check out the full solution article here:  SOL7784.  There is also an awesome 2009 iRule Contest entry that you should check out here. The iRule you will want to look at is the Cookie Tampering Prevention iRule written by Henrik Gyllkrans.

A friend of mine supplied the image to the left.  I am thinking that it may have to be the official logo for my website!  Of course, had I known he was taking pictures of me with his cell phone I would have flexed a bit more…

Not buying that are you?  Well OK, maybe that is just what I look like in my mind!  Coming next week to “The F5 Guy” website, news and reviews straight from the Dallas SecureWorld Expo!

Now this was an afront to my logic!  My brain was so used to thinking “If this, then this”, that it really was hard for me to wrap my brain around how I was going to pull this off.  So of course, I did what any sane F5′er does when he is looking for an answer to a puzzle he cannot solve.  I turned to Devcentral and the community forums.  I dug around for a while and eventually I found an old 4.0 iRule where an individual had used the “not” Logical Operator.

So I gave myself a big slap on the forehead and muttered a Homer Simpson’ish “DOH!!”.  I later went on to discover that the “not” Logical Operator is well documented on DevCentral here.  Below is the simple iRule that has saved our company thousands of dollars, saved the help desk many man hours of labor, prevented users from going insane because of broken links and keeps things simple.  It is amazing how an iRule so simple, can have such a dramatic impact.  So, the next time you are writing an iRule, just think of all the things you could “NOT” be doing!


when HTTP_REQUEST {
if { not ([string tolower [HTTP::host]] contains ".mycompany.com")}{
HTTP::redirect "https://[HTTP::host].mycompany.com[HTTP::uri]"
}
}


Bearing in mind that I have the “Default Persistence Profile” set to use a profile other than cookie, here is the iRule that I wrote:

 when HTTP_REQUEST {
 set header_uri [string tolower [HTTP::uri]]
 if { [matchclass $header_uri starts_with $::aaa_uri] } {
 	pool aaa_Pool
 } elseif { [matchclass $header_uri starts_with $::bbb_uri] } {
 	HTTP::redirect "https://bbb.companyname.com/bbb/main/Main.jsp"
 } elseif { [matchclass $header_uri starts_with $::CITRIX_uri] } {
 	persist cookie insert "CITRIX_Cookie" "0d 03:00:00"
 	pool CITRIX_Pool
 } else {
   pool ccc_Pool
  }
 } 

The command persist cookie insert “CITRIX_Cookie” “0d 03:00:00″, tells the BIG-IP® to create a cookie named CITRIX_Cookie, give it a duration of 3 hours and insert it into the header of traffic going to the CITRIX_Pool.  If traffic going to that pool already has the CITRIX_Cookie in its header then persist the connection to the same pool member that it used last time.

Traffic going to the rest of the pools will use whatever persistence method is set in the “Default Persistence Profile”.  It is also possible to disable persistence to pools by using the persist none command.