LearnCCNA

Search

Objective 1.4

Identify interface and cable issues (collisions, errors, mismatch duplex, and/or speed)

When a link misbehaves, the first place to look is the interface itself. This objective tests whether you can read the status and error counters that Cisco IOS shows for an interface and diagnose the physical cause.

Interface status

The command show ip interface brief lists every interface with two status columns. The first (Status) reflects Layer 1; the second (Protocol) reflects Layer 2:

R1# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     10.1.1.1        YES manual up                    up
GigabitEthernet0/1     unassigned      YES unset  administratively down down
GigabitEthernet0/2     10.1.2.1        YES manual down                  down
Serial0/0/0            10.1.3.1        YES manual up                    down
Status / Protocol Meaning Typical causes
up / up Working Nothing to fix
administratively down / down Shut down by configuration shutdown on the interface; fix with no shutdown
down / down No Layer 1 signal Cable unplugged or broken, far-end device off or shut down, speed mismatch, wrong cable type without auto-MDIX
down / down (err-disabled) Port disabled by the switch Port security violation, PoE policing, BPDU guard; check show interfaces status
up / down Layer 1 fine, Layer 2 failing Encapsulation mismatch or keepalive failure on serial links; rare on Ethernet

The switch command show interfaces status gives a compact view including speed, duplex, and VLAN, and is where err-disabled and notconnect states are easiest to see.

Speed and duplex autonegotiation

IEEE 802.3u defined autonegotiation, in which the two ends of a link exchange Fast Link Pulses to advertise the speeds and duplex modes they support and then pick the best common combination. The priority order is 10G, 1000 full, 1000 half, 100 full, 100 half, 10 full, 10 half. Both sides default to auto, and with autonegotiation on both sides everything just works.

Problems arise when an administrator hard-codes one side and leaves the other on auto, or hard-codes the two sides differently:

  • Speed mismatch (for example one side fixed at 1000, the other at 100): the two ends cannot understand each other’s signals, and the link goes down/down. This is an easy problem to spot.
  • Duplex mismatch (one side full, one side half): the link comes up/up, but performance is terrible. This is the hard one.

The classic cause of a duplex mismatch is one side set to speed 100 and duplex full while the other side is left on auto. The auto side receives no negotiation pulses from the fixed side, so it uses parallel detection: it can sense the speed from the signal (100 Mbps), but it cannot sense duplex, so the standard says it must fall back to half duplex. Result: one end full, one end half.

On the half-duplex end, the device still runs CSMA/CD. Every time it happens to transmit while the full-duplex end is also transmitting (which the full-duplex end does freely, since it thinks collisions are impossible), the half-duplex end detects a collision, aborts, and retries. The full-duplex end sees the aborted partial frame as a runt or a CRC error. Throughput collapses, especially under load, while ping may still work fine because it is low traffic.

Reading show interfaces

show interfaces on a specific interface gives the detailed counters:

SW1# show interfaces fastethernet 0/1
FastEthernet0/1 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0019.e8a1.0c01 (bia 0019.e8a1.0c01)
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Half-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  Last input 00:00:01, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  5 minute input rate 3000 bits/sec, 4 packets/sec
  5 minute output rate 12000 bits/sec, 9 packets/sec
     184532 packets input, 22134567 bytes, 0 no buffer
     Received 1204 broadcasts (0 multicasts)
     312 runts, 0 giants, 0 throttles
     1544 input errors, 1232 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     297811 packets output, 301245987 bytes, 0 underruns
     0 output errors, 2810 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 1955 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

The lines you must be able to interpret:

Counter Meaning Common cause
runts Frames received shorter than 64 bytes Collisions (a normal by-product on half duplex); duplex mismatch; bad NIC
giants Frames received longer than 1518 bytes (1522 with tag) Misconfigured MTU or jumbo frames on the far end; faulty NIC
input errors Total of runts, giants, no buffer, CRC, frame, overrun, ignored Any receive problem
CRC Frames whose FCS check failed Bad cable, EMI, bad connector, duplex mismatch
frame Frames with CRC error and a non-integer number of bytes (misaligned) Collisions, cable noise
collisions Collisions detected while transmitting (during the first 64 bytes) Normal on half duplex; should be zero on full duplex
late collision Collision detected after the first 64 bytes (512 bit times) were sent Duplex mismatch (by far the most common), or a cable longer than 100 m
deferred Frames delayed because the medium was busy Normal on half duplex
output errors Total transmit errors Includes late collisions and excessive collisions
interface resets Link went down and up Flapping cable or far-end reboots

Late collisions are the signature of a duplex mismatch. On a properly built half-duplex segment a collision must be detected within the first 64 bytes, because the cable is short enough that the signal reaches every station within that time. A collision after 64 bytes therefore means either the cable is illegally long, or the other end is full duplex and transmitting whenever it likes. The side that reports late collisions is the half-duplex side; the full-duplex side reports CRC errors and runts instead.

Rising CRC errors without collisions on a full-duplex link point to the physical layer: a damaged or poorly crimped cable, a run over 100 m, EMI from a motor or fluorescent light, or a dirty fiber connector. Replacing the cable is step one.

Finding and fixing mismatches

The fastest way to spot a mismatch is to compare both ends. show interfaces status shows the negotiated result on a switch, and the a- prefix (for example a-full, a-100) indicates the value was autonegotiated rather than hard-coded:

SW1# show interfaces status
Port      Name           Status       Vlan    Duplex  Speed Type
Fa0/1                    connected    10      half    100   10/100BaseTX
Fa0/2                    connected    10      a-full  a-100 10/100BaseTX
Gi0/1     Uplink to SW2  connected    trunk   a-full a-1000 10/100/1000BaseTX
Gi0/2                    notconnect   1         auto   auto 10/100/1000BaseTX
Gi0/3                    err-disabled 20        auto   auto 10/100/1000BaseTX

Fa0/1 above is hard-coded to half duplex at 100 Mbps (no a- prefix), which is almost certainly a mismatch with the PC on the other end. Cisco IOS also logs a CDP-based warning when it detects a mismatch with a neighboring Cisco device: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/1.

The fix is to make both ends agree, preferably by returning both to auto:

SW1(config)# interface fastethernet 0/1
SW1(config-if)# speed auto
SW1(config-if)# duplex auto
! Or, if policy requires hard-coding, set BOTH ends identically:
SW1(config-if)# speed 100
SW1(config-if)# duplex full
SW1(config-if)# end
! Reset the counters (privileged EXEC) so you can confirm the errors stop
SW1# clear counters fastethernet 0/1