Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Feb 13, 2012

OneConnect, Cookie Persistence, and LB_FAILED event

I've got an HTTP virtual with a OneConnect and Cookie profiles applied. The virtual also has an iRule applied. In effect, the iRule is written like this:


rule myrule {
  when HTTP_REQUEST {
    log local0. "[LB::server]"
    if { [HTTP::uri] starts_with "/app" } {
      pool mypool
    }
  }
  
  when LB_FAILED {
    HTTP::redirect "http://myapp.app.com/error_page"
  }
}

Client requests are coming to the app from a global content delivery provider. I have studied the requests at a TCP level, and it appears they are pipelining HTTP requests from different users through a single TCP connection. When a client request for "/something_else" comes in without a Cookie on an established TCP connection, the LTM appears to be making a load-balancing decision BEFORE processing the iRule. It appears this way because the log statement provides me with a pool name and a member, and the LB_FAILED event does not fire. When a client request for "/something_else" comes in on a new TCP session, no load-balancing decision is made and the LB_FAILED event fires as we expect (and want!). My understanding of OneConnect is that each request is evaluated for load-balancing. And if that's true, my expectation is that no load-balancing decision is made until all the iRules have been process. That appears to not be the case. Can someone explain to me what the expected behavior is in the scenario I described?

config
design

4 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 13, 2012
    Hi SMP,

     

     

    I'd have expected that LB_FAILED would trigger regardless of the past HTTP requests on the same TCP connection as long as you have OneConnect enabled. If you're not seeing that, can you open a case and reply with the case number?

     

     

    Thanks, Aaron
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Feb 14, 2012
    Hi Hoolio. You and I expected the same thing, but that is not what's happening. The case number is C1050675. Here's the explanation I got:

    I just went over this with ES for clarification

    How one connect works is each request is inspected for load balancing in the event that an LB modification needs to be made.

    Which is almost the same as how a normal connection functions.

    In this situation a lb decision already happened and it didn't need to make a modification.

    Thats why you would need to do a detach in the event a desion has already been made.

    One connect or not, when a pool is selected, it gets tied to the connection.

    once a pool member is tied to a connection it will remain tied to it until the connection times out, another pool is selected to be tied to that connection or it is detached from that connection.

    The recommendation we got was to add this iRule block at the beginning of our iRule:

    
if { not ($uri starts_with "/app") } {
   If the loadbalanced server is not the vip detach 
  if {not ([IP::local_addr] equals [LB::server addr])}
    {LB::detach}
}

    Our other idea was to add a pool statement at the beginning of the rule, referencing a pool which has no members to try and force "an LB modification".

    And while these may be viable workarounds, it really doesn't address my fundamental questions which are

    a) Is the behavior we are seeing intended, or a bug?

    b) If it is intended behavior, where is the documentation describing this behavior because I sure haven't found it.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 14, 2012
    Thanks for that. I'll watch the case. If you don't get a valid final response/solution let me know.

     

     

    Aaron
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Feb 14, 2012
    Our engineer pointed us to "sol9800: Using an iRule to load balance HTTP requests to multiple pools", which actually does a pretty good job of addressing most of the cases. However we seem to have found an edge case that the sol does not address, which is how does the LTM make a default pool selection for virtual servers using OneConnect when there is no Default Pool defined?

     

     

    We are going to try and set a default pool to a pool with no members and see if that allows us to get our LB_FAILED event to fire. I will keep you posted.