What are the causes of duplex mismatch other than misconfiguration? (power outage? improper cabling? auto negotiation implementation bugs?)

Any thoughts on discovering duplex mismatch? NetMRI seems to use interface error rate. Is it sufficient to just poll all interface error rates on switches/servers? What if this feature is not available on a device?

Edit: Drivers can definitely cause problems with duplex. I have seen Broadcom NIC stuck in half-duplex on FreeBSD.

  • what vendor's equipment are you thinking about? It matters for how it's discovered Commented Jul 19, 2013 at 9:17
  • really mixed.. Cisco Catalyst, H3C, HP Procurve, NetGear.. computers, printers, phones, IP cameras etc. Commented Jul 19, 2013 at 10:21
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Commented Jan 3, 2021 at 21:30

4 Answers 4


By far the most common issue would be misconfiguration. Some people still hold on to old beliefs that auto negotation does not work reliably.

If you have different vendors there can be issues but I don't see it very often. I would much rather rely on auto negotiation as my first solution and if that fails fall back to hard coding it.

It is quite common to see ports operating in 100/half because if one side has auto and other side has 100/full then the speed can be detected but the duplex must be assumed to be half because it can't be negotiated.

Your NMS should be able to detect this but you could do a script that logins and does:

sh int status | i half

And reports back all interfaces running in half duplex. This would only work for switches. For routers you would need something like:

sh interfaces | i Fast|Giga|half

Then you would need to parse it in some way. It's probably nicer to use SNMP though. Browsing Ciscos SNMP page SNMP Object Navigator indicates that you should be able to use OID which is PortDuplex.

  • Indeed it doesn't work reliably sometimes... When I worked in IT support I often get support calls because someone's computer woke up and decided to go with half-duplex. Never had a problem with Gigabit tho....Just those old FE ports.... Commented Jul 19, 2013 at 10:26
  • Btw PortDuplex on the switch doesn't tell much about the duplex setting on the other end? Commented Jul 19, 2013 at 10:28
  • "Some people still hold on to old beliefs that auto negotation does not work reliably." +1 on this statement alone. I can't tell you how many times our computer folks try to get us to hardcode our speed/duplex settings. Errors are always handled better at the lower layers.
    – Ryan Foley
    Commented Apr 19, 2014 at 13:12

One of the symptoms of a duplex mismatch is late collisions. Having your NMS alert you on these collisions is a good way of finding them. At least some Cisco models/IOS versions can send SNMP traps for these collisions.


It is always misconfiguration because duplex mode is a L1 configuration issue. If there are L1 issues despite matching DM and a flawless cable, at least one NIC is broken. I suggest you consider two facts about auto-configuration: Neither does every device support auto-configuration, nor is there certainty that both interfaces will running in full-duplex mode.

Considering power outage, that would be a cause of misconfiguration. The interfaces would have to negotiate once again. Either the manufacturer properly documents its devices or you can only guess how the NIC prioritizes duplex and data rate.

Gigabit Ethernet mandates full duplex operation, yet still allows half-duplex. However, duplex mode is a factor whenever Fast Ethernet or less are available. There are still devices in use which do not need more than 100 Mbps because it links to a line which will never deliver more speed.

Then there are devices without a Web interface or CLI. These use tiny DIP switches for HD and FD. A method which probably causes confusion among users.

And there are devices by the same manufacturer which are out of line with the rest of the series. For example, all devices mandate AN, except for one device. Maybe no one would expect that. So to say - never dismiss misconfiguration.


At a low level the big indicator of duplex mismatches is large numbers of "late collisions" reported on the half duplex end of the link. The full duplex end is unlikely to show errors.

At a higher level a common indicator of duplex mismatch is that pings work but more complex stuff either fails completely or works with abysmal performance. Protocols like TCP will try to send data in both directions at the same time, on a correctly operating full duplex link this obviously works fine, on a correctly operating half duplex link it also works fine as ethernet will buffer the packets until the line is free but on a duplex mismatched link it's practically gauranteed to result in late collisions and hence dropped packets.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.