Forum Discussion

hc_andy_35682's avatar
hc_andy_35682
Icon for Nimbostratus rankNimbostratus
Feb 14, 2011

Clearing connections on a backup LTM

Hi All,

 

 

Is there a way to clear all the connections from a node on the backup LTM?

 

 

 

We have two LTM's set up as a HA pair. For one particular VS we set up connection mirroring and set the max limit on the nodes to 5000 connections. When the VS plays up and eventually recovers, the connection count on the backup LTM still shows a high connection count on the nodes as seen below.

 

 

 

[root@f5-2-manage:Standby] config b node 210.15.x.x

 

NODE 210.15.x.x up session enable

 

| (cur, max, limit, tot) = (8977, 10179, 5000, 153.9M)

 

| (pkts,bits) in = (0, 0), out = (12, 127256)

 

| requests (total) = 0

 

 

 

 

 

 

Is there a way to clear the connection count on the backup LTM so it can perform the necessary health check which it does by telnettting to port 8080 and running a http get. It can't do this now because the connection count has exceeded the 5000 connection limit.

 

 

 

Thanks.

 

 

 

Andy

 

 

 

 

 

 

 

  • First question - Based on the fact that you're doing an HTTP GET, is this VIP only doing HTTP traffic? If so, any reason you decided to go with connection mirroring?

     

     

    As far as manually removing these connections, "b conn" would come in handy. In your case, "b conn server 210.15.x.x delete" should work. Otherwise, "b conn all delete" will nuke every connection on the box.
  • Hi Chris,

     

     

    The VIP is actually load balancing squid proxy requests on port 8080. We use a health monitor to telnet to port 8080 of the node and do a simple http HEAD query on a particular URL and the heath check succeeds if it gets back a 200 response.

     

     

     

    I've tried deleting the connections to the node with "b conn server 210.15.x.x delete" but it still shows a high connection count. To me they just look like stale mirrored connections left over from the Primary LTM when the VIP on there had it's little heart attack.

     

     

     

    Before:

     

     

     

    [root@f5-2-manage:Standby] config b node 210.15.x.x

     

    NODE 210.15.x.x up session enable

     

    | (cur, max, limit, tot) = (6415, 7209, 0, 133213)

     

    | (pkts,bits) in = (0, 0), out = (0, 0)

     

    | requests (total) = 0

     

     

     

     

     

     

    Run Command:

     

     

     

    [root@f5-2-manage:Standby] config b conn server 210.15.x.x delete

     

     

     

     

    After:

     

     

     

    [root@f5-2-manage:Standby] config b node 210.15.x.x

     

    NODE 210.15.x.x up session enable

     

    | (cur, max, limit, tot) = (6443, 7209, 0, 133417)

     

    | (pkts,bits) in = (0, 0), out = (0, 0)

     

    | requests (total) = 0

     

     

     

     

     

     

    Any more ideas?

     

     

     

    Thanks.

     

     

     

    Andy

     

     

     

     

     

  • I think Chris' original question of why you're using connection mirroring on HTTP requests is a good one. HTTP clients are fairly resilient to connection failures. Browsers typically open short lived TCP connections. Even if the connection goes down, the browser will either automatically retry or prompt the user to retry manually. It's generally not worth the overhead to mirror connections for an HTTP virtual server.

     

     

    That said, I'm not sure why deleting the connection on the standby unit wouldn't clear the connection counts on the node. Can you try a 'b load' after the 'b conn ... delete'?

     

     

    Aaron
  • Tried "b load" - no change to the connection count.

     

     

    [root@f5-2-manage:Standby] config b node 210.15.x.x

     

    NODE 210.15.x.x up session enable

     

    | (cur, max, limit, tot) = (6286, 6716, 0, 134390)

     

    | (pkts,bits) in = (0, 0), out = (0, 0)

     

    | requests (total) = 0

     

     

     

    [root@f5-2-manage:Standby] config b conn server 210.15.x.x delete

     

     

     

    [root@f5-2-manage:Standby] config b node 210.15.x.x

     

    NODE 210.15.x.x up session enable

     

    | (cur, max, limit, tot) = (6247, 6716, 0, 134859)

     

    | (pkts,bits) in = (0, 0), out = (0, 0)

     

    | requests (total) = 0

     

     

     

    [root@f5-2-manage:Standby] config b load

     

    Reading configuration from /config/low_profile_base.conf.

     

    Reading configuration from /defaults/config_base.conf.

     

    Reading configuration from /config/bigip_sys.conf.

     

    Reading configuration from /config/bigip_base.conf.

     

    Reading configuration from /usr/share/monitors/base_monitors.conf.

     

    Reading configuration from /config/profile_base.conf.

     

    Reading configuration from /config/daemon.conf.

     

    Reading configuration from /config/bigip.conf.

     

    Reading configuration from /config/bigip_local.conf.

     

    Loading the configuration ...

     

     

     

    [root@f5-2-manage:Standby] config b node 210.15.x.x

     

    NODE 210.15.x.x up session enable

     

    | (cur, max, limit, tot) = (6236, 6716, 5000, 135526)

     

    | (pkts,bits) in = (0, 0), out = (0, 0)

     

    | requests (total) = 0

     

     

     

     

  • Hi Arron,

     

     

    The VIP also passes HTTPS requests to the squid proxy farm. Will connection mirroring help with persistent HTTPS connections (eg: an online banking session) when the Primary LTM fails?

     

     

    Thanks.

     

     

    Andy
  • Neither HTTP or HTTPS will benefit much from connection mirroring.

     

     

    If the Squid proxy servers do source address translation *and* the destination web apps do validation of the source IP, you might want to enable persistence mirroring so that the newly active LTM would send requests to the same pool member and the destination web app would see the same IP. Or more ideally, as this is web proxy traffic, you could use a hash based load balancing algorithm that would give you stateless persistence (ie, hash on the host and URI to deterministically pick a pool member without storing any persistence information on the client or LTM).

     

     

    SOL11362: Overview of the CARP hash algorithm

     

    http://support.f5.com/kb/en-us/solutions/public/11000/300/sol11362.html

     

     

    Aaron
  • So is there a way to clear these stale mirrored connection on the backup LTM? I've tried the various suggestions above but the connections won't clear. Also note that I have turned off connection mirroring on the primary LTM and sync the config.