Wireshark for CCNA: Capturing Packets in Your Lab

What a packet capture actually shows you

A show command tells you what a device believes about the network: show ip ospf neighbor claims an adjacency is Full, show ip arp claims a MAC is learned. A capture shows you the packets that made those claims true. That difference matters when something is broken, because a protocol that 'should' be working but isn't will leave evidence on the wire — a hello that never gets answered, an ARP request with no reply, a TCP SYN that goes nowhere.

Wireshark decodes each frame layer by layer, so you can expand a single packet and read the Ethernet header, the IP header, and the protocol payload without memorizing byte offsets. For CCNA study that decoding is the whole point: you get to see that an OSPF hello really is sent to 224.0.0.5, that a DHCP Discover really is a broadcast, and that a Telnet password really does travel in clear text.

Capturing on a CML link, or on a host

In Cisco Modeling Labs you have two convenient places to capture. The first is a link: select the link between two nodes and start a packet capture, and CML taps that virtual point-to-point wire and can stream the packets straight into Wireshark (or save them as a .pcap you open later). Because a CML link is point-to-point, one capture sees both directions of everything on that wire — you don't have to work around a switch hiding unicast the way you would on real gear. The second place is an end host: on an Alpine or desktop node you can run Wireshark or tcpdump directly on its interface.

Placement is the part beginners get wrong. A capture only shows you traffic that actually crosses the segment you tapped, so where you attach it decides what you'll see. Capture the link between two routers to see OSPF hellos or CDP; capture a switch-to-switch trunk to see STP BPDUs. Routers don't run spanning tree and never emit BPDUs, so you will not find one on a router-to-router link — put the capture on the wrong segment and the protocol you're hunting for simply won't appear. When something you expect is missing, suspect your placement before you suspect your configuration.

# On a CML Alpine/desktop host, capture to a file you open in Wireshark
$ sudo tcpdump -i eth0 -w /tmp/capture.pcap

# Or watch a subset live in the terminal
$ sudo tcpdump -i eth0 arp or icmp

Display filters are the real skill

A busy link produces thousands of packets, so the skill that makes Wireshark useful is filtering. Display filters go in the bar at the top of the window and hide everything that doesn't match, without deleting anything — clear the filter and the full capture is still there. Most of the time you filter by protocol name or by an address or port.

Type a protocol keyword to isolate it: ospf, arp, icmp, stp, cdp, and dhcp each match just that protocol. Narrow by address with ip.addr == 10.0.12.1 (matches source or destination), or by port with tcp.port == 22 for SSH. You can combine expressions with and, or, and not — for example, ospf and ip.addr == 10.0.12.2 shows only the OSPF packets involving one neighbor. Note that some older Wireshark builds spell the DHCP filter bootp rather than dhcp.

ospf
arp
icmp
stp
cdp
dhcp
tcp.port == 22
ip.addr == 10.0.12.1
tcp.flags.syn == 1

Capture filters are a different language

There is a second kind of filter, and mixing the two up is a classic trap. A capture filter is applied before packets are ever stored, so anything that doesn't match is thrown away permanently — useful when a link is so busy you don't want to record all of it. A display filter, by contrast, only changes what you see and can be edited freely after the fact.

They also use different syntax. Capture filters use the libpcap/BPF grammar — host, port, net, with spaces — while display filters use Wireshark's own dotted grammar. So the same intent looks like tcp port 22 as a capture filter but tcp.port == 22 as a display filter. When a filter throws a red error bar, check that you're using the right grammar for the box you typed it in.

host 10.0.12.1
tcp port 22
net 192.168.10.0/24

Five captures worth doing for CCNA

A few captures teach more than a chapter of reading. First, watch an OSPF adjacency form: filter on ospf and you'll see the Hello packets, then the Database Description (DBD), Link-State Request, Link-State Update, and Link-State Acknowledgment exchange that carries the two neighbors up to Full. Second, capture an ARP: filter arp and ping an unknown host to see the broadcast request and the unicast reply that resolves the MAC.

Third, capture DHCP: filter dhcp and release/renew a host to see the four-message DORA sequence — Discover, Offer, Request, Ack. Fourth, capture a TCP three-way handshake: filter by the session (e.g. tcp.port == 22 for SSH) to see all three packets — SYN, SYN-ACK, and ACK — before any data moves. (The tcp.flags.syn == 1 filter is handy for spotting where a connection starts, but it shows only the two SYN-bearing packets, the SYN and the SYN-ACK, since the final ACK has its SYN flag cleared.) Fifth, do the security demo: open a Telnet session (tcp.port == 23), right-click a packet, and choose Follow TCP Stream — the username and password are right there in clear text, which is the entire argument for using SSH instead.

ospf
arp
dhcp
tcp.port == 22
tcp.port == 23

Mirroring a switch port with SPAN

On real switched hardware — or a CML switch node — you often can't just tap the wire you care about, because a switch only forwards unicast frames to the port that owns the destination MAC. If you plug a laptop into a spare port and start Wireshark, you'll see broadcasts and multicasts but almost none of the unicast traffic between two other hosts. The fix is SPAN (Switched Port Analyzer), which mirrors a source port's traffic to a destination port where your capture is listening.

Configure a monitor session with a source and a destination interface, then attach your Wireshark host to the destination. Everything crossing the source port is copied to it. This is the switch equivalent of the point-to-point link capture CML gives you for free, and it's the technique you'll reach for the moment you move off virtual links and onto real gear.

SW1(config)# monitor session 1 source interface gigabitethernet0/1
SW1(config)# monitor session 1 destination interface gigabitethernet0/2
SW1(config)# end
SW1# show monitor session 1

Common mistakes and how to read a capture

The mistake that eats the most time is the one from earlier: capturing on the wrong segment and concluding a protocol is broken when it was simply never going to appear there. Before you tear apart a working config, confirm the traffic you want actually transits the link you tapped. The second most common mistake is forgetting that a switch hides unicast — if you're capturing on a host port and only see broadcast and multicast, you need SPAN or a link capture, not a new theory about the network.

Once you have the right packets, a few habits make them readable: color rules and the protocol column tell you at a glance what each frame is, Follow TCP Stream reassembles a whole conversation, and the Statistics menu (Protocol Hierarchy, Conversations) summarizes who is talking and how much. Save the .pcap when you find something interesting — it's the clearest evidence you can attach to a troubleshooting note.

Every Goldfish Networks lab runs on real Cisco IOS in CML, so you can capture any link in the topology and check the protocol behavior against the graded answer key. Try the free sample lab, build it, and watch the packets prove your configuration works.