cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.

iRule to close an established connection

wlopez
Cirrostratus
Cirrostratus

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         } }
5 REPLIES 5

Hamish
Cirrocumulus
Cirrocumulus

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).

 

 

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?

wlopez
Cirrostratus
Cirrostratus

Anyone else has any suggestions?

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?

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.