| Walter Roberson 2005-06-24, 6:00 pm |
| In article <bqVue.295$Tk2.256@trnddc02>,
sinister <sinister@nospam.invalid> wrote:
:The curious thing is that all the cheap Suns with *really* bad problems
 i.e., graphics taking minutes to load, not just ftp slowness) show no
:intervening hosts/switches/whatever when I run traceroute. Hosts that show
:ftp slowness but graphics relatively unaffected show intermediate switches
:according to traceroute.
switches don't show up in traceroute -- only layer 3 hops decrement
the TTL field so only layer 3 hops can return icmp ttl exceeded messages.
Your v1280 server is unlikely to have more than a couple of ports,
so you almost certainly have a layer 2 switch in the middle that is
not showing up.
Anyhow, your description sounds very much like duplex problems to me.
I would suggest that you should launch right in to forcing the
speed and duplex on the v1280 server and the switchport it is
connected to: instances in which forcing speed and duplex on
both ends make things -worse- are quite uncommon (but not unknown )
The test after that would be to force speed and duplex on one of
the cheap Suns you mention (and corresponding switchport).
There is no firm agreement about autonegotiation vs forced
speed and duplex. The rule of thumb that seems to be most common
is that speed and duplex should be fixed for critical infrastructure
(switches, routers, key servers), but that autonegotiation should be
used for desktops. (Opinions vary on this, though!!) The practical
idea behind this particular rule of thumb is that you can't afford
to have speed and duplex issues on the key infrastructure that does
not change very often, but that desktops tend to change too often
to make it -convenient- to lock speed and duplex for all of them...
and if something does go wrong for the desktops, it isn't going
to affect very many people.
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth
|