New-VMSwitch command overrides interface's MTU #84
Description
I've been experimenting with containers on Windows Server 2016 and I ran into a problem: somewhere during the container networking setup the MTU of my interface was changed. I think I've narrowed it down to the New-VMSwitch command (I believe this command is executed during the default docker network setup). Executing the steps below in powershell as Administrator should reproduce the problem; I just followed them in new Windows Server 2016 VMs on Azure / EC2 / GCE.
cmd /c 'netsh interface ipv4 show subinterfaces'
# Set the MTU to a lower value:
cmd /c 'netsh interface ipv4 set subinterface "Ethernet 2" mtu=1460 store=persistent'
# Install docker to get container and Hyper-V components:
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider
Restart-Computer -Force
# Reconnect RDP session. The vEthernet interface for the default container
# always has MTU 1500, rather than taking MTU 1460 from "Ethernet 2":
cmd /c 'netsh interface ipv4 show subinterfaces'
# Remove the existing container network, then reconnect the RDP session:
Stop-Service docker
Get-ContainerNetwork | Remove-ContainerNetwork -Force
# Ethernet 2 is now the only interface again, with MTU 1460:
cmd /c 'netsh interface ipv4 show subinterfaces'
# Create a new VMSwitch, then reconnect the RDP session:
New-VMSwitch -name testMTU -netadaptername "Ethernet 2"
# The only interface is now "vEthernet (testMTU)", with MTU forced to 1500
# instead of 1460:
cmd /c 'netsh interface ipv4 show subinterfaces'
This unexpected MTU change will cause packet fragmentation and potentially other issues (in my case my RDP connection did not work until I lowered the MTU again). Is there a reason that New-VMSwitch overrides the MTU on the Ethernet interface? Can the command be changed to inherit the MTU from the interface?
(Filing this bug here after looking at https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/contact-sdn-team - hopefully this is the right place.)