Muli Ben-Yehuda wrote:
> On Tue, Aug 29, 2006 at 12:17:53AM +0300, Shachar Shemesh wrote:
>
>
>> If you do set it up like that (and I did), please be sure to turn off
>> hardware checksum generation for TCP/IP, or you'll have trouble
>> connecting from the Xen machines that are behind the firewall to the
>> internet
>>
>
> There were several bugs related to this area that have been
> resolved. Is there an inherent reason why this is problematic, or did
> you just run into Xen bugs?
>
> Cheers,
> Muli
>
I'll clarify the bug I've seen.
This bug happens when one of the DomU is the router for another DomU or
for Dom0.
The bug itself goes like this. Machine 1 (either DomU or Dom0) wants to
send a TCP packet to Machine X (not part of the Xen mes{h,s}). The
routing table on Machine 1 states that this packet should be directed to
Machine 2 (a DomU machine that acts as a router).
Xen has an optimization that states that TCP packets sent between the
Xen machines will not have their checksum calculated. After all, what's
the point, if the packet never actually goes on a network? It does this
by turning on hardware optimization for TCP checksums, and merely
skipping the actual calculation under such a case.
The problem is that this particular packet, while indeed being sent from
Machine 1 to Machine 2, is not actually destined for Machine 2. It is
truly destined for Machine X, which is located elsewhere, and does
actually check the TCP checksum. The result is that Machine X receives a
packet with a bad checksum, and ignores it.
The symptoms you will see:
- Only machine 2 (the router) manages to talk to machines not part of
the Xen setup. If you have truly virtualized machine using the hardware
support, this is likely to also be able to communicate.
- Other machines on the Xen setup will manage to communicate with
machines inside the Xen setup, but when trying to communicate with
another machine, a connection is established, but no data will be sent
on it.
Solution: RTFM ethtool for the command line option to disable hardware
offloading of checksum calculation.
Muli,
This seems to me like a conceptual bug in the way Xen determines which
is the true destination for the packet. I fail to see a method of
solving this bug without some serious OS level information being passed
cross DomUs, which I think is a worse problem than the current one. As
such, I'm content to simply live with this problem, and apply the
suggested solution.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
