Why Every Network Engineer Needs Wireshark in Their Toolkit
There’s a point in every network engineer’s career where the logs don’t tell the whole story, the vendor blames your config, and the only way forward is to look at the actual packets on the wire. That’s where Wireshark earns its place. It’s free, it’s powerful, and when you know the right filters, it turns raw packet captures into actionable answers in minutes.
This guide goes beyond “open Wireshark and start capturing.” We’ll cover capture filters vs. display filters, how to get packets off Cisco IOS-XE devices using Embedded Packet Capture (EPC) and SPAN, and a library of real-world display filters that’ll save you hours on your next troubleshooting job.
Capture Filters vs. Display Filters: Know the Difference
Beginners often conflate these two, and it costs them. Understanding the distinction matters because one affects what data you collect, and the other affects what you see after the fact.
- Capture filters use BPF (Berkeley Packet Filter) syntax. They run at capture time and discard non-matching packets entirely. Use them when you’re capturing long-term or on a high-traffic link — smaller capture files, less disk I/O.
- Display filters use Wireshark’s own dissector-aware syntax. They run after capture, on packets already in memory or in a .pcap file. These are far more expressive and are what you’ll use most in day-to-day analysis.
A common mistake: writing a capture filter using Wireshark display filter syntax (like ip.addr == 10.0.0.1) — that silently fails in BPF and captures everything. The BPF equivalent is host 10.0.0.1.
Essential Capture Filters (BPF Syntax)
Use these when starting a live capture in Wireshark or when running tcpdump on a Linux box or router with shell access.
By Host or Network
# Capture traffic to/from a single host
host 192.168.1.50
# Capture traffic to/from an entire subnet
net 10.10.10.0/24
# Capture only traffic between two specific hosts
host 10.1.1.1 and host 10.1.1.2
# Exclude a host (useful for filtering out your own management traffic)
not host 192.168.1.100By Protocol or Port
# Capture only OSPF (protocol 89)
ip proto 89
# Capture only BGP (TCP port 179)
tcp port 179
# Capture DHCP (UDP ports 67 and 68)
udp port 67 or udp port 68
# Capture only ICMP
icmp
# Capture SSH and HTTPS management traffic
tcp port 22 or tcp port 443Display Filters: Your Day-to-Day Toolkit
This is where Wireshark really shines. Display filters use full protocol dissection — Wireshark understands BGP, OSPF, STP, CDP, LLDP, and dozens more. You can filter on specific fields inside protocol headers, not just addresses and ports.
Basic IP and Transport Filters
# Filter by source or destination IP
ip.addr == 10.0.0.1
ip.src == 10.0.0.1
ip.dst == 192.168.1.1
# Filter a subnet
ip.addr == 172.16.0.0/16
# Filter by TCP flags — find TCP SYN packets (connection starts)
tcp.flags.syn == 1 and tcp.flags.ack == 0
# Find TCP RST packets (abrupt connection resets — tells you something closed hard)
tcp.flags.reset == 1
# Filter by port
tcp.port == 179
udp.port == 514Routing Protocol Filters
These are gold when you’re troubleshooting adjacency issues. If you’re already familiar with OSPF adjacency troubleshooting on IOS-XE, adding a Wireshark capture to your workflow gives you the packet-level proof to back up what debug ip ospf adj tells you.
# All OSPF packets
ospf
# Only OSPF Hello packets (type 1) — check hello intervals and dead timers
ospf.msg == 1
# OSPF DBD (Database Description) — exchange of LSDB summaries
ospf.msg == 2
# BGP traffic
bgp
# BGP OPEN messages (session establishment)
bgp.type == 1
# BGP NOTIFICATION messages (session errors — read the error code)
bgp.type == 3
# BGP UPDATE messages (route advertisements and withdrawals)
bgp.type == 2Spanning Tree and Layer 2 Filters
# All STP BPDUs
stp
# Only Topology Change Notification (TCN) BPDUs — if you see a lot of these, investigate
stp.flags.tc == 1
# Filter CDP (Cisco Discovery Protocol) announcements
cdp
# Filter LLDP
lldp
# Filter 802.1Q VLAN-tagged frames
vlan
# Filter a specific VLAN ID
vlan.id == 100Security and Anomaly Detection Filters
# Find ARP requests (baseline, then look for storms)
arp.opcode == 1
# Find gratuitous ARP — a source claiming its own IP. Could be HSRP failover or a rogue device.
arp.src.proto_ipv4 == arp.dst.proto_ipv4
# Find DNS queries
dns.flags.response == 0
# Find failed DNS responses (no such name)
dns.flags.rcode == 3
# Filter DHCP Discover messages
dhcp.option.dhcp == 1
# Find rogue DHCP servers: filter DHCP Offer from any server other than your legitimate one
dhcp.option.dhcp == 2 and not ip.src == 10.0.0.1For duplicate IP detection, Wireshark’s expert info system flags conflicts automatically — look for yellow or red entries in Analyze > Expert Information with the message “Duplicate IP address detected.” You can also apply arp.opcode == 2 (ARP replies), then check the packet list for two different source MACs claiming the same destination IP within a short time window.
QoS and DSCP Filters
Wireshark lets you verify that DSCP markings are actually present end-to-end — packets leaving a router with EF marking should still carry EF when they arrive at the far end. If they don’t, something in the path is re-marking them.
# Filter Expedited Forwarding (DSCP EF = 46) — voice RTP
ip.dsfield.dscp == 46
# Filter AF41 (DSCP 34) — typically video conferencing
ip.dsfield.dscp == 34
# Filter CS3 (DSCP 24) — signaling traffic
ip.dsfield.dscp == 24
# Filter all traffic with non-zero DSCP (anything marked above best-effort)
ip.dsfield.dscp != 0Getting Packets Off Cisco IOS-XE: EPC and SPAN
On a Cisco switch or router, you can’t just run Wireshark directly — you need to get the traffic to a capture point. There are two main methods: Embedded Packet Capture (EPC), which captures on-box into a buffer, and SPAN/RSPAN, which mirrors traffic to a monitor port where your laptop runs Wireshark live.
Embedded Packet Capture (EPC) on IOS-XE
EPC is built into IOS-XE and requires no additional hardware. It captures packets into an on-box buffer that you then export as a .pcap file. It’s ideal for capturing management-plane traffic, control-plane packets (OSPF, BGP hellos), or traffic on interfaces where you can’t easily plug in a laptop.
! Step 1: Define the capture buffer (size in MB, max-size is per-packet byte limit)
SW1# monitor capture MYTEST buffer size 10 max-size 1518
! Step 2: Associate a capture interface (both = ingress and egress)
SW1# monitor capture MYTEST interface GigabitEthernet0/1 both
! Step 3: Define a capture filter (optional but recommended on busy links)
SW1# ip access-list extended CAPTURE-ACL
SW1(config-ext-nacl)# permit tcp any host 10.0.0.1 eq 179
SW1(config-ext-nacl)# permit tcp host 10.0.0.1 eq 179 any
SW1(config-ext-nacl)# exit
SW1# monitor capture MYTEST match access-list CAPTURE-ACL
! Step 4: Start the capture
SW1# monitor capture MYTEST start
! ... reproduce the problem ...
! Step 5: Stop the capture
SW1# monitor capture MYTEST stop
! Step 6: Verify capture contents inline
SW1# show monitor capture MYTEST buffer brief
Starting the packet display .... Press Ctrl + Shift + 6 to exit
1 0.000000 10.0.0.1 -> 10.0.0.2 BGP 103 KEEPALIVE Message
2 0.001452 10.0.0.2 -> 10.0.0.1 BGP 103 KEEPALIVE Message
3 30.000021 10.0.0.1 -> 10.0.0.2 BGP 103 KEEPALIVE Message
! Step 7: Export to flash, then SCP to your workstation
SW1# monitor capture MYTEST export flash:bgp-capture.pcap
SW1# monitor capture MYTEST clear# SCP the file to your workstation
$ scp admin@10.0.0.1:bgp-capture.pcap ~/captures/Open the exported .pcap in Wireshark and apply your display filters from there. Full BGP session establishment, NOTIFICATION error codes, all of it — visible and filterable.
SPAN Configuration for Live Capture
SPAN (Switched Port Analyzer) mirrors traffic from a source port or VLAN to a destination port where your laptop is connected. Unlike EPC, SPAN gives you a real-time stream you can capture live in Wireshark. This is the method to use when you need to watch traffic patterns as they happen.
! Mirror all traffic on Gi1/0/1 to Gi1/0/24 (your laptop port)
SW1(config)# monitor session 1 source interface GigabitEthernet1/0/1 both
SW1(config)# monitor session 1 destination interface GigabitEthernet1/0/24
! Verify
SW1# show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/24
Encapsulation : Native
Ingress : DisabledTo capture a full VLAN instead of a single port:
! Mirror all VLAN 100 traffic to Gi1/0/24
SW1(config)# monitor session 2 source vlan 100 both
SW1(config)# monitor session 2 destination interface GigabitEthernet1/0/24Combine SPAN with display filters to surgically isolate what you need from a high-volume mirror. VLAN 100 might carry thousands of flows — but ospf and stp.flags.tc == 1 will show only the anomalies you care about.
Real-World Troubleshooting Scenarios
Scenario 1: BGP Session Keeps Dropping
You’ve got BGP neighbors flapping. Before you start tweaking timers, capture the session teardown. Look for BGP NOTIFICATION messages (type 3). The error code tells you exactly why the session dropped:
- Error code 2, subcode 2: Bad peer AS — your AS number doesn’t match what the neighbor expects
- Error code 4: Hold timer expired — keepalives aren’t making it through; check path MTU and firewall ACLs blocking TCP 179
- Error code 6, subcode 7: Connection collision — both sides opened a TCP session simultaneously; one tears down cleanly
Display filter: bgp.type == 3. Expand the packet, read the error code. No more guessing. The Wireshark capture gives you the actual packet-level reason for the teardown to complement what you see in show bgp neighbors.
Scenario 2: STP Topology Changes Causing Network Instability
Sudden MAC table flushes and brief outages are the classic symptom of unexpected STP topology changes. Every TCN triggers a MAC address table flush on affected switches, which causes a temporary flooding storm until the table rebuilds.
! On the switch, identify the source of topology changes
SW1# show spanning-tree detail | include occur|from
Number of topology changes 847 last change occurred 0:02:14 ago
from GigabitEthernet1/0/12Wireshark display filter to find the TCN source: stp.flags.tc == 1. The source MAC in the BPDU tells you which switch or port is generating the change notifications. Cross-reference with show mac address-table | include SOURCE_MAC to locate the physical port driving the changes.
Scenario 3: Duplicate IP Address Conflict
Symptom: users on a subnet intermittently lose connectivity. It’s often a duplicate IP. Open Analyze > Expert Information in Wireshark and look for “Duplicate IP address detected” entries — Wireshark auto-flags these from ARP traffic. Alternatively, apply arp.opcode == 2 and sort by source IP; two different source MACs claiming the same IP within seconds confirm the conflict. Once you have the offending MAC addresses, show mac address-table | include MAC on your switches will tell you which physical port each device is plugged into.
Pro Tips for Efficient Analysis
Use Coloring Rules
Wireshark’s built-in coloring highlights bad TCP retransmissions (black/red), ICMP errors (cyan), and other anomalies. Go to View > Coloring Rules and add custom rules for your environment — for example, highlight all STP TCN BPDUs in bright yellow. Visual triage is faster than filter-and-read on large capture files.
Statistics > IO Graph for Traffic Baseline Comparison
During a suspected traffic spike or control-plane attack, open Statistics > IO Graph. Add multiple filters as separate lines (e.g., tcp.flags.syn==1 vs the total ip volume) to see relative volumes over time. A spike in SYN packets with flat ACK packets is a textbook SYN flood — visible in seconds.
Follow TCP Stream for Application-Layer Debugging
Right-click any TCP packet and select Follow > TCP Stream. Wireshark reassembles the full session and displays it as readable text — HTTP headers, SMTP commands, Telnet output. Indispensable when you’re trying to understand what a management application is actually sending to a device. Keep in mind: Telnet and HTTP streams contain cleartext credentials. Treat capture files with the same care as any credential store.
Save and Share Filter Sets
Build a library of display filter bookmarks for your environment. In Wireshark, click the + button next to the filter bar to save any filter with a label like “BGP NOTIFY” or “STP TCN.” Export the filter file and share it with your team so everyone’s working from the same playbook — consistent filters mean consistent analysis across incidents.
Integrating Wireshark With Your Broader Toolchain
Wireshark is one piece of the puzzle. If you’re running network automation with Python, Netmiko, and NAPALM, you can script the EPC workflow — trigger a capture automatically when a BGP state change event fires, export the .pcap, and archive it for post-mortem analysis without manual intervention. Pair that with SNMP-based monitoring for long-term telemetry and you’ve got both the bird’s-eye view and the packet-level drill-down covered.
For securing the control plane you’re analyzing, the CoPP guide covers rate-limiting control-plane traffic — a useful benchmark when reading EPC captures. If your capture shows OSPF hello rates 10x higher than expected, a properly tuned CoPP policy is the first line of defense while you investigate the source of the excess traffic.
Putting It Together: A Troubleshooting Workflow
- Define the symptom precisely before capturing. “Network is slow” generates useless captures. “BGP to 10.0.0.2 resets every 90 seconds” gives you a capture filter and a time window.
- Choose your capture method: EPC for control-plane and on-box traffic; SPAN for data-plane and real-time analysis.
- Apply a targeted capture filter to limit file size on busy links.
- Reproduce the problem while capturing. A 30-second capture during a BGP reset is more valuable than a 24-hour capture of everything.
- Apply display filters in layers: start broad (protocol), narrow to error conditions (flags, NOTIFICATION types), then drill to the specific packet that shows the root cause.
- Cross-reference with device logs. The timestamp on a BGP NOTIFICATION packet should match a
%BGP-5-ADJCHANGEsyslog event within milliseconds. If they don’t align, you’re looking at the wrong capture window.
Wireshark won’t replace show commands and structured troubleshooting methodology, but it fills the gap that CLI output leaves — the actual bytes on the wire that prove or disprove what the device thinks is happening. Add it to your rotation and you’ll wonder how you shipped tickets without it.
