UDP Fragmentation Offload fragments packets with DF bit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

"tracepath www.example.net" does not work when a VM has UFO enabled
(as it is with virtio NIC):

$ sudo ethtool -k eth0 | grep udp
udp-fragmentation-offload: on

$ tracepath www.example.net
 1:  vlan3.gw.lappyfamily.net                              1.992ms
 2:  no reply

$ sudo ethtool -K eth0 ufo off
$ tracepath www.example.net
 1:  potato.lappyfamily.net                                0.447ms pmtu 1500
 1:  vlan3.gw.lappyfamily.net                              0.463ms
 2:  local-gw.236.teremki.kiev.ua                          1.268ms
...

tracepath works by sending a 65536-byte UDP packet with DF bit set,
then adjusts the packet size according to the ICMP replies for PMTU
discovery. However, when UDP fragmentation offload is enabled, the
packets are _fragmented_ into lots of small 1500-byte size packets.
The remote host does not need to send ICMP fragmentation-needed
responses, and it looks like my upstream ISP router drops incoming UDP
packets that are larger than 32K completely so it will return neither
ICMP time exceeded messages nor the message that a port is closed.

This is seen on the vnet2 tap device:
17:50:53.522206 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto
UDP (17), length 65535)
    192.168.100.8.51765 > 192.0.43.10.44444: UDP, length 65507

This is what seen leaving the host interface:
17:50:53.522398 IP (tos 0x0, ttl 1, id 0, offset 0, flags [+], proto
UDP (17), length 1500)
    192.168.100.8.51765 > 192.0.43.10.44444: UDP, length 65507
17:50:53.522416 IP (tos 0x0, ttl 1, id 0, offset 1480, flags [+],
proto UDP (17), length 1500)
    192.168.100.8 > 192.0.43.10: udp
...

I have checked 3.2.0 and 3.8.0 kernel hosts and they all happily split
a DF packet as seen above.

It looks like a bug to me. I assume that if an IP packet carrying this
UDP payload has DF bit set then it should not be fragmented even when
fragmentation is handled by the NIC (or VM host in our case). Does
this look like a real issue?

-- 
Regards, Roman Yepishev
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux