Re: NIC dropping packets

ivica <abc@xxxxxxx> wrote:
HP-UX 11.23, Itanium RX4640. NIC is dropping packets when pinging
clients on the local LAN segment. Reboot solved the problem, but
what can it be? (no firewalls between, no router, local segment)

Do you mean that ping reports dropped requests, or have you actually
run lanadmin and seen drops in the link-level statistics? Can you
provide us with the link-level stats?

How about stats from the switch? And the destination system?

Logs show no defects. Speed 100Mbit/full duplex as well as port on
switch.

Please say you aren't hardcoding NIC duplex settings.

rick jones

How 100Base-T 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
("normal" collisions don't count here). 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.

Further, it is important to keep in mind that a "clean" ping (or the
like - eg "linkloop" or default netperf TCP_RR) test result is
inconclusive here - a duplex mismatch causes lost traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.

Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.

--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.

Relevant Pages

  • Re: errors at NIC
    ... 612823 frame check sequence errors ... it would be the hardcoding of the duplex setting. ... When both sides of the link are set to autoneg, ... the duplex setting and select full-duplex if both sides can do ...
    (comp.unix.tru64)
  • Re: NFS problems
    ... On an otherwise clean network, ... Some boiler-plate on duplex: ... When both sides of the link are set to autoneg, ... the duplex setting and select full-duplex if both sides can do ...
    (comp.sys.hp.hpux)
  • Re: Socket Connection Probolem - SYN - RST
    ... This small network is ... a clean ping does not always mean that duplex settings are fine ... When both sides of the link are set to autoneg, ... the duplex setting and select full-duplex if both sides can do ...
    (comp.os.linux.networking)
  • Re: errors at NIC
    ... 612823 frame check sequence errors ... it would be the hardcoding of the duplex setting. ... When both sides of the link are set to autoneg, ... the duplex setting and select full-duplex if both sides can do ...
    (comp.unix.tru64)
  • Re: 100Mb lan tops out at 1.2Mb ?
    ... make sure there isn't a duplex mismatch between your hosts ... When both sides of the link are set to autoneg, ... If one side is using half-duplex, and the other is using full-duplex, ...
    (comp.os.linux.networking)