Technical Article

BIG-IP Upgrades & iRules

It’s commonplace in IT departments to stay on top of system patches and upgrades. There are internally developed standards as well as industry-defined processes (ITIL for example) that assist in managing the infrastructure. Is this true with product configuration as well within your organization? Each new release of product X undoubtedly introduces a different way of accomplishing the same goals. Sometimes this is due to a bug resolution, and sometimes it’s to take advantage of performance improvements. Often, the “old way” is preserved for compatibility, which shields users from unsuspected outages, but also allows configurations that are potentially sub-optimal to reside for years in the infrastructure. You should take this to heart with regards to iRules as well. Sometimes a new version necessarily “breaks” your iRule code going forward, but often it is supported. When you upgrade versions, I implore you to look at the new functionality and look at ways you might optimize and future-proof your iRules.

In this tech tip, I’m going to highlight three versions of an iRule that solves the same problem, but each subsequent version relies on improvements in TMOS. Note that version 1, whereas not at all an ideal iRule on the latest version of TMOS, will still run as is, albeit far less efficiently. All three rules are featured in the wiki:

Version 1 – Arrays and Global Variables

In the era before clustered multi-processing (pre v9.4), there was no concern with global variables. There’s always a concern with arrays, however, as a poor garbage collection logic, or, in some cases, no garbage collection logic, you can end up with out of control arrays that consume all memory and tank the box. But that’s what was available at the time.

The logic here is pretty straight forward. Two global variables are set, one for the maximum queries per second and the other for the amount of time that source will be prevented from a resolution response. Also in the RULE_INIT event, two arrays are built, the usertable where source IPs will be stored with their current counts, and then the blacklist where offending source IPs will be stored. The logic in the CLIENT_DATA event is best described in a workflow diagram:

Version 2 – Session Tables and Local Variables

Version two moves the variables from the global scope to local scope. This helps with CMP compatibility, but there is a performance cost due to the variables getting set on each connection instead of once when the iRule is initialized. Also in version two, arrays were scrapped in favor of the session table in hopes of CMP compatibility. Unfortunately, the session commands were not fully CMP compliant until version 10, so this approach is safer than arrays, but not as optimal on pre-v10 systems.

1:whenCLIENT_ACCEPTED {

2:set maxquery 2

3:set holdtime 10

4: }

5:whenCLIENT_DATA {

6:set srcip [IP::client_addr]

7:set c [clock second]

8:if {[ session lookup uie "b$c$srcip" ] != ""} {

9: UDP::drop

10:return

11: }

12:set f [session lookup uie "u$c$srcip"]

13:if { $f != "" } {

14:incr f

15:if { $f > $maxquery } {

16:for { set i 2} { $i < [expr $holdtime + 2 ]} {incr i} {

17:session add uie "b$c$srcip" b $i

18:incr c

19: }

20: UDP::drop

21:return

22: } else {

23:session add uie "u$c$srcip" $f 2

24: }

25: } else {

26:session add uie "u$c$srcip" 1 2

27: }

28: }

The logic is only slightly different in that no arrays need to be unset, the sessions will just expire.

Version 3 – Table Command and Static Variables

BIG-IP version 10 introduced the static namespace and version 10.1 introduced the table command. The static namespace allows you to create global variables that are CMP compatible. Setting them once at initialization instead of on every connection is optimal, so this is a good change. The table command is a killer expansion of the session table functionality.

With each progression, notice the iRule length decreasing? Also, the readability is improved as well. Here’s the logic:

Conclusion

Surviving change is the most important step as you upgrade your infrastructure, but don’t forget to review your configurations for potential optimizations, particularly in your profiles and iRules as it relates to your BIG-IP infrastructure.