CCNA Interface and Cable Issues: Duplex, Errors, Copper and Fiber Troubleshooting

Start with the interface status and line-protocol status: together they tell you which layer has failed before you look at a single counter. The first word reports the physical layer (is there a signal and a link?); the line-protocol word reports whether the data-link layer is working over it.

Two points are easy to miss. First, a notconnect port tells you nothing about the far end's IP address, VLAN or duplex: those do not stop a link from coming up, so a down/down port is a physical or link-establishment problem. Second, an err-disabled port that goes straight back to err-disabled after shutdown / no shutdown still has its cause attached: whatever tripped the feature (a device the port should not see, too many MAC addresses, a flapping link) is still there. Check the reason with show interfaces status err-disabled or show errdisable recovery and remove the cause first. Automatic errdisable recovery is only a timer that re-enables the port; with the cause still present, the port simply trips again.

SW1# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0/0   198.51.100.9    YES manual up                    up
GigabitEthernet0/1/0   172.16.40.1     YES manual administratively down down
GigabitEthernet0/1/1   172.16.41.1     YES manual down                  down

Useful commands: show ip interface brief (state at a glance), show interfaces status (switch ports: connected/notconnect/err-disabled, VLAN, duplex, speed, type), and show interfaces (full detail and counters).

Each counter in show interfaces points at a different kind of fault, and only some of them point at the cable. Read them as a pattern, compare both ends of the link, and clear them (clear counters) so you know whether they are still rising.

R4# show interfaces gi0/1/2
  Full Duplex, 1000Mbps, link type is auto, media type is RJ45
     0 runts, 0 giants, 0 throttles
     1187 input errors, 1187 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred

In the example, every input error is a CRC error and there are no runts or collisions: corruption on the medium is the first suspect, but you still check the other end before deciding. The practical rule: CRC errors with no collisions on either end suggest the medium (cable, connector, interference); CRC and runts on one end with late collisions on the other suggest a duplex mismatch; overruns, ignored and output drops are capacity problems, so replacing the cable will not help; giants are a frame-size (MTU) problem.

Autonegotiation lets both ends of a copper link advertise what they support and pick the best common speed and duplex. It works only when both ends take part. If one end is hard-set, it stops advertising, and the other end falls back to parallel detection:

• The autonegotiating end can still sense the speed from the signal, so speed normally matches.
• It cannot learn the duplex, so at 10 or 100 Mb/s it defaults to half duplex (IEEE 802.3 behaviour).

The classic result: an engineer hard-sets a switch port to speed 100 and duplex full, the PC is left on auto, the PC comes up at 100 Mb/s half duplex, and you now have a duplex mismatch. The same thing happens in reverse when a device's NIC is fixed and the switch port is on auto: show interfaces status shows the switch port as a-half.

SW1# show interfaces status
Port      Name     Status       Vlan  Duplex  Speed Type
Gi1/0/21  BADGE-RD connected    30    a-half  a-100 10/100/1000BaseTX
Gi1/0/22  LAPTOP22 connected    30    a-full a-1000 10/100/1000BaseTX

The a- prefix means the value was autonegotiated (or sensed); a value without the prefix was configured. a-full a-1000 is a healthy negotiated gigabit link (and a-full a-100 would be an equally healthy negotiated link at 100 Mb/s). a-half on a modern switch port is a warning sign: the peer probably is not negotiating.

The fix is to make both ends agree: either both on auto (the recommended default), or, when one end cannot be changed (firmware or a vendor policy fixes its NIC), hard-set the other end to exactly the same speed and duplex. Configure it under the interface:

SW1(config)# interface gi1/0/21
SW1(config-if)# speed 100
SW1(config-if)# duplex full

Use the peer's actual fixed values (the example assumes a peer fixed at 100 Mb/s full duplex). Two general rules follow from parallel detection: leaving one side on auto against a fixed peer always reproduces the half-duplex fallback, and any speed other than the peer's fixed speed keeps the link down.

A speed mismatch keeps the link down; a duplex mismatch lets the link come up and then corrupts traffic. That difference is the fastest way to tell them apart.

Why the counters split: the half-duplex end follows CSMA/CD and stops transmitting when it hears the other end sending, so it records collisions, many of them late because the full-duplex end sends whenever it likes. The full-duplex end never expects a collision, so it receives the truncated, corrupted frames the half-duplex end abandoned, and counts them as CRC errors and runts.

When you need evidence before dispatching a technician, look for the asymmetric pattern: half duplex reported on one end and full on the other, late collisions on one side and CRC errors only on the other. A damaged cable instead gives CRC errors on both ends with no collisions, or an open pair in a cable test.

When collisions are normal and what late collisions mean

Collisions are normal only on half-duplex shared media, such as several hosts sharing a hub segment or a device that only supports half duplex. A slowly rising collision count there, with no late collisions and no CRC errors, is just CSMA/CD contention. On a full-duplex link there should be no collisions at all, because each direction has its own pair or strand.

A late collision is one detected after the first 64 bytes (512 bit times) of a frame have been sent. A correctly built half-duplex network never produces them, because every station should hear a transmission before that point. Cisco lists the causes as:

• A duplex mismatch: the port is half duplex and the peer is full duplex (the most common cause on a modern network).
• Cabling that exceeds Ethernet length limits on a half-duplex segment: the signal takes too long to reach the far station, so it starts sending before it hears the frame.
• Faulty hardware such as a bad NIC or port.

Once duplex is confirmed to match on both ends of a half-duplex segment, a mismatch is ruled out, so persistent late collisions with few CRC errors point to segment length (then hardware). Interference, MTU mismatches and receive overruns do not create late collisions: they show up as CRC errors, giants and overruns respectively.

Twisted-pair Ethernet has a 100 m channel limit (typically 90 m of permanent horizontal cable plus up to 10 m of patch cords) regardless of category. The category decides which speed the cable carries reliably over that distance.

What exceeding the limits looks like:

• Too long for any copper (any channel past 100 m): the link flaps, drops or logs input/CRC errors. Category and shielding do not raise the 100 m limit, so the options are a different medium (fiber) or an active device that splits the run into legal segments.
• Category too low for the speed (for example Cat6 longer than about 55 m carrying 10GBASE-T): clean at the lower speed, CRC errors or renegotiation down at the higher one. The channel performs at the level of its weakest component, so every part of it (horizontal cable, jacks, patch cords) must be rated for the speed; speed settings cannot change a cable's electrical limits.

Older coaxial Ethernet had its own segment limits (for example 185 m for 10BASE2), but they have nothing to do with modern twisted pair.

Copper Ethernet uses RJ-45 connectors wired to T568A or T568B. A cable with the same standard at both ends is straight-through; a cable with T568A at one end and T568B at the other is a crossover. Which one you need depends on whether the two devices transmit on the same pins.

• Unlike devices (MDI to MDI-X): straight-through. PC to switch, router to switch.
• Like devices (MDI to MDI, or MDI-X to MDI-X): crossover. Switch to switch, hub to switch, PC to PC, PC directly to a router, router to router.
• Console access: a rollover (console) cable from the device's RJ-45 console port to the laptop's DB-9 serial adapter, or a USB console cable where the device has a USB console port. A rollover is not an Ethernet cable.

100BASE-TX uses only two pairs (pins 1-2 and 3-6). 1000BASE-T uses all four pairs, transmitting and receiving on every pair at once. That is why a cable with one broken pair can still pass 100 Mb/s while gigabit fails or will not negotiate, provided the broken pair is one 100BASE-TX does not use (pins 4-5 or 7-8). A break on pins 1-2 or 3-6 stops 100 Mb/s as well.

Auto-MDIX

Auto-MDIX detects the cable type and swaps the transmit and receive pairs internally, so a straight-through cable works between like devices. It is enabled by default on Catalyst switch ports (mdix auto). Two conditions break it:

• no mdix auto (for example from an old hardening template): like devices need a real crossover cable again. Only the pin mapping matters here: shielding and category do not change which pins transmit, and a rollover is a console cable.
• Hard-coding speed and duplex. Cisco's Catalyst configuration guides tell you to leave speed and duplex on auto when you rely on Auto-MDIX; on those platforms, fixing them disables the automatic pair swap, so any link between like devices that was relying on Auto-MDIX (a straight-through cable between two switches, say) goes down/down once fixed speed and duplex are configured.

Time-domain reflectometry (TDR) is a built-in cable test on many Catalyst copper ports: the switch sends a signal down each pair and times the reflection to report whether the pair is normal, open or shorted, and how far from the switch the fault is. It is a two-step process: run the test, then read the result.

SW2# test cable-diagnostics tdr interface gi2/0/33
SW2# show cable-diagnostics tdr interface gi2/0/33
Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- -----------
Gi2/0/33  100M  Pair A     67   +/- 5  meters Pair B      Normal
                Pair B     67   +/- 5  meters Pair A      Normal
                Pair C     67   +/- 5  meters Pair C      Normal
                Pair D     12   +/- 5  meters N/A         Open

How to read it: pairs that reach the far end all report roughly the same length (the cable length), and a pair reported Open at a shorter length is broken that far from the switch; here, pair D about 12 m out, for example at a patch panel or punch-down. Cisco labels pins 1-2, 3-6, 4-5 and 7-8 as pairs A to D, so an open pair C or D leaves the two 100BASE-TX pairs intact: a link may still run at 100 Mb/s while gigabit fails. Repair the cable; leaving the port forced to a lower speed only hides the fault. (A pair reported as Short means conductors touching; the lengths come with a stated tolerance.)

Limits to remember:

• The show command only displays the result of the last test; it does not run a new test.
• TDR is for copper only. On fiber SFP/SFP+ ports the test is not supported; use the optic's digital optical monitoring (show interfaces transceiver) instead.
• On many platforms the test interrupts the link while it runs, so use it on a port that is already down or in a maintenance window.

Optics must match the fiber type and the distance. Multimode fiber has a wide core (50 or 62.5 microns) and is used with short-reach 850 nm optics; single-mode fiber has a narrow core (about 9 microns) and is used with long-reach 1310/1550 nm optics.

The naming helps: SX/SR = short reach, multimode; LX/LR = long reach, single-mode; ER and ZX go further still. Common faults:

• Wrong optic family for the fiber: short-reach multimode optics (SR/SX) are not designed for single-mode fiber, and over kilometre distances the link will not come up even with clean, correctly polarised strands. Long runs on single-mode fiber need single-mode optics rated for the distance.
• Multimode grade too low for the speed: the reach of 10GBASE-SR depends on the fiber's grade (see the table). Beyond it, modal dispersion smears the pulses, so the link logs CRC errors even though light levels are in range. That is a bandwidth limit, not light loss, so cleaning cannot cure it; single-mode optics stay on single-mode fiber, and the way to keep SR optics over a longer run is a higher multimode grade (OM3 or OM4).
• Copper too long or electrically exposed: multimode fiber with short-reach optics covers a few hundred metres in one direct run, which is why it replaces copper runs beyond 100 m and copper between buildings.

Fiber Ethernet links run full duplex at the optic's speed in practice, so a duplex setting does not explain a dark or lossy optical link.

SFP and SFP+ optics with digital optical monitoring (DOM) report temperature, voltage, laser current, and transmit (Tx) and receive (Rx) power in dBm. show interfaces transceiver (add detail for the thresholds) is the main physical-layer evidence for a fiber link.

SW3# show interfaces te1/1/4 transceiver
                                    Optical   Optical
           Temperature  Voltage  Tx Power  Rx Power
Port       (Celsius)    (Volts)  (dBm)     (dBm)
---------  -----------  -------  --------  --------
Te1/1/4    36.8         3.31     -1.7      -10.4 -

Flags next to a value compare it with the optic's thresholds: ++ high alarm, + high warning, - low warning, -- low alarm. dBm is logarithmic, so a more negative number means less light. In the example, Rx carries a low-warning flag (-). Always compare this end's Rx with the far end's Tx:

Too much light is a fault, just like too little: an overloaded receiver produces CRC errors and flaps. Changing the fiber type does not fix it, and single-mode optics must stay on single-mode fiber.

When electromagnetic interference (EMI) from motors, welders, elevators or compressors corrupts frames on unshielded twisted pair (UTP), the symptom is CRC errors on both ends that rise when the noise source runs, with correct speed and duplex and no collisions. Speed, duplex and MTU are not the cause in that pattern.

• Shielded twisted pair (STP/F/UTP) reduces EMI, but only when the shield is correctly grounded through shielded jacks and patch panels. An ungrounded shield gives little protection.
• Fiber is immune to EMI because it carries light, not electrical signals, and it also removes length limits that copper cannot meet.
• Category and jacket ratings are not noise controls: a category describes bandwidth over distance, and plenum is a fire-safety rating for cable in air-handling spaces.

Between buildings, there is a second reason to choose fiber. Separate electrical systems can sit at different ground potentials, and a copper cable (especially a shield grounded in both buildings) bonds them together, driving current through the cable and the equipment. Fiber is non-conductive, so it removes that path entirely, which is why inter-building links are normally fiber.