Wireshark is the most widely used network protocol analyzer in the world. It lets you capture packets off a live network interface and inspect them at every layer of the OSI model — from raw Ethernet frames up through application-layer payloads. Whether you are troubleshooting a DHCP failure, diagnosing slow application performance, or investigating a security incident, Wireshark gives you ground truth. Logs can lie, dashboards can mislead, but the packet capture tells you exactly what happened on the wire.
In a production environment, the ability to read a packet capture separates the engineers who guess from the engineers who know. When a client reports "the network is slow," you can fire up Wireshark, capture traffic, and pinpoint whether the problem is DNS resolution delay, TCP retransmissions, TLS negotiation overhead, or something else entirely. This skill is not optional for any serious network or systems engineer.
This module walks you through the Wireshark interface, teaches you how to start and stop captures, apply filters to isolate the traffic you care about, and read the decoded packet fields. By the end, you will have deployed the full lab topology in CML and completed your first captures — ICMP and DNS — which lay the foundation for the DHCP deep-dives in Modules 2 through 4.
Wireshark is a free, open-source packet analyzer. It captures raw network frames from an interface (physical NIC, virtual NIC, or SPAN port) and decodes them into human-readable protocol fields. It supports over 3,000 protocols and can read/write `.pcap` and `.pcapng` file formats.
### Capture vs. Display Filters
These are two fundamentally different filter systems and confusing them is a common beginner mistake.
| Aspect | Capture Filter | Display Filter |
|---|---|---|
| **When applied** | Before packets are written to the buffer | After packets are already captured |
**Rule of thumb:** Use capture filters only when you know exactly what you need and cannot afford to capture everything (high-speed links, long-duration captures). Use display filters for everything else — they are non-destructive and let you change your mind.
### SPAN (Switched Port Analyzer)
Modern switches do not flood traffic to all ports the way hubs did. To capture traffic that is not destined for your Wireshark machine, you must either use a network tap or configure a SPAN session on the switch. SPAN copies traffic from one or more source ports/VLANs to a destination port where your analyzer sits.
### The Three Panes
1.**Packet List Pane** (top) — One row per packet. Columns: No., Time, Source, Destination, Protocol, Length, Info.
2.**Packet Details Pane** (middle) — Expandable protocol tree for the selected packet. Each layer (Frame, Ethernet II, IPv4, UDP, DHCP, etc.) can be expanded to see every field.
3.**Packet Bytes Pane** (bottom) — Raw hex dump and ASCII representation. When you click a field in the details pane, the corresponding bytes highlight here.
### Common Display Filters
| Filter | What It Does |
|---|---|
| `ip.addr == 10.10.10.1` | Any packet with this IP as source OR destination |
| `ip.src == 10.10.10.1` | Source IP only |
| `ip.dst == 10.10.10.1` | Destination IP only |
| `tcp.port == 443` | TCP source or destination port 443 |
| `udp.port == 53` | UDP source or destination port 53 (DNS) |
| `eth.addr == aa:bb:cc:dd:ee:ff` | Ethernet source or destination MAC |
| `icmp` | All ICMP traffic |
| `dns` | All DNS traffic |
| `dhcp` | All DHCP traffic (Wireshark uses "dhcp" not "bootp" in modern versions) |
| `tcp.flags.syn == 1 && tcp.flags.ack == 0` | TCP SYN packets only (connection initiations) |
| `ip.addr == 10.10.10.0/24` | Any IP in the 10.10.10.0/24 subnet |
| `!(arp or dns)` | Exclude ARP and DNS (reduce noise) |
### Common Capture Filters (BPF Syntax)
| Filter | What It Does |
|---|---|
| `host 10.10.10.1` | Traffic to/from this IP |
| `port 67 or port 68` | DHCP traffic |
| `net 10.10.10.0/24` | Traffic in this subnet |
| `ether host aa:bb:cc:dd:ee:ff` | Traffic to/from this MAC |
| `not port 22` | Exclude SSH (useful when capturing over SSH) |
### File Formats
- **`.pcap`** — Legacy format (libpcap). Universally supported. Single interface only.
- **`.pcapng`** — Next-generation format. Supports multiple interfaces, comments, name resolution blocks, and richer metadata. Wireshark default since version 1.8.
---
## Lab 1.1: Deploy the CML Topology
### Objective
Build the full lab topology in Cisco Modeling Labs (CML). This topology will be used for all modules in this course.
### Topology Diagram
```
┌──────────────────┐
│ RTR1 (CSR1000v)│
│ Gi0/1 (trunk) │
└────────┬─────────┘
│ 802.1Q Trunk
│ VLANs 10, 20, 30
┌────────┴─────────┐
│ SW1 (IOSv-L2) │
│ Gi0/0 - Trunk │
│ Gi0/1 - VLAN 10 │
│ Gi0/2 - VLAN 20 │
│ Gi0/3 - VLAN 30 │
│ Gi1/0 - SPAN dst│
└──┬───┬───┬───┬───┘
│ │ │ │
┌────┘ │ │ └────┐
│ │ │ │
┌──────┴──┐ ┌──┴───┴──┐ ┌───┴─────────┐
│ Client1 │ │ Client2 │ │ DHCP-SVR │
│ Ubuntu │ │ Ubuntu │ │ Ubuntu 22.04│
│ VLAN 10 │ │ VLAN 20 │ │ VLAN 30 │
│ │ │ │ │ 10.10.30.10 │
└──────────┘ └─────────┘ └─────────────┘
┌───────────────┐
│ Wireshark-PC │
│ Ubuntu Desktop│
│ SPAN dest │
│ (Gi1/0 on SW1)│
└───────────────┘
```
### SW1 Configuration (IOSv-L2)
```
! === SW1 Full Configuration ===
hostname SW1
! --- Create VLANs ---
vlan 10
name DATA
vlan 20
name VOICE
vlan 30
name SERVERS
! --- Trunk to RTR1 ---
interface GigabitEthernet0/0
description TRUNK_TO_RTR1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20,30
no shutdown
! --- Access port for Client1 (VLAN 10) ---
interface GigabitEthernet0/1
description CLIENT1_VLAN10
switchport mode access
switchport access vlan 10
spanning-tree portfast
no shutdown
! --- Access port for Client2 (VLAN 20) ---
interface GigabitEthernet0/2
description CLIENT2_VLAN20
switchport mode access
switchport access vlan 20
spanning-tree portfast
no shutdown
! --- Access port for DHCP-SVR (VLAN 30) ---
interface GigabitEthernet0/3
description DHCP_SERVER_VLAN30
switchport mode access
switchport access vlan 30
spanning-tree portfast
no shutdown
! --- SPAN Destination Port for Wireshark-PC ---
interface GigabitEthernet1/0
description SPAN_DESTINATION_WIRESHARK
no shutdown
! --- SPAN Session: Mirror ALL VLANs to Wireshark-PC ---
> **Note:** The SPAN destination port is removed from all VLANs and STP automatically. It becomes a dedicated mirror port. The Wireshark-PC connected to it will see copies of all frames on VLANs 10, 20, and 30.
Capture ICMP echo request/reply packets between two devices and dissect them field by field in Wireshark.
### Steps
**Step 1: Start Wireshark on Wireshark-PC**
```
1. Open Wireshark (Activities → Wireshark, or run `wireshark` from terminal)
2. In the interface list, double-click on your capture interface (ens3 — connected to SPAN port)
3. The capture starts immediately — you will see packets flowing if there is any traffic on VLANs 10/20/30
```
**Step 2: Generate ICMP Traffic**
On the DHCP-SVR (10.10.30.10), ping RTR1:
```bash
ping -c 5 10.10.30.1
```
**Step 3: Stop the Capture**
```
1. Click the red square (Stop) button in Wireshark
2. You now have a buffer of captured packets
```
**Step 4: Apply a Display Filter**
In the display filter toolbar, type:
```
icmp
```
Press Enter. Only ICMP packets will be shown.
**Step 5: Examine an Echo Request Packet**
Click on an "Echo (ping) request" packet. In the Packet Details pane, expand each layer:
| Layer | Key Fields | What You See |
|---|---|---|
| **Frame** | Frame Number, Frame Length, Capture Timestamp | Metadata about the capture itself — not part of the actual packet |
| **Ethernet II** | Src MAC, Dst MAC, Type (0x0800 = IPv4) | Layer 2 header — 14 bytes. The MACs tell you the next-hop, not the final destination |
| **Internet Protocol Version 4** | Src IP (10.10.30.10), Dst IP (10.10.30.1), TTL, Protocol (1 = ICMP), Header Length, Total Length | Layer 3 header — 20 bytes minimum. TTL decrements at each hop |
| **Internet Control Message Protocol** | Type (8 = Echo Request), Code (0), Checksum, Identifier, Sequence Number | ICMP payload — Type 8 = request, Type 0 = reply. The ID and Seq# tie requests to replies |
**Step 6: Compare Request and Reply**
| Field | Echo Request | Echo Reply |
|---|---|---|
| Source IP | 10.10.30.10 | 10.10.30.1 |
| Destination IP | 10.10.30.1 | 10.10.30.10 |
| ICMP Type | 8 (Echo Request) | 0 (Echo Reply) |
| ICMP Code | 0 | 0 |
| Identifier | Same value in both | Same value in both |
| Sequence | Increments per ping | Matches the request |
### What You Should See in Wireshark
- Alternating request/reply pairs (you sent 5 pings, so 10 ICMP packets)
- Source and destination swap between request and reply
- The packet bytes pane shows the raw hex — click on "Type: 8" in the details and see `08` highlighted in the hex dump
---
## Lab 1.3: Capture DNS Traffic
### Objective
Capture DNS queries and responses to understand how name resolution works at the packet level.
### Steps
**Step 1: Start a new capture on Wireshark-PC**
```
1. File → Close (discard the previous capture or save it)
2. Double-click your capture interface to start a new capture
```
**Step 2: Generate DNS Traffic from DHCP-SVR**
```bash
# Resolve a hostname
nslookup google.com
# Or use dig for more detail
dig google.com
```
**Step 3: Stop the capture and filter**
Display filter:
```
dns
```
**Step 4: Examine the DNS Query**
Click on the DNS query packet (Info column shows "Standard query A google.com"):
| Layer | Key Fields |
|---|---|
| **UDP** | Src Port: random high port, Dst Port: 53 |
| **Domain Name System (query)** | Transaction ID, Flags (Standard query, recursion desired), Questions: 1, Answer RRs: 0 |
| **Queries → google.com: type A, class IN** | The actual question — "What is the A record for google.com?" |
**Step 5: Examine the DNS Response**
Click the response packet (Info shows "Standard query response A google.com A x.x.x.x"):
| Layer | Key Fields |
|---|---|
| **UDP** | Src Port: 53, Dst Port: original high port |
| **Domain Name System (response)** | Same Transaction ID, Flags (response, recursion available), Answer RRs: 1+ |
| **Answers → google.com: type A, class IN, addr x.x.x.x** | The answer — the resolved IP address(es) |
**Step 6: Save the Capture**
```
1. File → Save As
2. Choose a location and filename (e.g., dns_capture.pcapng)
3. Format: pcapng (default)
```
### What You Should See in Wireshark
- Query and response paired by Transaction ID
- The query goes to UDP port 53, the response comes from UDP port 53
- If `dig` was used, you may also see an AAAA query (IPv6) alongside the A query
- Response contains one or more answer records with TTL values
---
## Understanding Check
1.**What is the difference between a capture filter and a display filter? When would you use each one?**
A capture filter (BPF syntax) is applied before packets enter the buffer — unmatched packets are discarded and cannot be recovered. A display filter is applied after capture — all packets remain in the file and you can change filters at any time. Use capture filters on high-speed links or long captures where disk/memory is a concern. Use display filters for analysis and investigation.
2.**You are capturing on a switch and only see your own traffic. What are two possible solutions?**
(a) Configure a SPAN session on the switch to mirror the source ports/VLANs to the port where your Wireshark machine is connected. (b) Use a physical network tap between the source device and the switch.
3.**In an ICMP echo request packet, what ICMP Type and Code values do you expect? What about the echo reply?**
Echo Request: Type 8, Code 0. Echo Reply: Type 0, Code 0. The Identifier and Sequence Number fields tie requests to their corresponding replies.
4.**Write a display filter that shows only DNS traffic to or from the IP address 10.10.30.10.**
