Every network engineer has been there: something is breaking, logs are unhelpful, and the ticket is on fire. Wireshark is your last line of defense — the tool that lets you see exactly what’s happening on the wire. But knowing how to run it and knowing how to use it are two different things. The right filter turns a wall of noise into a focused, actionable capture. This guide covers the essential Wireshark filters and techniques specifically for Cisco IOS-XE environments, including how to capture traffic directly on the router when you can’t get a SPAN port.
Why Filters Matter More Than You Think
On a busy link, Wireshark can capture thousands of frames per second. Without filters, you’re drowning. With the right display filters, a 500MB capture file becomes a 50-packet story. There are two levels of filtering to understand:
- Capture filters (BPF syntax): Applied at capture time. Reduces what gets written to disk. Less flexible but essential for high-speed links.
- Display filters: Applied after capture. More expressive syntax. You can slice and dice without losing the original data.
Most engineers live in display filters. Capture filters matter when you’re running Cisco IOS-XE Embedded Packet Capture (EPC) — which is often the only option when you can’t plug a laptop in directly.
Cisco IOS-XE Embedded Packet Capture (EPC)
EPC lets you capture traffic on the router itself and export a PCAP file for analysis in Wireshark. It’s invaluable when a SPAN session isn’t feasible or you’re working remotely. Here’s the full workflow for a typical troubleshooting scenario:
Step 1: Define the Capture Buffer and Access List
! Optional: filter with ACL to limit what gets captured
ip access-list extended CAPTURE_FILTER
permit ip host 192.168.10.5 host 10.0.0.1
permit ip host 10.0.0.1 host 192.168.10.5
! Create the capture buffer (4MB, linear — fills and stops)
monitor capture MYCAP buffer size 4 linear
! Alternatively, use a circular buffer to keep the last N MB
monitor capture MYCAP buffer size 10 circularStep 2: Define the Capture Point
! Capture on an interface, both directions
monitor capture MYCAP interface GigabitEthernet1 both
! Attach the ACL filter (optional but recommended on busy links)
monitor capture MYCAP access-list CAPTURE_FILTERStep 3: Start, Wait, Stop
monitor capture MYCAP start
! ... wait for the event you're troubleshooting ...
monitor capture MYCAP stopStep 4: Check What You Captured
show monitor capture MYCAP buffer brief
------------------------------------------------------------
# size timestamp src mac dst mac dscp src ip dst ip prot
1 74 0.000000 78:ba:f9:a1:22:01 ff:ff:ff:ff:ff:ff 0 192.168.10.5 255.255.255.255 17
2 90 0.002341 78:ba:f9:a1:22:01 10:1b:54:c9:33:aa 0 192.168.10.5 10.0.0.1 17
3 102 0.003112 10:1b:54:c9:33:aa 78:ba:f9:a1:22:01 0 10.0.0.1 192.168.10.5 6Step 5: Export to PCAP
! Export to flash or bootflash
monitor capture MYCAP export flash:mycap.pcap
! Then SCP it to your workstation
Once you have the PCAP, load it in Wireshark and apply display filters to find what you need. The sections below are organized by the protocol problems you’re likely chasing.
STP and RSTP Filters
Spanning Tree issues cause some of the most frustrating outages — loops, intermittent connectivity, ports bouncing. These filters help you quickly identify what’s happening.
! Display all STP/RSTP BPDUs
stp
! Filter for Topology Change Notifications (TCNs) — the first thing to check during a flap
stp.flags.tc == 1
! Show BPDUs from a specific bridge
stp.bridge.mac == aa:bb:cc:dd:ee:ff
! Find BPDUs with the TC ACK flag set
stp.flags.tcack == 1
! Filter for Rapid PVST+ specifically
stp.type == 0x02
! Root bridge announcement BPDUs (port role = designated, proposal flag set)
stp.flags.proposal == 1On the IOS-XE side, correlate with:
show spanning-tree detail | include ieee|occur|from|is exec
VLAN0010 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32778, sysid 10, address 10:1b:54:c9:33:aa
Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 3 last change occurred 00:14:23 ago
from GigabitEthernet1/0/3If topology changes are happening frequently, the from line tells you which interface is generating them. Cross-reference that with the Wireshark TCN filter above to see the exact BPDUs.
OSPF and BGP Filters
Routing protocol issues often show up as adjacency failures or route flaps. Wireshark can confirm whether control plane packets are actually being exchanged, ruling out CPU or software issues vs. actual link problems. For a deeper dive on OSPF adjacency troubleshooting, check our dedicated OSPF troubleshooting guide.
OSPF Filters
! All OSPF traffic
ospf
! Only Hello packets (type 1) — confirms neighbors are talking
ospf.msg.type == 1
! Database Description (DBD) packets — exchange during adjacency formation
ospf.msg.type == 2
! Link State Update (LSU) — when routes are being flooded
ospf.msg.type == 4
! Filter by OSPF router ID
ospf.srcrouter == 10.0.0.1
! Find OSPF packets with mismatched area (often causes adjacency failure)
ospf.hello.area_id != 0.0.0.0IOS-XE command to correlate:
debug ip ospf hello
*Sep 18 14:22:01.441: OSPF-1 HELLO Gi1/0/1: Rcv hello from 10.0.0.2 area 0 192.168.1.1
*Sep 18 14:22:01.441: OSPF-1 HELLO Gi1/0/1: Dead timer is wrong (40 != 30)
*Sep 18 14:22:01.442: OSPF-1 HELLO Gi1/0/1: Mismatching timer with 10.0.0.2That dead timer mismatch is a classic OSPF adjacency killer — and you’d see it in the OSPF Hello packet in Wireshark under ospf.hello.dead_interval.
BGP Filters
BGP runs over TCP port 179. For more context on BGP behavior and community manipulation, see our BGP protocol deep dive.
! All BGP traffic
bgp
! BGP OPEN messages — session establishment
bgp.type == 1
! BGP UPDATE messages — route advertisements and withdrawals
bgp.type == 2
! BGP NOTIFICATION messages — the session is dying (always investigate these)
bgp.type == 3
! BGP KEEPALIVE messages — filter these OUT when looking for real traffic
bgp.type != 4
! BGP session between specific peers
ip.addr == 10.0.0.1 && ip.addr == 10.0.0.2 && bgp
! BGP NOTIFICATION with error code 6 (Cease) — peer reset
bgp.type == 3 && bgp.error_code == 6DHCP and DNS Filters
Client connectivity issues often trace back to DHCP or DNS. These are high-volume protocols, so good filters are essential.
DHCP
! All DHCP traffic (UDP 67/68)
dhcp
! DHCP Discover — client looking for a server
dhcp.option.dhcp == 1
! DHCP Offer — server responding
dhcp.option.dhcp == 2
! DHCP Request
dhcp.option.dhcp == 3
! DHCP ACK — lease confirmed
dhcp.option.dhcp == 5
! DHCP NAK — lease denied
dhcp.option.dhcp == 6
! Filter by client MAC address (useful when tracking a specific device)
dhcp.hw.mac_addr == aa:bb:cc:dd:ee:ffOn IOS-XE, correlate with:
show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type State Interface
Hardware address/
User name
192.168.1.100 0100.5056.a1.22.01 Sep 25 2026 08:30 AM Automatic Active Gi1/0/10
192.168.1.101 0100.5056.a1.33.02 Sep 25 2026 09:15 AM Automatic Active Gi1/0/11
show ip dhcp conflict
IP address Detection method Detection time VRF
192.168.1.100 Gratuitous ARP Sep 18 2026 02:14 PMDHCP conflicts and stale bindings are common culprits. The conflict table plus a Wireshark capture showing DHCP NAKs tells the full story.
DNS
! All DNS traffic
dns
! Only DNS queries (not responses)
dns.flags.response == 0
! Only DNS responses
dns.flags.response == 1
! DNS queries for a specific name
dns.qry.name == "example.com"
! DNS responses with NXDOMAIN (name doesn't exist)
dns.flags.rcode == 3
! DNS responses with SERVFAIL
dns.flags.rcode == 2
! Slow DNS responses (RTT over 500ms) — requires column or time delta analysis
frame.time_delta > 0.5 && dns.flags.response == 1TCP Troubleshooting Filters
TCP issues are common and Wireshark’s built-in TCP analysis makes them easier to spot. Enable Analyze → Expert Information first to see automatic anomaly detection.
! TCP RST — connection forcibly terminated (firewall, app crash, port closed)
tcp.flags.reset == 1
! TCP SYN with no SYN-ACK response (connection refused or filtered)
tcp.flags.syn == 1 && tcp.flags.ack == 0
! Retransmissions — packet loss indicator
tcp.analysis.retransmission
! Out-of-order segments
tcp.analysis.out_of_order
! Duplicate ACKs — precursor to fast retransmit
tcp.analysis.duplicate_ack
! Zero window — receiver buffer full, flow control kicking in
tcp.analysis.zero_window
! TCP window updates (receiver expanding the window)
tcp.analysis.window_update
! All TCP expert analysis events in one filter
tcp.analysis.flagsCombining these: if you see retransmissions followed by zero window events, you have a congestion problem at the receiver. If you see RSTs immediately after SYN, it’s a firewall or application issue. If retransmissions appear with no zero window, it’s likely loss on the link.
QoS and DSCP Filters
For QoS troubleshooting, being able to verify DSCP markings are correct is critical. A packet incorrectly marked as Best Effort (DSCP 0) will get dropped or delayed in a congested network. Our Cisco QoS guide covers marking and queuing in detail — these filters let you verify the markings are actually making it through the network.
! Filter for Expedited Forwarding (EF = DSCP 46) — VoIP RTP
ip.dscp == 46
! Filter for CS3 (DSCP 24) — call signaling
ip.dscp == 24
! Best Effort — possibly remarked or mislabeled
ip.dscp == 0
! Show all traffic NOT marked as best effort
ip.dscp != 0
! DSCP AF class 4 high drop (DSCP 38) — video
ip.dscp == 38
! All traffic with any DSCP marking set
ip.tos != 0x00On IOS-XE, verify markings at the policy level:
show policy-map interface GigabitEthernet1/0/1
GigabitEthernet1/0/1
Service-policy output: WAN_EGRESS
Class-map: VOICE (match-all)
Match: dscp ef (46)
Queuing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 42187/6749920
Class-map: CALL_SIGNALING (match-all)
Match: dscp cs3 (24)
Queuing
(pkts output/bytes output) 1204/120400VoIP and RTP Filters
SIP and RTP issues — call drops, one-way audio, choppy voice — are notoriously hard to diagnose without a packet capture. These filters let you trace a call from INVITE to BYE and isolate exactly where it falls apart.
! SIP signaling
sip
! SIP INVITE (call setup)
sip.Method == "INVITE"
! SIP BYE (call teardown)
sip.Method == "BYE"
! RTP media streams
rtp
! RTP jitter analysis — use Telephony → RTP → RTP Streams in Wireshark GUI
! But for raw filter:
rtp && ip.src == 10.1.1.5
! RTCP — used for QoS statistics
rtcp
! Filter SIP and RTP together to track a full call
sip || rtp || rtcpUseful Compound Filters
Real troubleshooting usually requires combining protocol filters with IP address, port, and time constraints.
! Traffic between two specific hosts only
ip.addr == 10.0.0.1 && ip.addr == 10.0.0.2
! Exclude your own management traffic from results
!(ip.addr == 192.168.100.10) && !(ip.addr == 192.168.100.1)
! HTTP or HTTPS on non-standard ports
(tcp.port == 8080 || tcp.port == 8443) && http
! All traffic from subnet 10.10.0.0/24
ip.src >= 10.10.0.0 && ip.src <= 10.10.0.255
! Large packets that might indicate MTU issues
ip.len > 1400
! Fragmented IP packets (MTU/PMTUD problem)
ip.flags.mf == 1 || ip.frag_offset > 0
! ICMP unreachable — useful for finding blocked paths
icmp.type == 3
! ARP traffic (useful for finding duplicate IP issues)
arpWorking with EPC on High-Speed Interfaces
On Cat9K and ASR platforms, EPC has some limitations at high throughput. A few IOS-XE-specific tips:
! Check current capture status
show monitor capture
Status Information for Capture MYCAP
Target Type:
Interface: GigabitEthernet1/0/1, Direction: both
Status : Inactive
Filter Details:
IPv4 ACL: CAPTURE_FILTER
Buffer Details:
Buffer Type: LINEAR (default)
Buffer Size (in MB): 4
Limit Details:
Number of Packets to capture: 0 (no limit)
Duration to capture (in seconds): 0 (no limit)
Packet Length to capture (in bytes): 0 (entire packet)
! Limit capture to first 100 bytes per packet (headers only) — better performance
monitor capture MYCAP buffer size 10 limit packet-len 100
! Stop after 5000 packets
monitor capture MYCAP limit packets 5000
! Auto-stop after 60 seconds
monitor capture MYCAP limit duration 60
! Check buffer fill status during active capture
show monitor capture MYCAP buffer
Capture buffer status:
Bytes used: 2142688 of 4194304 (51%)
Packets captured: 14832Exporting Filters as Profiles
One underused Wireshark feature: save your filters as a Capture Profile (Edit → Configuration Profiles). Create profiles for different troubleshooting scenarios — one for STP analysis, one for VoIP, one for BGP troubleshooting. Your column layout, color rules, and filter bookmarks all travel with the profile. When someone hands you a PCAP at 2am, you switch profiles and the right columns appear automatically.
The Cheat Sheet Summary
| Scenario | Display Filter |
|---|---|
| STP topology change | stp.flags.tc == 1 |
| OSPF adjacency debug | ospf.msg.type == 1 |
| BGP session drop | bgp.type == 3 |
| DHCP failure | dhcp.option.dhcp == 6 |
| DNS NXDOMAIN | dns.flags.rcode == 3 |
| TCP RST storm | tcp.flags.reset == 1 |
| Packet loss indicator | tcp.analysis.retransmission |
| DSCP mismatch (voice) | ip.dscp != 46 && rtp |
| MTU/fragmentation | ip.flags.mf == 1 |
| All TCP anomalies | tcp.analysis.flags |
Conclusion
Wireshark without filters is like trying to drink from a fire hose. With the right filters, it becomes a surgical tool. The combination of Cisco IOS-XE’s Embedded Packet Capture and Wireshark’s display filters gives you the ability to diagnose virtually any network problem — even on live production devices without a maintenance window. Build up your profile library, practice the BPF capture syntax for when you need to limit buffer usage on high-speed links, and keep this filter reference close when the next ticket fires at 3am.
