switch matching incorrectly

I don't see anything wrong with your rule. Are there any errors reported in /var/log/ltm when this occurs?

No, no errors being reported. It's been difficult to track down since it can't be reliably debugged.

I made a mistake when I posted the first code sample. The iRule that is having problems looks more like the following. The 'default' condition doesn't specify the pool to use, so it should be using the virtual server's configured default.

 

 

when HTTP_REQUEST {  
      switch -glob [HTTP::path] {  
          /gwp*   {  
                  pool gwp_pool  
          }  
          default {  
                  persist none  
          }  
      }

 

 

This causes intermittent failures as requests which use the default are sent to the incorrect pool. This happens maybe 20% of the time.

 

 

If the default condition is changed to:

 

         default {  
                  persist none  
                  pool default_pool  
          }

 

then things work properly. While explicitly stating the pool in 'default' allows things to work, it seems like a bug to me since the virtual server's default pool is not honored.

Thanks for clarifying this.

Can you determine which wrong pool it is going to 20% of the time?

Is it the gwp_pool or is it some other arbitrary pool?

Here are some other steps that might be useful in getting more to the bottom of this:

It might be useful to add a log statement in the /gwp* portion of the switch, just to make sure that it isn't somehow inadvertently matching.

To determine the pool, you could add an LB_SELECTED event add log the selected pool, like so:

 
 when LB_SELECTED { 
    log "picked: [IP::remote_addr] from pool: [LB::server pool]" 
 } 
 

There are also other LB::server commands that can be used after the load-balancing decision has been made. So, in events like: LB_SELECTED, LB_FAILED, & SERVER_CONNECTED you can use the LB::server command to determine some of the aspects of the load balancing decision. Here are the forms of the command:

[LB::server] - returns a Tcl list with pool, node addr and port.

[LB::server name] - same as above

[LB::server pool] - returns the pool name.

[LB::server addr] - returns the selected pool member's address.

[LB::server port] - returns the selected pool member's service/port.

[LB::server priority] - returns the selected pool mbr's priority.

[LB::server ratio] - returns the selected pool mbr's current ratio.

There are some debugging statements for each element of the switch:

  
    if { $DEBUG } {   
       log local0. "proxy to dailyink"   
       log local0. "[HTTP::host]"   
       log local0. "[HTTP::path]"   
    }  
  

The image works fine if it is loaded on it's own, eg: http://fwiz4-dev.foobar.com/images/but_find_employee.gif

If the image is loaded in the same request as the home page (Shift-Reload in FireFox) then the server returns a 404. A packet trace reveals that the request is sent to the gwp pool.

<--Previous log's removed for brevity-->

Ah hah! The fact that the problem only happens in subsequent requests within the same connection tells me that this is related to our OneConnect feature.

 

 

I'm assuming that you do not have a oneconnect profile on your virtual (otherwise this would not be happening). Without the oneconnect profile, the BigIP will only remake the load-balancing decision when the pool actually changes between requests (with OneConnect it remakes it every time). So, when you add the pool default_pool to the default case, it forces the repick because the pool is changed.

 

 

So, you have two options here: a) you can leave your configuration the same and simply add the default pool to the default case like you had done, or b) you can add oneconnect to your virtual.

 

 

We are actually going to be changing the http profile in an upcoming release to have OneConnect enabled by default.

 

 

Hope this helps.