i recently installed woody as the base for a firewall. i basically set up a scheme where it was the only link to a subnet of 'protected' computers and no packets were allowed to reach them. i had set up NAT on them and let those packets through, but the connections would be originating from behind the wall. NFS was acting curiously slow.
to ensure that it wasn't the NAT, i opened the firewall up to forward packets, and added a route on my NFS server to the subnet of computers behind the (now disabled) firewall. interestingly, NFS was still horendously (unusably) slow, although it did actually function given enough time. i noticed that my route table on the debian firewall had entries of '40' for the MSS, a rather odd number, considering that the MSS is generally 40 *less* than the MTU (which is 1500 for ethernet). i hadn't set these explicitly, and 'tracepath' reported an MTU of 1500 to UDP port 2049 (NFS). i'm no network wiz, but something was funny. explicitly setting the MSS to 1460 (1500 - 40 for headers) changed neither performance nor what 'tracepath' reported for the MTU. ANYWAY, does anyone know why my route table was showing 40 as an MSS? presumably this would have been set by some auto-detection scheme, but the topology of the network is quite straightforward (node to hub to node to switch to node), end-to-end. all NICs are 10 or 100 Mb, and it's all CAT5 cabling. pretty standard stuff. aside all that, does it seem that the route MSS is misleading and its strictly an NFS problem? what gives? PS: i've played around with the r/w chunk sizes on the NFS clients (SGI), of course, accomplishing nothing. -c ------------------------------------------------------------------------