UDP / mDNS traffic from multiple Windows VMs stops networking from working properly

[tsarajar]

We ended up having DHCP problems with our Windows VMs. A VM sent dozens of DHCPDISCOVERY messages a minute, and got DHCPOFFER replies to them all, but Windows never reacted upon them. I can see them with Wireshark that they do arrive, but nothing is done about them, and the next DHCPDISCOVERY is just sent. This ends up causing our Windows VMs to never receive an IP address and thus not working very well.

This doesn't happen all the time however, but it starts happening when we have lots of Windows VMs up and running in our CI farm.

So, after some tracing, we found out that we have a lot of UDP mDNS traffic coming from Windows Delivery Optimization Service. The UDP packages could be recognized by the string _dosvc in them. After we shut down those services on Windows VMs, our DHCP handshaking problems went away.

We also saw this error message in our Windows Event viewer whenever we saw problems in handshaking.

WSAEMSGSIZE
10040 (0x2738)
A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself.

We're using libvirt networking with vhost-net enabled.

Has anyone else seen the same kind of problems? And any suggestions on how we fix it? At least I'm not keen on just saying "well disable the WUDO if that works".

[YanVugenfirer]

Tagging @ybendito

[YanVugenfirer]

@tsarajar Do you have some custom MTU settings on the host or guest side?

[tsarajar]

Nope, default 1500. I've been testing if everything works well with MTU 9000 on our testing environment to see if it's worth moving there, but we don't have the host capacity to reproduce 100 windows VMs to congest the UDP traffic.

We also have LSO disabled in production, since having it enabled in the past caused deterioration in throughput. However, based on tests in our testing environment, it should be enabled nowadays. Perhaps due to the fixes in Ubuntu kernels.

The hosts we have in production are Ubuntu 24.04.2 with kernel 6.8.0-59-generic.

[tsarajar]

In our testing env with iperf3 we manage to send back and forth TCP traffic at 9.5Gbit/s on our 10 Gbit network cards. But iperf3 sending UDP traffic starts suffering from packet loss already at 100Mbit/s. At 1Gbit/s it was already up at 20% and Windows event logs show "datagram dropped: 2: Process.... ....Seq 1001, Reason Insufficient local buffer space". Sounds like 100Mbit/s could easily be something Windows VM spams out when running WUDO.

[Directox01]

Try to disable rx-checksumming and LRO at host lvl and retry to test speed. Hope it will be helpful.

[tsarajar]

disabling rx-checksumming definitely had a positive effect. A windows transferring from a windows on another host upload speeds went up from 9.78 Gbit -> 16.8. And RX speeds from 2.53 -> 10.5 Gbit. Additionally if I set MTU to 9000 on Windows, the speeds went further up to TX 19.8 and 16.3 RX. LRO was off by default.
But it seems I opened a new can of worms here... I still have tcp-segmentation-offload on, generic-segmentation-offload on, generic-receive-offload on etc to test out. The combination matrix with these, MTU, LSO etc could take weeks to go through...

Oh and UDP... it's much better now. With previously iperf3 -u -b 500M having 20% packet loss it's now down to 3%. But it's still far coping a 25Gbit connection. With a 1Gbit UDP load we were up to 70% packet loss, now down to 26%.

[Directox01]

Glad to hear that. I guess issue is with your host kernel and network card firmware. I suggest you to give a try to upgrade firmware, and if there is no update available just one by one disable all features to find out from where the bottleneck comes.