|
Hi,
Christopher Seawood wrote:
> Has anyone else noticed that occassionally the masqueraded timeout values
> in the masq table are insanely huge?
>
> TCP 715818:58.14 10.0.2.104 203.130.248.38 1975 (1975) ->
> 1138
> TCP 715817:11.54 10.0.2.101 203.130.240.19 1975 (1975) ->
> 1651
>
Please tell me more about your VS running ipvs-0.4, so that I can
repeat the problem.
The insanely huge timeout problem of masquerading entry like the
incorrect refcnt (Reference Counter) of the masquerading entry.
>
> Now this server was setup to timeout after 5 seconds, a la /sbin/ipchains
> -M -S 5 5 5 , but that value doesn't seem to have taken everywhere. There
> are some values in the list generated by ipchains -M -L -n that appear to
> timeout in 5 secs and others that seem to use the default kernel values of
> 15, 2 & 5 mins.
>
> This is with a 2.2.7 kernel + 1-liner DoS fix + wensong's 0.4 patch. The
> same things appear to be occurring with peter's 0.2 patch as well. I'm
> not sure if this is a main stream kernel issue or a byproduct of ipvs.
>
> Also, we've noticed that after a few days of heavy load, that the server
> starts to become unresponsive even when logged in at the console. I've
> been told that some stock 2.2.x kernels exhibit the same behavior but I
> thought I'd give a heads up.
>
I have met the other phenonmena. When I rewrote the ipvs patch on a
RedHat-6.0 box last time, I locked the X-windows for near two days,
then the system became very slow, it took more than seconds to
switch from one Xterm to another. So, I have no choice but reboot
the system, then everything was OK.
>
> At first glance, it looks like an obo with an underflow.
> 715817:11.54 == ((715817 * 60) + 11) * 100) + 54 = 4294903154
> which is pretty close to 2^32 . Now to figure out where the problem
> occurs. :-/
>
> - cls
>
Wensong
|
