is vlan bpf broken in bro

Per this thread:

tcpdump can’t process vlan filters. Testing confirms this.

From link:

tcpdump -i eth0 -Uw - | tcpdump -en -r - vlan 4

This works and displays only vlan 4 stuff. The reverse does not:

tcpdump -i eth0 -Uw - "vlan 4" |tcpdump -en -r -

This displays ALL vlans tagged in the traffic, and not just vlan 4.

This is on RHEL 7. Apparently there are some issues with x86_64 vlan acceleration.

The short of it: Will bro respect vlan filters, or does it have the same issue that tcpdump and libpcap seem to have?

If it's acquiring packets through straight libpcap on linux and linux has an issue with vlan handling, then yes, you will have the same problem. If you are using some alternate packet handling mechanism then the problem with likely not be there. Are you using the default libpcap on your distro?


Libpcap from ntop for pf_ring, on a vmxnet3 interface. ixgbe nics have rxvlan option in ethtool which disables acceleration, but these are all virtual nics; I cant set rx-vlan-offload (bad command, despite being listed in ethtool -k), so I think I am out of luck for filtering.

Ah, that's a much more narrow case than I thought you were referring to. You might be out of luck without deeper changes to things (or you could use netmap, it might work there!).


Ive actually tried this with stock libpcap, and have the same results. I just checked an ixgbe nic I have laying around, and I get the same results, without any option to set rxvlan…

From the various boxes I have tried so far (e1000e, ixgbe, vmxnet3), all of these exhibit the same filtering problem with vlans. Maybe netmap can handle it, but it doesnt appear that libpcap (pf_ring or not) can properly handle vlan filtering… Since we are going with af_packet, netmap is unfortunately off the table.

Since we are going with af_packet, netmap is
unfortunately off the table.

In case you are using AF_Packet, unfortunately VLANs won't be available
in Bro. See