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.
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 1.3.6.1.4.1.9.5.1.4.1.1.10 which is PortDuplex.
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.
