Add latency and loss to a link, measure them, and unmask a slow DNS lookup

short · 45 min · Objective 4.3

Task

Use tc netem to add delay and packet loss to lin-b's link, measure both from lin-srv with ping and mtr, and see how each affects a file transfer differently. Then create the fixed few-second delay of an unreachable first DNS server, and prove the service is not slow -- the name lookup is.

Steps

  1. Baseline: from lin-srv, save ping -c 20 to lin-b and the time for curl -o /dev/null -w '%{time_total}' of the 20 MB file to lab/latency/baseline.txt.
  2. On lin-b, add 150 ms of delay with tc qdisc add dev <if> root netem delay 150ms. Repeat both measurements into lab/latency/delay.txt.
  3. Change it to 3 per cent loss and no delay with tc qdisc change. Repeat into lab/latency/loss.txt, and save mtr -rwc 50 to lin-b as well. Remove the rule with tc qdisc del dev <if> root.
  4. On lin-srv, make the first nameserver in the resolver configuration an unused address such as 192.168.56.254, with win-srv second. Time curl http://web.lab.internal/ and curl to the same server by IP, and save both times to lab/latency/dns.txt. Restore the resolver.
  5. Record in lab/latency/diagnosis.csv with header condition,ping_ms,loss_pct,transfer_s,what_it_hurts one row per condition.

Verify

These checks run in a POSIX shell: Terminal on macOS or Linux, and on Windows Git Bash (it comes with Git for Windows) or WSL. A stock Windows PowerShell or Command Prompt has no awk or grep, so there the first line fails.

grep -Eo 'rtt min/avg/max/mdev = [0-9.]+/[0-9.]+' lab/latency/baseline.txt lab/latency/delay.txt
grep -Eo '[0-9.]+% packet loss' lab/latency/loss.txt
grep -Eo '[0-9]+[.][0-9]+' lab/latency/dns.txt
awk -F, 'NR>1 {print $1": "$2" ms, "$3"% loss, "$4" s"}' lab/latency/diagnosis.csv

The delay capture's average round trip is about 150 ms higher than the baseline, the loss capture shows a few per cent lost, and the name-based request took several seconds longer than the same request by IP. Loss usually slows the large transfer far more than its percentage suggests, because TCP backs off on every lost packet.

Notes

If lin-b's latency had appeared at one hop in an mtr trace and disappeared at the next, the router at that hop was simply slow to answer ping. Real latency or loss persists through every hop after the one where it starts.

This is an independent study companion for CompTIA Server+ SK0-005 and is not produced by or endorsed by CompTIA.