Hi, please set this line in /etc/modules and reboot the ZLB:
xt_recent ip_list_tot=4000
Regards.
On Fri, Feb 28, 2014 at 11:18 AM, tibz <[email protected]> wrote:
> Well like usual, murphy law apply and I cannot reproduce the problem...
> The only difference is that yesterday this farm was production with 600
> clients, and today i'm alone.
>
> I still believe the IP Persistance in L4 farm is not reliable. I'm 200%
> sure my timeout was 4h yesterday when my session disappeared quickly.
> Moreover, we have a lot of issues with our clients being kicked out of the
> application when using this type of farm. (the error was about session, so
> client was auth on a backend and suddenly forwarded to another backend by
> ZLB).
>
> I switched back to PEN TCP farm with IP persistence and it's working
> perfectly. Could there be a bug with the IP persistance of L4 farm, like it
> cannot memorize so much IP? In my PEN farm I see around 600 clients
> (differents IP), but with the L4 farm, on the file /proc/net/xt_recent/
> there were only about 100-200 different IPs. That would explain why we had
> so much problem, if it was not memorizing all IPs or forgetting some of
> them very quickly ...
>
> Thanks
> tibz
>
> ps: I read in another thread that you consider to obselete PEN, please do
> not (yet :-))
> ps2: If you wonder why we were happily using PEN and switched to L4, it's
> because we started having issue with PEN after several months. I had
> configured max 2000 IPs in persistance with a timeout of 3600s. When 2000
> is reached, ccording to PEN's doc, it should delete the oldest/least used
> connection to make some room for new connections. But it doesnt seems to
> work correctly as client were randomly switched to another backend (like
> PEN was not deleting the unused entry but some random entry amongst the
> 2000)
>
>
> On 27/02/2014 21:29, tibz wrote:
>
> HI Laura,
>
> Thank you for your answser. When I did my test, the persistance was
> configured to 14400s (4h - same timeout as on the http backend).
>
> But still, after I closed my browser (and then no more connection was made
> from my laptop), my session disappeared from /proc/net/xt_recent/ in about
> 1min max. So I believe it's not right.
>
> What you explain is what I was expecting, and i've checked now the content
> of the /proc/net/xt_recent/ and I still see plenty of session despite no
> one is in the office anymore. So it seems to work "most of the time", but
> not always as like I explained, my session during my test disappeared much
> quicker than the timeout.
>
> I'll run some more tests tomorrow if possible and i'll update you.
>
> Cheers,
> tibz
>
> On 27/02/2014 17:49, Laura Garcia wrote:
>
> Hi again, the persistence will remain until the time specified in the
> farm option:
> *Source IP Address Persistence time to limit **in secs, only for IP
> persistence
> *. *
>
> which by default is 140 secs. So it's the right behavior. In order to
> work around your problem, you could increase that timeout at the same value
> as the HTTP persistence is set in your real servers/web application.
>
> The L4 farm has nothing to do with your browser so the behavior will be
> the same and the persistence will wait until the timeout although the user
> has logged out from the web application.
>
>
> On Thu, Feb 27, 2014 at 10:56 AM, tibz <[email protected]> wrote:
>
>> Hi again,
>>
>> I just did a test. Connected to the farm, then I can find an entry for my
>> laptop IP in the file in /proc/net/xt_recent/ :
>> 192.168.161.191....................................jeudi 27 février 2014,
>> 10:44:16 (UTC+0100)
>> (I used a script found there, if someone is interested:
>> http://forums.fedoraforum.org/showthread.php?t=224461)
>>
>> I just closed my browser, and then in around 30s to 1min, my entry is
>> gone. So apparently when the TCP session is gone, the entry is gone and the
>> persistence is lost. Is this expected or do I misunderstand something?
>> I was expecting that the persistence should be kept, regardless of the
>> current active session, at least as long as the TTL is not over. So here
>> normally when I close my browser, the TTL should start counting from 3600
>> to 0 and then only my persistence should be erased.
>>
>> Thanks
>> tibz
>>
>>
>> On 27/02/2014 10:34, tibz wrote:
>>
>> Hi Laura,
>>
>> Thanks for the information.
>>
>> I was wondering because we are having issues with a web application since
>> we switched to a L4 farm. It "seems" some users are switched to the other
>> backend before the end of the persistence, and therefore they loose their
>> session and get disconnected from the application. We are waiting for the
>> provider to help troubleshooting these errors, but so far when we run with
>> only one backend, we see far less disconnection error (though there are
>> still a few).
>>
>> A last question, I've found that the recent information are stored under
>> /proc/net/xt_recent/ but I wonder if the files (and therefore the
>> persistence) is cleared when the farm is restarted, or does it stay? In
>> another way: can I restart a L4 farm without loosing the persistence?
>>
>> Thanks
>>
>> On 25/02/2014 20:49, Laura Garcia wrote:
>>
>> Hi, yes the L4 farm should behave like the TCP farm in that subject.
>>
>> By other hand, you're absolutely right regarding the TTL field and the
>> farm is not reloaded automatically. This is a bug and will be fixed in the
>> next release. Good catch!
>>
>> Thank you.
>>
>>
>> On Fri, Feb 21, 2014 at 11:44 AM, tibz <[email protected]> wrote:
>>
>>> Hello,
>>>
>>> Can someone please confirm that it works as in TCP Farm with PEN, so
>>> it's the inactivity timeout and not the max session length ? (ie: 3600s
>>> means 1h with no traffic before we remove the persitence)
>>>
>>> Also a little feature enhancement, when a L4 farm is started and you
>>> change the persistence time, it says "The sessions TTL for ZLB-ULG farm
>>> has been modified." but it's NOT applied, it's just written in the
>>> config file.
>>> It would be worth mentionning next to this message that a restart of the
>>> farm is needed...
>>>
>>> Thanks
>>> tibz
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Zenloadbalancer-support mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one
>> tool.http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Zenloadbalancer-support mailing
>> [email protected]https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one
>> tool.http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Zenloadbalancer-support mailing
>> [email protected]https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Zenloadbalancer-support mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>>
>>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one
> tool.http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Zenloadbalancer-support mailing
> [email protected]https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one
> tool.http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Zenloadbalancer-support mailing
> [email protected]https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Zenloadbalancer-support mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
>
>
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support