Domain 5 capstone — troubleshoot the network you built

capstone · 150 min · Objective 5.5

Task

Take the network you built in domain 2, operated in domain 3 and secured in domain 4, and troubleshoot it under fault. A partner injects one fault from each domain-5 category; you drive each through CompTIA's seven-step methodology, reach for the right diagnostic tool, and document it. This is the whole course exercised at once, and it is the last lab.

Steps

  1. Set the ground rule. The partner injects exactly one fault per round and records what it was on a card. You do not see the card until you have stated your diagnosis, so the methodology is tested honestly.
  2. Physical (5.2). A duplex mismatch or rising errors on one link. Identify it by reading increasing interface counters with ip -s link and ethtool, and name the counter family — CRC for corruption, drops for congestion.
  3. Services (5.3). An addressing, routing, switching or ACL fault — wrong mask, missing default route, wrong VLAN, or a shadowed ACL rule. Diagnose by symptom: some hosts not others, internal-works-internet-does-not, up-but-wrong- network, or one-port-fails-everything-else-works.
  4. Performance (5.4). A shaped link adding latency or loss. Measure with ping and iperf, decide whether it is bandwidth, latency, jitter or loss, and locate the bottleneck rather than guessing.
  5. Methodology throughout. For every round: identify the problem, form and test a theory before fixing, plan the fix and its effects, implement, verify full functionality, and document — in order, no skipping ahead.
  6. Tool discipline. For each fault, note which diagnostic answered it — ping, traceroute, dig, ip/ethtool, the show commands, iperf — and which physical instrument you would have reached for on real hardware.
  7. Report. Produce a fault log: symptom, methodology step that identified the cause, tool used, fix, and verification, one row per round.

Verify

ping -c 20 -q 192.168.20.10 | tail -2
ip -s link show eth0 | grep -A1 RX:
ip route show; ip neigh show | awk '{print $5}' | sort | uniq -d
diff <(sort /tmp/faults-injected.txt) <(sort /tmp/faults-diagnosed.txt); echo "all diagnosed exit $?"

Connectivity restored, a clean interface counter, a sane route table and no duplicate MAC together show the network is healthy again after each round. The final diff is the capstone's real pass condition: every fault the partner injected has a matching row in your diagnosed list. An empty diff means you found them all — and found them, not stumbled onto the fix.

Notes

Three habits this capstone is built to instil, all of them exam content.

Test the theory before you fix. The most common wrong answer in domain 5 is a perfectly good action taken from a later step — implementing a fix before the theory is confirmed. Under fault, the pull to skip ahead is strongest, which is why practising the order against a real fault beats reciting it.

Read the counter, do not guess the cause. Drops and CRC errors both present as "slow" and need opposite fixes. The single most valuable reflex in this domain is to look at which counter is climbing before touching anything.

Measure before you replace. Nearly every expensive troubleshooting mistake is a component swapped on a theory one of these tools would have disproved in a minute. Carry that out of the course: the instruments and commands exist so you change what is broken, not what is easiest to blame — and you now have the whole network, built and secured and diagnosed, to prove you can.