The connectivity ladder: link to application

A user says the internet is slow. A ping to the router answers in 1 ms, a ping to 1.1.1.1 takes 220 ms, and a speed test reports 300 Mbit/s. Three numbers tell three different stories while the user waits, so which test do you run next, and which result do you believe?

The answer is an order. This lesson gives you a ladder of seven checks, from the cable to the application, and the rule to stop at the first one that fails. You will learn what ping, Test-NetConnection, curl -v and traceroute each prove and what they cannot, how to tell a narrow link from a lagging one from a choppy one with numbers, and how to decide whether a fault belongs to one user, one site or everyone before you change a setting.

Seven rungs, tested from the bottom, stop at the first failure

“No internet” is one symptom with at least seven causes: an unplugged cable, no address, a dead router, a broken provider link, a name that does not resolve, a blocked port, or an application that fails on its own. Test them lowest first. A rung only works when every rung under it works, so the first rung that fails is where you look.

The program further down prints the macOS and Linux commands beside each of these.

Two rungs need a closer look. At rung 2, an address that starts with 169.254 is an APIPAAPIPA: Automatic Private IP Addressing, Windows' name for the IPv4 link-local range 169.254.0.0/16 defined by RFC 3927, which an adapter uses when DHCP cannot reach a server and which allows communication only on the same physical link. More in “Windows command line for support work” address: RFC 3927 describes how a host gives itself one when no DHCP server answered, valid only on the same link. The cable is fine but nobody leased the client an address, so look at DHCP, not DNS. At rung 3, the default gatewaydefault gateway: The router address on a host's own subnet that receives every packet bound for another network. Without a default gateway, traffic cannot leave the subnet; DHCP hands it out as the router option of a lease. More in “How a device gets online: IP, DHCP and DNS” is the router every non-local packet goes to; a client that cannot reach it cannot reach anything beyond.

Step through the seven rungs, then through two tickets. The first stops at rung 2 and the second at rung 6, and the later rungs in each are never tested:

Rung 6 settles most arguments. Test-NetConnection with -Port tries a real TCP connection and reports TcpTestSucceeded as True or False; Microsoft says the cmdlet supports a “ping test, TCP test, route tracing, and route selection diagnostics”. When it fails, curl -v shows how: a connection that is refused means a host answered and nothing listens on that port, while one that times out means nothing answered, which is how a firewall that drops packets looks. The curl manual documents -v as the verbose switch.

The program below climbs the ladder for four invented tickets. Rung 2 uses the ipaddress module; rung 6 reads representative samples of Test-NetConnection and curl -v output, written in the style of Microsoft Learn and curl’s manual, with 203.0.113.10, an address reserved for documentation, so neither sample comes from a real server:

"""Walk the seven-rung connectivity ladder and name the first rung that fails, with the next command to run.

Four invented tickets are checked bottom-up. Rung 2 uses the ipaddress module on the address a client reports.
Rung 6 reads two representative samples: the output of Test-NetConnection (PowerShell) and of curl -v. The
samples use 203.0.113.10, an address reserved for documentation (RFC 5737), and follow the layouts on
Microsoft Learn and in curl's manual; they are written for this lesson, not captured from a real server.
"""

import ipaddress
import re

# rung number, id, the question, what to do at this rung, then one command each for Windows, macOS and Linux
RUNGS = [
    (1, "link", "Is the link up on the interface?", "check the cable, the switch, the Wi-Fi network",
     "Get-NetAdapter", "ifconfig en0", "ip link show"),
    (2, "address", "Is the address valid (not 169.254)?", "renew the lease and check the DHCP server",
     "ipconfig /all", "ipconfig getifaddr en0", "ip -4 addr show"),
    (3, "gateway", "Does the gateway answer a ping?", "check the local network: Wi-Fi signal, cable, switch",
     "ping 192.168.1.1", "ping -c 4 192.168.1.1", "ping -c 4 192.168.1.1"),
    (4, "outside", "Does an outside address answer?", "the fault is past the router: its WAN side or the ISP",
     "ping 1.1.1.1", "ping -c 4 1.1.1.1", "ping -c 4 1.1.1.1"),
    (5, "name", "Does a name resolve?", "troubleshoot DNS: the resolver, the cache, the records",
     "Resolve-DnsName example.com", "dscacheutil -q host -a name example.com", "getent hosts example.com"),
    (6, "port", "Does the service port open?", "read the curl -v failure: refused or timed out",
     "Test-NetConnection example.com -Port 443", "nc -vz example.com 443", "nc -vz example.com 443"),
    (7, "app", "Does the application work?", "read the application's own error, account and logs",
     "curl -I https://example.com", "curl -I https://example.com", "curl -I https://example.com"),
]

TNC_CLOSED = """\
WARNING: TCP connect to (203.0.113.10 : 443) failed
ComputerName           : example.com
RemoteAddress          : 203.0.113.10
RemotePort             : 443
InterfaceAlias         : Wi-Fi
SourceAddress          : 192.168.1.23
PingSucceeded          : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded       : False
"""

TNC_OPEN_NO_PING = """\
ComputerName     : example.com
RemoteAddress    : 203.0.113.10
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.23
PingSucceeded    : False
TcpTestSucceeded : True
"""

CURL_TIMEOUT = """\
*   Trying 203.0.113.10:443...
* Connection timed out after 5002 milliseconds
* Closing connection
curl: (28) Connection timed out after 5002 milliseconds
"""

CURL_REFUSED = """\
*   Trying 203.0.113.10:443...
* connect to 203.0.113.10 port 443 from 192.168.1.23 port 50599 failed: Connection refused
* Failed to connect to example.com port 443 after 0 ms: Couldn't connect to server
curl: (7) Failed to connect to example.com port 443 after 0 ms: Couldn't connect to server
"""

TICKETS = [
    {"title": "A: no internet on the guest Wi-Fi", "adapter": "Up", "ip": "169.254.121.8"},
    {"title": "B: the booking site will not load", "adapter": "Up", "ip": "192.168.1.23", "gateway": True,
     "outside": True, "names": ["203.0.113.10"], "tnc": TNC_CLOSED, "curl": CURL_TIMEOUT},
    {"title": "C: the server never answers a ping", "adapter": "Up", "ip": "192.168.1.23", "gateway": True,
     "outside": True, "names": ["203.0.113.10"], "tnc": TNC_OPEN_NO_PING, "http": 200},
    {"title": "D: sites by IP work, by name they do not", "adapter": "Up", "ip": "192.168.1.23", "gateway": True,
     "outside": True, "names": []},
]


def address_ok(text):
    """A usable client address is not link-local (169.254.0.0/16), not unspecified and not a loopback."""
    ip = ipaddress.ip_address(text)
    return not (ip.is_link_local or ip.is_unspecified or ip.is_loopback)


def tnc_value(text, field):
    found = re.search(rf"^{field}\s*:\s*(True|False)", text, re.MULTILINE)
    return found is not None and found.group(1) == "True"


def curl_reason(text):
    """What a failed curl -v says about the failure: silence means a drop, a refusal means a closed port."""
    if "Connection refused" in text:
        return "refused: the host answered and nothing listens on that port"
    if "timed out" in text:
        return "timed out: nothing answered, so a firewall or filter probably drops the packets"
    return "no failure found in the output"


def check(rung, t):
    """The result of one rung for one ticket."""
    if rung == "link":
        return t["adapter"] == "Up"
    if rung == "address":
        return address_ok(t["ip"])
    if rung in ("gateway", "outside"):
        return t.get(rung, False)
    if rung == "name":
        return len(t.get("names", [])) > 0
    if rung == "port":
        return tnc_value(t.get("tnc", ""), "TcpTestSucceeded")
    return 200 <= t.get("http", 0) < 400


def climb(t):
    """Bottom-up: return the first failing rung, or None when every rung passes."""
    for number, rung, question, *_ in RUNGS:
        passed = check(rung, t)
        print(f"  rung {number} {rung:<8} {'pass' if passed else 'FAIL'}  {question}")
        if not passed:
            return RUNGS[number - 1]
    return None


for ticket in TICKETS:
    print(ticket["title"])
    failed = climb(ticket)
    if failed:
        number, rung, question, then, windows, mac, linux = failed
        print(f"  -> stop at rung {number}: {then}")
        print(f"     run: {windows}   |   {mac}   |   {linux}")
        if rung == "port" and "curl" in ticket:
            print(f"     curl -v says: {curl_reason(ticket['curl'])}")
    else:
        print("  -> every rung passes: nothing on the path is at fault")
        if "tnc" in ticket and not tnc_value(ticket["tnc"], "PingSucceeded"):
            print("     the ping failed, yet the port opened: the server drops ICMP, and rung 6 is the stronger test")
    print()

print("The same curl -v run against a closed port:", curl_reason(CURL_REFUSED))

A: no internet on the guest Wi-Fi
  rung 1 link     pass  Is the link up on the interface?
  rung 2 address  FAIL  Is the address valid (not 169.254)?
  -> stop at rung 2: renew the lease and check the DHCP server
     run: ipconfig /all   |   ipconfig getifaddr en0   |   ip -4 addr show

B: the booking site will not load
  rung 1 link     pass  Is the link up on the interface?
  rung 2 address  pass  Is the address valid (not 169.254)?
  rung 3 gateway  pass  Does the gateway answer a ping?
  rung 4 outside  pass  Does an outside address answer?
  rung 5 name     pass  Does a name resolve?
  rung 6 port     FAIL  Does the service port open?
  -> stop at rung 6: read the curl -v failure: refused or timed out
     run: Test-NetConnection example.com -Port 443   |   nc -vz example.com 443   |   nc -vz example.com 443
     curl -v says: timed out: nothing answered, so a firewall or filter probably drops the packets

C: the server never answers a ping
  rung 1 link     pass  Is the link up on the interface?
  rung 2 address  pass  Is the address valid (not 169.254)?
  rung 3 gateway  pass  Does the gateway answer a ping?
  rung 4 outside  pass  Does an outside address answer?
  rung 5 name     pass  Does a name resolve?
  rung 6 port     pass  Does the service port open?
  rung 7 app      pass  Does the application work?
  -> every rung passes: nothing on the path is at fault
     the ping failed, yet the port opened: the server drops ICMP, and rung 6 is the stronger test

D: sites by IP work, by name they do not
  rung 1 link     pass  Is the link up on the interface?
  rung 2 address  pass  Is the address valid (not 169.254)?
  rung 3 gateway  pass  Does the gateway answer a ping?
  rung 4 outside  pass  Does an outside address answer?
  rung 5 name     FAIL  Does a name resolve?
  -> stop at rung 5: troubleshoot DNS: the resolver, the cache, the records
     run: Resolve-DnsName example.com   |   dscacheutil -q host -a name example.com   |   getent hosts example.com

The same curl -v run against a closed port: refused: the host answered and nothing listens on that port

Ticket A stops at rung 2 and never reaches the ping, ticket B stops at rung 6 with curl -v saying “timed out”, and ticket D stops at rung 5, a case the DNS lesson takes apart. Ticket C passes every rung, although its ping failed. The next section explains why that is not a contradiction.

A failed ping does not prove the server is down

Ticket C is common. The user cannot ping the company’s web server, yet a colleague opens its site. ping sends ICMP echo requests; Microsoft describes it as verifying “IP-level connectivity” with them. ICMPICMP: Internet Control Message Protocol (RFC 792): the protocol behind ping's echo request and reply and the time exceeded replies that traceroute reads. Firewalls often drop parts of it, so silence is weak evidence. is only one kind of traffic to a server, and the kind most often dropped. RFC 4890 notes that dropping Echo Request messages in firewalls has been common practice in IPv4 networks, to cut the risk of scanning attacks, since an echo reply tells a scanner an address is alive. RFC 1812 adds that a router may limit how often it sends other messages “such as ICMP Echo Replies”, because they cost it resources.

So silence from ping has causes besides a dead host: an edge that drops echo on purpose, or a device that rate-limits its replies. Blocking ICMP wholesale breaks real traffic, though. For IPv6, RFC 4890 lists Packet Too Big among the messages a firewall should not drop, since hosts use it to learn the largest packet a path carries. Blocking only echo does no such harm.

The remedy is to ask the question the user’s work asks. Their browser opens a TCP connection to port 443, so test exactly that with Test-NetConnectionTest-NetConnection: A PowerShell cmdlet that tests a network connection. With -Port it tries a TCP connection and reports TcpTestSucceeded; without it, it pings. The Windows counterpart of nc -vz., nc -vz or curl -v. This table shows what each result proves and what it leaves open:

The same limit applies one rung down. A guest Wi-Fi that drops all ICMP makes rungs 3 and 4 fail while browsing works, so before you call the network down, try Test-NetConnection 1.1.1.1 -Port 443: if that succeeds, the path is open and only ping is blocked.

Loss at one hop is a fault only if it carries on to the end

A traceroutetraceroute: A tool that lists the routers on the path to a destination by sending packets with rising time-to-live values and reading the replies. Called tracert on Windows; each line is one hop with its round-trip times. to a file server shows one router in the middle with 40 % loss. Is that the fault? Usually not, and the reason lies in how a trace works. tracert on Windows, traceroute on macOS and Linux, and pathping on Windows send packets whose time-to-live starts at 1 and rises by 1. Every router lowers the value, and at 0 it sends back an ICMP Time Exceeded message, which RFC 792 defines. Each line of the trace is one router answering for itself.

That answer is a courtesy. Microsoft’s tracert page says some routers do not return Time Exceeded messages and show as a row of asterisks, and RFC 1812 lets a router limit how often it sends such errors. A router can forward your traffic perfectly and still answer the probes only now and then. Microsoft’s page for pathpingpathping: A Windows command that traces the route like tracert, then sends many probes to every hop over a period to report packet loss and delay for each hop and each link. makes the same point: routers can drop packets addressed to them without affecting traffic they forward. pathping also sends 100 probes to each hop by default over a period, so one run gives a loss figure for every hop and link.

Compare two traces with invented numbers in the style of pathping, each showing the share of probes lost on the way to that hop:

In case A the loss at hop 3 vanishes at hop 4 and at the destination, so traffic crossing hop 3 arrives. The router is rate-limiting replies addressed to itself, and there is no fault. In case B the loss starts at hop 2 and stays near 12 % to the end, so real packets are lost on the link between hops 1 and 2. The rule is to read the destination’s row first, since that is the loss the user feels, and then find the earliest hop where the loss begins and never goes away.

Try it on a PC you own: tracert -d 1.1.1.1 on Windows, or traceroute -n 1.1.1.1 on macOS and Linux; the switches skip name lookups. Find the first hop where the time jumps and see whether the later hops jump too.

A slow ticket is latency, jitter or loss, not only bandwidth

Back to the opening numbers. The gateway answers in 1 ms, so the local network is fine. 1.1.1.1 answers, so rung 4 passes, but in 220 ms, while a speed test shows 300 Mbit/s, so bandwidth is not short. The delay is added beyond the router, and it is steady. That is one of three patterns. Latencylatency: The time a packet takes to reach a destination and come back, shown by ping in milliseconds as the round-trip time. A steady 220 ms makes every request slow even when bandwidth is plentiful. is the round trip of one packet, jitterjitter: How much the delay varies from one packet to the next, in milliseconds. Voice and video need evenly spaced packets, so high jitter makes a call choppy even when bandwidth is plentiful. is how much that time varies from packet to packet, and packet losspacket loss: The share of packets sent that never arrive, shown by ping as a percentage. TCP sends lost packets again, which slows transfers; calls and video show gaps instead. is the share of packets that never come back. RFC 3550 defines jitter as the “mean deviation” of the difference in packet spacing.

Voice and video suffer from jitter more than from low bandwidth: a call sends small packets at a steady pace and plays them at a steady pace, so a late packet is as useless as a lost one. Step through the three patterns on one 0 to 400 ms scale, each with the first tool to reach for:

The next program has two parts. The first reads the summary block of six representative ping runs, from Windows, macOS and Linux, into packets sent, received and lost and the shortest, average and longest round trip. The second takes 20 pings for each pattern in the figure and works out loss, latency and jitter:

"""Read the summary that ping prints on Windows, macOS and Linux, then compare three slow-link patterns.

Part 1 parses the summary block of six representative ping runs (written for this lesson, not captured from a
customer network; the layouts follow Microsoft's ping page, macOS and Linux iputils) into packets sent, received
and lost, and the shortest, average and longest round trip.

Part 2 takes 20 round-trip times per pattern and works out the three numbers a "slow" ticket needs: loss,
latency and jitter. Jitter here is the mean difference between neighbouring replies; RFC 3550 smooths the same
difference with a gain of 1/16. None marks a lost reply.
"""

import re

SAMPLES = [
    ("Windows, to the gateway", """\
Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2ms, Average = 1ms
"""),
    ("Windows, to 1.1.1.1", """\
Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 211ms, Maximum = 236ms, Average = 220ms
"""),
    ("macOS, to 1.1.1.1", """\
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 9 packets received, 10.0% packet loss
round-trip min/avg/max/stddev = 212.114/221.870/243.552/9.870 ms
"""),
    ("Linux, to a server that drops ICMP", """\
--- 203.0.113.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3071ms
"""),
    ("Windows, same server", """\
Ping statistics for 203.0.113.10:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
"""),
    ("Linux, to the gateway", """\
--- 192.168.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 1.012/1.834/4.271/0.806 ms
"""),
]

WINDOWS_COUNTS = re.compile(r"Sent = (\d+), Received = (\d+), Lost = (\d+)")
WINDOWS_TIMES = re.compile(r"Minimum = (\d+)ms, Maximum = (\d+)ms, Average = (\d+)ms")
UNIX_COUNTS = re.compile(r"(\d+) packets transmitted, (\d+) (?:packets )?received")
UNIX_TIMES = re.compile(r"min/avg/max/(?:stddev|mdev) = ([\d.]+)/([\d.]+)/([\d.]+)/")


def parse_summary(text):
    """Return sent, received, lost and the shortest, average and longest round trip (None if no reply)."""
    counts = WINDOWS_COUNTS.search(text)
    if counts:
        sent, received, lost = (int(n) for n in counts.groups())
        times = WINDOWS_TIMES.search(text)  # Windows prints Minimum, Maximum, Average, in that order
        low, high, mean = (float(times.group(i)) for i in (1, 2, 3)) if times else (None, None, None)
        return {"sent": sent, "received": received, "lost": lost, "min": low, "avg": mean, "max": high}
    counts = UNIX_COUNTS.search(text)
    sent, received = int(counts.group(1)), int(counts.group(2))
    times = UNIX_TIMES.search(text)
    low, mean, high = (float(g) for g in times.groups()) if times else (None, None, None)
    return {"sent": sent, "received": received, "lost": sent - received, "min": low, "avg": mean, "max": high}


def verdict(stats):
    """Say what the numbers allow you to conclude, and what they do not."""
    if stats["received"] == 0:
        return "no reply: ICMP may be dropped, so test the service port"
    if stats["lost"]:
        return f"{100 * stats['lost'] / stats['sent']:.0f}% of the packets lost"
    if stats["avg"] >= 100:
        return "every reply arrives, but each round trip is long"
    return "healthy"


def fmt(value):
    return "-" if value is None else f"{value:.1f}"


print("Part 1: six ping summaries (representative samples)")
print(f"{'sample':<36}{'sent':>5}{'recv':>5}{'lost':>5}{'min':>8}{'avg':>8}{'max':>8}")
for label, text in SAMPLES:
    s = parse_summary(text)
    print(f"{label:<36}{s['sent']:>5}{s['received']:>5}{s['lost']:>5}"
          f"{fmt(s['min']):>8}{fmt(s['avg']):>8}{fmt(s['max']):>8}")
    print(f"    -> {verdict(s)}")

PATTERNS = [
    ("low bandwidth", [21, 20, 22, 21, 20, 21, 23, 20, 21, 22, 20, 21, 21, 22, 20, 21, 20, 22, 21, 21]),
    ("high latency", [219, 221, 220, 222, 219, 220, 221, 223, 219, 220, 221, 220, 222, 219, 220, 221, 220, 219, 222, 220]),
    ("jitter and loss", [24, 88, 31, 152, 27, None, 45, 119, 29, None, 63, 24, 171, 38, 26, None, 95, 30, 41, 27]),
    ("idle link", [20, 21, 20, 22, 21, 20, 21, 20, 22, 21, 20, 21, 20, 22, 21, 20, 21, 20, 22, 21]),
    ("same link, upload running", [20, 21, 148, 262, 341, 389, 402, 396, 410, 405, 398, 412, 407, 401, 409, 404, 411, 406, 399, 408]),
]
BLOCKS = " ▁▂▃▄▅▆▇█"
SCALE_MS = 400  # the top of the sparkline, so every pattern is drawn on the same scale


def sparkline(rtts):
    """One character per reply, taller for a longer round trip; x marks a lost reply."""
    return "".join("x" if r is None else BLOCKS[max(1, min(8, round(8 * r / SCALE_MS)))] for r in rtts)


def measure(rtts):
    """Loss in percent, and the shortest, average and longest reply, and the jitter, all in milliseconds."""
    replies = [r for r in rtts if r is not None]
    steps = [abs(b - a) for a, b in zip(replies, replies[1:])]
    return {
        "loss": 100 * (len(rtts) - len(replies)) / len(rtts),
        "min": min(replies),
        "avg": sum(replies) / len(replies),
        "max": max(replies),
        "jitter": sum(steps) / len(steps),
    }


print()
print(f"Part 2: 20 pings per pattern, sparkline scale 0 to {SCALE_MS} ms, x = lost")
print(f"{'pattern':<27}{'loss':>6}{'min':>6}{'avg':>7}{'max':>6}{'jitter':>8}")
for name, rtts in PATTERNS:
    m = measure(rtts)
    print(f"{name:<27}{m['loss']:>5.0f}%{m['min']:>6.0f}{m['avg']:>7.1f}{m['max']:>6.0f}{m['jitter']:>8.1f}")
    print(f"    {sparkline(rtts)}")

Part 1: six ping summaries (representative samples)
sample                               sent recv lost     min     avg     max
Windows, to the gateway                 4    4    0     1.0     1.0     2.0
    -> healthy
Windows, to 1.1.1.1                     4    4    0   211.0   220.0   236.0
    -> every reply arrives, but each round trip is long
macOS, to 1.1.1.1                      10    9    1   212.1   221.9   243.6
    -> 10% of the packets lost
Linux, to a server that drops ICMP      4    0    4       -       -       -
    -> no reply: ICMP may be dropped, so test the service port
Windows, same server                    4    0    4       -       -       -
    -> no reply: ICMP may be dropped, so test the service port
Linux, to the gateway                  20   20    0     1.0     1.8     4.3
    -> healthy

Part 2: 20 pings per pattern, sparkline scale 0 to 400 ms, x = lost
pattern                      loss   min    avg   max  jitter
low bandwidth                  0%    20   21.0    23     1.3
    ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
high latency                   0%   219  220.4   223     1.7
    ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
jitter and loss               15%    24   60.6   171    67.1
    ▁▂▁▃▁x▁▂▁x▁▁▃▁▁x▂▁▁▁
idle link                      0%    20   20.8    22     1.2
    ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
same link, upload running      0%    20  342.4   412    25.3
    ▁▁▃▅▇███████████████

Part 1 shows why a summary needs care: the run to a server that drops ICMP shows 100 % loss and no times at all, the silence of section two. Part 2 gives the figure’s numbers: low bandwidth averages 21 ms with 1.3 ms of jitter and no loss, high latency averages 220.4 ms, and the jitter-and-loss pattern loses 15 % with 67.1 ms of jitter. Jitter here is the mean difference between neighbouring replies; RFC 3550 smooths the same difference with a gain of 1/16.

The last two rows are bufferbloatbufferbloat: Extra delay that builds when a busy link has a deep queue: packets wait in line instead of being dropped, so round trips grow from tens to hundreds of milliseconds while throughput still looks good.. An idle link answers in 20.8 ms; the same link with an upload running averages 342.4 ms, with no loss and a speed test that still looks good. A deep buffer only adds waiting. Take a 20 Mbit/s upload with a 1 MB buffer that fills: it drains at 2.5 MB/s, so a packet at the back waits 1 ÷ 2.5 = 0.4 s, 400 ms, while the bandwidth-delay product, 20 Mbit/s × 20 ms, is only 50 KB, a twentieth of that buffer. RFC 8290 calls FQ-CoDel “a powerful tool for fighting bufferbloat and reducing latency”.

If the gateway is clean on a cable and ragged on Wi-Fi, the radio is the problem, and the Wi-Fi lesson takes it from there. The internet speed test reports latency, jitter and bufferbloat against public test endpoints, and latency, loss and MTU problems gives the mechanics.

Decide one user, one site or everyone before you touch anything

The first question on every network ticket is how far the fault reaches, and it costs a minute. The answer decides where you climb the ladder and who you call:

Narrow it down with tests that cost nothing. Ask a colleague on the same network to repeat the step. Try the same device on a phone hotspot: if it works there, the device is fine and the local network is the suspect. For a website, ask an outside observer: MySmartCoPilot’s website down checker requests the address from its own server and from your browser at the same time, so a site that answers there and fails for you points at your side.

Take 31 calls from the Pune office at 10:05: the CRM will not load. Chennai staff are fine, so it is not everyone. A Pune user’s phone on mobile data opens the CRM, so the service is up. Two Pune PCs pass rung 3, and at rung 4 both ping 1.1.1.1 and Test-NetConnection 1.1.1.1 -Port 443 fail, so ICMP is not the only thing missing and the fault sits between the office router and the internet. That is one site, and one ticket to the link’s owner replaces 31 PC fixes. Had the phone failed too, the fault would be the service, and you would check its status and escalate instead of touching PCs.

Scope is also step two of the troubleshooting method, and the ladder holds the tests that follow. When a ticket crosses a VPN or a proxy, the VPN, proxy and file-share lesson adds more places to look, and the port number lookup tells you what should listen on a port before you test it at rung 6.

CompTIA’s A+ page describes the Core 1 exam as covering “hardware and networking”, so a ladder like this one is also exam ground.

Practise: climb the ladder on mixed tickets

The self-check below mixes the whole lesson and begins with the rung you know least well; the feedback on every choice names the slip behind it:

Interview questions

Warm-up (fresher): a user says “I have no internet”. Which three rungs do you check first, and what is the one command for each?

Rung 1 is the link. Get-NetAdapter on Windows shows whether the adapter is Up, and ip link show on Linux or ifconfig en0 on a Mac does the same; if it is down, fix the cable or the Wi-Fi join and stop. Rung 2 is the address. ipconfig /all on Windows, ipconfig getifaddr en0 on a Mac or ip -4 addr show on Linux shows it; a 169.254 address means DHCP never answered, so look at the lease and not at DNS. Rung 3 is the gateway: ping the default gateway from ipconfig, and a reply in a few milliseconds means the local network works. Stop at the first rung that fails, since each rung depends on those below, and write down which rung failed and what it printed so the next person can continue.

Two tickets go past the rungs above: a line that carries small pages but stalls on large uploads, and a home office whose line crawls only after 20:00. Work out the first number you would collect in each before you open them.

Key takeaways

• Test a “no internet” ticket bottom-up through seven rungs, from link to application, and stop at the first rung that fails.
• A ping with no reply does not prove a server is down, because many networks drop echo on purpose, so test the service port with Test-NetConnection -Port 443, nc -vz or curl -v.
• In a trace, loss at a middle hop is rate-limiting unless it carries on to the destination, and pathping measures loss at every hop over time.
• A slow ticket is latency, jitter or loss before it is bandwidth, so take 50 pings on a cable and on Wi-Fi, because calls need steady spacing more than speed.
• Bufferbloat is a deep queue on a busy link: high delay with good throughput, visible only when you ping while the link is loaded.
• Decide whether a fault belongs to one user, one site or everyone before you change anything, because the scope tells you where to start and who to call.