I’ve often spoken about how valuable learning from failures is to an IT professional’s development. The challenge is how best to limit these failures to a controlled environment in which business impact is minimized.  Due to the complexities of IT environments, it’s not always easy to notice a “mis-configuration” when it happens, thus exposing businesses to potentially pro-longed issues.

Fortunately, a lot of systems provide logging capabilities. Pretty much every network vendor allows SNMP trapping and syslogging from their devices. The challenge is configuring these properly and making sure you’re always watching them.

Here’s an example iRule that limits access to certain domains:


if { ! [class match  [HTTP::host] eq dg_host] } {


log local0. “[IP::client_addr] went to [HTTP::host][HTTP::uri] and was rejected.” } }

The line “log local0. “[IP::client_addr] went to [HTTP::host][HTTP::uri] and was rejected.”” is only executed if a user hits the Virtual Server with a host-header that doesn’t exist in our Data group of allowed hosts.  This is similar to logging blocks on a router ACL.

While viewing my log entires, I quickly noticed I was blocking people trying to go to “Domain.com”, “DOMAIN.COM”, and “domain.com.”.  Since the users were still trying to go to the proper domain, I modified my statement from

“if { ! [class match  [HTTP::host] eq dg_host] } {”


if { ! [class match  [string tolower [[HTTP::host]] eq dg_host] } {

“string tolower” converts the specified string to lowercase. The reason I hadn’t initially done this was because most browsers automatically lower the host-header when they submit a request. By logging the blocks for my rule, I was able to see exactly what was getting blocked so I could make a change.

Since LTMs are typically placed at “strategic places of control” within a network, they can control and report on traffic. In this case, we’re logging the User’s IP address, Host Header, and URI request.

A typical log entry might look like “ was blocked going to http://www.domain.com/index.html.”

This is actually a relatively simple logging statement. While having a recent issue where certain users weren’t accepting cookies from my LTM, I decided to add [HTTP::header “User-Agent”] to my logging which quickly pointed out that the users having issues were Google Droids which told me I needed to check our mobile-adaptive logic. If I added the User-Agent logic to my iRule above, I’d have quickly discovered which browsers don’t convert the host-headers to lower-case.

You can easily comment out logging commands from an iRule unless you need them. By locking at different points of your rule, you can quickly see at which steps you’re having issues.