One of the many things that I talk about quite often when presenting about or discussing iRules is troubleshooting and testing. Mind you these are two different, yet similar things. The difference is basically whether things are pre or post deployment, but the idea is the same. In both cases you're basically looking to figure out if your iRule is working, and if not, you want to figure out why. To do this there is no magic button, rather there is a process to go through, a bit of a logical loop to cycle through until you get the desired result. You're looking to execute the iRule(s) in question, gather information about what took place during the execution, likely from the logs, tweak the code as necessary, rinse, repeat.

That's all well and good, but not only does that require you to execute the iRule, which likely means passing traffic through a VIP to fire the iRule, which can be tedious sometimes when making many small tweaks to a particular chunk of code, but it also means digging through logs, updating your config repeatedly, and generally taking more time and steps than I, personally, like to mess with when making numerous, rapid changes to an iRule during either development or troubleshooting. Let's face it, if you're looking to tweak your scan syntax quickly to get the string format just right and it takes you 5 attempts (meaning you're amazing at scan, because it takes most mortals 25 attempts or more), you'd rather not have to jump through any more hoops than necessary for each iteration.

It is for exactly this reason that many of the iRule Illuminati have long been relying on tclsh for such rapid development tweaking and micro-syntax execution checking. What is tclsh, you ask? Exactly what it sounds like, a Tcl based shell available from the command line. What is so handy about it? Well, it allows you to execute Tcl commands natively and see how they respond. For instance:

   1: ~$ tclsh

   2: % puts $var

   3: can't read "var": no such variable

   4: % set var "some string with spaces"

   5: some string with spaces

   6: % puts $var

   7: some string with spaces

   8: % set newstring [string map {" " "."} $var]

   9: some.string.with.spaces

  10: % puts $newstring

  11: some.string.with.spaces

  12: %

Obviously that's a simple example, but as you can see I'm able to drop into the tcl shell and from there make use of Tcl commands just like you would in an iRule. So given the above example I could be completely confident that my string map command was going to execute in a particular way, by replacing all spaces in the string in question with periods. Because this functionality mimics what will happen within an iRule it can be a quick way to scope new pieces of code for your iRules development, getting real time feedback before even passing traffic through your iRule, and building confidence that the individual pieces of code behave the way you expect. The same concept applies for more complex structures such as looping and conditionals and the like, allowing you to functionally reproduce large amounts of functionality locally.

Perhaps a more germane example would be the aforementioned scan command. So you have a string that you want to match, perhaps you're trying to match an IP address and you remember that scan is one of the most efficient ways of doing so (maybe because you have been reading the iRules opt tips on DevCentral!), but you can't quite remember what matching an IP with scan looks like. Now...you can search and find it on DevCentral, which is always a viable answer, or you could start making attempts to match things within an iRule, but that's relatively time consuming. You have to have a feedback mechanism within the rule, so a log statement of some sort most likely, you have to generate and pass traffic to test it, check the logs, make updates, update your BIG-IP config over and over, and that's all assuming you have a development box. Instead, try dropping into tclsh and testing things there. Even if it takes a few attempts, it's quick and largely painless with immediate feedback as to what is being returned by the command(s) you're executing:

   1: ~$ tclsh

   2: % set ip 192.168.1.1

   3: 192.168.1.1

   4: % scan %d $ip

   5: % scan $ip %d

   6: 192

   7: % scan $ip %d.{4}

   8: 192

   9: % scan $ip %d.%d

  10: 192 168

  11: %

  12: % scan $ip %d.%d.%d.%d

  13: 192 168 1 1

As you can see, even though I had to stumble around a little bit to remember the correct syntax it was a closed loop and as such a very quick process to work through the syntax iterations needed to nail down the exact structure I wanted for the command. Now that I'm confident in that, I can forklift that directly into my iRule and know that it's going to work exactly how I want it to. Mind you this won't work with custom iRules commands such as HTTP::header and the like, of course, but for standard Tcl commands it's extremely handy.

Okay...all that said...what the heck does this have to do with v11.2? Well, as the more astute among the crowd may have by now guessed, tclsh is now included, by default, on the BIG-IP. This means that you can ssh into your BIG-IP and directly access the Tcl shell to help troubleshoot or scope out your TCL commands and logic for implementation in your iRules. Many of us have been using this tool for years now on our local systems, but having it included natively means not only is there no hassle to download or manage this local package, but it also means those poor people that don't run an OS with a native shell may have an easier time of things by simply logging into their BIG-IP and dropping into tcl shell from there.

This is just one of many handy new features in v11.2 ranging from nice to have utilities such as this all the way through some pretty dazzling new features. Keep an eye out for more examples as 11.2 continues making its way out into the wild more every day. Until then, happy iRuling, and here's hoping your life just got a little bit easier by way of tclsh. It may not look ground breaking, but from someone who writes an iRule or two, I can tell you that this one tool completely changed my development process when building iRules. I now construct the vast majority of my logic and structures, even when they're complex, before ever executing the iRule once to test, and know that they are going to behave just as I intended. It saves time, increases accuracy and improves visibility into exactly what's happening. I for one am glad to see it bundled into the BIG-IP platform.

Don't get me wrong, I still do my actual iRule development in the iRule Editor, but for making quick work of some particular TCL syntax or hammering out those moments of "Now what was that syntax again?" or "What is the output of this sequence going to look like?", tclsh is absolutely invaluable.

v11.2 Features: tclsh