[ovs-discuss] 802.1q tags being inserted by OpenVSwitch into payload ethernet headers

[Ben Pfaff]

On Mon, Feb 06, 2017 at 10:38:12AM +0100, Philip Poten wrote:
> Hi all,
> 
> I'm a very new user of openvswitch (via a fuel openstack test setup), and
> I'm at a loss debugging an MTU problem (1446 byte payload are ok, 1450
> aren't). I've come across a peculiar behavior for which I haven't found any
> explanation as of yet, and I had hoped someone on here can shed some light.
> 
> The behavior: an ethernet frame without 802.1q tagging is being routed
> through an openvswitch vxlan tunnel, and while it is encapsulated in VXLAN
> UDP packets, it also suddenly features an 802.1q tag for vlan id 0 on the
> /payload/ ethernet frame (not the outer, transport ethernet frame). The tag
> still exists on the vxlan_sys interface on the target, but then vanishes
> before it is reinjected into the host networking.
> 
> Basically, what happens is this:
> 
> 1. PayloadEthernet[PayloadIP[...]] becomes on the wire:
> 
> 2. EthernetWith8021q[IP[UDP[VXLAN[PayloadEthernet with unexpected 8021q tag
> id 0 [PayloadIP[...]]]]]] and then morphs back to
> 
> 3. PayloadEthernet[PayloadIP[...]]
> 
> for completeness sake: the physical transport is intentionally 8021q
> tagged, also, here are unnecessarily large wireshark screenshots:
> http://imgur.com/a/bJEjk
> 
> While I suspect the 4 Byte 8021q tag to be the culprit in my MTU problem, I
> fully accept if this is actually expected behaviour and will continue
> looking elsewhere, but it would be nice to hear that this is indeed
> expected behavior.

That's really bizarre behavior!  I can't imagine Open vSwitch doing this
on its own, so my first thought would be that it is most likely due to
whatever is in the flow table set up by OpenStack.  You might check
whether the flow table ever pushes VLAN 0 onto the packet.