I have confirmed the behavior. In both cases all new connections receive a RST when a backend server is not available to service the request. The behavior is Syn -> RST in both cases. Any existing connections timeout. On Mar 21, 2015 9:11 AM, "Brendan Kearney" <bpk...@gmail.com> wrote:
> On Sat, 2015-03-21 at 14:03 +0100, Lukas Tribus wrote: > > > haproxy is a tcp (layer 3/4) proxy, that can perform application (layer > > > 7) functions. i am already doing service checks against my proxies to > > > validate their availability. when no pool member is available, haproxy > > > knows it. there are no external helpers needed to make this > > > determination. the layer 7 capabilities make this possible. > > > > > > the injection of a RST is part-and-parcel to the tcp proxy > > > functionality. i can understand if the functionality in not in haproxy, > > > but it is not outside the realm of capability for a t. > > > > The 3 way TCP handshake happens before the application (haproxy) is even > > aware of the session, therefor this is only possible if the kernel > handles > > it (iptables), which is why I said its only possible with external > helpers. > > > > Or is what you are requesting to send a RST in the middle of an already > > established TCP session? > > > > > > Please CC the mailing list. > > > > > > Lukas > > > > > > sorry, thought i did cc the list. > > i will have to test out the behavior, as this is an implemented solution > where i work, using other products. i can test a couple of different > scenarios that come to mind. > > 1, new browser session comes in to the load balancer, and no backend > servers are available. where / when is the RST sent? > > 2, a session to the load balanced exists, and the backend servers become > unavailable. where / when is the RST sent? > > i'll run these scenarios and let you know what i find in a packet > capture. > >
