Current connections not dropped when using command:discard

I think it's time we ask: what layer 7 protocol are we dealing with here? It may really matter given the use case.

 

 

This is a really interesting one...my gut is pointing me toward action on service down, combined with another technique or two, as I mentioned above.

 

 

-- I thought I had cooked up a clever hack with a dummy pool, with a single member forced offline. Set action on service down to reject on that one, then select that pool if you're <2 on your real member pool. But that won't work either, because you still have to address the active flows.

 

 

-- SERVER_DATA may be an option, but it also means that you'll need to use TCP::collect on every egress segment, and even still I'm not sure how you'd fail those active flows in a consistent way.

 

 

-- LB::down your pool members to force action on service down to fire on existing flows - I think that this would work, but it introduces a statistical possibility that you'll still get some flapping because LB::down will cause an immediate re-probe of the monitor, and if your pool members are up you may end up with some connections failing as expected, and others working.

 

 

For this one I think that your best bet is an EAV with TMSH calls (or bigpipe, depending on your version) to check the pool member count, then fail that pool based on the results. With action on service down it'll reject all connections, and you can probably avoid the iRule path completely.

 

 

It's a philosophical debate as to whether a decision like this should be made on the data plane or the management plane, with valid arguments on both sides. But that'll have to wait for another thread :)

 

 

--Matt