|
Hi Chris,
I think I have got the reason of masq hugh timeout values.
Sometimes timer checking is behind system's jiffies ticking, masq expire
value is less than jiffies, and masq timeout value = masq.expires-jiffies,
so it is less than zero and you saw the huge timeout (unsigned).
Anyway, it doesn't matter, because when the run_timer_list() is executed,
masq entries who expire is less than jiffies will be expired.
Wensong
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
>
> 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.
>
> 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
>
|
