Rainer Toebbicke wrote:
> It's not the first time that people at external sites complain about bad
> AFS performance from our servers.
> 
> Usually, it boils down to that every now and then one of the routers or
> firewalls in the external networking clouds starts to choke on IP packet
> fragmentation - when we repeat the tests with "-nojumbo" everything
> works like a charm. The problem is that every time its the users who
> detect this, it takes some time until the problem surfaces at the
> sysadmin level, and the networking guys swear that there wasn't a change
> since ages.
> 
> As '-nojumbo' has a measurable price on our own local network where
> fragmentation does not exhibit any problem we hesitate to run everything
> in that mode.
> 
> Ideally, RX would be adaptive and stop using jumbograms when they cause
> problems, but I understand that the algorithm to detect those reliably
> can be challenging.
> 
> How about a config file a la NetRestrict then that turns off jumbograms
> to external sites, or allows them to others?
> 
> Any brilliant ideas?

Rainer:

There is a bug in Rx related to -nojumbo that Derrick identified
yesterday and for which we are testing a patch.  There are three
instances of rxi_AdjustDgramPackets() which instead of being passed
the constant RX_MAX_FRAGS (4) should instead be passed 'rxi_nSendFrags'
which is set to 1 when -nojumbo is enabled.   By always setting this
value to RX_MAX_FRAGS, the sender always attempts to send a jumbogram
even when that entity explicitly has said it does not want it.

The patch can be found at:

/afs/andrew.cmu.edu/usr/shadow/rx-nojumbo-really.diff

As another work around, the client can set the RxMaxMTU size to 1431.
This value is small enough to disable the sending of jumbo grams.

Prior to 1.5.34 the Windows client set RxMaxMTU size to 1260 which
in effect disabled the use of jumbograms on both the clients and
the servers.  This was done to permit OAFW to work with the Cisco
VPN 4.x client.  I removed this in 1.5.34 because it the Cisco VPN
5.x client had been widely deployed and does not suffer from the
inability to send IP fragments.

Unfortunately, there are a large number of other network devices
that also have trouble transmitting IP fragments.  Removing the
RxMaxMTU restriction enabled the OAFW client to once again start
sending jumbograms even though the RxNoJumbo setting is enabled.  The
above patch fixes this problem.

Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to