[OpenAFS] OpenAFS, Cisco VPN and MAC OS and mtu

Douglas E. Engert deengert@anl.gov
Thu, 28 May 2009 11:27:06 -0500


Jeff Blaine wrote:
> FWIW, this appears to be the same problem I reported in
> April, but for Windows.
> 
> https://lists.openafs.org/pipermail/openafs-info/2009-April/031127.html
> 
> We are still working with our networking+VPN folks to
> try to determine if it's the same thing or not, as well
> as how to fix it.


Have you tried the Windows registry setting rxMaxMtu?

It needs to be 56 bytes less then the actually MTU.
Cisco VPN appears to force a MTU of 1300 on the interface,
so rxMaxMtu should be 1244.

If you are having a fragmentation problem, ping can help, by setting
the don't fragment bit and varying the size can help see what the
limit is.

On Windows:   ping -f -l nnnn ...
On Linux:     ping -M do -s nnnn ....


On the windows client that is failing, try:
rxdebug 127.0.0.1 -port 7001 -peer -long
ipconfig /all

Look for the ifMTU nnnn natMTU nnnn maxMTU nnnn
lines for each afs server. Also compare the IP numbers
with the ip number in the ipconfig.

As best as I can tell, The code in rx_kcommon.c tries to
determine the ifMTU based on the addresses of the client and server.
If they appear to be on the same class a, b, or c network, it
may work by using the MTU from the matching interface. But none
if the interfaces match at all, it defaults to using 1500, which can case
fragmentation. Even in the Windows case I think this might happen.

To test this I need to get off site. Will try tonight from home.




> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444