SharkTap vs. Switch Mirror: The Network Tap That Finally Shows the Truth
- Alex Khachaturian
- Nov 12, 2025
- 6 min read
Promise: One tool, full picture. A network tap like SharkTap lets you see both sides of the conversation, without changing the network, so you can solve “ghost” BACnet/IP and controller issues fast.
TL;DR
Switch mirrors (SPAN) and NIC captures miss packets or show only one side; taps show the entire exchange.
SharkTap is inline, stealth, and aggregates both directions to your analyzer for true full-duplex visibility.
With a tap + Wireshark, you find floods, retries, broadcast storms, and protocol errors in minutes, not days.
Key Takeaways
A network tap is the only capture method that guarantees symmetric, loss-free visibility under load.
“Sniffing” from a device NIC or a SPAN port can hide drops, reorder packets, and distort timing.
On BACnet/IP, a tap exposes Who-Is/I-Am floods, unicast retries, duplicate device IDs, and noisy gateways.
Taps are electrically transparent and fail-safe; if your laptop dies, the building stays up.
Faster root cause = fewer callbacks, tighter change documentation, and better trust with owners.
Quick Links
Next Read
Why Capturing from a NIC or Switch Mirror Can Lie
Capturing on a device NIC
Sees only traffic to and from that device (plus some broadcasts).
Misses conversations between other devices that affect the segment.
The device’s OS/network stack can reorder, buffer, or drop before your capture sees it, hiding wire-level timing problems.
Capturing on a switch mirror (SPAN)
Under load, SPAN is best-effort and may drop or throttle packets.
Aggregated full-duplex streams mirrored to a single 1G SPAN can oversubscribe the monitor port.
Timestamps reflect mirror/queue delay, not true on-the-wire timing.
Some errors (FCS, runts/giants) never traverse SPAN.
Capturing with an inline network tap (SharkTap)
Physically sits between endpoints and passes traffic through unchanged.
Exposes both directions concurrently, preserving timing and low-level anomalies.
Many taps aggregate A→B and B→A onto one monitor port for simple single-NIC capture.
Power-loss failsafe (pass-through) designs keep the building online even if your laptop dies.
Bottom line: if you need courtroom-grade truth for control-network issues, you need a network tap, not a mirror, and not a one-sided NIC capture.
How the Protocol Works (Metaphor): The Two-Way Wiretap vs. Speakerphone
Think of two people in different rooms speaking through a wall intercom.
NIC capture on one device is like pressing your ear to one speaker, you hear what that person says and whatever echoes come back, but you don’t hear the other room’s side clearly or on the same clock.
Switch mirror is like asking a receptionist to retell everything both people said, fast, but when it gets busy, pieces get paraphrased or lost.
Network tap (SharkTap) is a two-way wiretap placed in the cable between rooms. You hear each syllable from both sides, with the true timing and overlaps. That’s how you catch interruptions, collisions, and stutters.
Quick Win: 10-Minute Tap Capture Checklist
Insert tap between controller and access switch (controller → Tap Port A, switch → Tap Port B).
Connect your laptop to the tap’s Monitor output.
Start Wireshark with a ring buffer (e.g., 100 MB files × 50 files).
Set display filter udp.port == 47808 || arp || icmp for BACnet/IP triage.
Note top talkers (Endpoints, Conversations).
Trigger the symptom (logon, schedule change, peak time).
Mark time when alarms occur.
Stop capture → Save PCAP → Tag evidence with device, port, and time.
Result: In one visit, you’ll know if it’s a broadcast storm, duplicate device ID, chatty front end, noisy gateway, or switch issue.
Recommended Gear
Step-by-Step Playbook: From Insert to Insight
1) Plan the Observation Point
Start where symptoms present (problem controller, chatty gateway, front-end uplink).
If the path is controller → access switch → core, first tap controller↔access to catch local issues (duplex, retries, floods). Move upstream if clean.
2) Insert the Tap (Safely)
Announce a brief maintenance window for that port pair.
Power the tap, then move cables: Controller ↦ Tap A, Switch ↦ Tap B.
Connect laptop to Monitor port. Verify link LEDs pass-through.
3) Harden Your Capture
Disable Wi-Fi and other NICs; select the tap NIC.
Use Wireshark ring buffer (Files: 50; Size: 100 MB) to avoid giant PCAPs.
Optional: enable monitor NIC promiscuous mode (default).
4) Establish Baseline (60–120 seconds)
Filters off; watch the live IO graph.
Note Link-Local, ARP cadence, DNS/MDNS. Stable? Good. Noisy? Tag it.
5) Focus for BACnet/IP
Display filters:
udp.port == 47808 (BACnet/IP)
bacnet (if you have the dissector profile enabled)
arp || icmp for reachability noise
Color rules: mark I-Am, Who-Is, ReadProperty, I-Have, UnconfirmedCOVNotification.
6) Trigger and Observe
Log into the front end, nudge a schedule, or wait for the natural alarm window.
Use Endpoints and Conversations (Statistics menu) to rank talkers.
Check Follow UDP Stream to see one dialog end-to-end.
Compare Tx/Rx timing on both sides. True tap = true timing.
7) Decide the Likely Fault Domain
Broadcast flood: Who-Is/I-Am saturating; often misconfigured BBMD/FD or duplicate Device IDs.
Server-pushed storms: Front end hammering ReadProperty on short intervals.
Gateway echo loops: Multiple paths between subnets; BBMD loops.
Rate/duplex mismatch: Late collisions, retries, FCS errors (tap reveals wire-level anomalies better than SPAN).
Non-BAS noise: MDNS/SSDP or camera chatter polluting a control VLAN.
8) Prove It
Save PCAP with a clear filename: SITE-CTRL12-TAP-2025-11-08-1403Z.pcapng.
Screenshot Endpoints/Conversations top-talkers.
Write a 2-line plain-English summary plus a “Before/After” capture after the fix.
Wireshark: Network Tap & See the Wasted Packets
What you’ll only see with a tap:
True simultaneity: overlapping frames A→B and B→A that mirrors often serialize.
Micro-bursts: 2–10 ms floods that SPAN statistically drops.
FCS/physical errors (when supported): SPAN often strips them; taps preserve evidence.
Retry patterns: repeated unicast reads with consistent inter-retry gaps = latency/queueing problem.
Quick Filters
BACnet/IP: udp.port == 47808
Who-Is/I-Am storm: bacnet.service == 8 || bacnet.service == 0
Talker ranking: Statistics → Endpoints → IPv4 (sort by Packets/Bytes)
Conversation health: Statistics → Conversations → UDP → Filter to 47808
Troubleshooting (Symptom → Cause → Fix)
Symptom: “Server capture looks normal, but devices still drop.”
Cause: NIC capture is one-sided; missing opposite-direction timing and micro-bursts.
Fix: Insert a network tap inline at the device↔switch and capture both directions.
Symptom: “SPAN shows nothing unusual; issues spike at noon.”
Cause: SPAN oversubscription or queueing hides short floods.
Fix: Use a tap; enable ring buffer; capture during the noon spike.
Symptom: “BACnet floods random hours.”
Cause: Misconfigured BBMD/FD or duplicate Device IDs; Who-Is/I-Am storms.
Fix: De-duplicate IDs; correct BBMD tables; rate-limit broadcasts at gateways.
Symptom: “High retries and delayed responses.”
Cause: Duplex mismatch or noisy VLAN (cameras/MDNS).
Fix: Hard-set duplex/speed per design; isolate BAS to a clean VLAN.
Symptom: “Tap installed, but I only see one direction.”
Cause: Using a non-aggregating tap with single-NIC capture.
Fix: Use an aggregating tap (like SharkTap) or two-NIC capture with merge.
Symptom: “Capture stops when laptop sleeps.”
Cause: Power management on the USB NIC.
Fix: Disable NIC sleep; use wired power; keep screen awake during tests.
FAQ
Does a tap change my network?
No. A proper tap is passive/transparent. It doesn’t participate in ARP, doesn’t add a MAC, and fails pass-through on power loss.
Why not just use a cheap switch and mirror?
SPAN is fine for low-load observation. For root cause, you need guaranteed, symmetric, timestamp-faithful visibility. Only a tap provides that.
Can I see TLS/HTTPS traffic from vendor front ends?
Headers, SNI, and TCP behavior, yes; encrypted payloads, no. But even encrypted flows reveal rate limits, retries, and contention.
Will a tap help with BACnet MS/TP (RS-485)?
MS/TP is serial. Use a serial line analyzer for that. For BACnet/IP and all Ethernet-based vendor systems, the SharkTap is ideal.
Is it safe to leave a tap in place?
Yes, if secured and documented. Many leave taps on chronic circuits for recurring captures.
Field Checklist
□ Identify suspect link (controller, BBMD, uplink).
□ Announce 2–5 min maintenance window.
□ Power tap; move cords: CTRL→Tap A, SW→Tap B.
□ Laptop → Tap Monitor; Wi-Fi off.
□ Wireshark ring buffer on; BACnet/IP profile loaded.
□ Capture at baseline 120 s; then during symptom window.
□ Save PCAP; export Endpoints/Conversations.
□ Two-line summary; attach “Before/After” after fix.
□ Revert cables; label evidence in ticket.
Results & ROI
MTTR drops from days to hours: one visit, one capture, one fix.
Fewer parts swapped: evidence distinguishes network path issues from device faults.
Cleaner vendor conversations: PCAPs end the “it’s not us” loop.
Trust & transparency: owners see exactly what’s happening on their network.
Process maturity: each PCAP becomes a reusable case in your team’s knowledge base.
Wrap-Up
If you only “listen” from one chair, you’ll miss the argument. A network tap like SharkTap hears both people, at the same time, with the real timing that exposes floods, retries, and lies that SPAN and NIC captures can’t show. Put the tap in your bag, and make the invisible obvious.
Comments