Technical Articles
F5 SMEs share good practice.
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner
Legacy Employee
Legacy Employee

If you've been following along in the new #The101: iRules series, it's time to add another building block to the framework of what iRules are and can do. If you're new, it would behoove you to start at the beginning and catch up. So far we've covered introductions across the board for programming basics and concepts, F5 terminology and basic technology concepts, the core of what iRules are and why you'd use them, as well as a couple of cornerstone iRules concepts like events and control structures. All of these concepts are required to get a proper understanding of the base iRules infrastructure and functionality. If you missed an earlier installment of this series or could just use a refresher, I highly recommend perusing through the earlier articles:


iRules: Introduction to Programming & TCL

Introduction to F5 Technology & Terms

Introduction to iRules

Events & Priorities

Control Structures & Operators


Using those concepts as foundations we're going to add to the mix something that's integral to any programming language: variables. We'll cover a bit about what variables are, but also some iRules specific variables functionality and commentary. Things to look for in this article:

  -  What is a variable?

  -  How do I work with variables in my iRule?

  -  What types of variables are available to me in iRules?

  -  Is there a performance impact when using variables?

  -  When should I use variables?




What is a variable?

A variable, in simple terms, is a piece of data stored in memory. This is done usually with the notion of using that data again at some point, recalling it to make use of it later in your script. For instance if you want to store the hostname of an incoming connection so that you can reference that hostname on the response, or if you want to store the result of a given command, etc. those things would be stored in a variable. Every scripting language has variables of some form or another, and they're quite important in the grand scheme of things. Without them you'd be building static scripts to perform one off, iterative tasks. Variables are a large part of what allows dynamic programming to account for multiple conditions and use cases. Whether it's storing the data from a math operation to be compared against a desired result, or checking to see if a given condition has been met yet, variables are at the very core of just about everything in programming, and aren't something that we could live without in modern coding. The idea is simple, take a piece of data, whether it's a number or a string or...anything, and store it in memory with a unique name. Then, later, you can recall the value of that data by simply referencing the name you created to represent it. You can, of course, modify, or delete variables at will also.



How do I work with variables in my iRule?

There are two main functions when it comes to any variable: setting and retrieving. To set a variable in Tcl you simply use the set command and specify the desired value. This can be a static or dynamic value, such as an integer or the result of a command. The desired value is then stored in memory and associated with the variable name supplied. This looks like:

   1: #Basic variable creation in Tcl
   2: set integer 5
   3: set hostname [HTTP::host]

To retrieve the value associated with a given variable you simply reference that variable directly and you will get the resulting value. For instance "$integer" and "$hostname" would reference the values from the above example. Of course calling them by themselves won't do much good. Simple referring to a variable within your code will do pretty much nothing. You'll almost certainly be referencing the variables in relation to something or from another command. I.E.:

   1: #Basic variable reference to retrieve and use the value stored in memory
   2: if {$integer > 0) {
   3: log local0. "Host: $hostname"



What types of variables are available to me in iRules?

This topic can creep in scope pretty darn quickly, given that variables are just a simple memory structure, and there are many different types of memory structures available to you via Tcl and iRules. From simple variables to arrays to tables and data groups, there are many ways to manage data in memory. For the purposes of this article, however, we're going to focus on the two main types of actual variables and leave the discussion of other data structures for later.

There are two main types of variables in iRules, local and global.

Local Variables

All variables, unless otherwise specified, are created as local variables within an iRule. What does that mean? Well, a local variable means that it is assigned the same scope as the iRule that created it. All iRules are inherently session based, and as such all local variables are session based as well. This means that the session dictates the memory space for a given iRule's local variables and data. For instance, if connection1 comes in and an iRule executes, creating 5 variables, those variables will only exist until connection1 closes and the session is terminated on the BIG-IP. At that time the memory allocated to that flow will be freed up, and the variables created while processing that particular session's iRule(s) will no longer be accessible.

This is the case with all iRules and all variables created from within an iRule using the basic set command structure pictured above. Local variables are low cost, easy to use, you never have to worry about memory management with them, as they are automatically cleaned up when the session terminates. It's important to remember that iRules as a whole, and the variables therein are session bound. This can cause some confusion when people are expecting a more static state.

Local variables will account for the vast majority of your variable usage within iRules. They're efficient, easy to use, and highly useful depending on the situation. These can be set directly as shown above but are also often the result of a command that provides output. There are also multiple ways to reference a variable within iRules. When using a command that directly affects the variable it is usually appropriate to leave the "$" off and reference the name directly, other times braces allow you to more clearly define the beginning and end of a variable name. Some examples would look like:

   1: #Standard variable reference
   2: log local0. "My host is $host"
   4: #Set variable to the output of a particular command using brackets []
   5: set int [expr {5 + 8}]
   7: #Directly manipulating a variable's value means no "$", most times
   8: incr int
  10: #Bracing can allow you to deliniate between variable name and adjacent characters
  11: log local0. "Today's date is the ${int}th"


Global Variables

"Global variables" is a bit of a misnomer, actually. This is the general terminology used within most programming languages, including Tcl, for variables that exist outside of the local memory space. I.E., in the case of iRules, variables that exist beyond the constraints of a single session. For instance, what if I want to store the IP address of my logging server, and have that always available, to every session that comes through the BIG-IP, without having to re-set that variable every single time my iRule fires? That would be a global variable. Tcl has a mechanism for handling this, and it's relatively easy to use. Interestingly, though...we aren't using it.

The global variable handling within Tcl requires a shared memory space, which in our world does something referred to as "demoting" from CMP. As you'll recall from the "Introduction to F5 Technology & Terms" article, CMP is Clustered Multi-Processing, and is the technology that allows us to distribute tasks within the BIG-IP to multiple cores in an efficient, scalable manner. Because of the requirements of the default Tcl global variable handling, making use of a global variable within Tcl forces any connection going through the Virtual to which the offending iRule is applied to be demoted from CMP, I.E. use only a single processing core, rather than all of them to process the traffic for that Virtual. This is a bad thing, and will severely limit performance.

As such, we strongly recommend avoiding global variables in their traditional sense all together. But what about that log server address? There's still a definite need for long lived data to be stored in memory and available at will. It's for this purpose that we've included a new namespace within iRules called the "static" namespace. You can effectively set static global variable data in the static namespace without breaking CMP, and thereby not decreasing performance. To do so simply set up your static::varname variables, likely in RULE_INIT, since that special event only runs once at load time and static variables are global in scope, meaning they stay set until the configuration is reloaded. Once these variables are set you can call them like you would any other variable from within any iRule, and they will always be available. It looks something like this:

   1: #Set a static variable value, which will exist until config reload, living outside of the scope of any one particular iRule
   2: set static::logserver ""
   4: #Reference that static variable just as you would any other variable from within any iRule
   5: log $static::logserver "This is a remote log message"


For a more complete look at the different types of memory structures that you can access in iRules, I've included a handy dandy table to show memory structures by type along with some information about each, and an example of using that structure. We'll cover some of these in more detail in later installments of this series, but I want to make you aware of the different types of memory structures available.





Is there a performance impact when using variables?

Running any command that isn't cached in any script has some cost associated with it, there's just no way around it. Variables in iRules happen to have a miniscule cost, generally speaking, so long as you're using them appropriately. The cost associated with a variable is in the creation process. It takes resources, albeit a very small amount, to store the desired data in memory and create a reference to that data to be used in the future. Accessing a variable is simply making a call to that reference, and as such doesn't have an additional cost.

A common misunderstanding, however, is just what constitutes a variable within iRules, vs. a command or function that will perform a query. Many people see things like "HTTP::host" or "IP::client_addr" and, due to the format, assume it is a command or function and as such will cost CPU cycles to query the value and return it. This is not the case at all. These type of references are cached within TMM, so whether you call "HTTP::host" once or 100 times, you're not going to require more resources, as you're not performing a query to determine the hostname each time, rather just referencing a value that's already stored in memory. Think of these and many other similar commands as pre-populated variable data that you can use at will.




When should I use variables?

While the cost of creating variables is low, there still is some overhead associated with it. In iRules, due to the exorbitantly high rate of execution in some deployments, we tend to lean towards extreme efficiency mindedness. In this vein we recommend only using variables where they are actually necessary, rather than many programming practices which dictate to use them often as a means of keeping code tidy, even when not truly warranted.

For instance, a common practice with many new iRule programmers is to do things like:

   1: set host [HTTP::host]

As I just explained above, however, this is completely unnecessary. Rather, it would be more efficient to simply re-use the HTTP::host command any time you need to reference this information.

When it does make sense to use a variable, however, is when you are going to modify the data in some way. For instance:

   1: log local0. "My lower case URI: [string tolower [HTTP::uri]]"

The above will give you an all lowercase representation of the HTTP URI. This is a very common use case, and it is not abnormal to have the need to reference the lowercase version of the URI multiple times in a given iRule. While the HTTP::uri command is cached and will not incur additional overhead regardless of how many times you reference it, the string tolower command is not. As such, it would make sense in this case, assuming you're going to reference the lowercase URI at least 2 or more times, to create a variable and reference that:

   1: set loweruri [string tolower [HTTP::uri]]
   2: log local0. "My lower case URI: $loweruri"

Effectively you want to use variables any time you are going to have to repeat any operation against a value that has a cost associated with it. Rather than repeat that operation multiple times and accumulate extra overhead it's better to perform the operation once, store the result, and reference the variable from there.


That covers the basics of variables: What they are, how they work, when to use them and when not, which types you can make use of and how they'll affect your performance, if at all. Hopefully that allows you to approach your iRules with that much more confidence, understanding such a core piece of their makeup. Next week we'll dig into logging and debugging, talking about a not only logging options but also how to effectively troubleshoot an iRule.

"All variables, unless otherwise specified, are created as local variables within an iRule. What does that mean? Well, a local variable means that it is assigned the same scope as the iRule that created it. All iRules are inherently session based, and as such all local variables are session based as well. "



You mean that variables are lexically scoped and variables with same name on different iRules does not impact each other ?



I clarify my question:



If there is


ltm virtual some-virtual {




rules {













On there is variable "userid" on


ltm rule rule-1


and on


ltm rule rule-2



Are modifications of "userid" on rule-1 visible on rule-2 ?



Both rules apply to same connection because they are on same virtual.



In other words: Need I worry other rules when I use some variable name on rule?
Historic F5 Account
Kari, local variables are local to the connection being processed, so



rule rule1 {




set a 1







rule rule2 {




log local0. "$a"







with both rules attached to a virtual when a HTTP request arrives, a will exist and have a value of 1.


Local variable scope extends to all rules attached to a virtual server for the duration of each client-side connection.
The table says that statics can't be unset, and then lists the "unset $static::" command...
Version history
Last update:
‎27-Sep-2012 05:44
Updated by: