Forum Discussion

wlopez's avatar
wlopez
Icon for Cirrocumulus rankCirrocumulus
Oct 22, 2020

iRule to close an established connection

I have tcp (not http) based service where client connections are permanent.

By that I mean that once a connection to a pool member gets established its stays there 24x7.

The pool has 2 pool members configured with priority group.

The first pool member has priority 2 and the second one priority 1, with a Less than '1' value for Priority Group Activation.

The pool also has the setting of 'Reject' for 'Action On Service Down'.

That takes care of any scenario where a pool member is marked down by health monitors.

Whenever a highest priority pool is marked down by health monitors all established connections to that pool members get closed automatically.

The client applications immediately try to reconnect and get established connections to the second pool member with the lower priority.

So far, everything is exactly what we want to accomplish.

The challenge comes when the higher priority pool member is marked up/available once again.

We're looking for an automatic way to close the already established connections to the lower priority pool member as soon as the higher priority pool member becomes available.

Is there a way to do so?

Not sure what event I should use for an already established connection.

First ones that came to mind were LB_SELECTED and CLIENT_ACCEPTED.

So far, I've tried the following options without any results:

when LB_SELECTED {
        if { [LB::status pool poolname member 10.0.0.1 80 ] equals "up" and [IP::addr [LB::server addr] equals 10.0.0.2] } {
            reject
        }
}


when LB_SELECTED {
        if { [LB::status pool poolname member 10.0.0.1 80 ] equals "up" and [IP::addr [LB::server addr] equals 10.0.0.2] } {
            LB::reselect pool poolname member 10.0.0.1
        }
}
application delivery
iRules
LTM
pool
Priority Group
tcp
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Oct 22, 2020

    LB_SELECTED is only going to fire when initially selecting a pool member. It won't fire after that.

     

    There really isn't an event I can think of that will fire because a pool member came up/down if it's not associated with the connection itself (The iRule context is associated with a connection).

     

    You could however run a timer... (Although it fails your 'as soon as' requirement unless you pool very often which will waste CPU). And ever X seconds check the availability of the pool hosts on the VS. If the connection is to a lower priority pool member than an available one, close the connection (Or if your protocol/app can handle it just connect to the newly available hi-priority pool member).

     

     

    • wlopez's avatar
      wlopez
      Icon for Cirrocumulus rankCirrocumulus
      Oct 22, 2020

      Thanks for your feedback.

      I'm not necessarily looking to do an instantaneous switch back to the higher priority member as soon as it becomes available..

      The main goal is to automatically close established connections to the lower priority pool member, so that the client platform is forced to reconnect and be sent back to the higher priority pool member within a reasonable amount of time (maybe up to a couple of minutes).

      I've never worked with timers.

      Would you happen to have an example you can share?

  • Patrik_Jonsson's avatar
    Patrik_Jonsson
    Icon for MVP rankMVP
    Nov 01, 2020

    Thinking out loud here and not sure if this is possible, but an external monitor might be able to read the states and kill the connections automatically using a bash script?

  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for MVP rankMVP
    Nov 02, 2020

    I'd try the custom user_alert option. Whenever the higher PG member comes back, you'll see the Pool member 10.0.0.1 Up log. With this, create an alert. Then use the "exec command=" feature to run delete sys connection cmd for your lower PG member. Hope this would do the trick. Try testing it with logger cmd to throw a dummy log.

    alert higher_PG_Up "that high pg pool member up log" {
exec command="tmsh delete sys connection ss-server-addr 10.0.0.2 ss-server-port 80"
}

    If the above doesn't work due to some syslog alertd daemon dependencies, try the icall method. That should definitely work. Keep us posted.