xenU sending too big packets

[Andreas Jellinghaus]

etup: amd64, xen0 = ubuntu 7.10 ("gutsy"), xenU = ubuntu 7.10 ("gutsy"),
network config with xenU routing via xen0.

scp xenU:file . very slow, ~50KB/s
scp xen0:file . several MB/s

on xen0:
scp xenU:file . many MB/s

had a look at tcpdump, I see lines like this:
10:55:30.319389 IP (tos 0x8, ttl 64, id 59286, offset 0, flags [DF], proto TCP
(6), length 2948) xenU.22 > desktop: . 47785:50681(2896) ack 0 win 404
<nop,nop,timestamp 20681576 687514747>
10:55:30.319399 IP (tos 0xc8, ttl 64, id 52994, offset 0, flags [none], proto
ICMP (1), length 576) xen0 > xenU: ICMP desktop unreachable - need to frag
(mtu 1500), length 556 IP (tos 0x8, ttl 64, id 59286, offset 0, flags [DF],
proto TCP (6), length 2948) xenU.22 > desktop.41056: . 47785:50681(2896) ack
0 win 404 <nop,nop,timestamp 20681576 687514747>[|icmp]

so the xenU is sending packets with size 2948? why?
ifconfig on xenU:

eth0 Link encap:Ethernet HWaddr 00:16:3E:6D:03:2D
          inet addr:xenU Bcast:... Mask:255.255.255.255
          inet6 addr: fe80::216:3eff:fe6d:32d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:34918213 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34262839 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12337072144 (11.4 GB) TX bytes:48486812526 (45.1 GB)

so the MTU is 1500 which is fine. xenU sending too big packets.

== WORK AROUND ==

It seems that turning off TX checksum offloading within the domU eliminates the issue:

    ethtool -K ethN tx off

[Andreas Jellinghaus (tolonuga)]

ethtool -K eth0 tx off
in xenU fixes the problem.

[darks (brueckner)]

this also affects sarge, etch, lenny and probably all the other domU installations.
the ethtool fix works, but it would really be nice if this would get fixed.

[agent 8131 (agent-8131)]

I can confirm this behavior in Xen 3.1. I have left checksums off in Xen 3.2 so cannot verify that it is still a problem.

[runout (office-runout)]

still the same problem on xen 3.3 (hardy backports amd64)

[Petri Lehtinen (petri)]

Actually, on xenU, issuing the commands

ethtool -K eth0 tx off
ethtool -K eth0 tx on

fixes the problem too, so changing the tx offloading back to on doesn't break it again.

And the real problem here is that xenU keeps sending big packets even though it gets the fragmentation needed info. I don't have a tcpdump to copy-paste at hand right now, but for me it looked like this:

xenU > target: length 2948
firewall > xenU: ICMP fragmentatinon needed
xenU > destination: length 1480
target > xenU: ACK
xenU > target: length 2948
firewall > xenU: ICMP fragmentatinon needed

So xenU is sending too big packets over and over again, and firewall has to ask it to fragment them each time. And this hurts performance REALLY hard.

[Petri Lehtinen (petri)]

s/destination/target/g in the hand-written tcpdump lookalike in comment #5 if you're confused :)

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 154271

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Phillip Susi (psusi)]

The xen-3.3 source package has been superceeded by the xen package. If you still have this issue on 12.04 or later, please reassign to there.

[dino99 (9d9)]

closing that old report, as it has not got recent comment.