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 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!
