Why Network Engineers Need Wireshark in Their Toolkit
When a router CLI shows you everything except the answer you need, Wireshark is where you go next. It doesn’t lie, it doesn’t summarize, and it doesn’t hide Layer 2 frames behind abstraction. Every hello packet, every TCP retransmit, every DHCP DISCOVER that never gets a reply — it’s all there in raw form.
The problem is that most engineers open Wireshark, get slammed with a wall of traffic, and give up on filters entirely. That’s leaving one of the most powerful diagnostic tools in networking half-used. This guide covers the Wireshark display filters that actually move the needle for Cisco IOS-XE work, plus how to get packets off the wire in the first place using SPAN on a Catalyst switch.
Step 1: Getting Packets to Wireshark via Cisco SPAN
Wireshark needs to see traffic it wouldn’t normally receive. On a Cisco Catalyst running IOS-XE, you do that with a SPAN (Switched Port Analyzer) session — also called port mirroring. You mirror one or more source ports to a monitor port where your capture machine sits.
Basic local SPAN on a Catalyst 9000:
! Mirror all traffic from Gi1/0/1 to Gi1/0/48
monitor session 1 source interface GigabitEthernet1/0/1 both
monitor session 1 destination interface GigabitEthernet1/0/48
! Verify the session
SW1# show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/1
Destination Ports : Gi1/0/48
Encapsulation : Native
Ingress : Disabled
If you need to capture a VLAN instead of a single port — useful for broadcast-domain-level issues — mirror the entire VLAN:
monitor session 1 source vlan 10 both
monitor session 1 destination interface GigabitEthernet1/0/48
For remote captures across the network, RSPAN (Remote SPAN) uses a dedicated VLAN to carry mirrored traffic to a remote switch. That’s a longer topic, but the principle is the same: get packets to a destination port where Wireshark can see them.
Once your capture machine is plugged into the destination port, open Wireshark and start capturing on that interface. You’ll see all traffic from the source — in both directions if you specified both.
Capture Filters vs. Display Filters
Before diving into filters, it’s important to know the difference between the two filter types in Wireshark:
- Capture filters (BPF syntax): Applied at capture time. Only matching packets are stored. Use these when you’re capturing to disk and want to reduce file size. Syntax is different from display filters.
- Display filters (Wireshark syntax): Applied after capture. All packets are stored, but only matching ones are shown. More flexible and forgiving.
For most troubleshooting workflows, you’ll use display filters. Capture everything first, then drill down. The rest of this guide covers display filter syntax.
Essential Display Filters for Everyday Troubleshooting
Filter by IP Address
ip.addr == 192.168.1.1 ! Any packet to or from this host
ip.src == 192.168.1.1 ! Only packets FROM this host
ip.dst == 10.0.0.1 ! Only packets TO this host
ip.addr == 192.168.0.0/24 ! Entire subnet
not ip.addr == 192.168.1.1 ! Exclude a host (useful to filter out your own machine)
Filter by Protocol
tcp ! All TCP traffic
udp ! All UDP traffic
icmp ! Ping / ICMP
icmpv6 ! ICMPv6 (neighbor discovery, router advertisements)
arp ! ARP requests and replies
Filter by Port
tcp.port == 22 ! SSH
tcp.port == 443 ! HTTPS
tcp.port == 179 ! BGP
udp.port == 161 ! SNMP
udp.port == 67 or udp.port == 68 ! DHCP
tcp.port == 49 ! TACACS+
Combining Filters
ip.addr == 10.0.0.1 and tcp.port == 179 ! BGP traffic to/from a specific peer
ip.src == 10.0.0.1 and not tcp.port == 22 ! Everything from host except SSH
(ip.addr == 10.0.0.1 or ip.addr == 10.0.0.2) and ospf ! OSPF between two routers
Cisco Protocol Filters
CDP — Cisco Discovery Protocol
CDP is a Layer 2 protocol that runs between directly connected Cisco devices. If you’re troubleshooting neighbor discovery or trying to confirm topology, capture CDP frames:
cdp
CDP frames are sent every 60 seconds by default. In the capture you’ll see the sending device’s hostname, IOS version, capabilities, and IP addresses — same information as show cdp neighbors detail but raw from the wire.
Verify CDP is running on the switch side:
SW1# show cdp interface GigabitEthernet1/0/1
GigabitEthernet1/0/1 is up, line protocol is up
Encapsulation ARPA
Sending CDP packets every 60 seconds
Holdtime is 180 seconds
LLDP — Link Layer Discovery Protocol
lldp
LLDP is the vendor-neutral equivalent to CDP, used in multi-vendor environments and required when connecting to non-Cisco infrastructure. The Wireshark dissector decodes LLDP TLVs cleanly, showing chassis ID, port ID, system name, and capabilities.
STP / RSTP — Spanning Tree Protocol
Spanning Tree issues — topology changes, port state transitions, root bridge elections — are notoriously hard to catch with CLI alone because they’re often transient. Wireshark gives you the full picture:
stp
In the STP packets you’ll see BPDUs with the root bridge ID, root path cost, port ID, and BPDU type. For RSTP, look for Proposal/Agreement handshakes (BPDU flags field: Proposal bit and Agreement bit).
If you’re seeing unexpected topology changes, filter specifically for TCN (Topology Change Notification) BPDUs:
stp.flags.tc == 1
This isolates BPDUs with the Topology Change flag set — telling you exactly which port is triggering the TC, which you can then trace back to the source.
To cross-reference what the switch sees during the capture:
SW1# show spanning-tree detail
VLAN0010 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32778, sysid 10, address aabb.cc00.0100
...
Number of topology changes 3 last change occurred 00:02:15 ago
from GigabitEthernet1/0/5
OSPF — Open Shortest Path First
OSPF runs directly over IP (protocol 89) and uses multicast addresses 224.0.0.5 (All OSPF Routers) and 224.0.0.6 (All Designated Routers). The Wireshark filter is simply:
ospf
Common OSPF troubleshooting scenarios with Wireshark:
Adjacency never reaches FULL state — capture Hello packets and check for mismatched parameters:
ospf.v2.type == 1 ! Only Hello packets (type 1)
In the Hello packet details, verify these match on both sides: Hello/Dead intervals, Area ID, Authentication type, Stub area flag, and Subnet mask. A mismatch in any of these prevents adjacency. This is a great complement to the IOS-XE debug commands — for a deeper look at OSPF adjacency failures, see our OSPF troubleshooting guide.
Flapping adjacency — filter for DBD and LS Update exchanges to see if the adjacency is cycling through Init → 2-Way → ExStart → Exchange → Loading:
ospf.v2.type == 2 ! Database Description (DBD) packets
ospf.v2.type == 4 ! LS Update packets
ospf.v2.type == 3 ! LS Request packets
On the router side, cross-reference with:
R1# debug ip ospf adj
*Jul 14 09:12:05.222: OSPF-1 ADJ Gi0/0: Neighbor 10.0.0.2, state INIT -> 2WAY
*Jul 14 09:12:05.224: OSPF-1 ADJ Gi0/0: Neighbor 10.0.0.2, state 2WAY -> EXSTART
BGP — Border Gateway Protocol
BGP runs over TCP port 179. Unlike OSPF, BGP is unicast and connection-oriented, making it easier to isolate:
bgp
Or filter for a specific BGP peer session:
ip.addr == 10.0.0.1 and bgp
In Wireshark, BGP messages are decoded with full detail — OPEN messages show AS number, Hold Time, and capabilities (4-byte AS, route refresh, multiprotocol extensions). UPDATE messages show withdrawn routes and NLRI. NOTIFICATION messages — the BGP equivalent of a hard reset — show the error code and subcode, which is essential for diagnosing why a session dropped.
Useful BGP-specific filters:
bgp.type == 1 ! OPEN messages only
bgp.type == 2 ! UPDATE messages only
bgp.type == 3 ! NOTIFICATION messages (session errors)
bgp.type == 4 ! KEEPALIVE messages
bgp.notify.major_error == 6 ! Cease notification (peer admin shutdown)
Understanding BGP behavior at the packet level pairs well with knowing the route policies in play — see our guide on how BGP runs the internet for context on what you’re seeing in those UPDATE messages.
HSRP / VRRP — First-Hop Redundancy
hsrp ! HSRP hellos and state changes
vrrp ! VRRP advertisements
HSRP uses UDP port 1985 on both versions. HSRPv1 multicasts to 224.0.0.2; HSRPv2 multicasts to 224.0.0.102. When capturing HSRP, you’ll see priority values and state in each hello — useful for confirming active/standby roles and catching unexpected preemption events.
DHCP
DHCP is UDP-based (client port 68, server port 67). The four-way exchange — DISCOVER, OFFER, REQUEST, ACK — is easy to follow in Wireshark:
dhcp
! Or use the older filter:
bootp
To find a specific client’s DHCP exchange by MAC address:
dhcp.hw.mac_addr == aa:bb:cc:dd:ee:ff
For DHCP starvation attacks (someone flooding DISCOVER packets), this filter shows the scope of it fast:
dhcp.option.dhcp == 1 ! Only DISCOVER messages
Practical Scenarios: End-to-End Troubleshooting Workflows
Scenario 1: Is OSPF actually sending Hellos?
A neighbor that never comes up can be caused by a configuration issue, an ACL dropping OSPF, or a Layer 2 problem. Wireshark answers this definitively:
! Filter: ospf.v2.type == 1
! What you should see: Hellos every 10 seconds (default) from each neighbor's interface IP
! What indicates a problem: Hellos from only one side, or no Hellos at all
If you see no Hellos, check that OSPF is enabled on the interface:
R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet Address 10.0.0.1/30, Area 0, Attached via Network Statement
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Hello due in 00:00:04
If you see Hellos from only one side, check for an ACL on the remote end blocking protocol 89 or the OSPF multicast addresses:
R2# show ip access-lists
! Look for entries denying protocol 89, or blocking 224.0.0.5 (All OSPF Routers)
Scenario 2: BGP session keeps dropping
! Filter: ip.addr == PEER_IP and bgp
! Look for: NOTIFICATION messages — they contain the exact error code
! BGP error code 4 = Hold Timer Expired (keepalives not arriving in time)
! BGP error code 6 = Cease (usually admin shutdown or reset)
If you see BGP OPEN followed immediately by NOTIFICATION, the session is being rejected. Expand the NOTIFICATION in Wireshark — Error Code and Error Subcode tell you exactly why. For example, Error Code 2 Subcode 2 means “Bad Peer AS” — the remote router is rejecting the session because your AS number doesn’t match what it expects.
Scenario 3: VLAN traffic not reaching the right ports
When packets should be on a VLAN but aren’t arriving, capture on the trunk port and filter by VLAN tag:
vlan.id == 10 ! Only traffic tagged with VLAN 10
vlan.id == 10 and ip.dst == 10.10.10.1 ! VLAN 10 traffic to a specific host
If you see frames on the trunk without the expected 802.1Q tag, the sending port may be misconfigured as an access port or the native VLAN is stripping the tag. Cross-reference with the interface config and VLAN database — our guide on VLAN segmentation covers the full config side of this.
Using tshark for CLI-Based Analysis
On a Linux jump box or monitoring server, tshark (the CLI version of Wireshark) lets you run the same filters without a GUI. This is especially useful for automated analysis or when you’re on a remote system via SSH:
# Install on Debian/Ubuntu
apt-get install -y tshark
# Live capture with display filter
tshark -i eth0 -f "host 10.0.0.1" -Y "ospf"
# Read a .pcap file and apply a display filter
tshark -r capture.pcap -Y "bgp.type == 3"
# Capture DHCP and show specific fields
tshark -i eth0 -Y "dhcp" -T fields -e dhcp.hw.mac_addr -e dhcp.option.dhcp -e ip.src
# Capture BGP NOTIFICATION messages, show error codes
tshark -r bgp_capture.pcap -Y "bgp.type == 3" \
-T fields -e ip.src -e ip.dst \
-e bgp.notify.major_error \
-e bgp.notify.minor_error
tshark output can be piped into grep, awk, or Python for scripted analysis — very useful for parsing large captures looking for specific events.
Pro Tips for Efficient Wireshark Workflows
Follow TCP Stream
Right-click any packet in a TCP session → “Follow” → “TCP Stream”. Wireshark reconstructs the full conversation in order, showing the raw data exchange. For BGP or TACACS+ sessions this is invaluable — you can read the negotiation payload directly.
Coloring Rules
Go to View → Coloring Rules to highlight protocol families. A standard setup highlights OSPF in green, BGP in blue, TCP retransmits in red, and ICMP unreachables in orange. This makes multi-protocol captures significantly easier to parse visually.
Export Specific Packets
File → Export Specified Packets lets you export only the packets matching the current display filter to a new .pcap file. This is the right way to share a subset of a capture with a vendor TAC case — strip it down to just the relevant traffic and send a clean file.
Statistics → Conversations
The Conversations view (Statistics → Conversations) gives you a ranked list of all IP pairs by byte count and packet count. In a network issue, this immediately shows you which hosts are talking most — useful for spotting unexpected bandwidth consumers or flood sources before you even apply a display filter.
Quick Reference: Common Wireshark Filters for Cisco Engineers
! Routing Protocols
ospf ! All OSPF
ospf.v2.type == 1 ! OSPF Hellos only
bgp ! All BGP
bgp.type == 3 ! BGP NOTIFICATIONs (session errors)
eigrp ! EIGRP
! Layer 2 / Discovery
cdp ! Cisco Discovery Protocol
lldp ! Link Layer Discovery Protocol
stp ! Spanning Tree (all types)
stp.flags.tc == 1 ! STP Topology Change BPDUs
! First-Hop Redundancy
hsrp ! HSRP (v1 and v2)
vrrp ! VRRP
! Management / Control
dhcp ! DHCP (all messages)
dns ! DNS queries and responses
ntp ! NTP sync traffic
snmp ! SNMP polls and traps
tcp.port == 22 ! SSH management sessions
tcp.port == 23 ! Telnet (should not be present)
tcp.port == 49 ! TACACS+ authentication
! Filtering Tricks
stp.flags.tc == 1 ! STP topology change flag
vlan.id == 10 ! 802.1Q tagged VLAN 10 frames
tcp.analysis.retransmission ! TCP retransmits (congestion/loss indicator)
tcp.analysis.zero_window ! TCP zero window (receiver buffer full)
icmp.type == 3 ! ICMP Destination Unreachable
Putting It All Together
Wireshark doesn’t replace the CLI — it complements it. The CLI tells you the current state; Wireshark tells you what happened to get there. An OSPF adjacency stuck in INIT makes sense once Wireshark shows you that Hellos are arriving from only one side. A BGP session that keeps dropping makes sense once Wireshark reveals NOTIFICATION messages with error code 4 (Hold Timer Expired) — which points you directly at an MTU or transit delay issue killing keepalives.
The filters in this guide cover the protocols you’ll encounter daily on Cisco IOS-XE networks. Build a profile of your go-to filters, save them as Wireshark filter buttons (the “+” next to the filter bar), and they become a one-click diagnostic that takes seconds to apply during a live outage.
Get comfortable with SPAN configuration on your Catalyst switches — once that’s set up, pulling a packet capture from any segment in your network becomes a standard part of the troubleshooting toolkit, not a last resort.
