This post will provide basic information related to iRULE. The intention of writing this post is to provide someone new to iRULE with basic introduction and cover some of the often used Functionality. This isn’t an in-depth coverage of iRule.
What is an iRULE:
TCL based scripting that is utilized by F5 Application Delivery Modules to manipulate traffic.
Structure of an iRULE:
when <EVENT> { <PERFORM ACTION> }Commonly used iRULE Events:
- HTTP_REQUEST
- HTTP_RESPONSE
- CLIENT_ACCEPTED
Having worked with iRules for almost 5 years, the above 3 events are what I utilize on a daily basis. Almost 9 out of 10 iRules that I have written cover the above events. For an iRule rookie, I would recommend understanding the above 3 events.
Within the structure of the iRule, <PERFORM_ACTION> provides the ACTION to be performed if certain CONDITIONS are matched. For example:
if { [HTTP::host] equals “domain.com” } {pool POOL_WEB-SERVER
}
Even if you don’t understand scripting, the above information should be quite clear that you are sending the traffic to the pool: POOL_WEB-SERVER, if the incoming host header equals “domain.com” 🙂
Common ACTIONS that I have utilized:
- Load Balancing based on incoming header values
- Redirection based on incoming header values
- Persistence based on incoming header values
As seen above, the vast majority of ACTIONS involve one of three actions based on the incoming header value. We can also perform more complicated actions based on the content of the incoming packet. However, in my opinion, it is better to avoid performing such actions on the load balancer. As the code gets complex, there is a serious question on accountability and ownership – who owns the code (Dev guys, Network guys ?!?) – this requires a separate post just to hash out the realms of control.
Points to Remember:
- iRULE is TCL based scripting utilized to manipulate traffic on an F5 device
- iRULE, like TCL is EVENT based
- iRULE’s structure consists of EVENT, CONDITIONAL statements & ACTION to perform