Net Balancer ‘Sticky Sessions’ problem

Home Page Forums Network Management ZeroShell Net Balancer ‘Sticky Sessions’ problem

This topic contains 0 replies, has 0 voices, and was last updated by  smto 2 years, 7 months ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #44341

    smto
    Member

    We’ve been using Zeroshell version 3.0.0 with 3xWAN links balanced through the Net Balancer for over a year with excellent results.
    In the past we had a problem with session stickiness which caused empty shopping carts, banks and anything else based on ip address for sessoins etc to not be work on for our users. The reason was that as far as those sites are concerned, the user changed its ip address with every page load causing it to “lose” the cart/session as a security measure.

    This was solved by adding the rhash_entries=300000 parameter to the kernel which cached ip routes (source ip->wan interface->destination ip) and solved the stickiness problem.

    Recently we upgraded to Zeroshell 3.3.2 and the latest 3.18 kernel. In this kernel version (anything>3.6) the rhash_entries parameter is no longer supported and sessions are not “sticky” any longer.

    Is there an alternative solution?
    Any suggestion will be highly appreciated.

    #53852

    francozamp
    Member

    @smto wrote:

    Recently we upgraded to Zeroshell 3.3.2 and the latest 3.18 kernel. In this kernel version (anything>3.6) the rhash_entries parameter is no longer supported and sessions are not “sticky” any longer.

    Is there an alternative solution?
    Any suggestion will be highly appreciated.

    Any updates wrt 3.6 release? It appears now clients are fully sticked with a route. E.g. LAN side Client1 will always go through WAN1, Client2 to WAN2, Client3 to WAN1 and so on, alternatively. Of course failover still works, but it is not possible now with this behaviour to achieve the aggregate WAN1+WAN2 (with multiple connections).

    Before, to my understanding, on the same LAN Client1, odd TCP connections went through WAN1 and even TCP connections went to WAN2, so that 2 iperf could go to the maximum rate aggregate.

    F.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.