[OpenAFS] Re: mtu problem

[Antony Mayi]

=0A=0A=0A=0A=0A>________________________________=0A> From: Andrew Deason <a=
deason@sinenomine.net>=0A>To: openafs-info@openafs.org =0A>Sent: Thursday, =
7 February 2013, 15:16=0A>Subject: [OpenAFS] Re: mtu problem=0A> =0A>On Thu=
, 7 Feb 2013 11:09:28 +0000 (GMT)=0A>Antony Mayi <antonymayi@yahoo.com> wro=
te:=0A>=0A>> I seem to have problem with one particular client that is unab=
le to=0A>> access AFS. When tcpdumping both sides I can see the server send=
s some=0A>> packets that are 1488B long and non of these ever arrives to th=
e=0A>> client so this points out to a MTU problem (verified with ping).=0A>=
=0A>If the MTU is lower, the packets should still get there; they should=0A=
>just be fragmented and then reassembled. But you may have something that=
=0A>drops UDP fragments, which is pretty common (or something that's just=
=0A>dropping UDP packets over a certain size for some reason).=0A=0Amodern =
tcp/ip stack is setting Don'tFragment flag by default so oversized packets =
are always dropped (relevant ICMP should be sent back for PMTU discovery to=
 kick in though which is not happening in my case).=0A=0A>=0A>> Is there a =
way to work this around on the client's side? This is just=0A>> a single cl=
ient suffering so don't want to decrease the MTU on all the=0A>> servers ju=
st because of one client. And decreasing it just on the=0A>> client side do=
esn't make any difference.=0A>=0A>By "decreasing it on the client side", so=
 you mean you adjusted the=0A>actual interface MTU? You can try forcing the=
 max packet size Rx uses=0A>with the -rxmaxmtu option to afsd. Say, 'afsd -=
rxmaxmtu 1200'.=0A=0Ayes, I meant adjusting client interface MTU. I already=
 tried the -rxmaxmtu without any success.=0A=0A>=0A>-- =0A>Andrew Deason=0A=
>adeason@sinenomine.net=0A>=0A>____________________________________________=
___=0A>OpenAFS-info mailing list=0A>OpenAFS-info@openafs.org=0A>https://lis=
ts.openafs.org/mailman/listinfo/openafs-info=0A>=0A>=0A>