Forum Discussion

Remco's avatar
Remco
Icon for Nimbostratus rankNimbostratus
Jan 16, 2012

Virtual sends [RST, ACK]

Hi,

 

 

 

we recently replaced Cisco CSS by F5 BigIP, but we know have a problem in our production environment under load which we did not noticed in out acceptance environment.

 

 

We have a virtual configured and on this virtual we have an irules which does pool selection based on the requested uri.

 

 

What I see in the tcpdumps I took, is that on an existing tcp session there are several GET and POST requests where I can see the identical GET or POST message is also send to a poolmember as you would expect. But sometimes on an open client tcp connection we are getting a http GET or POST request and I do not see the request being send to a poolmember. I do see the F5 is first responding with a ACK and than ~5 seconds later a [RST, ACK] is send back to the client terminating the TCP session.

 

The uri requested should match on of uri's in the irules and I don't have any poolmembers down messages in the ltm log. Some of the pools are used in combination with SNAT automap, the uri with problems are mostly for pools without snat.

 

 

I have seen a couple of post reporting the same behaviour, but haven't seen a solution. Does anybody know what can cause this behaviour and how it can be solved?

 

 

The problem looks a similar as posted at: http://devcentral.f5.com/Community/...ault.aspxv

 

 

 

13 Replies

  • Remco's avatar
    Remco
    Icon for Nimbostratus rankNimbostratus
    Does anybody know if the following would work:

    enable SNAT automap on the virtual and under the HTTP_REQUEST do a 'snat none' and only do a 'snat automap' on the required pool.

    The irule would then be:

    rule irule-p__urllb {

    when HTTP_REQUEST {

    snat none

    switch -glob [HTTP::uri] {

    "/app1*" {

    pool pool-p__app1

    persist cookie insert 111

    }

    "/app2*" {

    pool pool-p__app2

    persist cookie insert 222

    }

    "/app3*" {

    pool pool-p__app3

    persist none

    }

    "/app4*" {

    pool pool-p__app4

    persist none

    snat automap

    }

    default {

    reject

    }

    }

    }

    }

     
  • Hi Remco,

     

     

    I think the most intuitive way to handle this is to call snat none or snat automap for each switch case in the iRule. You'd want to leave SNAT set to the default of allow on each pool. This way all of the SNAT related config is handled in one place in the iRule.

     

     

    Aaron
  • Personally, I'd follow the old (Python) idiom of "explicit is better than implicit" and setup a dedicated snat pool for each of your destination pools, even with a single member in the snat pool. Then switch to the appropriate snat pool specifically. It's way more predictable, tunable, and less ambiguous than relying on automap. E.g. app1, app2, app3 would have a snat pool each.

     

     

    --Matt Cauthorn