And a big +1 to this. Would love to be able to filter VLAN's as well
as we have listen to physical interfaces that have other interfaces
mirrored that include some unwanted VLAN's.James
I thought, if you are hoping to filter out traffic by VLANs, you can do a
PCAP filter. Is that not true?
In my case, we do want to process different VLANs, but we need to log
through which links the traffic was observed.
I thought, if you are hoping to filter out traffic by VLANs, you can do a
PCAP filter. Is that not true?
That’s correct, you can include or exclude VLAN traffic using Bro capture filters. I believe PacketFilter::restricted_filter from the PacketFilter framework is for doing just that (https://www.bro.org/sphinx/scripts/base/frameworks/packet-filter/main.bro.html).
In fact, you need to use the VLAN keyword to do any IP filtering of VLAN tagged (802.1q) traffic. It won’t work correctly otherwise.
You can specify VLAN ID’s also, ex: not (van 100 or vlan 101).
You may also encounter multiple VLAN tags on a single packet, there you’ll need the correct number of VLAN keywords, ex: (vlan 100 and vlan 101).
You could see asynchronous tagging where traffic from a particular stream heading in one direction has 1 tag and traffic going in the opposite direction has 2 or more, so directionality matters also.
This is all true for MPLS encapsulated traffic too. The filtering behavior is basically the same from what I’ve seen.
In my case, we do want to process different VLANs, but we need to log
through which links the traffic was observed.
I agree, it would be helpful to have VLAN ID(’s) available in conn records if they are present. Its valuable info when your troubleshooting tap and traffic mirroring configurations in complex environments.
Adam