Jesus College Uses NetMRI
"Without NetMRI we would have had to hunt down a recent configuration file if we didn't have the most recent settings. It turned a potentially full-day job into half an hour. It literally took five minutes to locate the configuration settings. With NetMRI, the preparation for our VoIP system roll out took two hours instead of two full-days. The process was incredibly smooth and saved us a huge amount of time."
—Damian Kramer, Operations Manager, IT DepartmentRead Case Study
Take the Next Step:
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.
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.
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.