Forum Discussion

Anthony_Hatch_3's avatar
Anthony_Hatch_3
Icon for Nimbostratus rankNimbostratus
Apr 01, 2011

iRule 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.

 

application delivery
dev
devops
iRules

7 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 02, 2011
    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_3's avatar
    Anthony_Hatch_3
    Icon for Nimbostratus rankNimbostratus
    Apr 04, 2011
    Thanks 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.
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Apr 04, 2011
    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_3's avatar
    Anthony_Hatch_3
    Icon for Nimbostratus rankNimbostratus
    Apr 04, 2011
    Thanks 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
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 04, 2011
    The 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