[OpenAFS] OpenAFS Client Availability

[ted creedon]

In the kernel ip_conntrak_proto_udp.c:

unsigned int ip_ct_udp_timeout = 30*HZ;
unsigned int ip_ct_udp_timeout_stream = 180*HZ;
in .config CONFIG_HZ_250=y

so the default values published assume an RTC clock frequency of 1 HZ, which
it is not. 

Looks like the timeout here is 45000 seconds for any Tx+Rx packets observed
in a 7500 second window "several times". That's 125 hours by my
calculations.

This may explain why things work on the Linux box here (FreeBSD firewall
aside) and not elsewhere.

>From make xconfig:
Timer frequency

Allows the configuration of the timer frequency. It is customary
to have the timer interrupt run at 1000 HZ but 100 HZ may be more
beneficial for servers and NUMA systems that do not need to have
a fast response for user interaction and that may experience bus
contention and cacheline bounces as a result of timer interrupts.
Note that the timer interrupt occurs on each processor in an SMP
environment leading to NR_CPUS * HZ number of timer interrupts
per second.

>From Netfilter Reference:

3.7.16. ip_ct_udp_timeout

The ip_ct_udp_timeout variable specifies the timeout for initial UDP packets
in a connection. When a UDP connection is initialized, the UDP packet enters
an NEW and then ESTABLISHED state once it has seen return traffic to the
original UDP packet. However, it maintains the same timeout until it has
seen several packets go back and forth and becomes assured, at which point
it is instead considered a stream.

While this initial state is maintained, the default timeout is 30 seconds.
If you are using UDP protocols that send very little data during longer
timeframes, you should consider raising this value so that the state machine
is able to keep track of your connections properly. It is generally a bad
idea to lower this, unless you know that your hosts sends UDP packets very
often and don't expect a lot of late replies, which would mean a lot of
unnecessary open conntrack entries.
3.7.17. ip_ct_udp_timeout_stream

The ip_ct_udp_timeout_stream variable specifies the timeout values of the
UDP streams once they have sent enough packets to reach the assured state.
This state is normally reached for connections that send a lot of data and
relatively often, such as streaming services or ICQ. Examples of streaming
services may be certain realplayer servers, or speak freely. This value
should always be larger than the initial timeout value for UDP streams since
it is used on connections that we know for sure expects a lot of traffic
back and forth, even though it may not be very often.

The ip_ct_udp_timeout_stream variable is per default set to 180 seconds, or
3 minutes in recent kernels. If you are having problems with connections
timing out, you may try raising this value a bit. It is generally a bad idea
to lower this value, since the connection will be destroyed once it times
out from this state. Unfortunately, UDP is a stateless protocol, so it is
very hard to derive any specific states of the connections. Because of this,
there is no specific conntrack timeouts for UDP streams that are about to
close, or that has closed.
tedc
Derrick J Brashear wrote:
> On Thu, 8 Mar 2007, ted creedon wrote:
>
>> Good question, but I forgot, there are 2 firewalls, an ancient
>> Freebsd one
>> in Anchorage and the Fubuilder one in Portland. Have no idea what the
>> rules
>> and settings are in Anchorage. Yet.
>>
>> On Linux sysctl -q ip_ct_udp_timeout_stream gets an unknown key error.
>>
>> Where else can I look in the Linux and Freebsd boxes?
>
> beats me. however, sure seems like you could determine it empirically.
> "try it"
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>