Network+ N10-009 simulation
Packet Analysis Practice
Read packet-capture evidence, identify the most likely network problem, and review the protocol clues that support the diagnosis.
What this simulation practises
CompTIA Network+ (N10-009) does not ask you to memorise Wireshark menus. It asks you to look at evidence — a handful of frames from a capture, a support ticket, and a symptom — and decide which layer of the network is actually failing. Domain 5 (Network Troubleshooting) is 22% of the exam, and performance-based questions routinely hand you a capture excerpt and ask for the most likely cause.
The eight captures below cover the protocol behaviours that show up most often: DNS queries with no answer, TCP handshakes that are dropped versus actively refused, gratuitous ARP replies claiming the gateway address, DHCP Discover loops that end in an APIPA address, path MTU black holes, port scans, and duplicate IPv4 addresses. Each one maps to a published N10-009 objective, and each explains the specific clue that rules the other answers out.
Work through the simulation first — captures and answer choices are shuffled on every run — then use the protocol clue table and the full answer key further down the page to review anything you missed.
- Captures: 8, shuffled each attempt
- Protocols covered: DNS, TCP, ARP, DHCP, ICMP
- Exam: CompTIA Network+ N10-009
- Cost: free, no sign-up, nothing stored
Scenario 1 of 8
Analyze the capture
Support ticket
| Time | Source | Destination | Protocol | Info |
|---|
How to read a capture in four steps
- Identify the protocol and the conversation it belongs to. Before judging anything, decide what the exchange should look like. A DNS lookup is one query and one response. A TCP session opens with SYN, SYN-ACK, ACK. DHCP runs Discover, Offer, Request, Acknowledge. ARP is a broadcast question followed by a unicast answer. If you know the normal sequence, the missing step is the finding.
- Look for what is absent, not only what is present. Most exam captures are diagnosed by an absence: a query with no reply, a SYN with no SYN-ACK, a Discover with no Offer. Retransmissions at roughly 1s, 2s and 4s intervals are the client giving up on a peer that never answered — that is silence, which points at a drop upstream rather than a refusal.
- Separate silence from an explicit refusal. This is the single most common trap. Nothing coming back means a firewall or ACL is discarding the traffic. A TCP RST-ACK coming back immediately means the host is reachable and answering, but no service is listening on that port. An ICMP destination-unreachable message means a router in the path is telling you why it cannot forward.
- Pick the answer that explains every clue, not just one. If the ticket says direct IP addresses work but names do not, any answer about routing or gateways is already ruled out. Check each remaining option against every line in the capture; the correct diagnosis accounts for all of them.
Protocol clue reference
These are the observations that carry the most diagnostic weight on N10-009 troubleshooting questions. Learn the middle column and most capture questions answer themselves.
| What you see in the capture | What it means | Usual cause |
|---|---|---|
| DNS query, repeated, no response | Name resolution is failing while IP connectivity is intact | Wrong or unreachable DNS server, or UDP 53 filtered |
| DNS response: NXDOMAIN | The server answered — the record genuinely does not exist | Missing record, wrong search suffix, typo in the name |
| TCP SYN retransmitted, nothing back | Traffic is being discarded silently somewhere in the path | Firewall or ACL drop, blackhole route, host powered off |
| TCP RST, ACK immediately after SYN | Host is reachable and responding; the port is closed or refused | Service not running, wrong port, host-based firewall reject |
| Many SYNs to sequential ports from one source | Service discovery, not normal client traffic | TCP SYN port scan or reconnaissance |
| Unsolicited ARP reply for the gateway IP | A second MAC address is claiming an address it should not own | ARP spoofing / on-path attack, or a misconfigured device |
| ARP probe answered by another MAC | Two hosts hold the same IPv4 address | Static address inside the DHCP scope, cloned configuration |
| DHCP Discover repeated, no Offer | No server or relay is hearing the broadcast | Missing DHCP relay/helper address, exhausted scope, wrong VLAN |
| ICMP fragmentation needed (DF set) | The packet is larger than the smallest link in the path | Tunnel/VPN overhead reducing MTU; blocked ICMP breaks discovery |
| ICMP time exceeded | TTL hit zero before the destination was reached | Routing loop, or simply a traceroute in progress |
| TCP window size shrinking to zero | The receiver cannot keep up with the sender | Overloaded endpoint, not a network path problem |
| Duplicate ACKs then a retransmission | Segments are being lost mid-stream | Congestion, a failing link, duplex mismatch, or bad cabling |
All eight captures, explained
The full answer key for the simulation above. Each entry shows the support ticket, the frames the analyst sees, every answer choice with the correct one marked, and the reasoning that eliminates the rest. Open the ones you want to review — the simulation draws its questions from exactly this set.
Capture 1 — DNS queries retransmitted with no reply
Support ticket: A user can reach 8.8.8.8 but websites do not load by name.
Question: What is the most likely cause?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 10.20.1.44 | 10.20.1.10 | DNS | Standard query A portal.example.com |
| 1.002 | 10.20.1.44 | 10.20.1.10 | DNS | Standard query A portal.example.com (retransmission) |
| 3.004 | 10.20.1.44 | 10.20.1.10 | DNS | Standard query A portal.example.com (retransmission) |
- The configured DNS server is not responding
- The default gateway has a routing loop
- The client has a duplicate IP address
- The web server certificate has expired
Why: The client repeatedly sends a DNS query to 10.20.1.10 and receives no reply. Direct IP connectivity still works, which isolates the failure to name resolution rather than general routing.
N10-009 objective: 3.4: Implement IPv4 and IPv6 network services
Capture 2 — TCP SYN retransmissions with no answer at all
Support ticket: A client cannot connect to an internal HTTPS service, but the server is online.
Question: Which condition best explains the capture?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 10.4.8.23:51422 | 10.4.20.15:443 | TCP | SYN Seq=0 |
| 1.001 | 10.4.8.23:51422 | 10.4.20.15:443 | TCP | SYN Seq=0 (retransmission) |
| 3.003 | 10.4.8.23:51422 | 10.4.20.15:443 | TCP | SYN Seq=0 (retransmission) |
- A device is silently dropping TCP port 443
- The server is rejecting the session with a TCP reset
- TLS negotiation is using an unsupported cipher
- The client completed the three-way handshake
Why: Multiple SYN retransmissions with no SYN-ACK or RST indicate silent packet loss. A firewall ACL or another filtering device dropping TCP 443 is the strongest diagnosis.
N10-009 objective: 5.3: Troubleshoot common issues with network services
Capture 3 — Two MAC addresses claiming the gateway
Support ticket: Users report intermittent gateway warnings after an unknown device joined the LAN.
Question: What attack is visible in the capture?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 00:11:22:33:44:55 | Broadcast | ARP | 192.168.10.1 is at 00:11:22:33:44:55 |
| 0.428 | de:ad:be:ef:10:01 | Broadcast | ARP | 192.168.10.1 is at de:ad:be:ef:10:01 |
| 1.031 | de:ad:be:ef:10:01 | Broadcast | ARP | 192.168.10.1 is at de:ad:be:ef:10:01 |
- ARP spoofing
- DNS poisoning
- VLAN hopping
- DHCP starvation
Why: Two different MAC addresses claim the gateway IP. The repeated unsolicited ARP claim from the unknown MAC is characteristic of ARP spoofing and may redirect local traffic.
N10-009 objective: 4.2: Summarize network attacks and their impact
Capture 4 — DHCP Discover loop ending in an APIPA address
Support ticket: A laptop self-assigns a 169.254.x.x address after connecting to the office network.
Question: Which DHCP failure does the trace show?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 0.0.0.0:68 | 255.255.255.255:67 | DHCP | DHCP Discover - Transaction 0x41ae |
| 4.008 | 0.0.0.0:68 | 255.255.255.255:67 | DHCP | DHCP Discover - Transaction 0x41ae |
| 12.021 | 0.0.0.0:68 | 255.255.255.255:67 | DHCP | DHCP Discover - Transaction 0x41ae |
- No DHCP server offer reaches the client
- The client rejects the offered default gateway
- The DHCP server sends a negative acknowledgment
- The client fails after receiving an acknowledgment
Why: The client broadcasts repeated Discover messages but no Offer appears. Without a DHCP lease, it eventually uses an APIPA address in 169.254.0.0/16.
N10-009 objective: 3.4: Implement IPv4 and IPv6 network services
Capture 5 — ICMP fragmentation needed on a VPN transfer
Support ticket: Large transfers fail over a VPN, while small pings and short requests succeed.
Question: What should the administrator investigate first?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 10.1.5.20 | 172.18.4.50 | TCP | Len=1460 DF set |
| 0.013 | 10.1.5.1 | 10.1.5.20 | ICMP | Destination unreachable: fragmentation needed (MTU 1400) |
| 1.016 | 10.1.5.20 | 172.18.4.50 | TCP | Len=1460 DF set (retransmission) |
- An MTU or path MTU discovery problem
- A DNS zone transfer failure
- A duplicate gateway MAC address
- A TCP port exhaustion event
Why: The packet exceeds the supported path MTU, has the Don't Fragment flag set, and triggers an ICMP fragmentation-needed message. MTU adjustment or blocked ICMP path discovery should be checked.
N10-009 objective: 2.2: Configure switching technologies and features (MTU)
Capture 6 — TCP RST-ACK returned on every connection attempt
Support ticket: A service is reachable at the host, but connections to TCP 22 close immediately.
Question: What does the response indicate?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 192.168.50.18:53114 | 192.168.50.40:22 | TCP | SYN Seq=0 |
| 0.001 | 192.168.50.40:22 | 192.168.50.18:53114 | TCP | RST, ACK Seq=1 Ack=1 |
| 2.144 | 192.168.50.18:53115 | 192.168.50.40:22 | TCP | SYN Seq=0 |
| 2.145 | 192.168.50.40:22 | 192.168.50.18:53115 | TCP | RST, ACK Seq=1 Ack=1 |
- The host is reachable, but TCP port 22 is closed or rejected
- A firewall silently drops the SYN packets
- The three-way handshake completes normally
- The client cannot resolve the server name
Why: The server immediately answers each SYN with RST-ACK. That confirms IP reachability while showing that no service accepts TCP 22 or that the host actively rejects it.
N10-009 objective: 5.3: Troubleshoot common issues with network services
Capture 7 — Rapid SYNs across many destination ports
Support ticket: An intrusion alert reports rapid connection attempts against one server.
Question: Which activity is most consistent with the trace?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 10.9.2.77:42001 | 10.9.2.15:21 | TCP | SYN |
| 0.003 | 10.9.2.77:42002 | 10.9.2.15:22 | TCP | SYN |
| 0.006 | 10.9.2.77:42003 | 10.9.2.15:23 | TCP | SYN |
| 0.009 | 10.9.2.77:42004 | 10.9.2.15:25 | TCP | SYN |
| 0.012 | 10.9.2.77:42005 | 10.9.2.15:53 | TCP | SYN |
- A TCP SYN port scan
- A DNS amplification attack
- An ARP broadcast storm
- A successful TCP session migration
Why: One source sends SYN packets to many destination ports in milliseconds without establishing normal sessions. That pattern is a TCP SYN port scan used for service discovery.
N10-009 objective: 4.2: Summarize network attacks and their impact
Capture 8 — ARP duplicate address detection
Support ticket: A workstation reports that its address is already in use on the network.
Question: Which issue is confirmed by the packets?
| Time | Source | Destination | Protocol | Info |
|---|---|---|---|---|
| 0.000 | 00:25:96:aa:10:20 | Broadcast | ARP | Who has 192.168.30.77? Tell 192.168.30.77 |
| 0.002 | 84:7b:eb:32:19:44 | 00:25:96:aa:10:20 | ARP | 192.168.30.77 is at 84:7b:eb:32:19:44 |
| 0.003 | 00:25:96:aa:10:20 | Broadcast | ARP | Duplicate address detected for 192.168.30.77 |
- A duplicate IPv4 address
- A missing DNS PTR record
- An incorrect VLAN trunk native ID
- A depleted NAT port pool
Why: The workstation probes for its own intended address and another MAC responds that it already owns the IP. This directly confirms an IPv4 address conflict.
N10-009 objective: 5.3: Troubleshoot common issues with network services
Packet analysis questions students ask
Does the Network+ exam require Wireshark?
No. N10-009 lists protocol analysers among the tools you should recognise, but the exam tests whether you can interpret capture output, not whether you can drive a particular application. You will not be asked to build a display filter; you will be asked what a sequence of frames means.
What is the difference between a dropped packet and a refused connection?
A drop produces silence: your SYN is retransmitted and nothing ever comes back, which points at a firewall, ACL, or blackhole route between the two hosts. A refusal produces an immediate TCP RST-ACK, which proves the host received your packet and chose to reject it — usually because nothing is listening on that port.
Why does a client end up with a 169.254 address?
That range is APIPA (link-local). A client falls back to it after its DHCP Discover broadcasts go unanswered. In a capture you see Discover repeated with the same transaction ID and no Offer. The usual causes are a missing DHCP relay or helper address on the router interface, an exhausted scope, or the port being in the wrong VLAN.
How do I spot ARP spoofing in a capture?
Look for two different MAC addresses claiming the same IP address, especially the default gateway, and for unsolicited ARP replies — replies that no host asked for. A legitimate ARP reply follows a request; repeated unrequested announcements for the gateway address are the signature of an on-path attack.
Why do small packets work over a VPN but large ones fail?
Tunnel headers reduce the usable MTU. When an application sends a full-size segment with the Don't Fragment bit set, a router in the path answers with ICMP destination unreachable, fragmentation needed. If that ICMP message is blocked by a firewall, path MTU discovery breaks and the transfer simply hangs — the classic MTU black hole.
Is this simulation the same as a CompTIA performance-based question?
It uses the same reasoning — evidence in, diagnosis out — but it is not a copy of any exam item. Real PBQs may ask you to drag findings onto a diagram or configure a device afterwards. Nothing here is drawn from live exam content; ProfTIA is an independent study resource.