[ovs-discuss] Running into MTU problem (2 extra bytes)

[Jesse Gross]

On Fri, Jun 19, 2015 at 1:52 PM, Johnson L. Wu <johnson at snoopy.org> wrote:
>
>
> Greetings,
>
>
>
> I am currently running
>
> 3.16.0-4-amd64
>
> No LSB modules are available.
>
> Distributor ID: Debian
>
> Description:    Debian GNU/Linux 8.1 (jessie)
>
> Release:        8.1
>
> Codename:       jessie
>
> ovs-vsctl (Open vSwitch) 2.3.1
>
> Compiled Jun 15 2015 19:30:36
>
> DB Schema 7.6.2
>
> libvirtd (libvirt) 1.2.9
>
>
>
> and I am seeing an MTU issue where packets coming in from the physical side
> are vanilla 1500Bytes
>
> Once it gets to the virtual NIC I see the following in dmesg:
>
>
>
> [ 6754.472356] openvswitch: vnet5: dropped over-mtu packet: 1502 > 1500
>
> [ 6754.472363] openvswitch: inter-1tom: dropped over-mtu packet: 1502 > 1500
>
>
>
> If I set BOTH the vnet5 vnic to mtu 1502 AND the guest OS MTU to 1502 things
> will flow
>
> Otherwise mant protocols with full sized packets will see timeout.
>
>
>
> Wireshark loaded on the client didn’t help, as a trace done on the client
> itself sees the IP packets coming in (AFTER adjusting MTU to 1502) as 1500.
>
>
>
> I think OVS must be doing something that added a tag to the packets.
>
> Anyone with the same observation?

I've never heard of this problem before and there were two threads
started on it within 10 minutes, so I'm combining them together on the
assumption that they are somehow related.

It's not really obvious to me how or why OVS would be increasing the
size of the packet by 1 or 2 bytes, especially if the packet is just
flowing through. As I said, I've never heard this reported before. In
the other message, it looks like OVS should be removing a VLAN tag. Is
that true in both cases?

Similarly, in the other thread, it looks the MTUs of the physical
interfaces are 9000, which makes it seems like it is possible that
these packets are actually coming across the wire. What happens if the
MTUs are all the same, as required by Ethernet specs?

Finally, it would be helpful to try this with the Linux bridge instead
of OVS, if possible, since it seems likely that the cause may be
another component.