iRules Troubleshooting Tips

1.) Ensure the iRule compiles

I prefer to use the iRule Editor (latest) for this. By simply creating a new, blank iRule and pasting in the rule in question you can use the check syntax button to ensure that the iRule compiles properly. The iRule editor is also excellent for troubleshooting the syntax of an iRule if there is an error found upon compiling. Verification can also be done by entering the iRule into the GUI or manually into the bigip.conf via the command line and saving / loading as appropriate.

2.) Ensure that you have an accurate problem description

It’s easy to follow one path in an attempt to solve a problem and end up pulling your hair out because you’re trying to solve a different problem than the user reporting the issue is actually trying to resolve. Stating and re-stating exactly what the desired result is, as well as the incorrect behavior they’re seeing, can save you huge amounts of time and stress down the road. Not only will it help you avoid working on the wrong problem, but it also allows you to present other possible solutions that would achieve their desired result.

3.) Check the logs

Once you’ve ensured that the iRule does in fact compile and is applied to the Virtual in question, it’s time to pass some traffic through that virtual and check the /var/log/ltm log to see if the iRule is returning any errors. Some errors can’t be caught when compiling and will only turn up when trying to actually execute the rule.

4.) Add logging

Provided you’ve passed traffic through the applied rule and are receiving nothing in the /var/log/ltm file, it’s time to start adding logging to the rule to help point out possible issues. You can log as much or as little as you think is necessary, but logging more is often a better place to start, narrowing down the information being logged as you get closer to diagnosing the issue at hand.
Logging practices that can be helpful:
  • Log variable values before and after each time they are set
  • Log at least once in each event to ensure all events are firing as intended
  • Add a log entry inside each conditional block to see if the conditional returned true or false (don’t forget Else clauses)
  • Log the result of each command being executed if possible by re-logging any variable that was effected

5.) Ensure the configuration supports the iRule

Double check everything in the config that might affect the way the iRule is processing. Is the class name spelled properly? Does the case match? Is the profile not only enabled but set up the way it needs to be to yield the expected results? Are the host, node and pool names correct?

6.) Use single-case comparisons

Is there a possibility that capitalization is an issue? If so force all comparisons to a single case. This is normally lowercase but it makes no difference.

7.) Capture and analyze the traffic being sent

If you’re still having issues identifying the problem after adding sufficient logging to either be assured that the iRule is firing properly, or isn’t firing properly but you still aren’t sure why, it can help to analyze the incoming traffic. This will allow you to check your logic, regular expression or search matching and syntax, data positioning in the packet, packet size, order, etc. It’s easy to specify an offset of 23 when it should be 24 and have your findstr command return incorrectly, causing your entire rule to be off but still technically functioning. There are many such cases besides findstr. Make sure the traffic being sent to the Virtual the iRule is applied to is what you’re expecting, and compare the iRule’s logic against the traffic you’re seeing to be sure they match up, and your expected result is correct.

8.) Analyze traffic leaving the Virtual with and without the iRule applied

If the traffic going in is good, and the iRule is technically firing, then perhaps you can track down what it IS doing by analyzing the traffic that’s leaving the Virtual before and after the iRule is applied. By discerning how the iRule is affecting the traffic, even if it’s not in the desired manner, you may find clues as to where the problem is.

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.