8 exercises — fill in the blanks in real troubleshooting report excerpts and put diagnostic steps in the correct logical order.
0 / 13 completed
1 / 13
Fill in the blank: "I ____ the gateway and got no response, so I suspect the local network segment is down."
"I pinged the gateway" — "ping" is both a noun and a verb in networking English: to ping a host means to send ICMP Echo Request packets and wait for Echo Reply. "No response" (or "100% packet loss") means the host is unreachable or not answering ICMP.
Standard troubleshooting narration pattern: "I pinged X and got Y" — e.g., "I pinged 8.8.8.8 and got a reply in 12ms" (confirms internet reachability) vs. "I pinged the gateway and got no response" (suggests a local problem, before even reaching the internet).
Ping is usually the very first diagnostic step because it is fast and tells you whether basic IP connectivity exists at all.
2 / 13
Fill in the blank: "Traceroute shows the packet is timing out at hop 4, which points to a problem at the ____ between our network and the ISP."
"Handoff" — the point where responsibility for traffic passes from one network to another, e.g., from an organisation's edge router to their ISP's router. "The ISP handoff" is a very common phrase in network troubleshooting reports.
Reading a traceroute: each line is a "hop" (one router along the path), showing round-trip time. "Timing out at hop 4" means that router either dropped the probe packet or is configured not to respond to traceroute probes — the latter is common and not always a problem ("some hops don't respond to traceroute by design, but as long as later hops respond, the path is likely fine").
Vocabulary: "the trace dies at hop N" (informal), "we lose the path after hop N", "the RTT jumps from 5ms to 80ms at hop N" (suggests a slow or congested link at that specific hop).
3 / 13
Fill in the blank: "I ran a packet capture on the interface and observed ____ — the client sends a SYN, but no SYN-ACK ever comes back."
"The TCP handshake never completes" — a very specific and useful observation. Seeing a client-sent SYN with no SYN-ACK reply usually means the destination is unreachable, a firewall is silently dropping the packet, or nothing is listening on that port.
Packet capture vocabulary (Wireshark / tcpdump): • SYN, SYN-ACK, ACK — the TCP three-way handshake • RST (reset) — the connection was actively refused (something is listening but rejects it, or a firewall sent a reset) • retransmission — a packet is being re-sent because no acknowledgment was received in time • dup ACK — a duplicate acknowledgment, often signalling packet loss
Framing an observation like a report: "I captured traffic on eth0 and observed the client retransmitting the SYN three times with no response, consistent with a firewall silently dropping inbound traffic on that port."
4 / 13
Fill in the blank: "The interface counters show a rising number of ____, which usually points to a bad cable, a faulty NIC, or a duplex mismatch."
"CRC (Cyclic Redundancy Check) errors" — indicate that frames arrived corrupted; the checksum computed on arrival did not match the one sent. Classic causes: a damaged or too-long cable, electromagnetic interference, a failing NIC, or a duplex mismatch (one side set to full-duplex, the other to half-duplex).
Common interface-level troubleshooting vocabulary: • CRC errors — corrupted frames, usually Layer 1/2 cabling or hardware issue • collisions — two devices transmitted at the same time (rare on modern switched, full-duplex networks; suggests a duplex mismatch if seen) • MTU mismatch causing fragmentation — a packet exceeds the maximum size a link can carry and either gets fragmented (if allowed) or silently dropped (if the "don't fragment" bit is set) — a very common cause of "small requests work, large transfers fail" • interface flapping — the link repeatedly goes up and down
Sentence pattern: "We're seeing a steadily increasing CRC error count on Gi0/1 — I suspect the patch cable, I'll swap it and monitor."
5 / 13
Fill in the blank: "Since DNS might be the cause, I ran ____ to check whether the hostname resolves to the correct IP address, and it does — so DNS is not the problem."
nslookup (and its more modern equivalent, dig) query DNS servers directly to resolve a hostname to an IP address — the standard first step to rule DNS in or out as the cause of a connectivity problem.
Core diagnostic tool vocabulary: • ping — tests basic ICMP reachability and round-trip time • traceroute / tracert — shows the path (hop by hop) packets take to a destination • nslookup / dig — resolves DNS names to IP addresses (dig gives more detail: TTL, record type, authoritative server) • netstat — shows active connections, listening ports, and routing tables (older, being replaced by `ss` on Linux) • ss — modern, faster replacement for netstat on Linux for inspecting sockets • tcpdump / Wireshark — captures and inspects raw packets on the wire for deep-dive analysis
Phrase: "I ruled out DNS — `dig` returns the correct A record with a healthy TTL, so the issue is downstream of name resolution."
6 / 13
Fill in the blank: "I checked which process was listening on port 8080 by running `ss -tlnp`, and found ____."
"Nothing was bound to that port" is exactly the kind of finding `ss -tlnp` (or `netstat -tlnp` on older systems) reveals: it lists TCP sockets (`-t`), in listening state (`-l`), showing numeric addresses (`-n`), with the owning process (`-p`).
"Connection refused" vs. "connection timed out" is an important diagnostic distinction to communicate precisely: • Connection refused: a host actively responded that nothing is listening on that port (a TCP RST was sent) — the network path works, but the service isn't there or isn't running • Connection timed out: no response at all — could mean a firewall is silently dropping the packet, the host is unreachable, or a route doesn't exist
This distinction narrows down whether the problem is a service configuration issue (refused) or a network-path/firewall issue (timeout) — a distinction worth stating explicitly in an incident report.
7 / 13
Order these 6 troubleshooting steps for "a user reports they cannot reach an internal web application" into the correct logical order.
1. Check whether the web service process is running and listening on the expected port on the server.
2. Ping the user's default gateway to confirm local network connectivity.
3. Check the firewall/security group rules between the user's network and the server.
4. Confirm the hostname resolves to the correct IP address using dig or nslookup.
5. Attempt to reach the server's IP address directly with curl or telnet on the expected port.
6. Ping the server's IP address to confirm basic reachability.
The correct order follows a bottom-up, "closest to the user first" approach: 2 → 4 → 6 → 3 → 5 → 1.
1. Ping the gateway — confirm the user's own local network is working at all 2. Resolve the hostname (dig/nslookup) — rule out DNS before assuming a network path problem 3. Ping the server's IP — confirm basic Layer 3 reachability to the destination 4. Check firewall/security group rules — since ping succeeded but the application might still be blocked at a specific port 5. Try curl/telnet on the specific port — confirm whether the application port itself is reachable (distinguishes "refused" vs "timed out") 6. Check whether the service is actually running and listening on the server — the final step, once the network path is confirmed clean
This ordering mirrors the OSI model's bottom-up troubleshooting philosophy: confirm the network layers first, then move up to the application itself, so you don't waste time debugging application code when the real issue is a firewall rule.
8 / 13
Which sentence best communicates a finished troubleshooting investigation in a professional incident report?
A good incident report states: root cause (what exactly was wrong and why — including how/when it was introduced), the fix applied (the specific change made), and verification (how you confirmed it actually resolved the issue).
Structure for a troubleshooting summary: 1. Symptom: what the user/monitoring reported 2. Investigation: steps taken and findings at each step (this is where ping/traceroute/dig/tcpdump results go) 3. Root cause: the specific, confirmed reason for the failure 4. Fix: exactly what was changed 5. Verification: how you proved the fix worked
Vague reports ("probably DNS", "tried some stuff") waste the next engineer's time if the issue recurs, since there is no record of what was actually confirmed versus guessed.
9 / 13
Liam from DevOps sent this Slack message: 'Hey team, we're seeing intermittent timeouts to our API endpoint. The logs show a lot of 502 Bad Gateway errors. I've restarted the app server, but it's still happening. Any ideas?'. Which action should Sarah, a backend developer, take FIRST?
The message indicates a 'Bad Gateway' error, suggesting a problem with the API gateway itself. Starting with the configuration is the most logical first step – rate limiting or recent changes are common causes of these errors. Running diagnostics would be premature without understanding the immediate symptoms. Escalating immediately isn't warranted until a more focused investigation has been attempted.
10 / 13
During a root cause analysis for a service outage, the network engineer noted: 'The traceroute indicated packet loss at hop 3, suggesting an issue within our own datacenter. I suspect a faulty switch port is causing the disruption.' To confirm this, what command should be used to examine the switch port's status and statistics?
The traceroute result points to a specific hop where packet loss is occurring. The show interface counters errors command provides detailed statistics about the switch port's performance, including error counts (CRC, frame collisions, etc.), which are crucial for identifying hardware problems like a faulty NIC or cable.
11 / 13
David left this comment on a pull request that adds new functionality to an application: 'This code doesn't handle potential network errors gracefully. If the connection fails, it just crashes. Add error handling and logging to improve robustness.' What is the MOST effective way for Maria, the developer who wrote the code, to address this feedback?
Maria's feedback highlights the need for robust error handling. While all options have *some* merit, adding a try-catch block is the most direct and immediate way to address the core issue – catching network exceptions that would otherwise cause the application to crash. Comprehensive logging provides valuable information for debugging, while ignoring the comment or adding complex retry logic might not fully resolve the problem.
12 / 13
Ben, a senior developer, is explaining a recent network issue to the team during a stand-up. 'We experienced intermittent connectivity problems with our database server. The monitoring system showed an increase in TCP retransmissions on port 3306, suggesting congestion or packet loss. I've checked for resource exhaustion, but nothing obvious.' What should Chloe, a junior developer, suggest as the next step to investigate?
The monitoring data indicates TCP retransmissions, a strong indicator of network-level issues. Analyzing network traffic with Wireshark is the most direct way to pinpoint the source of congestion or packet loss – this is more informative than simply checking CPU/memory usage which might be unrelated.
13 / 13
Tom, a network administrator, sends this message in an incident report: 'After investigating the reported DNS resolution failures, I ran `dig example.com` and confirmed that it resolves to the correct IP address. Therefore, DNS was not the root cause of the issue.' What does this statement primarily demonstrate?
Tom's message illustrates the process of eliminating potential causes. By running `dig` and confirming DNS resolution, he effectively ruled out DNS as the source of the problem – this is a crucial step in systematic troubleshooting. It demonstrates that he wasn't just jumping to conclusions.
What does the "Network Troubleshooting Language — Networking Language Exercises" exercise cover?
Practise network troubleshooting vocabulary in English: ping, traceroute, nslookup, dig, netstat, ss, tcpdump, CRC errors, MTU mismatch, and writing clear diagnostic reports.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Network Troubleshooting Language — Networking Language Exercises"?
This exercise has 13 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Networking Language exercises?
Browse the full Networking Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.