For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Apr 28, 2010

v9 matchclass and v10 class match iRule commands

I've got a v9 irule that takes action based on whether or not the client IP address is in a data class. The v9 iRule looks like this:     if { [matchclass [IP::remote_addr] equals $::allow...
application delivery
dev
devops
iRules
smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Jul 13, 2010
My upgrade retained the class definitions properly. However I think you are going to need iRule code changes. I tested the rule as you wrote it, it only returns the URI in v10.2.0. One of the things I took away from this thread is that I needed to remove the "$::" string from class references during my move from 9.3.1 to 10.1.0, which I did with no negative impact. My understanding was that keeping the $:: reference in v10 demotes the VS with the offending iRule to a single processor, effectively disabling CMP on the VS.

 

 

I don't really understand these class statements very well at all, but I did quickly reproduce the behavior your desired in v10.2.0 with the following iRule. This was generated based on an example in the "class" command description in the iRule wiki:

 

 


when HTTP_REQUEST {
  set myURI [string tolower [URI::decode [HTTP::uri]]]
  set target [class match -value $myURI starts_with class_table]
  log local0. "$target"
}

 

 

However you may want to wait for some more feedback on whether this is better than the findclass statement, because it is not clear to me which is better and why, and I could not get it to work in v10.2.0. My thinking was that the findclass syntax should not be used in v10 since it's examples still use the "$::" class reference syntax, but obviously that's not very conclusive.