[OpenAFS] UDP timeouts
Avinesh Kumar
avinesh@gmail.com
Sat, 7 May 2011 00:17:43 +0530
--0015174c4278fd416904a29fed88
Content-Type: text/plain; charset=ISO-8859-1
Hi All,
I was seeing timeout errors with my OpenAFS client. I have OpenAFS client
from a RHEL 5.5 in a VMware image,
where the IP is NATted.
The VMware Player tool comes with a network configuration utility, using
which I set up UDP timeout for NAT
to "0" that would mean to not timeout.
The problem as I understand is after timeout value the port number NAT
mapping for the virtual OS image is not
maintained and when the file server tries to send responses to the port
where it was sending earlier, the OpenAFS
client is not able to get it, as the earlier port mapping is gone.
This is working pretty good for me, if you have similar configuation you may
try this out.
--
Avinesh Kumar
On Fri, May 6, 2011 at 11:29 PM, Jeffrey Altman <
jaltman@secure-endpoints.com> wrote:
> On 5/6/2011 7:10 AM, Jaap Winius wrote:
> > Quoting Jeffrey Altman <jaltman@secure-endpoints.com>:
> >
> >> 10 to 15 minutes is more than sufficient.
> >
> > Since ip_conntrack_udp_timeout and ip_conntrack_udp_timeout_stream were
> > decreased from 28800 to 900 seconds, I've been seeing lots of dropped
> > packets again. Any explanations? I've now increased both values to 3600.
> >
> > Cheers,
> >
> > Jaap
>
> Which party is behind the NAT? Server or Client?
>
>
>
--0015174c4278fd416904a29fed88
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi All,<br><br>I was seeing timeout errors with my OpenAFS client. I have O=
penAFS client from a RHEL 5.5 in a VMware image,<br>where the IP is NATted.=
<br>The VMware Player tool comes with a network configuration utility, usin=
g which I set up UDP timeout for NAT<br>
to "0" that would mean to not timeout.<br><br>The problem as I un=
derstand is after timeout value the port number NAT mapping for the virtual=
OS image is not<br>maintained and when the file server tries to send respo=
nses to the port where it was sending earlier, the OpenAFS<br>
client is not able to get it, as the earlier port mapping is gone.<br><br>T=
his is working pretty good for me, if you have similar configuation you may=
try this out.<br><br>--<br>Avinesh Kumar<br><br><div class=3D"gmail_quote"=
>
On Fri, May 6, 2011 at 11:29 PM, Jeffrey Altman <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jaltman@secure-endpoints.com">jaltman@secure-endpoints.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">
<div class=3D"im">On 5/6/2011 7:10 AM, Jaap Winius wrote:<br>
> Quoting Jeffrey Altman <<a href=3D"mailto:jaltman@secure-endpoints.=
com">jaltman@secure-endpoints.com</a>>:<br>
><br>
>> 10 to 15 minutes is more than sufficient.<br>
><br>
> Since ip_conntrack_udp_timeout and ip_conntrack_udp_timeout_stream wer=
e<br>
> decreased from 28800 to 900 seconds, I've been seeing lots of drop=
ped<br>
> packets again. Any explanations? I've now increased both values to=
3600.<br>
><br>
> Cheers,<br>
><br>
> Jaap<br>
<br>
</div>Which party is behind the NAT? =A0Server or Client?<br>
<br>
<br>
</blockquote></div><br>
--0015174c4278fd416904a29fed88--