Field Guide · Networking
A misconception is a false belief about what a signal proves — and each one sends root-cause analysis down the wrong branch. This guide pairs the common network myths with the mechanism that refutes them and the wrong call each one causes, so you spend your bisection steps on evidence rather than folklore. It's the counterweight to the rest of the Networking family: those guides say how things work; this one catches the beliefs that survive anyway.
Every diagnostic check proves exactly one narrow thing. A misconception is what happens when you credit a check with proving more than it does — "ping worked, so the network's fine" — and act on the inflated belief. The cost is always the same: you skip the step that would have found the fault, and chase the one that wouldn't. The fix is equally consistent: state what each signal actually proves, and confirm the next thing rather than assuming it.
Troubleshooting is bisection: you split the path, test one point, and let the result tell you which half to keep. That only works if you read each result for what it proves and no more. A misconception corrupts the read — it treats a narrow "yes" as a broad one — so the bisection branches the wrong way and every step afterward is spent in the wrong half. The myths below are grouped by the signal they misread; in each case the pattern is the same three parts: the belief, the mechanism that refutes it, and the wrong call it produces.
Myth: a signal is credited with proving something it doesn't. Mechanism: why the signal is narrower than the belief. Wrong call: the branch you take, and the fault you therefore miss. Read them as inoculation — you'll recognise the pull of each one mid-incident.
"Ping works, so it's fine." Ping proves ICMP round-trips to the host — Layer 3 reachability and rough latency, nothing more. The port may be closed, the service down, the TLS cert expired, the app throwing 500s. Wrong call: you tell the user "the network's fine" and stop, when the fault is one layer up.
"Ping fails, so the host is down." ICMP is frequently filtered while the actual service is perfectly reachable. Wrong call: you declare an outage and escalate to the wrong team, when a TCP connect to the real port would have succeeded.
"That middle hop has high latency — there's the problem." A latency spike at an intermediate traceroute hop that does not carry through to the final hop is the router de-prioritising ICMP to its own control plane, not real forwarding delay. Only loss or latency that persists to the destination is real. Wrong call: you open a ticket on a transit router that's forwarding your traffic perfectly.
"Packet loss means a bad cable or link." Loss is equally produced by congestion, a policer or shaper, buffer exhaustion, or a duplex mismatch. Wrong call: you replace hardware while an oversubscribed uplink keeps dropping.
"It's always DNS." Often it is — but the belief becomes a trap when it replaces the check. The discipline is to find out which resolver answered and whether it matches the authoritative record, not to assume DNS and restart the resolver. Wrong call: you flush caches and move on, when the divergence was a stale record you never compared against the authoritative server.
"The DNS change hasn't propagated yet." There is no propagation. A change is immediate at the authoritative server; the delay you see is caches holding the old answer until their TTL expires (and negative answers are cached too). Wrong call: you "wait for propagation" for hours instead of lowering the TTL ahead of the change and querying the authoritative server to confirm it's already correct.
"The certificate is expired." Maybe — but a wrong client clock fakes an "expired" or "not yet valid" error on a perfectly good certificate. Wrong call: you reissue a valid cert while the real fault is unsynced time (check NTP on both ends first).
"It's HTTPS, so the site is safe." TLS encrypts the channel and authenticates the name — it does not vouch for the site's intent or protect the endpoints. A phishing site can serve flawless TLS. Wrong call: you treat the padlock as a trust verdict, when it only attests that you're talking to the name you asked for over an encrypted channel.
"Private (RFC 1918) addresses are a security boundary." Private ranges are an addressing scope — a decision about which addresses route on the public internet — not a security control. Traffic reaches private hosts constantly, via routing, VPNs, and compromised internal hosts. Wrong call: you treat "it's on a 10.x address" as protection and skip the access control that actually enforces the boundary.
"NAT is a firewall." NAT translates addresses; the fact that unsolicited inbound often can't be mapped is a side effect, not a policy. Stateful filtering is a separate function that usually rides on the same box but is configured independently — and in IPv6, where there's typically no NAT, the firewall is unmistakably the boundary. Wrong call: you rely on NAT for security, leave the firewall permissive, and are surprised when the IPv6 path (or a port forward) is wide open.
"It's reachable, so it's allowed." The route table decides reachability; a packet arriving at a destination says nothing about whether it should be permitted there — that's the firewall's and zero trust's job. Wrong call: you conclude a control is missing because traffic flows, when reachability and authorization are simply different questions.
Each of these credits a mechanism built for one purpose (address scoping, address translation, forwarding) with a security property it was never designed to provide. Name the threat you actually want stopped and the control that stops it — don't infer safety from an addressing or forwarding artifact.
"It's slow — we need more bandwidth." Bandwidth is capacity; much of what users call "slow" is latency, and the two are independent. A single TCP stream on a high-bandwidth, high-RTT path is limited by the window and the bandwidth-delay product, not the link — parallel streams that suddenly saturate it prove the link had room all along. A duplex mismatch throttles throughput regardless of link speed. And QoS only acts at the point of congestion; it reorders traffic under contention, it does not create bandwidth. Wrong call: you buy a bigger pipe that does nothing, because the limiter was RTT, a window, or a half-duplex port.
"It must be the firewall." The reflexive blame. A blocked-looking symptom is equally produced by a missing route, a service bound to loopback (which refuses remote clients with a reset), an MTU black hole (small packets pass, large ones vanish), a DNS failure, or the service simply being down. Wrong call: you escalate a firewall change request while a one-line ss/netstat would have shown the service listening only on 127.0.0.1. The firewall is one hypothesis; make it earn its place with a check, not a reflex.
"It worked yesterday, so nothing changed." Plenty changed without anyone touching it: a certificate crossed its expiry, a DHCP lease or reservation lapsed, a cached record's TTL flipped it to a new answer, a scheduled task fired, a table or disk filled, a capacity ceiling was reached. "Nothing changed" almost always means "nothing I changed." Wrong call: you rule out change and hunt for a brand-new fault, missing the scheduled or threshold event that was always going to trip.
"It's not in the capture, so it was never sent." A capture only ever sees what crossed that point. A SPAN port drops frames under load, a small snaplen truncates payloads, a full buffer loses packets, and NAT or a proxy rewrites addresses so the endpoints you see aren't the real ones. Absence of a packet is not proof the event didn't happen — only that it didn't cross your capture point. Wrong call: you declare the sender at fault when your vantage simply missed the traffic; capture closer to the problem before concluding.
The whole set on one page — belief, the mechanism that refutes it, and the wrong call it produces:
| Myth | Mechanism (reality) | Wrong call it causes |
|---|---|---|
| Ping works → it's fine | ICMP proves L3 reachability only; port, service, TLS, authorization all unproven | "Network's fine," stop one layer too low |
| Ping fails → host down | ICMP is often filtered while the service is reachable | False outage, wrong escalation |
| High middle-hop latency → the fault | Routers deprioritize ICMP to their control plane; only end-to-end counts | Ticket on a healthy transit router |
| Packet loss → bad cable | Also congestion, a policer, buffers, or a duplex mismatch | Swap hardware, miss the oversubscribed uplink |
| It's always DNS | Confirm which resolver answered vs the authoritative record | Flush and move on, miss a stale record |
| DNS is still propagating | No propagation; caches expire per TTL | "Wait hours" instead of lowering TTL + querying authoritative |
| The cert is expired | A wrong client clock fakes expiry on a good cert | Reissue a valid cert, miss NTP skew |
| HTTPS → safe | TLS secures the channel and the name, not intent or endpoints | Treat the padlock as a trust verdict |
| RFC 1918 → a security boundary | Addressing scope, not a security control | Skip the access control that actually enforces it |
| NAT → a firewall | Translation isn't policy; IPv6 typically has no NAT | Permissive firewall; open IPv6 path or port-forward |
| Reachable → allowed | Routing decides reachability, not authorization | Wrong conclusion about whether a control exists |
| Slow → need bandwidth | Often latency, TCP window/BDP, or duplex; QoS doesn't add bandwidth | Buy a bigger pipe that changes nothing |
| It must be the firewall | Also bind address, MTU black hole, route, DNS, or service down | Firewall change request while the service sits on loopback |
| Worked yesterday → nothing changed | Silent expiries, leases, TTLs, schedules, thresholds | Hunt a new fault, miss the event that was always going to trip |
| Not in the capture → never sent | Capture sees one vantage; SPAN loss, snaplen, rewriting | Blame the wrong side for missing traffic |
The reason these matter is mechanical: one misread signal branches the whole investigation the wrong way.
The antidote is a short habit, not a longer checklist: state what each signal actually proves before you act on it; confirm the next rung rather than assuming it (test the port, compare against the authoritative record or a known baseline); read the last hop, not the worst hop; and change one thing reversibly, so a wrong guess costs a rollback rather than a second incident. Every myth above falls to the same move — refuse to let a narrow "yes" stand in for a broad one.
Every check proves one narrow thing. A misconception credits it with more, so root-cause analysis branches the wrong way and every step after is wasted. Belief → mechanism → wrong call.
Ping ≠ app works. "Always DNS" → confirm resolver vs authoritative. Expired cert → check NTP first. HTTPS ≠ safe. NAT / RFC 1918 ≠ security. Reachable ≠ allowed. Slow ≠ more bandwidth. "The firewall" is a hypothesis, not a default.
State what each signal proves. Confirm the next rung; don't assume it. Read the last hop. Compare to the authoritative record or a baseline. Change one thing, reversibly.
These corrections are stable, well-established network behaviour, and each is developed in the guide that owns it: resolver-vs-authoritative and TTL in DNS; clock skew and "HTTPS attests the channel and the name, not intent" in TLS & Certificates; "private range is a scope, not a boundary" in Subnetting & CIDR; "reachability is not authorization" in IP Routing; ping and traceroute semantics and the port/loopback checks on the Diagnostic Command Card; and capture vantage limits in the Networking coverage of captures. The confirming checks live on the Command Card, and the Triage Decision Trees sequence them. No unqualified assurance is intended — the recurring lesson is exactly that reachability, encryption, and address scope are not security or health verdicts: name the threat and the control that addresses it. Terms are in the Glossary; 00 · Start Here indexes the set.