🚀 go-pugleaf

In article <3022@orion.cf.uci.edu> iglesias@orion.oac.uci.edu (Mike Iglesias) writes:
>On occasion (more often than we'd like), the client systems will start
>printing messages about the NFS server not responding.  This goes on
>for about 45 seconds or so, and then the client can talk to the server
>again.  We don't see this on Suns that are on the same subnet as the
>Sequent server, which could indicate it's a network problem.

That's the key that tells you it's a routing problem. You can easily verify
this by attempting an rlogin at the same time as NFS is having trouble. If
the rlogin just sits there, then routing is the problem.

Whether it's something you can easily fix is less clear. Older versions of
routed, the route daemon, are known for going catatonic, spitting up, and
other rude behavior that can result in networks temporarilly being separated
from each other; and last I knew, Dynix was still using the 4.2BSD routed.
Also SunOS older than, oh, 3.4 or so.

Figuring out who dropped what involves using netstat -r to determine which
routes are vanishing at which nodes. If you can find a TCP/IP wizard to watch
the netstat output while you are having troubles, you may be able to find a
single node that is eating routes because of some trivial configuration
problem. More often than not, it will be the gateway machine itself that is
having problems.

The draconion solution is to use static routing, instead of dynamic. You then
use the route(8) command to add the routes by hand in /etc/rc.boot, and do
*not* start routed(8). It actually works very well if your network is small
and you don't change the topology very often. If it's the gateway that is
dropping routes, then you use static routing on the gateway, and dynamic on
all other machines.

<csg>

In article <3022@orion.cf.uci.edu> iglesias@orion.cf.uci.edu (Mike Iglesias) writes:

   On occasion (more often than we'd like), the client systems will start
   printing messages about the NFS server not responding.  This goes on
   for about 45 seconds or so, and then the client can talk to the server
   again.  

one thing to look at is your NFS read/write block size.  We found here
at MIT that our network router software/hardware had some problems with
the 8k packets normally used (which must be fragmented, and usually are
sent out back-to-back at maximum ethernet packet size).  Although the
network group here has finally fixed the software, Athena has for a long
time used 1k read/write packets to avoid excercising this bug.

I have seen this problem both with MIT's custom C-gateway code and with
a vendor's stock hardware/software solution with very similar topology
(lots of IP subnets on ethernet, connected to routers which sit on a
central fiber-optic campus spine).

--
John Kohl <jtkohl@ATHENA.MIT.EDU> or <jtkohl@Kolvir.Brookline.MA.US>
Digital Equipment Corporation/Project Athena
(The above opinions are MINE.  Don't put my words in somebody else's mouth!)