Skip to content

All the information you need—in one place.

Want to read our latest whitepapers or Tech Tips? Or check out our library of data sheets and case studies? Netcordia's resource center is constantly updated with new materials, so you can always stay on top of our products, solutions, and services.

Media Saturn Management AG Uses NetMRI

"Thanks to the automated analysis and the fast detection of network problems, we were able to save a lot of money since we did not need to hire a full-time outside consultant anymore. My daily work became more effective and convenient through the use of NetMRI. Since the deployment of NetMRI, I can answer questions about the network more promptly."

—Franco Carlo Blank, IT Manager

Read Case Study

Tech Tips

Take the Next Step:

Related Information

Network Analysis Tip: Switch Port Duplex Mismatch

Why is this important?

Switch port duplex mismatch problems are a real pain! They occur when the switch port and attached computer are not configured to use the same duplex setting or for both ends to auto negotiate the setting. Regardless of the setting the connection seems to work fine at low traffic levels, particularly for ping packets. But as the traffic level grows, the errors increase, affecting network throughput. Unless you monitor the errors on every switch port, you may not be aware of the problem. Errors will accumulate on each end of the misconfigured link. The half duplex end will see late collisions, alignment errors, and FCS errors. The full duplex end will see FCS errors.

Duplex mismatch is typically caused by configuration errors. If one end of the connection is configured for full duplex, and the other end is configured for auto negotiation, the system configured for full duplex will not participate in the negotiation. The negotiation fails and the standard requires that the system configured for auto negotiation must use half duplex. So now we have one end configured for full duplex and the other end auto negotiated to half duplex. Duplex mismatch can also occur when a NIC driver doesn’t remember its settings when the system is rebooted or it may not have been properly configured when a defective NIC was replaced. We’ve seen networks in which the number of duplex mismatches grew from 10 to over 70 ports over a two-month period, simply due to changes in the devices connecting into the network. Finally, there’s the case where the configurations are inconsistently set on both ends of the link, such as would happen when a server that’s configured for full duplex is plugged into a switch port that’s configured for half duplex.

The major source of errors is because the half duplex system will be sensing collisions and the full duplex system will not. That’s why the errors are proportional to traffic volume. Pinging across such a link will work fine, because there is little traffic. However, as the traffic load builds, more and more collisions occur.

Manual determination

Periodically verify the server network connections to make sure that they are setup with either fixed speed and duplex settings on each side or that both are set to autonegotiate. Checking for errors on the switch port is a simple check that is easier than trying to collect and verify the duplex settings on both ends of a link. For example, in the Cisco IOS, the command ‘show interface fa0/1’ would display the duplex and speed setting and the number of input and output errors (in bold text below).

top_switch>sh int fa0/1 FastEthernet0/1 is up, line protocol is up
  Hardware is Fast Ethernet, address is 0002.b9fc.b701 (bia 0002.b9fc.b701)
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
    reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Auto-duplex (Half), Auto Speed (10), 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 30000 bits/sec, 50 packets/sec
  5 minute output rate 29000 bits/sec, 51 packets/sec
    107183547 packets input, 45975296 bytes
    Received 1563002 broadcasts, 185 runts, 0 giants, 0 throttles
    185 input errors, 0 CRC, 0 frame, 0 overrun, 381 ignored
    0 watchdog, 1072083 multicast
    0 input packets with dribble condition detected
    111309492 packets output, 455124708 bytes, 0 underruns
    0 output errors, 4524 collisions, 1 interface resets
    0 babbles, 0 late collision, 79057 deferred
    0 lost carrier, 0 no carrier
    0 output buffer failures, 0 output buffers swapped out

Manually checking more than a few switch ports is very boring and so it isn’t performed as often as it should.

Note that errors may also be caused by bad cabling, so even if the duplex settings are correct, identifying switch ports with high error percentages is an important periodic task.

Automatic determination

NetMRI identifies 100Mbps switch ports reporting more than 0.01% errors on either input or output. At an average packet size of 100 to 1500 bytes, this is equivalent to a bit error rate (BER) of roughly 10E-7 to 10E-8. A good LAN interface should have a BER of less than 10E-10, or one bit out of every 10 billion bits. On a 100Mbps link, that's one error for every 100 or more seconds of full-speed operation. The switch ports are sorted by the percentage of errors. Any switch port handling more than 100,000 packets per day should be investigated. In the example to the right, the interface in row 1 has over 6% in error state. By tracking volume, along with the balanced packet count for input and output, indicates that the system connected to this port is likely to be a server. At these error rates, the applications on this server will have very poor performance.

Back to Tech Tips