Duplex Issues

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.

Interface Issues

Using the LEDs to Troubleshoot

If you have physical access to the switch, it can save time to look at the port LEDs which give you the link status or can indicate an error condition (if red or orange).

Ensure that both sides have a link. A single broken wire or one shutdown port can cause the problem where one side has a link light, but the other side does not.

A link light does not guarantee that the cable is fully functional. The cable can have encountered physical stress that causes it to be functional at a marginal level. Normally you can identify this situation if the port has many packet errors, or the port constantly flaps (loses and regains link).

Check the Cable and Both Sides of the Connection

If the link light for the port does not come on, you can consider these possibilities:

Ethernet Copper and Fiber Cables

Make sure you have the correct cable for the type of connection you are making. Category 3 copper cable can be used for 10 Mbps unshielded twisted pair (UTP) connections, but must never be used for 10/100 or 10/100/1000Mbps UTP connections. Always use either Category 5, Category 5e, or Category 6 UTP for 10/100 or 10/100/1000Mbps connections.

Warning: Category 5e and Category 6 cables can store high levels of static electricity because of the dielectric properties of the materials used in their construction. Always ground the cables (especially in new cable runs) to a suitable and safe earth ground before you connect them to the module.

You can view summary or detailed information on the switch ports using the show interfaces status command. To see summary information on all ports on the switch, enter the
show interfaces status command with no arguments. Specify a particular module number to see information on the ports on that module only. Enter both the module number and the port number to see detailed information about the specified port.

To apply configuration commands to a particular port, you must specify the appropriate logical module.

This example shows how to display the status of all interfaces on a Catalyst 4500 series switch, including transceivers. Output of this command displays "Unapproved GBIC" for non-Cisco transceivers:

Switch#show interfaces status


Port    Name               Status       Vlan       Duplex  Speed Type

Gi1/1                      notconnect   1            auto   auto No Gbic

Gi1/2                      notconnect   1            auto   auto No Gbic

Gi5/1                      notconnect   1            auto   auto 10/100/1000-TX

Gi5/2                      notconnect   1            auto   auto 10/100/1000-TX

Gi5/3                      notconnect   1            auto   auto 10/100/1000-TX

Gi5/4                      notconnect   1            auto   auto 10/100/1000-TX

Fa6/1                      connected    1          a-full  a-100 10/100BaseTX

Fa6/2                      connected    2          a-full  a-100 10/100BaseTX

Fa6/3                      notconnect   1            auto   auto 10/100BaseTX

Fa6/4                      notconnect   1            auto   auto 10/100BaseTX


Switch#


This example shows how to display the status of interfaces in error-disabled state:

Switch# show interfaces status err-disabled

Port    Name               Status         Reason

Fa9/4                      err-disabled   link-flap

informational error message when the timer expires on a cause

--------------------------------------------------------------

5d04h:%PM-SP-4-ERR_RECOVER:Attempting to recover from link-flap err-disable state on Fa9/4

Switch#

Speed Issues

Things that are worth to explore

1) check interface between the gear and the ISP. Ensure the right speed and duplex is present, and whether there are any errors / drops / etc.

2) check interface between the gear to the LAN for the same thing.

3) if possible, use Fluke meter to check the cabling.

4) check the outputs of the following Cisco IOS commands:

- show process cpu history
- show proc mem
- show process cpu | exclude 0.00%__0.00%__0.00%

Also, following can also be used -

STP is one of the most stable technologies you'll ever work with, but certain conditions can cause it to become unstable or inoperable. STP can be debugged, but before doing so, consider the following three situations that can cause STP issues.

A duplex mismatch occurs when the endpoints of a switch-switch connection are using different duplex settings. The problem, of course, is that a port placed into half-duplex will not be able to transmit a BPDU if it happens to be receiving one at the same time - hello, switching loop!

This scenario must be guarded against, since bridging loops can occur as a result. Luckily, if you make this error, the switch is going to let you know really fast! In the following config, Sw1 and Sw2 are trunking on fast 0/11. I changed Sw2's fast0/11 port to half-duplex and Sw1's to full. Quickly, I find out I shouldn't have done that:

SW2(config)#int fast 0/11
SW2(config-if)#speed 100
SW2(config-if)#duplex half

SW1(config)#int fast 0/11
SW1(config-if)#speed 100
SW1(config-if)#duplex full

SW1#
00:14:47: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/11
(not half duplex), with SW2 FastEthernet0/11 (half duplex).
00:14:47: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/11
(not half duplex), with SW2 FastEthernet0/11 (half duplex).
00:14:47: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/11
(not half duplex), with SW2 FastEthernet0/11 (half duplex).

The message is so important that the router gave it to us three times! Placing Sw1's fast 0/11 port into half-duplex stops the messages, and the trunk is up and operational

SW1(config)#int fast 0/11
SW1(config-if)#duplex half

SW1#show interface trunk

Port          Mode         Encapsulation    Status        Native vlan
Fa0/11      desirable         802.1q       trunking            1