Reading Packet Captures for CCNA

Mental model

Show commands tell you what a device believes. A packet capture tells you what actually went over the wire.

Think of a capture as a security camera pointed at one doorway. It records what walks through that doorway, in the direction you pointed it, while it runs. If the camera is on the wrong door, you see nothing, and that tells you nothing about the building.

The skill CCNA wants is simple to state: look at a few lines of capture output and say which step of a conversation failed. Did the request leave? Did a reply come back? Was the reply a “no”?

Where captures come from

Wireshark on a PC. Capture on the NIC of the client or server with the problem. You see that host’s own traffic plus broadcasts, not other hosts’ unicast traffic.

A SPAN or mirror port. The switch copies traffic from one port or VLAN to another port where your laptop runs Wireshark. See SPAN and port mirroring for the config.

Embedded Packet Capture (EPC) on the switch itself. Catalyst 9000 switches running IOS XE can capture on a physical port and save the result as a pcap file. The commands run from privileged EXEC mode, not config mode:

SW1# monitor capture CAP interface GigabitEthernet1/0/1 both
SW1# monitor capture CAP match ipv4 any any
SW1# monitor capture CAP start
  ... reproduce the problem ...
SW1# monitor capture CAP stop
SW1# show monitor capture CAP buffer brief
SW1# monitor capture CAP export flash:cap.pcap
SW1# no monitor capture CAP

The direction keyword is in, out or both. The buffer is readable after you stop the capture. Export writes a standard pcap file (to flash or a TFTP server) that you can open in Wireshark on your laptop. The buffer brief output looks like a short Wireshark summary:

  1   0.000000   10.10.10.2 -> 10.10.10.1   ICMP 114 Echo (ping) request

Reading one line

Wireshark’s top pane shows one line per packet:

No.  Time      Source         Destination    Protocol Length Info
14   2.301887  192.168.10.25  172.16.5.20    TCP      66     51514 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
15   2.312402  172.16.5.20    192.168.10.25  TCP      66     443 → 51514 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM
16   2.312511  192.168.10.25  172.16.5.20    TCP      54     51514 → 443 [ACK] Seq=1 Ack=1 Win=262144 Len=0

• No. is the frame number in this file.
• Time is seconds since the capture started by default. The gap between a request and its reply is your round trip time (about 10.5 ms here).
• Source and Destination are IP addresses when there is an IP header, MAC addresses when there is not (ARP, for example).
• Protocol is the highest layer Wireshark decoded; Length is the frame size in bytes.
• Info is Wireshark’s one line summary: ports, flags, query names, message types. Most of your diagnosis happens here.

Reading the layers

Click a packet and the middle pane opens it layer by layer. Read it top down, like the OSI model:

Ethernet II, Src: 00:50:56:a1:3c:07, Dst: 00:1e:7a:44:9b:01
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.10.25, Dst: 172.16.5.20
    Flags: 0x2, Don't fragment
    Time to Live: 128
    Protocol: TCP (6)
Transmission Control Protocol, Src Port: 51514, Dst Port: 443, Seq: 0, Len: 0
    Flags: 0x002 (SYN)

Ethernet II. Source and destination MAC plus the EtherType: 0x0800 for IPv4, 0x0806 for ARP, 0x86dd for IPv6. For traffic leaving the subnet, the destination MAC is the default gateway, not the far server. If it is some other MAC, the host has a bad gateway or a bad ARP entry.

802.1Q tag. On a trunk you will see a line such as 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 20 between Ethernet and IP. The ID is the VLAN. Many PC NICs strip tags before Wireshark sees them, so a missing tag on a laptop capture does not always mean the frame was untagged.

IPv4. Check source and destination, TTL and protocol number (1 ICMP, 6 TCP, 17 UDP). TTL drops by one per router hop, so a TTL of 125 from a host that starts at 128 means three routers in the path. DF (Don’t fragment) matters when you chase MTU problems.

TCP. Ports tell you the application (443, 22, 80). Flags tell you the state: SYN opens, ACK confirms, FIN closes politely, RST slams the door.

UDP. Just ports, length and checksum. No flags and no handshake, so for UDP apps like DNS and DHCP you judge success by whether a reply comes back.

Patterns that point to the problem

ARP request with no reply

No.  Time      Source             Destination  Protocol Info
1    0.000000  VMware_a1:3c:07    Broadcast    ARP      Who has 192.168.10.1? Tell 192.168.10.25
2    1.002114  VMware_a1:3c:07    Broadcast    ARP      Who has 192.168.10.1? Tell 192.168.10.25
3    2.004301  VMware_a1:3c:07    Broadcast    ARP      Who has 192.168.10.1? Tell 192.168.10.25

The host is asking for its gateway and nobody answers. Think layer 2: gateway down, wrong VLAN, or the host has the wrong gateway IP. A healthy exchange ends with 192.168.10.1 is at 00:1e:7a:44:9b:01. More in ARP.

DHCP DORA, and DISCOVER with no OFFER

1  0.000000  0.0.0.0       255.255.255.255  DHCP  DHCP Discover: Transaction ID 0x6e2d91a4
2  0.004512  192.168.10.1  192.168.10.25    DHCP  DHCP Offer: Transaction ID 0x6e2d91a4
3  0.005130  0.0.0.0       255.255.255.255  DHCP  DHCP Request: Transaction ID 0x6e2d91a4
4  0.009877  192.168.10.1  192.168.10.25    DHCP  DHCP ACK: Transaction ID 0x6e2d91a4

Discover, Offer, Request, Ack, all with the same transaction ID. Broken version:

1  0.000000  0.0.0.0  255.255.255.255  DHCP  DHCP Discover: Transaction ID 0x51c0e7b3
2  4.021337  0.0.0.0  255.255.255.255  DHCP  DHCP Discover: Transaction ID 0x51c0e7b3
3  11.83902  0.0.0.0  255.255.255.255  DHCP  DHCP Discover: Transaction ID 0x51c0e7b3

Discovers leave, no Offer returns. The server is not getting the broadcast (missing ip helper-address, wrong VLAN) or has no free leases.

TCP: handshake, RST, and repeated SYN

A good handshake is the three line capture in “Reading one line”. Compare these two failures:

21  4.110201  192.168.10.25  172.16.5.20  TCP  66  51520 → 8443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
22  4.120876  172.16.5.20    192.168.10.25  TCP  54  8443 → 51520 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

The server answered fast with RST. The path works; nothing is listening on 8443 (or a device in the path is actively rejecting it). Check the service, not the routing.

30  6.000000  192.168.10.25  172.16.5.20  TCP  66  51522 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
31  7.004118  192.168.10.25  172.16.5.20  TCP  66  [TCP Retransmission] 51522 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
32  9.012377  192.168.10.25  172.16.5.20  TCP  66  [TCP Retransmission] 51522 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM

Repeated SYNs with growing gaps and silence back. Something dropped the packet silently: an ACL, a firewall, or a missing route in either direction. See the TCP three-way handshake page for the flags.

DNS query and NXDOMAIN

40  8.201155  192.168.10.25  192.168.10.53  DNS  81  Standard query 0x3b7a A intranet.corp.example
41  8.203890  192.168.10.53  192.168.10.25  DNS  132 Standard query response 0x3b7a No such name A intranet.corp.example SOA ns1.corp.example

The DNS server answered; the answer is “that name does not exist” (NXDOMAIN, rcode 3). Networking is fine. Look for a typo or a missing record. If there is no response line at all, suspect reachability to the DNS server instead.

ICMP: no reply vs destination unreachable

50  10.00000  192.168.10.25  10.20.30.40  ICMP  74  Echo (ping) request  id=0x0001, seq=12/3072, ttl=128 (no response found!)

Silence. The far host may filter ICMP, or the return path may be broken.

51  12.00000  192.168.10.25  10.20.30.40  ICMP  74  Echo (ping) request  id=0x0001, seq=13/3328, ttl=128 (no response found!)
52  12.00211  192.168.10.1   192.168.10.25  ICMP  70  Destination unreachable (Host unreachable)

Here a router (the source of the error) told you it could not deliver. That points at that router: no route, or no ARP reply for the host on its connected subnet. Details in ICMP.

Wrong VLAN tag

802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 20
Address Resolution Protocol (request)
    Sender IP address: 192.168.10.25
    Target IP address: 192.168.10.1

Captured on a trunk. The host’s address belongs to the 192.168.10.0/24 subnet, which is VLAN 10 in this network, yet the frame is tagged VLAN 20. Its ARP requests go unanswered because the gateway lives in VLAN 10. Fix the access port’s VLAN assignment.

Display filters worth memorizing

Display filters only hide packets from view. They do not remove anything from the capture file.

Common mistakes

1. Capturing on the wrong port or direction and concluding traffic is not sent. An EPC set to in on the uplink will never show the replies going out to the user. A SPAN session on the wrong port shows someone else’s traffic. Before you blame a device, prove your capture point sees the host at all (look for its ARP or DHCP broadcasts).

2. Treating silence as a single answer. “No reply” can mean the request was dropped on the way out or the reply was dropped on the way back. Capture on both ends when you can.

3. Forgetting the gateway MAC rule. For off subnet traffic, the destination MAC is the gateway. Seeing the server’s IP with the gateway’s MAC is normal, not a bug.

4. Reading RST as a network failure. A fast RST means the packet arrived and something answered. Routing works.

5. Leaving a capture running on a busy switch. Use match filters and stop the capture when you have what you need, then remove it with no monitor capture.

Lab to try tonight

1. Start Wireshark on your PC, filter arp or dhcp, then run ipconfig /release and ipconfig /renew. Find all four DORA messages.
2. Filter dns, then run nslookup doesnotexist.example. Find the “No such name” response.
3. Filter tcp.flags.reset==1, then try to connect to a closed port on a lab host (for example SSH to a box that has no SSH server). Watch the SYN get a RST.
4. On a Catalyst 9000 in the lab, run the EPC commands above against the port facing a test PC, ping from the PC, stop, and read show monitor capture CAP buffer brief.
5. Now change the direction to in only, capture again, and notice the echo replies are gone. That is mistake number one, on purpose.

Cheat strip

Frequently asked questions

Q: Do I need to know Wireshark menus for the CCNA exam? A: Expect to read capture output and interpret it rather than drive the tool. Knowing the columns, the layers and the common patterns on this page is the useful part.

Q: Why do I see only my own traffic in Wireshark on a switched network? A: A switch forwards unicast frames only to the port where the destination MAC lives. To see other hosts, capture on a SPAN destination port or use Embedded Packet Capture on the switch.

Q: What is the difference between a capture filter and a display filter? A: A capture filter decides what gets recorded in the first place. A display filter such as tcp.flags.reset==1 only changes what you see from a capture you already have.

Q: Why does Wireshark say Seq=0 when TCP uses random sequence numbers? A: Wireshark shows relative sequence numbers by default to make captures easier to read. The real random value is still in the packet, and you can see it in the TCP details pane.

Q: Can I open a switch EPC capture in Wireshark? A: Yes. monitor capture CAP export writes a pcap file to flash or a TFTP server. Copy it to your laptop and open it like any other capture.