There are many possible explanations for such problems.
After eliminating the obvious sources (like broken cables etc.)
you should check the configuration of your Ethernet PHY. One
common cause of problems is if your PHY is hard configured in
duplex mode (for example 100baseTX Full Duplex or 10baseT Full
Duplex). If such a setup is combined with a autonegotiating
switch, then trouble is ahead.
Jerry Van Baren
explained this as follows:
Ignoring the configuration where both ends are (presumably correctly)
manually configured, you end up with five cases, two of them
misconfigured and WRONG:
1) Autonegotiation <-> autonegotiation - reliable.
2) 10bT half duplex <-> autonegotiation - reliable.
3) 100bT half duplex <-> autonegotiation - reliable.
4) 10bT *FULL* duplex <-> autonegotiation - *UNreliable*.
5) 100bT *FULL* duplex <-> autonegotiation - *UNreliable*.
The problem that I've observed is that the *humans* (the weak links)
that do the manual configuration don't understand that "parallel
detection" *must be* half duplex by definition in the spec (it is hard
to define a reliable algorithm to detect full duplex capability so the
spec writers punted). As a result, the human invariably picks "full
duplex" because everybody knows full duplex is better... and end up as
case (4) or (5). They inadvertently end up with a slower unreliable
link (lots of "collisions" resulting in runt packets) rather than the
faster better link they thought they were picking (d'oh!). The really
bad thing is that the network works fine in testing on an isolated LAN
with no traffic and absolutely craps its pants when it hits the real
world.
That is my reasoning behind my statement that we can generally ignore
the autonegotiation <-> fixed configuration case because the odds of it
working properly are poor anyway.
