NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
GS316EP: Port mirroring fails to capture traffic between two ports isolated in their own VLAN
Setup: I have two VLANs configured: VLAN 1 (default): most ports, including my normal LAN traffic VLAN 10: exactly two ports (Port 3 and Port 4), used for an isolated point-to-point link betwe...
Wanted to follow up with final results and where I landed, since you both took real time to help troubleshoot this.
StephenB — tried your suggestion of swapping VLAN roles (moving the LAN to the isolated VLAN, moving the WAN link to VLAN 1) to test whether VLAN 1 had privileged status in the mirroring engine. Ran into an unrelated snag getting there (moving the Management VLAN to the isolated segment locked me out of the switch GUI, since that segment has no path back to the internal management subnet) — had to revert before completing a clean test. But I did run one more direct test: added a third plain port to the isolated VLAN (no mirroring involved, just normal VLAN membership) and connected a separate laptop with Wireshark directly. Same result as mirroring — only broadcast/ARP traffic visible, zero unicast traffic between the two isolated-VLAN ports. That's now been confirmed independently across two different capture devices (Security Onion sensor + a separate Wireshark laptop) and two different capture methods (formal port mirroring + plain VLAN bystander port), so I'm confident this isn't a config issue on my end.
schumaku — appreciate the SPAN/RSPAN/ERSPAN context. It sounds like what I'm hitting is a limitation of local SPAN on this switch specifically for a minimal two-port isolated VLAN, without the more advanced RSPAN/ERSPAN capabilities that would be needed to work around it on this class of hardware.
Where I landed: Going with a passive network tap (SharkTap Gigabit Network Sniffer) installed inline between my modem and router's WAN port instead. Since it's electrically passive with no VLAN/switching logic involved, it sidesteps this limitation entirely.
Thanks again for the troubleshooting help — even though we didn't land on a switch-side fix, the process ruled out a lot of possibilities and gave me confidence the tap is the right call rather than a workaround for something I misconfigured. Marking this as resolved on my end.
Thank you both for the detailed responses — really appreciate the expertise.
StephenB — you're right that mirroring both Port 3 and Port 4 was redundant since it's a single pass-through link. I've simplified to just mirroring Port 3.
schumaku — good catch on Port 16 needing to be a clean, single-purpose mirror destination. I reverted it to a plain untagged member of VLAN 1 only (its original, working configuration), removed it entirely from VLAN 10, and confirmed via the PVID table that it's back to a proper dedicated mirror port with no other VLAN membership.
Unfortunately, even with this cleaner configuration, the result is unchanged: mirroring from Port 1 (my normal LAN VLAN) to Port 16 works perfectly, but mirroring from Port 3 (the isolated two-port VLAN carrying my modem-to-router link) still captures zero packets on the destination — confirmed via tcpdump on the receiving end, both with and without VLAN tag filtering, over multiple 60+ second active-traffic test windows.
For what it's worth, I also confirmed via port statistics that Port 3 has substantial live traffic flowing through it the entire time — so the switch is definitely seeing and forwarding the traffic normally, it's just not reaching the mirror destination.
At this point I've tested: basic mirror config, VLAN membership on source and destination, tagged vs. untagged handling, and port count in the isolated VLAN (2 vs. 3 members) — all with the same negative result.
If either of you has seen this specific pattern before, or knows of a firmware setting that might affect it, I'd love to hear it — otherwise I'll likely move forward with a passive network tap for this particular link, since the mirroring approach doesn't seem to be working here.
Thanks again for taking the time.
For what it's worth, I also confirmed via port statistics that Port 3 has substantial live traffic flowing through it the entire time — so the switch is definitely seeing and forwarding the traffic normally, it's just not reaching the mirror destination.
Try reversing the VLAN - using that for the LAN network, and using the default VLAN 1 for ports 3,4. Then see if the mirroring behaves differently.
Thank you StephenB. I'll give this a try when I'm able to in the next few days and will report the results.
Wanted to follow up with final results and where I landed, since you both took real time to help troubleshoot this.
StephenB — tried your suggestion of swapping VLAN roles (moving the LAN to the isolated VLAN, moving the WAN link to VLAN 1) to test whether VLAN 1 had privileged status in the mirroring engine. Ran into an unrelated snag getting there (moving the Management VLAN to the isolated segment locked me out of the switch GUI, since that segment has no path back to the internal management subnet) — had to revert before completing a clean test. But I did run one more direct test: added a third plain port to the isolated VLAN (no mirroring involved, just normal VLAN membership) and connected a separate laptop with Wireshark directly. Same result as mirroring — only broadcast/ARP traffic visible, zero unicast traffic between the two isolated-VLAN ports. That's now been confirmed independently across two different capture devices (Security Onion sensor + a separate Wireshark laptop) and two different capture methods (formal port mirroring + plain VLAN bystander port), so I'm confident this isn't a config issue on my end.
schumaku — appreciate the SPAN/RSPAN/ERSPAN context. It sounds like what I'm hitting is a limitation of local SPAN on this switch specifically for a minimal two-port isolated VLAN, without the more advanced RSPAN/ERSPAN capabilities that would be needed to work around it on this class of hardware.
Where I landed: Going with a passive network tap (SharkTap Gigabit Network Sniffer) installed inline between my modem and router's WAN port instead. Since it's electrically passive with no VLAN/switching logic involved, it sidesteps this limitation entirely.
Thanks again for the troubleshooting help — even though we didn't land on a switch-side fix, the process ruled out a lot of possibilities and gave me confidence the tap is the right call rather than a workaround for something I misconfigured. Marking this as resolved on my end.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
