Just some observations about all this stuff, based upon experience...

In configuring your host networking it is ABSOLUTELY ESSENTIAL that you
coordinate your intended host settings with your network people.  It is a
common problem for host administrators to see parameters like "Half Duplex",
think to themselves that it would be better if it were "Full Duplex" and
simply make that change in the host - and then see performance degrade due to
a mismatch with the network hardware through which the host communicates.  The
inverse can also happen, where some network person comes along and sees a
router setting that they don't agree with and simply change it, resulting in
performance problems that the host users see and which the network person
won't because he/she doesn't use that host, which means that it can go on for
days or weeks unaddressed.  ("Gee, performance was okay yesterday: what
happened?")  Or you can be the victim of network equipment upgrades which come
in with configuration values which degrade performance.  I'll also stress that
you should try to avoid Autonegotiate in your network equipment, as it is a
frequent cause of conflict between router and host.

In general, it is a good idea to periodically review your current host
settings with your network people - even if you don't think anything is wrong.
It will help uncover anomalies *before* they become serious problems, and
foster coordination which will make for better implementations and upgrade
paths.

Every site should also be prepared, ahead of time, for dealing with network
problems (as in "dig a well before you become thirsty").  Your network people
should have line monitors, router monitors, and the like.  Host support people
should have operating system monitors and be ready to run fixed-size FTP jobs
and the like to gauge throughput.  Be ready to look for really stupid stuff
like students running the hacker 'bmb' program in using your system to attack
remote sites (Denial Of Service attack) - which also clogs your network.  Get
baseline values when your network is not busy so you can know what it's
capable of.  Get stats for what the system looks like with a normal load, to
compare against when performance is bad.  Even a simple thing like doing a
Unix 'cat' command of a large text file to the terminal screen can be useful
in detecting problems (in a duplex mismatch, the output will stutter rather
than flow, for example).  In general, be ready to "dig up the street" in
pursuing your problems so that you can more readily resolve them and not be a
harried victim of the situation.

No one ever said system administration is simple - that's why we get paid so
much.

       Richard Sims, BU