This article has been re-released as part of the new Intermediate iRules series in the Data-Groups articles.

When dealing with iRules there is sometimes a need to store static information in lists that you can search when your iRule is executed. Are you looking to check every incoming connection for a certain list of Client IPs? Perhaps you want to parse the incoming URI and direct to different pools based on what URI parts are found. To perform inspections/actions like this you need to have a defined list of data to search for, and that list needs to remain constant across multiple connections. This is exactly what classes are designed for. Other articles in the series: 

We'll be going over some of the common questions that seem to crop up when talking to/with people about classes in iRules. Hopefully by the time we're through here you'll have a clear understanding of what classes are, how you can use them, and perhaps even when/why you would. ;)

What is the difference between a "class" and a "Data Group" when dealing with F5 systems?
Nothing! These terms are interchangeable, which can sometimes throw people off. They are referred as "Data Groups" via the GUI, and "class"(es) via the configuration file. This can be a bit confusing, but I assure you they really mean the same thing. For the rest of this document, however, I will refer to them as classes.

Are there different types of classes?
Yes. There are four kinds of classes that you can choose to make use of via iRules. Each of these, as you might imagine, can serve different purposes:

  • String - The "string" type class is the most basic and general type of class provided for your use. This is the type of class that will likely be used most often as it allows you to store any type of data in string format to be used later by your iRules to perform tasks like the URI substitution we spoke about above.
  • Address - Address Classes allow you to store IP addresses and/or address ranges to be searched via matchclass or findclass which we'll talk about more later. This can be very useful when trying to search for multiple IP addresses that happen to be within a network range and can save a fair amount of hassle over adding each IP individually to, say, a string class.
  • Integer - Allowing you to store integer values for quick referencing and comparison, the integer class type can be useful and efficient when dealing with this specific type of data.
  • External File - This unique class type actually allows you to store your class information in an external file, as opposed to the bigip.conf with the rest of your iRules config data. This can be beneficial for administration clarity and automation.

 

How do I create a class?
Like most things you create in your F5 device configurations, there are a few main ways you can create classes for your iRule. You can create them via the GUI, CLI, or in this case, via the iRule Editor as well.

  • GUI - To see/create a class via the GUI, navigate to Local Traffic -> iRules -> Data Group List. Here you can see your current classes to edit them, or create a new one to use.
  • CLI - Via the bigpipe class command and the permutations therin, you can add, modify and delete the classes on your BIG-IP as desired. To learn more about this type bigpipe class help from the command line of your system.
  • iRule Editor - If you happen to have the handy iRule editor installed (available on DevCentral - Here) you can create and manage your classes directly from the editor while writing/modifying your iRules. Just go to the "Tools" menu, and select "Data Group Editor". Here you'll be able to add, remove or modify classes as needed.

 

How can I search through classes?
The two main ways to search through a class are with the matchclass and findclass commands. These commands have similar syntax and functionality, but accomplish different tasks.

  • matchclass - The matchclass command searches a data group list for a member that matches exactly a specified search parameter and returns a true/false value (0/1) indicating the success of the match. This can be very useful when building logic checks, such as:
    when HTTP_REQUEST {
      if { matchclass [HTTP::uri] equals $::uri_list } {
        ...
      }
    }
    
  • findclass - The findclass command searches a data group list for a member that starts with a specified search parameter and returns the matching class member. This is similar to the matchclass command, except that the member is not required to be equal; instead, the member is only required to start with the string and the command returns the entire member value. Also, this command can be used to return a matching portion of a class member. For instance, if your class member looks like "192.168.5.42 pool1", you can use the findclass command to return the second portion of the class member, after the space separator, thereby making findclass very useful for matching key/value pairs in your iRule class. It would look something like:
    when HTTP_REQUEST {
       if { matchclass [HTTP::uri] starts_with $::uri_list } {
         set myPool [findclass [HTTP::uri] starts_with $::uri_list " "]
         pool $myPool
         ...
       }
     }
    

 

Can I modify a class real-time with my iRule?
Technically, yes. Once the configuration is loaded into memory, you can technically modify a class with TCL's list commands. Doing so, however, not only converts the data in the class from an efficient, hashed format into a simple list format, thereby slowing down queries; but the changes made are also not permanent, as they cannot be written back to the file that stores the class data. This makes the changes effective only until TMM is restarted. In general, there is usually another way of structuring your code to avoid this that would be preferred.

Get the Flash Player to see this player.