[OpenAFS] Re: mtu problem

[Derrick Brashear]

On Feb 7, 2013, at 12:37 PM, Andrew Deason <adeason@sinenomine.net> wrote:

> On Thu, 7 Feb 2013 16:36:18 +0000 (GMT)
> Antony Mayi <antonymayi@yahoo.com> wrote:
>=20
>> modern 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).
>=20
> Okay, but there is no tcp/ip traffic here. In 1.6, OpenAFS does not
> (yet) interpret the ICMP errors necessary for standard PMTU discovery,
> and so we explicitly turn it off on Linux. UDP PMTU must be handled by
> the application; it doesn't just happen transparently like it does for
> TCP communication, and we haven't done it properly yet. (We have a
> different mechanism for trying to figure out the path mtu, which I
> thought worked well enough for common scenarios...)
>=20
> Are you actually seeing the DF bit set on the packets? If it is... well
> first of all, "why?", but even if so, are you sure you're not seeing the
> ICMP errors on the wire? (they could very well appear on the wire, and
> we're not doing anything with them)
>=20
> What version of OpenAFS is running at the two ends?
>=20
>>> By "decreasing it on the client side", so you mean you adjusted the
>>> actual interface MTU? You can try forcing the max packet size Rx uses
>>> with the -rxmaxmtu option to afsd. Say, 'afsd -rxmaxmtu 1200'.
>>=20
>> yes, I meant adjusting client interface MTU. I already tried the
>> -rxmaxmtu without any success.
>=20
> I can try looking at this... I thought this was addressed after the
> network problems at the illinois conference; but if someone remembers
> more issues or something, chime in.
>=20

It was, but there were subsequent issues we ended up substantially disabling=
 the code that dealt with it over, and at the moment the result is probably a=
 failure (as before, not a new one) to properly deal with sub 1500 MTU netwo=
rks.

>=20