802.1q for packet filtering

separate thread to earlier answers....

1. any NIC should be able to "see" a 802.1Q packet once it is operating in promiscuous mode - but some drivers cut off over length packets. but any analyser s/w then has to know what to do with it.

if you want to try this, use your favorite sniffer - or download the trial of Netassyst (based on Sniffer Pro code)from sniffer.com - it works for 7 or

14 days without the magic key - i use this at work and it does pick up VLANs.

FWIW i suspect that using an 802.1q NIC with a sniffer may strip the tags before they get to the sniffer - depends on whether the driver gives you a logical card looking at a vlan or a port. or, even more likely, the driver writer didnt think of this and it will crash and burn....

1. you need some way to get the packets to arrive at the sniffer - an inline hub may work (but there are some that dont like long packets), or a specialsed device called a "network tap".

setting up a SPAN port means you will see copies of something - usually a port or a vlan is feasible, but there may be others depending on the switch and the config. Some of those would send you packets complete with 802.1q tags, some would strip them 1st (again switch dependent).

if you dont have any of these then you will only see what arrives at the port your PC is plugged into

in a typical switched network this is all multicast / broadcast in any VLAN sent to your port, anything sent to your PC if you have a protocol stack set up (which may be per VLAN), and any packets to MAC addresses that have aged out of the switch tables.

In article , stephen wrote: :setting up a SPAN port means you will see copies of something - usually a :port or a vlan is feasible, but there may be others depending on the switch :and the config. Some of those would send you packets complete with 802.1q :tags, some would strip them 1st (again switch dependent).

Seeing your message triggered a memory: in some switches/routers, when you SPAN or RSPAN, the source MAC address of each packet will be the MAC associated with the output interface of the SPAN, rather than the original source MAC. This can be sometimes be a pain in the fundament, but sometimes you are able to deduce the missing information.