Duplex mismatch would not be a complete loss of connectivity, and pings will often get through without trouble when there is a mismatch - at least if the NIC is otherwise idle - it takes concurrent access to the link from both ends to start seeing the effects of a duplex mismatch.
_Never_ hardcode just one side of the link. Both sides of the link _must_ be set to the same thing - either both auto, both hd, or both fd. You cannot mix and match, or sorrow and woe is the frequent result:
How Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full duplex if both sides can do
full-duplex.
If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.
If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.
So, the following table shows what will happen given various settings
on each side:
Auto Half Full
Auto Happiness Lucky Sorrow
Half Lucky Happiness Sorrow
Full Sorrow Sorrow Happiness
Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.
When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of late collisions. On
the side running full-duplex you will see things like FCS errors.
Note that those errors are not necessarily conclusive, they are simply
indicators.
If you have other HP-UX kit on the same switch(es), or want to grab linkloop for linux from
http://osx.freshmeat.net/projects/linkloop/ you can use that to verify link-level connectivity. If that is all OK, then you move-up to checking that all your routing is correct.
there is no rest for the wicked yet the virtuous have no pillows
