Forum Discussion
Anthony_Hatch_3
Nimbostratus
NimbostratusiRule Syntax Requirement for Data Group Names
Today we received the following error on our LTM:
err local/tmm3 tmm3[7053] 01220001 TCL error: rewrite_mstatic-irule - ambiguous option "-": must be -all, -index, -element, -name, or -value while executing "class match [string tolower [HTTP::header User-Agent]] contains non_mobi_ua"
I had never before received this error in testing or in the millions of prior executions. Then today, I received 51 failures, all with that same err msg. They stopped as abruptly as they started.
Doing some research, I found SOL10745 (Click Here) that states that when special chars are used in the DG entries, the DG name must be enclosed in braces within the iRule. I do have two DG entries that have special chars (one of which uses a "-").
As a test, I applied a dev version of the same iRule to a dev vs, then targeted the vs while spoofing the UA with only a "-" as the value. Even with the DG name wrapped in braces, I was still able to duplicate the err. Shouldn't this cause the iRule to not match since there is no DG entry that matches "-"? Instead, the connection is just dropped. The intended behavior when not matched is just to pass through to the pool.
hoolioCirrostratus
Hi Anthony,
I think what's happening here is that the leading hyphen in the value you're looking up is causing the value to be interpreted as a flag on the class match command. You can prevent this from happening by entering two hyphens. Here is an example which triggers the error:RULE_INIT { log local0. "[class match -value "-lookup_string" equals $my_class]" }
< RULE_INIT > - bad option "-lookup_string": must be -all, -index, -element, -name, or -value while executing "class match -value "-lookup_string" equals $my_class"
To avoid this issue, insert two hyphens after the last actual flag:RULE_INIT { log local0. "[class match -value -- "-lookup_string" equals $my_class]" }
Or for your example:
class match -- [string tolower [HTTP::header User-Agent]] contains non_mobi_ua
Note that this option is described on the class command page:
http://devcentral.f5.com/wiki/default.aspx/iRules/class-- Terminates option processing (useful if the or begins with a hyphen).
Aaron
Anthony_Hatch_3Thanks for your assistance Aaron! Implementing this change has resolved the issue. My statement now reads:
if {[class match -- [string tolower [HTTP::header User-Agent]] contains {non_mobi_ua}]}
I do have a question though, going back to that article (SOL10745). In your experience, if you had DG entries that contained special chars, would you still enclose the DG reference in curly braces like in my above example? It seems like this would be best practice in accordance to what f5 support says in the article, but in the scenarios I ran through previously, it didn't seem to matter anyway. Granted, the example wasn't using a string type, but also didn't say it was restricted to an address type either. Maybe I'll try and test a little more thoroughly this week.- Anthony,
Keep in mind that dashes aren't the only special character you have to worry about, and others won't be avoided with the double dash syntax. So yes, if your class contains some chars you're concerned about, it's a good idea to use the braces. Besides, it's not going to hurt anything.
Colin - Anthony_Hatch_3Thanks Colin! That's a good point. There are two other special chars in that particular DG, so I'll certainly maintain that syntax. Appreciate the pointers guys.
Anthony - Sure thing man, let us know if you've got any other questions.
Colin - hoolioThe double hyphen terminates the flags passed to a command. The curly braces only escape special characters in the name of the datagroup--not in the names of the elements.
If your datagroup is listed as the first parameter for a command and the name of any datagroup starts with a hyphen, then you'd need to use the double hyphens. If it's the second parameter in the command, then it depend on whether the first parameter could have a leading hyphen.
It can't hurt to always use the double hyphens or curly braces for the datagroup name. But it's not necessary in most scenarios.
Aaron - Anthony_Hatch_3I see. I misread that in the article. Thanks for clearing that up. :)
