Forum Discussion

3 Replies

  • This isn't a question, so it's a bit misleading to call this an answer, but this is ID 688744, which is called out in the above article.

     

    The article is fairly short, but worth reading as it does explain how to work around the issue. It would be helpful to have the irule workaround included here, but as it's not my irule, I won't copy it here.

     

  • Hi Chris!

    Thanks for your post. SomoIT.net is my blog. Given that I've been having problems with that new bug i decided to share about it. Usually I write very short articles, true jaja. I try to make fast reading articles (that's what I prefer when searching for solutions, howtos... while working as sysadmin) but its true I dont explain things deeply.

    Regarding the bug:

    Symptom - When using LTM policies with conditions like -- “TCP” – “address” – “matches” – “in datagroup” –- it seems it only verifies the first datagroup that come first in order in the datagroup list instead of the one configured in the rule.

    Workaround - IRules are not affected so its a good way to workaround it

    when HTTP_REQUEST {
       if { [class match [IP::client_addr] equals MY_DATAGROUP]} {
       log local0. "[IP::client_addr] IP client accepted"
       ...
       }
    }
    

    Confirmed this behaviour is bug-related, and they have filled bug ID688744 to track this problem. Since this is a new bug, no fix is available yet.

    Hope I have helped!