This chapter covers a NEW objective in the CCNA v2 exam (200-301 v2.0, 2026 blueprint): interpreting packet capture output for Layer 2/3 troubleshooting. As networks grow more complex, the ability to read a pcap file and identify issues like ARP failures, MTU problems, or routing loops is a critical skill for network engineers. Cisco added this objective to ensure candidates can move beyond theory and into real-world diagnostics, where packet captures are the ultimate source of truth. Master this, and you'll not only ace exam scenario questions but also impress your first network team.
Jump to a section
Imagine you're a postal inspector trying to figure out why a package never arrived. You have a detailed log of every step: the sender's post office, each sorting facility, the carrier, and the delivery attempt. Each log entry has a timestamp, a location, and a status code. If the package was misrouted, you'd see it went to the wrong city. If it was too large for a mailbox, you'd see a 'delivery attempted – item oversized' note. If the address was wrong, you'd see 'return to sender – insufficient address'. Now imagine you're not just looking at one package but a stream of thousands. You need to filter for anomalies: packages that took too long, went to odd locations, or were returned. In networking, packet captures are that log. Each packet is like a postal item with source and destination addresses (envelopes), payload (contents), and flags (stamps). At Layer 2, the MAC addresses are like the street address and return address for the local delivery truck. At Layer 3, IP addresses are like the city and state. A network engineer reads packet captures to find where a packet got lost or delayed. Maybe an ARP request never got a reply (like a carrier not knowing the street address). Maybe a packet was fragmented because it was too big (like splitting a package into two boxes). Maybe a router sent an ICMP redirect (like a postal worker telling the sender a better route). Just as a postal inspector can trace a package's journey, you can trace a packet's path through the network by examining each frame's source and destination MACs, IPs, ports, and flags. The key is knowing what normal looks like so you can spot the anomaly.
What Is Packet Capture Interpretation and Why It Matters
Packet capture (pcap) interpretation is the skill of reading raw network traffic to diagnose connectivity, performance, or security issues. In the CCNA v2 exam, you will be presented with output from tools like Wireshark or tcpdump and asked to identify problems at Layer 2 (Ethernet, ARP) or Layer 3 (IP, ICMP). This is not about memorizing every field but about recognizing patterns: missing ARP replies, duplicate ACKs, ICMP unreachables, or TTL expiry. Cisco added this objective because real-world troubleshooting often starts with a pcap, and junior engineers must be able to extract meaningful information.
How to Read a Packet Capture: Field by Field
Every packet capture shows frames with the following key fields: - Frame number and timestamp: When the packet was captured. - Source and destination MAC (Layer 2): Identifies the devices directly communicating on the same broadcast domain. - Source and destination IP (Layer 3): Identifies the end-to-end hosts. - Protocol and port numbers: Indicates the upper-layer protocol (TCP, UDP, ICMP, etc.) and application. - Flags and payload: For TCP, flags like SYN, ACK, FIN, RST indicate connection state. For ICMP, type and code indicate the message purpose.
When troubleshooting, you first establish a baseline: what should normal traffic look like? For example, a successful TCP connection shows a three-way handshake: SYN, SYN-ACK, ACK. A missing SYN-ACK suggests the destination is unreachable or filtering. A series of SYN retransmissions (same sequence number) indicates no response.
Common Layer 2 Issues in Captures
ARP failures: If host A sends an ARP request for host B's IP but receives no ARP reply, the capture shows multiple ARP requests with no response. This means host B is either down or on a different VLAN/subnet without a gateway. Exam scenario: You see ARP requests for 192.168.1.1 (the default gateway) but no reply. The problem is likely a misconfigured gateway or a VLAN mismatch.
STP topology changes: When a switch port transitions from blocking to forwarding, you may see a burst of unknown unicast flooding. In captures, you'll see frames with the same source MAC but different destination MACs being sent out multiple ports. This is normal after a topology change but indicates a brief disruption.
MAC address flapping: If a switch sees the same MAC address on different ports within a short time, it generates a log message. In captures, you might see frames from the same source MAC arriving on different interfaces. This often indicates a loop or a misconfigured host.
Common Layer 3 Issues in Captures
ICMP unreachables: If a router cannot deliver a packet, it sends an ICMP Type 3 (Destination Unreachable) with codes like 0 (network unreachable), 1 (host unreachable), or 4 (fragmentation needed but DF set). For example, a capture showing ICMP Type 3, Code 4 tells you the packet was too large for the next hop and the Don't Fragment flag was set. This is a classic MTU black hole problem.
TTL expiry: When a packet's TTL reaches 0, the router drops it and sends ICMP Type 11, Code 0 (Time Exceeded). This is how traceroute works. In troubleshooting, seeing multiple TTL-exceeded messages for the same destination suggests a routing loop (the packet is going around in circles).
TCP retransmissions: If a sender does not receive an ACK within the retransmission timeout (RTO), it resends the packet. In captures, you'll see the same TCP sequence number multiple times. This indicates packet loss, which could be due to congestion, a faulty link, or a mismatch in MTU.
Duplicate ACKs: When a receiver gets an out-of-order packet, it sends a duplicate ACK for the last in-order byte. Three duplicate ACKs trigger fast retransmit. In captures, seeing multiple duplicate ACKs suggests packet reordering or loss.
IOS CLI Verification Commands for Packet Capture
While you won't run Wireshark on a router, Cisco IOS supports embedded packet capture (EPC) and can export captures for analysis. Key commands:
! Configure a capture buffer
monitor capture buffer mycap size 2048 max-size 1518
! Define a capture point (interface and direction)
monitor capture point ip cef mycap GigabitEthernet0/0 both
! Start the capture
monitor capture point start mycap
! Stop the capture
monitor capture point stop mycap
! Export the capture to a TFTP server for analysis
monitor capture buffer mycap export tftp://192.168.1.100/mycap.pcapFor real-time troubleshooting, use debug ip packet with caution, or show ip traffic to see packet counts. But the exam will present pcap outputs directly, so focus on interpreting them.
How Packet Capture Interpretation Interacts with Other Protocols
ARP and IP: ARP requests and replies are the bridge between Layer 2 and Layer 3. A missing ARP reply means IP communication fails.
ICMP and IP: ICMP error messages (unreachable, time exceeded) are the network's feedback mechanism. They help diagnose routing and MTU issues.
TCP and IP: TCP relies on IP for delivery. Packet loss seen in TCP retransmissions can stem from IP routing problems or Layer 2 errors.
DHCP and IP: DHCP uses broadcasts (Layer 2) and UDP (Layer 3). A capture showing DHCP Discover but no Offer indicates the DHCP server is unreachable or not responding.
Exam-First: What You Must Know
The 200-301 v2.0 exam will test your ability to:
Identify the type of packet (ARP, ICMP, TCP SYN, etc.) from a hex dump or summary line.
Determine the source and destination MAC and IP addresses.
Recognize error messages (ICMP unreachable, TTL exceeded) and explain their cause.
Identify retransmissions and duplicate ACKs.
Correlate missing ARP replies with connectivity failures.
Use packet captures to differentiate between Layer 2 and Layer 3 problems.
Trap patterns: The exam will show a capture with multiple ARP requests but no reply. Wrong answer: "The destination IP is unreachable." Correct: "The destination MAC is unknown because ARP failed." Another trap: A capture shows ICMP Echo Request but no Echo Reply. Wrong answer: "The destination is down." Correct: "Could be a firewall blocking ICMP or the destination not responding." Look for additional clues like ICMP unreachable messages.
New in CCNA v2
What changed vs v1.1: CCNA v1.1 briefly mentioned packet capture as a tool but never required interpretation. The new objective 2.4 explicitly expects candidates to analyze pcap output. This aligns with the new 5-domain blueprint: Switching and Network Access (25%) now includes this skill. Candidates who studied v1.1 materials are missing the ability to read a hex dump or identify a TCP retransmission from a capture summary. The exam now includes exhibit questions with pcap screenshots.
Why Cisco added this: In modern networks, packet capture is the definitive troubleshooting method. Cisco wants CCNA holders to be job-ready from day one. With SD-Access, DNA Center, and cloud-managed networks, the ability to interpret captures is essential. The old approach of memorizing show commands is insufficient when the problem is a misconfigured MTU or a silent packet drop.
What v1.1 candidates are missing: They haven't practiced reading a capture to identify ARP poisoning, ICMP redirects, or TCP window scaling issues. They also lack exposure to tcpdump-style output, which the new exam may use. This chapter fills that gap.
Identify the Problem Type
Start by reading the exam scenario: is the complaint 'no connectivity', 'slow performance', or 'intermittent drops'? For no connectivity, look for ARP failures or ICMP unreachables. For slow performance, look for TCP retransmissions, duplicate ACKs, or MTU issues. For intermittent drops, look for TTL expiry (routing loops) or STP topology changes. In a pcap, the first packet often tells the story. If the first packet is an ARP request, the problem is likely Layer 2. If it's a TCP SYN, the problem is likely Layer 3 or above. Always check the source and destination MACs first: do they match the expected next-hop? For example, if the destination MAC is not the gateway's MAC, the host may have an incorrect ARP cache.
Analyze ARP Traffic
If the capture shows ARP requests but no replies, the target host is unreachable at Layer 2. Check if the ARP request is broadcast (FF:FF:FF:FF:FF:FF) and for which IP. If the IP is the default gateway and no reply, the gateway may be down, or there's a VLAN mismatch. If the ARP request is for an off-subnet IP, the host is misconfigured (it should send to the gateway). In a capture, note the timestamps: if ARP requests repeat every few seconds, the host is persistently trying. This is typical of a dead gateway. Also look for gratuitous ARP: if a host sends an ARP reply without a request (gratuitous ARP), it may be announcing a new MAC, possibly indicating ARP spoofing.
Examine ICMP Messages
ICMP messages are the network's diagnostic tool. Type 3 (Destination Unreachable) with Code 0 (network unreachable) means the router has no route to the destination network. Code 1 (host unreachable) means the router knows the network but cannot reach the host. Code 4 (fragmentation needed but DF set) means the packet is too large for the next hop. Type 11 (Time Exceeded) with Code 0 (TTL expired) indicates a routing loop if multiple packets show this. In a capture, look for the ICMP packet in response to a specific packet. For example, if you see a TCP SYN followed by an ICMP Type 3, Code 1, the destination host is down. If you see ICMP Type 11, trace the path: the source IP of the ICMP is the router that decremented TTL to 0.
Check TCP Handshake and Retransmissions
A normal TCP connection starts with SYN, SYN-ACK, ACK. If you see only SYN packets with the same sequence number (retransmissions), the destination is not responding. This could be due to a firewall dropping packets or the destination being down. If you see SYN-ACK but no ACK, the client may have crashed or a firewall is blocking the ACK. Look for duplicate ACKs (same ACK number repeated three times) – this triggers fast retransmit. If you see many retransmissions, check the IP IDs: if they are the same, the packet is being resent. If they are different, the sender is sending new data but getting no ACK. Also check for TCP window size: if the receiver advertises a window of 0, it's overwhelmed.
Inspect IP Fragmentation and MTU
If the capture shows ICMP Type 3, Code 4 (fragmentation needed but DF set), the path MTU is smaller than the packet size. Look for the 'Don't Fragment' (DF) flag in the IP header. If DF is set, the router cannot fragment and must drop the packet. This often happens with VPN tunnels (e.g., IPSec adds overhead). In the capture, the ICMP packet will include the original packet's header for reference. Also look for fragmented IP packets: the 'More Fragments' (MF) flag and fragment offset indicate fragmentation. If fragments are missing or out of order, the receiver will not reassemble the packet. This can cause timeouts.
Correlate with Higher-Layer Clues
Use DNS and HTTP to infer problems. If a capture shows a DNS query but no response, the DNS server is unreachable or not responding. If the DNS response has a valid IP but subsequent TCP SYN gets no response, the web server is down. If you see HTTP GET requests but no data, the server may be slow or the connection is dropping. Also look for ARP requests for the DNS server IP – if they fail, the problem is Layer 2. In the exam, you may be given a pcap with multiple protocols. Always start at Layer 2 and work up: verify MACs, then IPs, then ports. The exam expects you to pinpoint the layer where the breakdown occurs.
In a large enterprise, packet capture interpretation is often the final step when 'show' commands don't reveal the issue. Consider these scenarios:
Scenario 1: MTU Black Hole in a VPN Tunnel A remote office reports that large file transfers fail, but small packets work. The network team runs a ping with DF bit set (ping -f -l 1500) and gets no reply. They capture traffic on the head-end router. The pcap shows the file transfer packets with DF set, followed by ICMP Type 3, Code 4 from the head-end router. The ICMP includes the MTU of the next hop (1400 bytes). The team then adjusts the tunnel MTU or enables TCP MSS clamping. Without the capture, they might have blamed the VPN or the firewall.
Scenario 2: ARP Flooding Due to VLAN Mismatch A user on VLAN 100 cannot reach the default gateway (192.168.1.1). The capture on the user's PC shows continuous ARP requests for 192.168.1.1 with no reply. Meanwhile, the switch port is configured as access VLAN 200. The gateway's MAC is never learned because the broadcast domain is different. The network engineer sees the VLAN mismatch by checking the switch configuration and fixes it. The capture confirmed the Layer 2 failure.
Scenario 3: Routing Loop Causing Intermittent Outages A data center experiences periodic slowdowns. A packet capture on one of the core switches shows ICMP Time Exceeded messages from multiple routers for the same destination. The TTL in the original packet is high, but it's being decremented to zero. By examining the source IPs of the ICMP messages, the engineer identifies a loop between two routers. The loop is due to a missing route filter in a redistribution configuration. The capture was key because routing tables looked correct at any given moment, but the loop only appeared under load.
Scale and Performance: In a large network, capturing all traffic is impractical. Engineers use ACLs to capture specific traffic (e.g., only traffic to a problematic server). They also use rolling buffers to capture after an event. The key is knowing what to filter: source/destination IP, protocol, or port. Misinterpreting a capture can lead to wasted hours. For example, seeing many TCP retransmissions might point to a faulty cable, but the real issue could be a server that is too slow to ACK (application delay). Always correlate captures with application logs.
What happens when misconfigured: If you misread a capture, you might replace a working cable or restart a healthy server. Worse, you might implement a change that breaks other services. For instance, if you see ICMP unreachables and assume a route is missing, but the real issue is a firewall blocking ICMP, you could add a route that creates a loop. Always verify with multiple sources (show commands, logs, and captures) before acting.
Exactly What 200-301 v2.0 Tests on This Topic
Exam objective 2.4: 'Interpret packet capture output for Layer 2/3 troubleshooting.' The exam will present a pcap exhibit (screenshot or text summary) and ask you to identify the problem. Specific tasks include:
Identify the type of packet (ARP, ICMP, TCP SYN, etc.) from fields.
Determine why a host cannot reach another (e.g., ARP failure, ICMP unreachable, TTL expiry).
Recognize TCP retransmissions and duplicate ACKs.
Differentiate between Layer 2 (MAC, ARP) and Layer 3 (IP, ICMP) issues.
Interpret ICMP error codes.
Top 4 Wrong Answers and Why Candidates Choose Them
Wrong: 'The destination host is down.' Right: 'The capture shows ARP requests with no reply, so the destination MAC is unknown.' Why: Candidates see no response and assume the host is off, but the real issue is Layer 2 resolution failure.
Wrong: 'There is a routing loop.' Right: 'The capture shows ICMP Time Exceeded, which could be a routing loop or a traceroute.' Why: One TTL-exceeded packet is normal for traceroute; multiple for the same destination indicate a loop.
Wrong: 'The connection is slow because of packet loss.' Right: 'The capture shows duplicate ACKs, triggering fast retransmit, indicating packet reordering or loss.' Why: Candidates see retransmissions and assume loss, but duplicate ACKs specifically indicate out-of-order delivery.
Wrong: 'The firewall is blocking traffic.' Right: 'The capture shows ICMP Type 3, Code 4 (fragmentation needed), indicating an MTU issue.' Why: Firewalls often drop ICMP, but the specific code points to MTU.
Specific Values and Command Outputs
ARP request: Sender MAC (6 bytes), Target MAC (00:00:00_00:00:00), Opcode 1 (request).
ARP reply: Opcode 2, Target MAC filled.
ICMP Type 3 codes: 0=network unreachable, 1=host unreachable, 4=frag needed DF set.
ICMP Type 11: Code 0=TTL expired, Code 1=fragment reassembly time exceeded.
TCP SYN flag: 0x002, SYN-ACK: 0x012, ACK: 0x010, FIN: 0x001, RST: 0x004.
TCP retransmission: Same sequence number and IP ID (if not random).
Duplicate ACK: Same ACK number, no payload, repeated.
Decision Rule for Scenario Questions
When given a pcap exhibit, follow this elimination strategy: 1. Check if the problem is at Layer 2: Are there ARP requests with no reply? If yes, answer is ARP failure (wrong VLAN, dead gateway, etc.). 2. If Layer 2 looks fine, check for ICMP errors: If you see ICMP unreachable (Type 3), identify the code. Code 4 = MTU; Code 0/1 = routing/host issue. 3. If no ICMP errors, check TCP handshake: Is it incomplete? Missing SYN-ACK? Then destination not responding (firewall or down). Missing ACK? Then client issue. 4. If handshake completes but performance is poor, look for retransmissions or duplicate ACKs. If retransmissions with same sequence number, it's loss. If duplicate ACKs, it's reordering. 5. If you see TTL-exceeded for multiple packets, suspect a routing loop. If only one, it's likely a traceroute.
Calculation Traps
There are no calculations in this objective, but you must be able to read hex: MAC addresses are 6 hex pairs, IP addresses are dotted decimal in the packet (though often decoded). The exam may show a raw hex dump for a frame. Focus on the Ethernet type field (0x0800 for IPv4, 0x0806 for ARP) and the IP protocol field (1 for ICMP, 6 for TCP, 17 for UDP).
Packet capture interpretation is a NEW objective in CCNA v2 (200-301 v2.0, 2026).
ARP requests with no reply indicate a Layer 2 failure (wrong VLAN, host down, or gateway issue).
ICMP Type 3, Code 4 means fragmentation needed but DF set – a classic MTU black hole.
ICMP Type 11, Code 0 (TTL expired) for multiple packets suggests a routing loop.
TCP retransmissions (same sequence number) indicate packet loss; duplicate ACKs indicate reordering.
When reading a pcap, start at Layer 2 (MAC, ARP) and work up to Layer 3 (IP, ICMP) and Layer 4 (TCP).
The Ethernet type field 0x0806 = ARP, 0x0800 = IPv4. The IP protocol field 1 = ICMP, 6 = TCP, 17 = UDP.
[CCNA v2 NEW] Candidates must now interpret pcap output to identify Layer 2/3 issues, a skill not tested in v1.1.
These come up on the exam all the time. Here's how to tell them apart.
Layer 2 Issues
Involve MAC addresses and Ethernet frames
ARP failures (request no reply)
STP topology changes (flooding)
MAC address flapping
VLAN mismatch (broadcast domain)
Layer 3 Issues
Involve IP addresses and routing
ICMP unreachables (Type 3)
TTL expiry (Type 11)
IP fragmentation/MTU problems
Routing loops or missing routes
Mistake
If a host sends ARP requests but gets no reply, the destination IP is unreachable.
Correct
ARP requests are for MAC resolution; no reply means the destination MAC is unknown, not that the IP is unreachable at Layer 3.
Candidates confuse Layer 2 (ARP) with Layer 3 (IP reachability).
Mistake
A single ICMP Time Exceeded message indicates a routing loop.
Correct
One TTL-exceeded packet is normal for traceroute. Multiple for the same destination indicate a loop.
Candidates don't understand traceroute behavior.
Mistake
TCP retransmissions always mean packet loss.
Correct
Retransmissions can also be due to packet reordering (duplicate ACKs) or a slow receiver (zero window).
Candidates oversimplify TCP behavior.
Mistake
ICMP redirect messages are always a problem.
Correct
ICMP redirects are normal for hosts with suboptimal routing; they tell the host to use a better next hop.
Candidates think any ICMP error is bad.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An ARP request has Ethernet type 0x0806. The destination MAC is broadcast (FF:FF:FF:FF:FF:FF). In the ARP portion, the opcode is 1 (request), and the target MAC is all zeros (00:00:00_00:00:00). The sender MAC and IP are the host making the request, and the target IP is the address being resolved. In Wireshark, it's displayed as 'ARP Request' with the target IP.
It means 'fragmentation needed but Don't Fragment (DF) flag set'. The router received a packet larger than the outgoing interface MTU, but the DF flag in the IP header prevents fragmentation. The router drops the packet and sends this ICMP error to the source. This is the core of path MTU discovery. To fix, either reduce the packet size or clear the DF flag (not recommended). In TCP, enable MSS clamping on the router.
In a capture, a TCP retransmission has the same sequence number as a previous packet, and often the same IP identification (ID) field if the source does not randomize IP IDs. The timestamp will be later. Wireshark marks retransmissions with '[TCP Retransmission]'. Also, the sender will not have received an ACK for that sequence number yet.
A duplicate ACK is sent by the receiver when it receives an out-of-order segment. It repeats the ACK number of the last in-order byte. Three duplicate ACKs trigger fast retransmit (the sender resends the missing segment without waiting for a timeout). A retransmission is the sender resending a segment due to timeout or fast retransmit. In captures, duplicate ACKs have no payload and the same ACK number; retransmissions have payload and the same sequence number.
In the Ethernet header, the first 6 bytes are the destination MAC, and the next 6 bytes are the source MAC. In Wireshark, they are displayed in the 'Ethernet II' section. In a hex dump, they appear as six pairs of hex digits. For example, '00:1a:2b:3c:4d:5e' is a MAC. The broadcast MAC is FF:FF:FF:FF:FF:FF. Note that the destination MAC is the next-hop device, not necessarily the final destination.
A TTL of 1 means the packet can only traverse one router. If it reaches a router, the router decrements TTL to 0 and drops the packet, sending an ICMP Time Exceeded (Type 11) back to the source. This is used by traceroute: the first packet has TTL=1, the second TTL=2, etc. In troubleshooting, a TTL of 1 in a regular data packet is unusual and may indicate a misconfiguration or a loop.
Check the ARP traffic first. If the host cannot resolve the next-hop MAC (no ARP reply), it's a Layer 2 problem (wrong VLAN, dead gateway, etc.). If ARP succeeds but the packet gets an ICMP unreachable, it's a Layer 3 problem (routing, MTU). If ARP succeeds and no ICMP but no TCP handshake, it could be a firewall (Layer 4) issue. The key is to see if the packet leaves the first-hop router: if the source MAC changes to the router's MAC, the packet is being routed.
You've just covered Interpreting Packet Capture Output for Layer 2/3 Troubleshooting — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?