LB::reselect - LB_SELECTED event occures twice

Hi,

 

 

Here's some info you might find useful.

 

 

1) ASM virtuals work a bit differently than non-ASM virtuals, in that, as you've observed, the LB_SELECTED rule event does fire twice. The first LB_SELECTED indicates which server the request will eventually be serviced by - the second LB_SELECTED is due to the request being routed to ASM for processing.

 

 

ASM virtuals use httpclasses, so the appropriate place to select an alternate destination for a given request is in the HTTP_CLASS_SELECTED rule event, which fires between HTTP_REQUEST and LB_SELECTED.

 

 

Your iRule should work if you move the code in LB_SELECTED to HTTP_CLASS_SELECTED, provided you intend for the request to go through ASM.

 

 

2) Currently, BIG-IP log files are rotated daily and one week's worth of log files are kept on the system.

 

 

-S

A clarification about the TMM log file. In general, BIG-IP log files are rotated daily, but depending on your BIG-IP version, the TMM log file may be an exception - some releases rotate the TMM log based on size. For more complete details, please contact F5 Support.

Hi Tal,

 

 

You're running into a conflict with the internal iRules used to handle traffic between TMM and ASM when trying to set the pool in a custom iRule on a VIP with ASM enabled.

 

 

There are a few changes coming up in 9.2.3 for the way custom rules interact with the internal ASM-related rules.

 

 

I'll try testing this with the updated rules and let you know what I find. I think this might be better handled with a case though. I'll open one and send you the case number.

 

 

Thanks,

 

Aaron

In the upcoming 9.2.4 release, you can select a pool in the HTTP_REQUEST event, in a custom rule attached to a virtual server that also has an HTTP class with ASM enabled. 9.2.4 should be released shortly. Check the release notes page for ASM on AskF5 for more detail.

 

 

Thanks,

 

Aaron

Actually, it was pointed out that my last note wasn't correct.

If you use a rule to set the pool to a new value in the HTTP_REQUEST event, it doesn't generate an error as it used to. However, if the request matches an HTTP class with ASM enabled that has a pool configured, that pool will be used for the request, instead of the pool selected in the rule.

If a request matches an HTTP class, the class's pool will be set after the HTTP_REQUEST event and before the HTTP_CLASS_SELECTED event.

So to ensure that changes made in a custom rule to the selected pool aren't overwritten, you would want to select the pool after the HTTP class match has been done (and the corresponding pool is selected) in the HTTP_CLASS_SELECTED event.

If you are using filters on your HTTP classes, and there is a possibility that a request will not match all of the filters of at least one HTTP class, then you would want to add your pool selection logic to the HTTP_CLASS_FAILED event (Click here)

Here is an example rule which shows the how a pool set in HTTP_REQUEST will be overwritten when a request matches an HTTP class:

when HTTP_REQUEST {
   set uri [HTTP::uri]
   log local0. "uri: $uri"
   if { $uri starts_with "/pool" }{
      pool http_request_pool
      log local0. "Set pool to http_request_pool"
   }
   elseif { [HTTP::uri] starts_with "/node"}{
      node 10.10.31.14 80
      log local0. "Set node to 10.10.31.14 80"
   }
   else {
      log local0. "No match in HTTP_REQUEST, using default pool"
   }
}
when HTTP_CLASS_SELECTED {
   if { $uri starts_with "/selected/pool" }{
      pool http_class_selected_pool
      log local0. "Set pool to http_class_selected_pool"
   }
   elseif { [HTTP::uri] starts_with "/selected/node"}{
      node 10.10.31.15 80
      log local0. "Set node to 10.10.31.15 80"
   }
   else {
      log local0. "No match in HTTP_CLASS_SELECTED, using default pool"
   }
}

And here is a sample VIP and a catch-all HTTP class which reference the rule:

virtual asm_http_vip {
   destination 172.24.59.174:http
   snat automap
   ip protocol tcp
   profile http tcp
   rule select_pool_node_rule
   httpclass asm_httpclass
}
profile httpclass asm_httpclass {
   defaults from httpclass
   hosts none
   paths none
   headers none
   cookies none
   pool httpclass_pool
   asm enable
}

Requests that match the HTTP_REQUEST criteria for going to the pool or node set will actually be routed to the pool configured on the HTTP class.

Requests that match the HTTP_CLASS_SELECTED criteria for going to the pool or node will be routed to that pool or node because the change is made after the pool in the HTTP class was selected.

And again, if there are filters on the HTTP class and it's possible that a request would not match the filters, you would want to add additional logic in the HTTP_CLASS_FAILED event to ensure the request is handled as you want. Else, the behavior would be to use the default pool on the VIP if there is one (and therefore bypassing ASM).

Aaron