Blog

Wireshark Filters for Network Engineers: BGP, OSPF, STP, and IOS-XE Capture Reference

Sarah Chen
12 min read

Why Every Network Engineer Needs a Wireshark Filter Cheat Sheet

If you’ve ever stared at a packet capture trying to find the one STP BPDU causing a topology change, or hunted for the TCP RST blowing up a BGP session, you already know the value of a precise display filter. Wireshark is the de-facto standard for packet analysis, but its filter syntax has enough nuance to trip up even experienced engineers. This guide is the reference I wish I’d had — real filter strings, practical examples, and a structured approach to hunting down problems on Cisco IOS-XE networks.

We’ll cover display filters (applied to an existing capture) and capture filters (BPF syntax that controls what hits the buffer in the first place), with an emphasis on the protocols you actually see in enterprise networks: OSPF, BGP, STP, CDP, LLDP, and the usual TCP suspects. If you’ve already wired up Python automation with Netmiko and NAPALM to pull data off your switches, you’ll appreciate having these filters ready to pair with SPAN sessions.

Capture Filters vs. Display Filters: Know the Difference

These two filter types do fundamentally different things and use completely different syntax:

  • Capture filters (BPF — Berkeley Packet Filter) run at the capture engine level. They decide what packets are even written to the capture buffer. Use them when you’re dealing with high-volume links and can’t afford to capture everything. Syntax is compact and less expressive.
  • Display filters run post-capture on the frames already in memory or in a .pcap file. They’re more powerful, support protocol dissection, and use Wireshark’s own filter language (DFSL). These are what you spend most of your time with.

A common mistake: typing a display filter expression into the capture filter box. They’re incompatible syntactically, and Wireshark will error out or silently capture the wrong traffic.

Capture Filters (BPF) — Quick Reference

Capture filters go in the “Capture Options → Capture Filter” field before you start a session. BPF syntax is close to tcpdump:

# Capture only traffic to/from a specific host
host 192.168.1.1

# Capture only TCP traffic
tcp

# Capture only traffic on port 179 (BGP)
tcp port 179

# Capture OSPF (protocol 89)
ip proto 89

# Capture only traffic between two specific hosts
host 10.0.0.1 and host 10.0.0.2

# Capture everything except ICMP
not icmp

# Capture from a subnet
net 10.10.0.0/24

# Capture STP (Ethernet frames with STP destination MAC)
ether dst 01:80:c2:00:00:00

# Capture CDP multicast
ether dst 01:00:0c:cc:cc:cc

Use capture filters on production SPAN sessions when link rates exceed a few hundred Mbps — trying to capture a 10G trunk unfiltered on a laptop will drop frames and give you a useless capture.

Display Filter Deep Dive

Display filters are where you do real analysis. The syntax uses protocol fields with comparison operators and logical connectors. Let’s go through the categories you’ll use most.

Basic IP and Transport Filters

# Filter by IP address (source or destination)
ip.addr == 192.168.1.1

# Source only
ip.src == 192.168.1.1

# Destination only
ip.dst == 10.0.0.1

# Filter a subnet
ip.addr == 10.10.0.0/24

# TCP traffic on a specific port
tcp.port == 443

# UDP traffic
udp

# Filter by TCP flags — find all SYN packets
tcp.flags.syn == 1 and tcp.flags.ack == 0

# Find RST packets (connection teardowns)
tcp.flags.reset == 1

# Find FIN packets
tcp.flags.fin == 1

# Show only ICMP
icmp

# ICMP type 8 = echo request, type 0 = echo reply
icmp.type == 8

BGP Troubleshooting Filters

BGP runs over TCP/179. Before you can filter BGP messages, you need Wireshark to successfully decode the session. If sessions are encrypted (TCP-AO or MD5), the payload will be opaque.

# All BGP traffic
tcp.port == 179

# BGP OPEN messages (type 1) — session establishment
bgp.type == 1

# BGP UPDATE messages (type 2) — route advertisements
bgp.type == 2

# BGP NOTIFICATION messages (type 3) — errors and teardowns
bgp.type == 3

# BGP KEEPALIVE messages (type 4)
bgp.type == 4

# BGP NOTIFICATION with specific error code
# Error code 6 = CEASE (e.g., admin reset, max-prefix hit)
bgp.notify.major_error == 6

# Filter UPDATE messages advertising a specific prefix
bgp.update.path_attribute.as_path contains "65001"

# Find BGP sessions between two specific peers
(ip.src == 10.0.0.1 and ip.dst == 10.0.0.2 and tcp.port == 179) or (ip.src == 10.0.0.2 and ip.dst == 10.0.0.1 and tcp.port == 179)

For a deeper look at BGP filtering and community design on IOS-XE, see our BGP protocol guide.

OSPF Filters

OSPF uses IP protocol 89 and multicast addresses 224.0.0.5 (AllSPFRouters) and 224.0.0.6 (AllDRRouters). OSPF adjacency flaps are a common pain point — here’s how to isolate them:

# All OSPF traffic
ospf

# OSPF Hello packets (type 1)
ospf.msg.type == 1

# OSPF DBD — database description, type 2
ospf.msg.type == 2

# OSPF LSR — link state request, type 3
ospf.msg.type == 3

# OSPF LSU — link state update, type 4
ospf.msg.type == 4

# OSPF LSAck — acknowledgment, type 5
ospf.msg.type == 5

# Filter OSPF from a specific router ID
ospf.srcrouter == 10.0.0.1

# Find hellos with mismatched parameters (Dead/Hello intervals)
# Look for hellos — compare hello interval field
ospf.hello.hello_interval

# Filter for area 0 traffic
ospf.area_id == 0.0.0.0

If you’re debugging adjacency failures caused by MTU mismatches or dead interval mismatch, focus on DBD packets (type 2) — the exchange state issues will show there. Our OSPF troubleshooting guide has the full IOS-XE command workflow to pair with Wireshark analysis.

STP and RSTP Filters

STP BPDUs are Ethernet frames sent to the well-known 01:80:c2:00:00:00 multicast — they don’t have IP headers, so you filter on STP protocol fields directly:

# All STP traffic
stp

# STP Configuration BPDUs (classic STP)
stp.type == 0x00

# STP TCN BPDUs (topology change notification)
stp.type == 0x80

# RSTP BPDUs (type 0x02)
stp.type == 0x02

# Filter by root bridge MAC
stp.root.hw == aa:bb:cc:dd:ee:ff

# Filter topology change flag set
stp.flags.tc == 1

# Find BPDUs from a specific switch port (by source MAC)
eth.src == 00:11:22:33:44:55 and stp

# MSTP BPDUs
stp.version == 3

When chasing a flapping topology, add a column for stp.flags.tc and stp.root.hw in the packet list view — it makes it immediately obvious which switch is triggering topology changes.

CDP and LLDP Filters

CDP (Cisco Discovery Protocol) and LLDP are invaluable for neighbor verification and troubleshooting adjacency issues. They’re Layer 2 only.

# All CDP frames
cdp

# CDP version
cdp.version

# CDP device ID (neighbor's hostname)
cdp.deviceid

# CDP native VLAN TLV
cdp.native_vlan

# CDP capabilities (router, switch, etc.)
cdp.capabilities

# CDP platform (device model)
cdp.platform

# All LLDP frames
lldp

# LLDP System Name TLV
lldp.tlv.type == 5

# LLDP Port Description
lldp.tlv.type == 4

# LLDP System Capabilities
lldp.tlv.type == 7

If you’re seeing %CDP-4-NATIVE_VLAN_MISMATCH in your logs, filter on cdp.native_vlan and compare the values between adjacent switches — you’ll see the mismatch directly in the capture.

DHCP Filters

# All DHCP traffic
dhcp

# DHCP Discover (type 1)
dhcp.option.dhcp == 1

# DHCP Offer (type 2)
dhcp.option.dhcp == 2

# DHCP Request (type 3)
dhcp.option.dhcp == 3

# DHCP ACK (type 5)
dhcp.option.dhcp == 5

# DHCP NAK (type 6) — look for these if clients aren't getting addresses
dhcp.option.dhcp == 6

# Filter by client MAC
dhcp.hw.mac_addr == 00:11:22:33:44:55

DNS Filters

# All DNS traffic
dns

# DNS queries only
dns.flags.response == 0

# DNS responses only
dns.flags.response == 1

# DNS responses with errors (RCODE != 0)
dns.flags.rcode != 0

# NXDOMAIN (name does not exist)
dns.flags.rcode == 3

# Filter for a specific domain query
dns.qry.name contains "ignaonline.com"

# DNS over TCP (zone transfers, large responses)
tcp.port == 53

TCP Performance Filters — Spotting the Real Problems

Wireshark’s built-in TCP analysis flags are some of the most useful tools in your kit. Use these to instantly surface performance and reliability issues:

# TCP retransmissions — packet loss indicator
tcp.analysis.retransmission

# Fast retransmission (3 duplicate ACKs received)
tcp.analysis.fast_retransmission

# Duplicate ACKs
tcp.analysis.duplicate_ack

# Zero window — receiver is overwhelmed
tcp.analysis.zero_window

# Window full — sender is holding back
tcp.analysis.window_full

# TCP out-of-order — reordering in the path
tcp.analysis.out_of_order

# Previous segment not captured — gaps in your capture
tcp.analysis.lost_segment

# All TCP problems in one filter
tcp.analysis.flags

# High RTT indicator — time delta between SYN and SYN-ACK
# Use Statistics → TCP Stream Graphs → Round Trip Time for this

When a BGP session keeps resetting and you’re not seeing NOTIFICATION messages, run tcp.flags.reset == 1 alongside tcp.port == 179. A RST from the router’s IP without a BGP NOTIFICATION usually points to a TCP keepalive timeout, firewall ACL, or platform bug rather than a BGP protocol issue.

Combining Filters: Logical Operators

Wireshark display filters support full boolean logic:

# AND — both conditions must be true
ip.addr == 10.0.0.1 and tcp.port == 179

# OR — either condition
icmp or arp

# NOT — exclude
not arp and not stp

# Grouping with parentheses
(ip.src == 10.0.0.1 or ip.src == 10.0.0.2) and tcp.flags.reset == 1

# String contains (case-sensitive substring)
http.host contains "example"

# Regex match (PCRE)
http.request.uri matches "^/api/v[0-9]"

# Field exists
bgp.update.withdrawn_routes

SPAN Sessions on Cisco IOS-XE: Getting Traffic to Wireshark

You can’t run Wireshark on a Catalyst switch — you need to mirror traffic to an analysis port. Here’s the IOS-XE configuration for a local SPAN session mirroring a specific interface:

! Mirror traffic from Gi1/0/1 to Gi1/0/48 (laptop running Wireshark)
monitor session 1 source interface GigabitEthernet1/0/1 both
monitor session 1 destination interface GigabitEthernet1/0/48

! Verify
show monitor session 1

Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Gi1/0/1
Destination Ports      : Gi1/0/48
    Encapsulation      : Native
          Ingress      : Disabled

For RSPAN (remote SPAN across switches):

! Source switch
vlan 999
 remote-span
!
monitor session 1 source interface GigabitEthernet1/0/1 both
monitor session 1 destination remote vlan 999

! Destination switch
monitor session 1 source remote vlan 999
monitor session 1 destination interface GigabitEthernet1/0/48

Note that RSPAN injects VLAN tags into the mirrored traffic — if you’re analyzing Layer 2 protocol headers (STP, CDP), make sure you’re stripping the RSPAN VLAN in your analysis or filtering on vlan.id == 999 to isolate the mirrored frames.

For encrypted control plane traffic or traffic on routed interfaces, consider using Cisco EEM to trigger captures at specific events — the EEM scripting guide covers how to automate this kind of reactive capture.

Embedded Packet Capture on IOS-XE (No Laptop Required)

IOS-XE supports Embedded Packet Capture (EPC) — you can capture directly on the router or switch and export to a .pcap file for Wireshark analysis later:

! Define a capture buffer
monitor capture CAP buffer size 10 max-size 1500

! Define access list to filter what's captured
ip access-list extended CAP-ACL
 permit ip host 10.0.0.1 host 10.0.0.2
 permit ip host 10.0.0.2 host 10.0.0.1

! Associate ACL with capture
monitor capture CAP access-list CAP-ACL

! Attach to an interface
monitor capture CAP interface GigabitEthernet0/0/0 both

! Start capture
monitor capture CAP start

! Stop capture
monitor capture CAP stop

! Export to TFTP/FTP/flash
monitor capture CAP export tftp://192.168.1.10/capture.pcap

! Or save to flash and copy off
monitor capture CAP export flash:capture.pcap

! Verify capture state
show monitor capture CAP

Status Information for Capture CAP
  Target Type:
   Interface: GigabitEthernet0/0/0, Direction: both
   Status : Inactive
  Filter Details:
   IPv4
    Source IP:  10.0.0.1
    Destination IP: 10.0.0.2
   Protocol: any
  Buffer Details:
   Buffer Type: LINEAR (default)
   Buffer Size (in MB): 10
  Limit Details:
   Number of Packets to capture: 0 (no limit)
   Packet Capture duration: 0 (no limit)
   Packet Size to capture: 1500 (default)
   Maximum number of packets to capture per second: 1000

EPC is the right tool when you’re troubleshooting issues on a remote device where shipping a laptop isn’t feasible, or when the issue only happens at 2 AM during a maintenance window. The .pcap files open directly in Wireshark with all dissectors working normally.

Practical Workflow: From Symptom to Filter

Here’s the decision tree I use when sitting down with a fresh capture:

  1. Is it a Layer 2 issue? Start with stp, cdp, lldp, arp. Look for topology changes, native VLAN mismatches, ARP storms.
  2. Is it a routing protocol issue? Filter ospf or bgp. Check for NOTIFICATION messages, missing hellos, LSA storms.
  3. Is it a specific application or host? Use ip.addr == x.x.x.x first, then drill down to tcp.flags.reset or tcp.analysis.retransmission.
  4. Is it intermittent? Enable packet time display (Edit → Preferences → Protocols → Frame → Show time delta) and look for gaps correlated with the symptom.
  5. Is it performance-related? Start with tcp.analysis.flags to get an overview of all TCP anomalies, then drill into specific types.

Pair Wireshark analysis with IOS-XE show commands and syslog. A retransmission storm in Wireshark should correlate with interface error counters from show interface or log messages visible via your SNMP integration — if you’re running Control Plane Policing, high CoPP drop counters alongside TCP retransmissions often point to the same root cause.

Useful Wireshark Settings for Engineers

A few quality-of-life settings worth configuring:

  • Name resolution: Edit → Preferences → Name Resolution. Enable “Resolve network (IP) addresses” but be careful — DNS lookups during a live capture can slow Wireshark significantly on fast links.
  • Protocol color rules: View → Coloring Rules. Add rules for tcp.analysis.flags with a red background — it makes retransmissions visually pop.
  • Relative sequence numbers: Enabled by default. They make TCP stream analysis dramatically easier — don’t disable them.
  • Follow TCP Stream: Right-click any TCP packet → Follow → TCP Stream. Essential for reading application-layer data in context.
  • Statistics → IO Graphs: Plot packet rates over time against protocol filters. Use this to visualize STP BPDU rates spiking during a topology change event.
  • Statistics → Conversations: Immediately shows you which IP pairs are generating the most traffic — often the fastest way to find a rogue host or unexpected flow.

Final Thoughts

Wireshark filters aren’t something you memorize — they’re something you build a reference for and refine over time. Save your most-used filters as named profiles in Wireshark’s filter toolbar. When you’re dealing with a live incident, the last thing you want is to be fumbling through documentation trying to remember the OSPF type field.

The real skill is knowing which filter to reach for in the first 60 seconds of a capture. Start broad (protocol filter only), confirm you’re seeing the right traffic, then narrow down to the specific flags and fields that tell you what’s actually happening. For more on the IOS-XE control plane and how to protect it while you’re capturing, the CoPP guide is the companion read.

Enjoying this post?

Get more guides like this delivered straight to your inbox. No spam, just tech and trails.