I agree with Aaron. the expire period in the stick table should cover at least the expected work period. This is also how I setup them.
Baptiste On Fri, Jun 13, 2014 at 10:40 PM, Aaron West <aa...@loadbalancer.org> wrote: > Hi, > > I'm not aware of a way to achieve what you want exactly. > > The stick table expiry works best with something like HTTP where connections > are not that long so fresh connections keep refreshing the timer. > > In the case of SSH or RDP you have 1 potentially very long connection so the > only option you have is to use a very long expire timeout. An example being > RDP where I regularly recommend 12 hours or so for expire time... > > Aaron > > > On 13 June 2014 02:52, Hailing Xu <hailin...@gmail.com> wrote: >> >> Hello haproxy geeks, >> >> I am trying to use haproxy in the following scenario that persistent tcp >> connections using source ip. >> >> The client establishes a tcp connection (such as ssh for e.g),to vip, and >> vip allocates a real server rs1. I can see the stick table entry via cli. >> When this tcp session keeps a long time, during this period, the relevant >> stick table entry's expiration time is always decresing, until it is removed >> for timeout. But at this time point the existing tcp connection is still >> alive. If I close the connection, and start a new one, it is allocated a >> different real server, for round robin and no stick table entry matches. >> >> My question is "is it normal that timeout the stick entry even there is >> still a session alive from that client?" >> if yes, why it is designed such a way. Is it more comprehensible that the >> stick table starts timing out after no session from that client. >> if no, is there any configuration in haproxy I missed to avoid the stick >> table timeout in case there still existing live session from that client. >> >> Thanks a lot for your help and information. >> Hailing. > >
