Hardware tools and device commands

Why this matters

This is the final lesson and the domain 5 capstone. It covers the two things software cannot do for you: the physical instruments that diagnose a cable, and the commands that make a switch or router tell you what it believes.

The hardware tools are the part self-taught candidates are weakest on, because you cannot practise them in a VM — which is exactly why CompTIA examines them. Each one answers a specific question, and knowing which instrument answers which question is the whole objective.

The lesson

Toner and probe

A toner (tone generator) and its matching probe are how you find which cable is which. The generator injects an audible tone onto a conductor at one end; the probe, waved over cables at the other end, sings when it finds the one carrying it.

Use it when you have a bundle of unlabelled cables and need to identify one — the punch-down in a patch panel that corresponds to a wall outlet, or which of forty cables in a ceiling void goes where.

It tells you identity, not quality. A cable you have successfully toned may still be broken, miswired or too long. And it is a physical-layer tool only: do not connect it to a live switch port.

The related instrument is a fox and hound, which is the same idea by another name.

Cable tester

A cable tester verifies a cable's electrical correctness. The basic kind checks continuity and pinout — that each of the eight conductors is connected end to end and in the right position — and will detect opens, shorts, reversed pairs and crossed pairs.

That catches most termination errors, and it misses one important class. A basic continuity tester will pass a split pair, because every pin maps correctly to the right pin at the far end; only the pairing is wrong. Detecting that needs a tester that measures crosstalk.

Which brings in the tiers:

• A verifier checks continuity and wiring map. Cheap, adequate for finding a gross fault.
• A qualifier additionally tests whether the cable supports a given speed.
• A certifier measures the full set of parameters the standard demands — crosstalk, attenuation, return loss, delay skew — against the category's limits, and produces the pass/fail report an installer is contractually required to supply. Expensive, and the only instrument that can prove a run is Cat 6a rather than assert it.

A TDR (time-domain reflectometer) deserves a mention because it answers a question nothing else does: it sends a pulse and times the reflection, so it reports the distance to a fault. "There is a break 43 metres along" turns pulling up an entire run into opening one ceiling tile. The optical equivalent is an OTDR.

Visual fault locator

A visual fault locator injects visible red laser light into a fibre. Where the fibre is broken, sharply bent or badly terminated, light escapes and glows visibly through the jacket.

It is the cheapest and fastest fibre diagnostic there is, and it answers questions an OTDR struggles with: it finds faults very close to the connector, which fall inside an OTDR's dead zone, and it confirms continuity along a patch lead in seconds. It also identifies which strand is which — inject at one end and look for the glow at the other.

What it does not do is measure. It shows you a break; it does not tell you the loss budget. Pair it with an optical power meter for that, and remember the transceiver's own signal strength reading from lesson 40 often makes a meter unnecessary.

Safety: never look directly into a fibre or a VFL. Even visible laser light at these powers can damage the eye, and infrared transmission light is invisible and more dangerous for exactly that reason.

Wi-Fi analyzer

A Wi-Fi analyzer shows what is happening in the radio spectrum: which networks are present, on which channels, at what signal strength, and how congested each channel is.

It is the tool for the wireless problems in the previous lesson. It identifies channel overlap by showing several APs on the same or adjacent channels; it measures signal strength in dBm so coverage gaps become numbers rather than opinions; and it reveals neighbouring networks competing for your spectrum.

Its limitation is that it sees 802.11 traffic. A microwave oven, a cordless phone or a video sender causes real interference and shows up as poor performance with no visible network to blame. Identifying non-Wi-Fi interference needs a spectrum analyzer, which looks at raw radio energy rather than decoded frames. If a channel performs badly and the Wi-Fi analyser shows it as quiet, that gap is the clue.

Taps

A tap is a passive hardware device inserted into a link that copies traffic to a monitoring port.

Compared with the port mirroring from domain 3:

• A tap cannot drop frames. A mirror session can, when the destination port has less capacity than the sources — and a capture that silently lost frames looks exactly like packet loss on the network, which is the worst kind of wrong answer.
• A tap does not consume switch resources.
• A passive optical tap keeps working if it loses power, so inserting one does not create a new point of failure.
• It sees everything on that link, including errors and malformed frames a switch might not forward.

The costs: it must be physically installed in the path, which means taking an outage to fit it, and it sees only the one link it is on.

The rule: mirror for a quick, temporary look; tap for permanent monitoring or for anything where the capture must be provably complete — security monitoring, or evidence.

Basic networking device commands

The show commands are how you ask a device what it believes to be true, and the answers are frequently different from what you assumed.

show interface — the workhorse. Status (up/down, administratively down, err-disabled), speed and duplex, and the error counters from lesson 40. This is where you see CRC errors, runts, giants, drops and collisions, and where you confirm whether they are increasing.

show mac-address-table — which MAC addresses the switch has learned and on which ports. Use it to find where a device physically is, to confirm a device is present at layer 2, and to spot a MAC appearing on an unexpected port or flapping between ports, which indicates a loop or a duplicate.

show route — the routing table. Read it with the selection order from domain 2: longest prefix first, then administrative distance, then metric. Use it to confirm a route exists, to see which route will actually be used, and to check that the default route is present and points somewhere sensible.

show arp — the device's own IP-to-MAC mappings. The same diagnostic value as arp -a on a host: confirms layer 2 reachability, exposes duplicate addresses, and reveals poisoning.

show vlan — which VLANs exist and which ports belong to each. The first command to run for the incorrect VLAN assignment fault: it shows immediately whether a port is in the VLAN you believed, or sitting in VLAN 1 because nothing was configured.

show config — the running configuration. What the device is actually doing, as opposed to what the documentation says or what was intended. Comparing it against the golden configuration from domain 3 is how configuration drift is found, and comparing it against a backup taken before a change is how you answer "what changed?".

show power — power status, and specifically the PoE budget and its allocation. This is the command that diagnoses the "devices boot and then reset" fault from lesson 40, by showing available budget against what is drawn.

Choosing the right instrument

The objective is about appropriateness, so the summary is a mapping from question to tool:

The habit that underlies all of it, and the one worth carrying out of this course: measure before you replace. Almost every expensive troubleshooting mistake is a component swapped on a theory that one of these tools would have disproved in a minute.