A cable diagnosis should identify a physical-path boundary, not merely a symptom
An Ethernet cable problem can look like “no network,” intermittent disconnects, unexpectedly low link speed, packet loss, or poor throughput. None of those symptoms uniquely identifies a cable. The stronger method is to define the physical channel, collect evidence that intersects that channel, substitute or test one segment at a time, and then verify that the original failure disappears under comparable conditions.
A physical symptom becomes more useful when it is compared with a known-good path. In the AP Networking Network Components and Media Practice Test, work through cable substitutions, negotiated-rate changes, optical power clues, and CRC-versus-congestion evidence before choosing which component deserves inspection.
This page uses Observation → Physical Boundary → Discriminating Evidence → Controlled Substitution/Test → Smallest Repair → Same-Condition Verification. A successful link light is one checkpoint, not proof that the copper path is healthy.
“The cable” may actually be seven different physical components
In structured cabling, the endpoint-to-switch path can include the NIC, endpoint connector, desk patch cord, wall jack, permanent horizontal cable, patch-panel termination, switch-side patch cord, and switch port. Replacing the visible desk cord tests only one part of that chain.
Endpoint
NIC electronics, connector seating, driver/link behavior, and the short patch cord.
Work-area termination
Wall jack/keystone contact and termination quality.
Permanent link
Installed cable and intermediate termination path.
Closet side
Patch panel, patch cord, and switch interface.
A good isolation plan changes one boundary while keeping higher-layer configuration equivalent. Moving the same endpoint to a known-good jack can be more informative than replacing several components simultaneously.
Match the symptom to the physical evidence it predicts
| Observation | Cable/path hypothesis | Best next evidence | Important alternative |
|---|---|---|---|
| No link | Open path, bad termination, disconnected patch, failed port/NIC | Known-good endpoint/port/cable controls; cable test | Disabled interface or device power/state |
| Link flaps when cable moves | Intermittent connector/conductor contact | Timestamped link events plus controlled replacement | NIC or switch-port mechanical fault |
| CRC/FCS errors rise under load | Corrupted frames somewhere on the physical receive path | Error deltas, peer-side counters, substitution/test | Transceiver/NIC/port or other physical impairment |
| 1 Gbps expected, 100 Mbps negotiated | Pair/termination/path problem is plausible | Known-good jack/path comparison and qualified cable test | Endpoint/port capability or configured negotiation |
| Link stable, clean counters, one website slow | Cable hypothesis weak | Trace higher-layer/application path | DNS, routing, server, congestion, application |
Swipe horizontally to see the full table.
Link down, link up, and link flapping answer different questions
A persistent link-down condition says the interfaces have not established the expected physical link. It does not identify whether the cause is the patch cord, permanent cable, termination, switch port, NIC, power, or administrative state. A stable link-up proves that physical signaling/negotiation succeeded at that moment, but a marginal channel may still pass enough signaling to remain up while data frames are corrupted.
Repeated up/down transitions become stronger when their timestamps match the user's interruptions. If touching or repositioning a patch cord repeatedly coincides with link events, that correlation supports a mechanical-path hypothesis. Still use a known-good replacement or alternate path before declaring the cord uniquely guilty.
14:22:07 Gi1/0/18 link DOWN 14:22:09 Gi1/0/18 link UP 1000/full 14:24:31 Gi1/0/18 link DOWN 14:24:33 Gi1/0/18 link UP 1000/full User report: disconnect occurred at 14:22 and again at 14:24. Next question: which physical component can be changed while preserving the same endpoint and switch configuration?
Error deltas are stronger than lifetime totals—and they still do not uniquely name the cable
An Ethernet Frame Check Sequence allows a receiver to detect a corrupted frame. Interface statistics may expose CRC/FCS-related receive errors. The diagnostic value comes from change during the failure window. A port with 9,000 historical errors but zero new errors during today's problem is weaker evidence than a port whose counter rises by 400 while the user reproduces the failure.
Evidence boundary
Rising CRC/FCS errors support corruption on or near the physical receive path. They do not, by themselves, distinguish the installed cable from a connector, NIC, switch port, or other physical-layer component. Use direction, peer evidence, and substitution to narrow the boundary.
Record a baseline, generate a controlled workload, record the new value, and calculate the delta. Then repeat after the repair under similar conditions.
An unexpected link rate is a clue only after you establish what both ends should support
If a gigabit-capable endpoint and switch normally establish 1 Gbps but one wall path repeatedly establishes only 100 Mbps, the physical channel deserves attention. The inference becomes stronger when the same endpoint and patch cord achieve the expected rate on a nearby known-good path, and another known-good endpoint also falls to 100 Mbps on the suspect path.
Do not memorize “100 Mbps means bad cable.” Device capability, switch configuration, adapter settings, and negotiation behavior can also explain a lower rate. The useful evidence is the controlled difference between otherwise comparable paths.
| Test | Result | Inference |
|---|---|---|
| PC-A + cord A → Jack 14 | 100 Mbps | Problem still broad |
| PC-A + cord A → Jack 15 | 1 Gbps | PC-A and cord A can achieve expected rate elsewhere |
| PC-B + cord B → Jack 14 | 100 Mbps | Suspicion shifts toward Jack-14 path/termination |
| Qualified test of Jack 14 permanent link | Fault identified | Direct physical evidence localizes repair |
A known-good replacement is powerful only when you know exactly what changed
“I swapped the cable and it worked” can be good evidence, but ask what the swap actually changed. Did you replace only the desk patch cord? Did you move to another wall jack, thereby changing the permanent cable and closet termination? Did you also move switch ports? Each version isolates a different boundary.
For a clean experiment, preserve endpoint configuration, VLAN, destination, workload, and observation interval whenever possible. Change one physical dependency. If the symptom follows the component, that is stronger than a test in which five dependencies changed together.
Continuity, wire-map, length/fault location, and certification are not interchangeable tests
Different testers answer different questions. A basic wire-map/continuity tool can reveal opens, shorts, reversals, or pair mapping problems. More capable instruments may estimate distance to a fault. Certification-class testing evaluates an installed link against the performance requirements of a cabling category/standard using measurements beyond simple continuity.
Wire map
Useful for conductor continuity and termination mapping. Passing it does not prove full high-speed performance.
Fault distance
Can help localize where along a path a discontinuity/reflection is suspected, depending on tester capability.
Certification
Provides much stronger evidence about whether an installed link meets the relevant performance specification.
The exam principle is simple: choose a tool whose measurement answers the unresolved physical question. Do not claim that a cheap continuity pass proves a cable can reliably carry the intended Ethernet service.
Interface errors are observed at a receiver, so use both ends to reason about direction
If Switch Port 18 reports receive CRC errors, the switch is detecting corrupted frames arriving toward that interface. That observation intersects the endpoint-to-switch receive direction. Peer-side statistics can add another view. Directional evidence does not magically identify one conductor, but it helps prevent the vague conclusion that “the network has errors.”
When both directions show physical symptoms, consider dependencies shared by the channel. When only one receiver accumulates errors, compare the transmitter, receiver, connectors, and path used in that direction before replacing unrelated higher-layer configuration.
Power problems and data problems can share a cable but produce different evidence
A powered Ethernet device can fail because it is not receiving expected power, because its data link is unhealthy, or because both functions are affected by the physical path. A device that will not power at all creates a different first question from a powered device whose Ethernet link flaps or accumulates errors.
Keep the evidence streams separate: power-delivery state, device boot/power behavior, Ethernet link state, negotiated rate, and data errors. A cable replacement that restores both is useful, but the explanation should still identify which requirement failed and what the before/after evidence demonstrated.
Five common “bad cable” reports that can originate somewhere else
No Internet
A healthy Ethernet link can coexist with DHCP, gateway, DNS, routing, firewall, or WAN failure.
Slow downloads
Congestion, server limits, Wi-Fi elsewhere in the path, or application behavior can dominate performance.
Intermittent access
Duplicate IPs, DHCP changes, switching loops, or application failures can be intermittent without a cable fault.
One service fails
Exact-flow firewall policy or server listener state is usually a stronger branch than physical replacement.
Port down
Administrative shutdown, device power, NIC failure, or switch-port failure can resemble an open cable.
Movement-triggered link flaps isolate a desk-side component
A desktop loses connectivity whenever its desk is moved. Switch logs show link-down/up events at the same timestamps. The interface returns at the expected speed and has few data errors between events. The technician replaces only the desk patch cord while keeping the endpoint, wall jack, switch port, VLAN, and workload unchanged. Repeated movement no longer causes a link event.
The conclusion is stronger than “wiggling means cable.” Timestamp correlation established the physical symptom, controlled substitution changed one component, and the original trigger was repeated during verification.
Replacing the patch cord does not fix a damaged termination
A classroom workstation accumulates receive errors under sustained transfer. A new desk patch cord changes nothing. The same workstation and cord operate cleanly on a nearby known-good jack. A second known-good endpoint also accumulates errors on the original jack. Testing then identifies a fault associated with the original terminated path.
The important reasoning is the sequence. The failed patch-cord substitution prevents premature closure; the alternate-jack control preserves the endpoint; the second endpoint reduces the chance of blaming one NIC; the physical test then localizes the repair.
A stable link and clean error counters falsify the cable hypothesis
A user reports that a cloud application is slow. The Ethernet interface remains stable at the expected rate. CRC/FCS and other physical error counters do not increase during reproduction. Local file transfer to a nearby server performs normally, while the remote application remains slow.
Those observations do not prove every centimeter of cabling is perfect, but they make a cable fault a poor explanation for the specific failure. The next investigation should follow the dependencies unique to the remote application rather than replacing physical infrastructure without evidence.
A lower negotiated rate follows one wall path, not the endpoint
A gigabit-capable laptop repeatedly negotiates 100 Mbps at Jack 14 and 1 Gbps at Jack 15 using the same adapter and patch cord. A second known-good laptop shows the same difference. The switch interfaces are configured equivalently. This is a high-information comparison because the result follows the wall path across two endpoints.
The next step is not to declare “bad Cat cable” from speed alone. Test the permanent link and its terminations to identify the actual physical defect and verify the repaired path at the expected rate and under load.
For faults that disappear, build a timeline before the next occurrence
Intermittent physical faults are easy to erase by rebooting, reseating, or moving equipment. If the problem recurs, collect switch link events, negotiated speed, relevant error-counter snapshots, user timestamps, and any physical trigger such as movement or temperature/environment change. Compare a failing window with a healthy window.
Prepare the capture
If you cannot reproduce the fault now, decide in advance which port counters and logs must be captured when it returns. Troubleshooting can advance even when the final cause is not yet known.
Rank physical evidence by how directly it intersects the failed requirement
| Evidence | Strength | Boundary |
|---|---|---|
| User says “cable is bad” | Low specificity | Defines reported symptom only |
| Link event matches outage time | Moderate | Physical/link state intersects failure |
| CRC/FCS delta rises during reproduction | Moderate–strong | Corruption detected at receiving interface |
| Symptom follows one physical segment in controlled substitution | Strong | Narrows component/path |
| Qualified physical test identifies fault | Strong/direct | Localizes physical defect according to tester capability |
| Repair removes fault and original workload succeeds | Verification | Connects correction to requirement |
Swipe horizontally to see the full table.
Make the smallest physical change justified by the evidence
If a known-bad patch cord is isolated, replace that cord. If a termination is defective, repair the termination. If the permanent link fails an appropriate test, correct that path. Avoid simultaneously changing the NIC, switch port, wall jack, patch cords, VLAN, and IP configuration; doing so may restore service while destroying your ability to explain what fixed it.
Broad replacement is sometimes operationally necessary, but for AP Networking reasoning the goal is to connect each action to a demonstrated boundary.
Prove stable link, expected capability, clean behavior, and the original user task
| Verification target | Test | Success condition |
|---|---|---|
| Link stability | Observe across prior trigger/recurrence window | No unexpected up/down transitions |
| Negotiation | Check rate/duplex against intended capability | Expected state remains stable |
| Error behavior | Snapshot counters before/after comparable load | Relevant physical-error counters do not continue rising abnormally |
| Original requirement | Repeat the application/file-transfer/task that failed | User task succeeds under comparable conditions |
| Control | Keep a known-good comparison where useful | Repair behaves consistently with healthy path |
Write the answer as evidence → physical mechanism → discriminating test → verification
Evidence: “The endpoint's link repeatedly drops when the patch cord is moved, and switch link-event timestamps match the user's outages.” Mechanism: “That pattern supports an intermittent physical connection somewhere in the moved portion of the path.” Next test: “Replace only the patch cord with a known-good cord while preserving the endpoint, jack, switch port, and configuration.” Verification: “Repeat the movement trigger and workload, then confirm stable link and non-increasing physical-error counters.”
This answer is stronger than “replace the Ethernet cable” because it states what is known, what remains uncertain, why the next test is discriminating, and what result would count as success.
24 network-cable failure flashcards
Use these cards to practice evidence boundaries, link-state reasoning, CRC/FCS interpretation, negotiated speed, controlled substitution, cable testing, differential diagnosis, and verification.