netdev - macvtap vlan and tcp header overhead (and mtu size)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <"H0000071001429ae.1561726014.sx.f1-outsourcing.eu*"@MHS>
Date:   Fri, 28 Jun 2019 14:46:54 +0200
From:   "Marc Roos" <M.Roos@...outsourcing.eu>
To:     netdev <netdev@...r.kernel.org>
Subject: macvtap vlan and tcp header overhead (and mtu size)

I hope this is the right place to ask. I have a host setup for libvirt 
kvm/qemu vms. And I wonder a bit about the overhead of the macvtap and 
how to configure the mtu's properly. To be able to communicate with the 
host, I have moved the ip address of the host from the adapter to a 
macvtap to allow host communication. 

I have the below setup on hosts. 

                                +---------+   
                                | macvtap0|   
                             +--|   ip    |   
                             |  | mtu1500 |   
                             |  +---------+   
                 +---------+ |  +---------+   
                 |eth0.v100| |  | macvtap1|   
              +--|  no ip  +-+--|   ip    |   
 +---------+  |  | mtu1500 |    | mtu1500 |   
 |   eth0  |  |  +---------+    +---------+   
 |         +--+                               
 | mtu9000 |  |  +---------+                  
 +---------+  |  |eth0.v101|                  
              +--|   ip    |                  
                 | mtu9000 |                  
                 +---------+                  

https://pastebin.com/9jJrMCTD

I can do a ping -M do -s 9000 between hosts via the vlan interface 
eth0.v101. That is as expected.

The ping -M do -s 1500 macvtap0 and another host or macvtap1 fails. The 
maximum size that does not fragment is 1472.
That is 28 bytes??? Where have they gone? I am only using macvtap, can 
this be the combination of the parent interface being a vlan and that 
macvtap is not properly handling this? Anyone experienced something 
similar? Or can explain where these 28 bytes go?