v.10 Command Interoperability

While performing internal testing on some advanced iRules on the newly released v10 platform, we discovered a couple possible scenarios that users should be aware of. Making use of certain commands: (session, persist , after) inside one of a few specific constructs: (switch, foreach, eval, catch) can result in an error condition, causing serious repercussions to the performance and stability of your device. Because of this, they need to be avoided when upgrading to or installing v10, at least temporarily. It's important to note here that while these temporary workarounds are important for immediate upgrades to v10, our rock-star PD crew is well aware of this and will have a fix out very soon.

 

 

These situations in code are thankfully relatively painless to work around, in many cases. To help facilitate this, we've distilled down a couple of simple, possible scenarios that you might run into, in hopes of showing you an alternate method of achieving the same functionality with your code. These examples are straight-forward, but the concepts carry over into more complex iRules. Understand that this is in no way a comprehensive list of examples, just a visual guide to show what we're talking about, in code.

 

 

First, here's an example of a session lookup inside of a switch statement. This should work properly in v9.x, and variations on this type of structure are quite possible.

 

 

  
  when HTTP_REQUEST {  
     session add uie 12345 "this is a session" 200  
     switch [HTTP::path] {  
        "/foo.html" {  
            session lookup uie 12345  
            log local0. "done with all session requests"  
        }  
        default   {  
            log local0. "default path, no request made"  
        }  
     }  
  }  
  

 

 

Please note that the above code will not function in v10, and it will need to be re-written. A possible solution for how to do so is to make use of if-else, instead of switch, if you're going to be using one of the commands listed above (session, persist , after). The same logic without the switch statement would look something like this in v10.

 

 

  
  when HTTP_REQUEST {  
    session add uie 12345 "this is a session" 200  
    if { [HTTP::path] eq "/foo.html" } {  
      session lookup uie 12345  
      log local0. "done with all session requests"  
    } else {  
      log local0. "default path, no request made"  
    }  
  }  
  

 

 

You'll notice that we're achieving the same goal but without causing the combination of commands that were discovered to be a problem, at least temporarily. This allows your iRules to continue giving you the functionality you need while this issue is resolved.

 

 

Next is an example of a persist lookup being executed from within a foreach loop, working in v9.x.

 

 

  
  when HTTP_REQUEST {  
    foreach client $::myIPs {  
      set val [persist lookup uie "$client any pool"]  
      if {[string length $val] < 7 } {  
        persist add uie $client  
      }  
    }  
  }  
  

 

 

Again, this combination of commands should be temporarily avoided in v10. Instead, the below example is a possible solution that not only achieves the same functionality, but shows off some of the features of the amazingly powerful new class command. This code isn't the simplest way to produce this result, but I wanted to take the opportunity to showcase the awesome new command and some of the things that it can do.

 

 

  
  when HTTP_REQUEST {  
    set n [class size myIPs]  
    set id [class startsearch myIPs]  
    for {set x 0} {$x < $n} {incr x} {  
      set client [class nextelement -value myIPs $id]  
      set val [persist lookup uie $client]  
      if {[string length $val] < 7 } {  
        persist add uie $client  
      }  
    }  
    class donesearch myIPs $id  
  }  
  

 

 

So there are a couple of examples of what we were seeing. I know that having to modify your code isn't always ideal, hopefully this has helped to clarify a couple of ways around the problem that was uncovered. The good part of this though, is that our amazing PD team is already completely on top of this and are already working towards getting this resolved in the very near future. I don't have an exact date for you, but I can assure you it's a top priority, and that I expect to see something very soon. Until then, hopefully this helps get you pointed in the right direction.