Some interesting observations. The customer deployed a pair of Centos7 machines and confirmed the vlan0 tag issue existed there as well. That wasn't too surprising.
However, they deployed a pair of Centos6 machines and they do NOT have the vlan0 tag issue.
This seems to confirm that the issue is not actually within the switch but within linux itself.
Within a thread on a community discussion on cisco.com, a Cisco employee responded saying it's a Linux bug that should already be patched. The Cisco person's response:
Some interesting observations. The customer deployed a pair of Centos7 machines and confirmed the vlan0 tag issue existed there as well. That wasn't too surprising.
However, they deployed a pair of Centos6 machines and they do NOT have the vlan0 tag issue.
This seems to confirm that the issue is not actually within the switch but within linux itself.
Within a thread on a community discussion on cisco.com, a Cisco employee responded saying it's a Linux bug that should already be patched. The Cisco person's response:
> You will find this behavior in all linux destro. This issue has been documented under- /bst.cloudapps. cisco.com/ bugsearch/ bug/CSCuu29425/ ?reffering_ site=dumpcr bridge- nf-filter- vlan-tagged = 1" but I haven't tested it.
> https:/
>
> You may wanna try "net.bridge.
That URL referenced is behind a login page so I've attached a pdf of the page from the customer.
Within that document it mentions a couple of URLS:
https:/ /lists. openwall. net/netdev/ 2013/09/ 10/30 /lists. linuxfoundation .org/pipermail/ bridge/ 2015-July/ 009630. html
https:/
Those are very old. If they are describing the same problem/solution, then this would be a regression.
The net.bridge. bridge- nf-filter- vlan-tagged setting is for filtering vlans with iptables. I feel that is not likely the right direction.