This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] crc checksum problems

To: René Pfeiffer <lynx@xxxxxxxxx>
Subject: Re: [Xen-users] crc checksum problems
From: Daniel Goertzen <goertzen@xxxxxxxx>
Date: Tue, 17 Jan 2006 08:30:42 -0600
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 Jan 2006 14:41:14 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060117101651.GH1057@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <20060104044158.GA13318@xxxxxxxxxxxxxxxxxxxxxxx> <20060117000110.GD32198@xxxxxxxxxxxxxxxxxx> <43CC6642.1010707@xxxxxxxx> <20060117101651.GH1057@xxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
Instead of adding a dummy interface to the bridge try adding another vif0.x.

The xen drivers try to optimize networking by skipping out on checksumming at various stages, because the assumption is that inter-domain network transport is immune to error. My theory is that if you don't properly use the vifx.y/vethx interfaces, you bypass some of these checksum optimizations and end up performing integrity checks when you shouldn't. My dream is that this will someday be documented somewhere, or better yet degrade gracefully to checksum operation with a kernel warning or something. The existing design seems brittle.

Again, that's only my theory based on my experience. If someone really knows whats going on, I look forward to hearing about it.


René Pfeiffer wrote:

On Jan 16, 2006 at 2136 -0600, Daniel Goertzen appeared and said:
I observed similar problems (checksum errors) when I directly assigned an IP address to the bridge in dom0.

My bridges have IP addresses, but the addresses are not used. Could this
be a problem?

I corrected the situation by adding vif0.0 to the bridge and assigning
the IP address to veth0.  If you're using the network-bridge script
that comes with xend this all happens automatically, but I had to roll
my own solution and ran afoul.

I use xend's network-bridge script and have additional network
interfaces defined in /etc/network/interfaces. The bridges look as

xen0:~# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.feffffffffff       no              peth0
xenbr1          8000.dabb912575c8       no              dummy1
peth0 and vif0.0 are from Dom0. vif19.0 and vif19.1 belong to the
firewall in the first DomU and the vif14.0 belongs to the webserver.
dummy1 is one of two dummy interfaces. A /29 network is routed to the
machine. Dom0 has the first address, eth0 inside the firewall's DomU has
the second, both use the gateway serving the /29. Neither peth0 nor
vif0.0 have IP addresses configured.
My assumption was that the first bridge xenbr0 forwards the packets to
the gateway. ICMP, TCP SYN and even TCP SYN plus data works, everything
else won't.

Maybe someone can explain the background of the checksum errors.

Best regards,

Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>