Forum Discussion

mahnsc's avatar
mahnsc
Icon for Nimbostratus rankNimbostratus
Apr 17, 2010

If-Then-Else within a Switch

Hi everyone. I had a question about a rule I recently wrote. Initially, I had a rule that comprised a switch -glob statement with a bunch of URIs that, when a match occurs, would route traffic to a particular pool. One of our customers was having issues with some web services which went away once I added ONECONNECT::reuse disable to the affected URI like so: "/web/services/*" { ONECONNECT::reuse disable pool $ws_pool_1 } The problem they were having was intermittent connection resets after a period of inactivity, (for example, if an hour passed between their requests). We could tell from sniffer traces that there request would never actually get to the web servers from the BigIP and assumed that this was a oneconnect (ghosted connection) issue. Adding the ONECONNECT::reuse disable command fixed the problem for this customer. Months later, another customer using the same set of services began suffering unrelated problems after an upgrade went in so I had to modify the rule to route traffic to one pool (running the old code) if their IP address was matched and all other users get routed to the new pool. I modified the rule like so: "/web/services/*" { ONECONNECT::reuse disable if { ( [IP::addr [IP::client_addr] equals 111.222.333.444] ) }{ pool $ws_pool_1 } else { pool $ws_pool_2 } } Subsequent to this change going in, the first customer began experiencing intermittent connectivity failures again. The logic that routes to a particular pool works fine but I suspect that where I have placed the ONECONNECT::reuse disable command is causing it to be ignored. Should this be placed before the pool command within each branch of the If | Else block? I was assuming, possibly incorrectly, that positioning it before the block would have made it valid regardless of the pool requests were being routed to. If someone could help me understand it better, that would be great.
application delivery
dev
devops
iRules

5 Replies

Sort By
  • mahnsc's avatar
    mahnsc
    Icon for Nimbostratus rankNimbostratus
    Apr 17, 2010
    OK....well, I'm not sure what happened there but here is the post again with more legible formatiing:

    Hi everyone. I had a question about a rule I recently wrote. Initially, I had a rule that comprised a switch -glob statement with a bunch of URIs that, when a match occurs, would route traffic to a particular pool. One of our customers was having issues with some web services which went away once I added ONECONNECT::reuse disable to the affected URI like so:

     

    "/web/services/*" {
  ONECONNECT::reuse disable
  pool $ws_pool_1
  }

    The problem they were having was intermittent connection resets after a period of inactivity, (for example, if an hour passed between their requests). We could tell from sniffer traces that their request would never actually get to the web servers from the BigIP and assumed that this was a oneconnect (ghosted connection) issue. Adding the ONECONNECT::reuse disable command fixed the problem for this customer.

     

    Months later, another customer using the same set of services began suffering unrelated problems after an upgrade went in so I had to modify the rule to route traffic to one pool (running the old code) if their IP address was matched and all other users get routed to the new pool. I modified the rule like so:

     

    "/web/services/*" {
  ONECONNECT::reuse disable
  if { ( [IP::addr [IP::client_addr] equals 111.222.333.444] ) }{
    pool $ws_pool_1
    } else {
    pool $ws_pool_2
    }
  }

    Subsequent to this change going in, the first customer began experiencing intermittent connectivity failures again. The logic that routes to a particular pool works fine but I suspect that where I have placed the ONECONNECT::reuse disable command is causing it to be ignored. Should this be placed before the pool command within each branch of the If | Else block? I was assuming, possibly incorrectly, that positioning it before the block would have made it valid regardless of the pool requests were being routed to. If someone could help me understand it better, that would be great.

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 19, 2010
    Hi Chris,

     

     

    You can manually try to set OneConnect behavior in the iRule, but I think it's simpler to create a custom OneConnect profile with a /32 source mask and add that to the virtual server. See this article for details:

     

     

    http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/oneconnect.html

     

     

    Aaron
  • mahnsc's avatar
    mahnsc
    Icon for Nimbostratus rankNimbostratus
    Apr 19, 2010
    Thanks Aaron. One thing I neglected to mention is that these web services are presently a very small part of a fairly busy JEE site. Setting a /32 might overwhelm the 2 apache servers, (each are configured to support 500 MaxClients). OneConnect is doing an awesome job of multiplexing 1000's of concurrent requests into 50 or 60 apache children per web server.

     

     

    I don't have the agility (yet) in my data center to drop in additional capacity in the event I need to quickly add web server capacity.

     

     

    But, based on your experience with irules, does it look like oneconnect re-use is getting disabled on both pools, which is my intent, or just on ws_pool_2? The rule is supposed to disable oneconnect reuse for every one when the URI requested matches /web/services/*
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Apr 20, 2010
    I would have expected the ONECONNECT::reuse disable command to take effect for whichever pool was selected. If you move the command down into each 'if' clause, does it work for both customers?

     

     

    Aaron
  • mahnsc's avatar
    mahnsc
    Icon for Nimbostratus rankNimbostratus
    Apr 20, 2010
    Hi Aaron. Thanks again for taking the time to look at this. The rule doesn't appear to be doing that. I thought it was odd as well but it appears as if it's either only working for pool_2 (or it isn't working at all). It's tough for me to tell from a tcpdump what is a multiplexed connection versus one that is persistent/keep-alive and there is no pattern to this particular end-user's request other that their requests are spaced relatively far apart.

     

     

    I have an updated rule I'm putting into a staging environment to make sure there is no adverse impact that moves the reuse disable down into the if sections, to see if that helps.