Bug #3737


Incoming VLAN traffic fails to reach VLAN interface if PCP not 0

Added by Clement Barnier almost 10 years ago. Updated almost 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


On ESXi, incoming VLAN traffic fails to reach the related VLAN interface if PCP is set to anything else than the default value (0); it stops at the parent interface.

The problem and setup is almost identical to issue #2613, except it only occurs when incoming PCP is not default.
It occurs on my regular setup (inbound IPtv traffic on WAN with PCP 4) and also on a test setup between two pfSense over a dedicated (virtual) LAN.

So if inbound VLAN packets have default PCP (0) it's fine and traffic goes through to the actual VLAN interface.
But if PCP differs from 0, packets stops being forwarded to the VLAN interface, and are only visible on the parent.

The host is ESXi 5.5 with E1000 or VMXNET3 virtual adapters (no difference).
The hardware is a Dell Poweredge 2900 II with integrated BMC5708 NICs
Tested with pfSense 2.1.4 and 2.2-ALPHA.


if_vlan.diff (1.34 KB) if_vlan.diff Clement Barnier, 07/27/2014 05:38 AM
Actions #1

Updated by Chris Buechler almost 10 years ago

I haven't dug too deeply into this, but I suspect the root issue here is this should be a feature request for PCP configuration (sysctls, ifconfig, etc.).

Clement: for best chance of a quick implementation, if you could spend some time digging into configuring the underlying FreeBSD to work in this circumstance, and hence then narrow down exactly what we need to allow configuring and where, that would make this much more likely to gain traction quickly. Otherwise it's probably one of those things that one of us will eventually get into, at some point.

Might want to start your testing with a stock FreeBSD 10.0 or 10-STABLE, see if you can make it work there, then try the same on pfSense 2.2.

Actions #2

Updated by Clement Barnier almost 10 years ago

As far as I know FreeBSD does not support PCP by itself (a “man vlan” on the latest 10-STABLE still indicates “No 802.1Q features except VLAN tagging are implemented.”) so the current pfSense implementation is in-house, and my guess is that there is a problem in there.

I’ve found the following diff which seems to details part of it:

I would love to take a closer look at the code but it seems the full pfSense repo is not freely accessible.

Actions #3

Updated by Chris Buechler almost 10 years ago

source is freely accessible, info here:

Actions #4

Updated by Clement Barnier almost 10 years ago

I've finally managed to put together a fully working environment and take a deeper look at this.

The problem is that setting PCP for a VLAN interface to anything except 0 corrupts its VID (seen with ifconfig).
This happens because there is a mix-up in if_vlan.c which likely got unnoticed in the pf_802.1p patch:

#define ifv_vid ifv_mib.ifvm_tag

So the VID and the full 802.1Q tag are equal when PCP is 0, but it obviously breaks in all other cases (vlan_input will be unable to match VLAN packets to existing VLAN interfaces).

It can be resolved by adding the proper ifvm_vid field to the mib, as shown in the attached diff.

Actions #5

Updated by Clement Barnier almost 10 years ago

So can this be pushed in the 802.1Q patch?
I confirm that it solves the problem.

Actions #6

Updated by Damien Flament over 9 years ago

I encounter the same issue, with the patch PCP is working fine.
Can you push this patch so it can be included in the 2.2?

Actions #7

Updated by Chris Christensen almost 9 years ago

I believe this may be related to (of which I am experiencing the same issue on 2.2.3-RELEASE).

I have not been able to access the pfsense-tools repo to validate the patchset yet; but, I suspect that the original may have been

Notably the upstream FreeBSD patchset appears to have the changes noted in this diff...

Actions #8

Updated by Clement Barnier almost 9 years ago

Chris, if you're interested in using PCP in your configuration you can take a look at #4133 which is more "up-to-date" and also include GUI support.

Actions #9

Updated by Chris Christensen almost 9 years ago

Thanks Clement!

Actions #10

Updated by Chris Buechler almost 9 years ago

  • Status changed from New to Duplicate
  • Affected Architecture added
  • Affected Architecture deleted (amd64)

closing this in favor of #4133


Also available in: Atom PDF