What could you do with your code in 20 Lines or Less? That's the question I ask (sometimes?) every week for the DevCentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week nitass and hoolio deliver the 1-2-3 punch with 3 cool iRules to perform various tasks that I deem useful, or interesting, or...both. We get a look at dealing with destination servers with a dynamic IP, handling SSL and non SSL connections on the same VIP to proxy both seamlessly, and selecting a hostname based on destination. No, that isn't backwards, you heard that right. Hostname based on destination, not destination based on hostname. Just the kind of fun stuff I love looking at! So let's get to it.

CLIENTSSL_HANDSHAKE without a client SSL profile

http://bit.ly/yYqGcW

We've seen a similar take before, but this is a new look and a good one, courtesy of hoolio. If you're looking to process HTTP and HTTPS traffic on the same VIP, this iRule will get you there. Keep in mind that it's using a couple of tricks. One is hiding the SSL::cipher command within an eval, and the other is using the catch command to prevent the iRule from dumping the connection based on a TCL error in non SSL cases. While this works, it's good to know that this is using a bit of wizardry to achieve the goal. At some point in the future there may well be a more straight-forward way to do this.

   1: when HTTP_REQUEST {

   2:  

   3:    # Hide the SSL:: command from the iRule parser

   4:    # so the iRule can be used on a non-client SSL VS

   5:    set cipher_cmd "SSL::cipher version"

   6:  

   7:    # Check if the client used an SSL cipher and it's not "none"

   8:    if {not ([catch {eval $cipher_cmd} result]) && $result ne "none"}{

   9:       # Client did use a cipher

  10:       set proto "https"

  11:    } else {

  12:       # Client did not use a cipher

  13:       set proto "http"

  14:    }

  15: }

Node with dynamic IP

http://bit.ly/xisrlX

In this cool example nitass solves the problem of a destination server with a dynamic IP address, and how to route to it. Most people tend to think about dynamic addresses always being on the front end, with back-end resources being static and dependable. That is, of course, not always the case. Given iRules and the power therein however, that is hardly a problem. A quick RESOLV::lookup and you're able to route traffic easily to the appropriate resource. A cool look at using simple, built-in commands in inventive ways to solve problems that could be head scratchers otherwise.

   1: when HTTP_REQUEST {

   2:      set dest [RESOLV::lookup @8.8.8.8 -a "www.google.com"]

   3:      log local0. "\[RESOLV::lookup @8.8.8.8 -a \"www.google.com\"\]: $dest"

   4:      log local0. "\[getfield $dest \" \" 1\]: [getfield $dest " " 1]"

   5:      node [getfield $dest " " 1] 80

   6: }

   7:  

   8: when HTTP_RESPONSE {

   9:      log local0. "[IP::client_addr]:[TCP::client_port] -> [IP::remote_addr]:[TCP::remote_port]"

  10: }

Destination based hostnames

http://bit.ly/ysuN4R

In another example that is actually quite simple and elegant in code, but made me stop and do a triple take because it just sounds so wrong, logically, nitass shows us destination based hostname modification. Hostname based destination modification is amazingly commonplace. We've seen and done that a thousand times. Perhaps it is because of that very prevalence that this feels so backwards, and took me a few seconds to allow my brain to logically process it. Regardless, this is a darn cool example and this would be extremely hard to do anywhere else without redirects and other tom-foolery. Fun stuff!

   1: when LB_SELECTED {

   2:        if {[HTTP::host] equals "xxx.com"} {

   3:                 switch [LB::server addr] {

   4:                         "200.200.200.101" { HTTP::header replace Host "yyy.com" }

   5:                         "200.200.200.102" { HTTP::header replace Host "zzz.com" }

   6:                 }

   7:         }

   8: }

There are your three iRules for the week that can go into the "in case of monotony, read me" bin. iRules, as a technology, continues to impress me, as does the community and the differing ways in which you all come up with to put this stuff to work. Keep it up, and we'll get this series to 100 in no time.

#Colin

Read the original blog entry...