WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] Networking problem xen 3.0.2-2

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] Networking problem xen 3.0.2-2
From: Birger Brunswiek <birger.b@xxxxxxx>
Date: Tue, 25 Apr 2006 17:30:08 +0200
Delivery-date: Wed, 26 Apr 2006 03:09:23 -0700
Envelope-to: www-data@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>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (Windows/20051201)
Hi list,
I'm not sure if this is a bridge problem or a problem that is caused by xen.

The symptons I see is that some network traffic is not getting through the
bridge setup by the network-bridge script. I'm using the version with the
RELEASE-3.0.2-2 tag (change set 9615) from
http://xenbits.xensource.com/xen-3.0-testing.hg and have not modified the
defautlt settings.

After sniffing the different devices attached to the bridge I think the problem
is that fragmented IP packets are not forwarded correctly. They are reassembled
by the bridge so that they are larger than the MTUs of the devices in the 
bridge.

If I go
ping -s 1500 any-ip-address-that-normally-responds
I see something like the following, in tethereal, on the vif0.0 device
source -> destination ICMP Echo (Ping) Request
source -> destination IP Fragmented IP Protocol
source -> destination ICMP Echo (Ping) Request
source -> destination IP Fragmented IP Protocol
.... (no reply)

Now on xenbr0 I see
source -> destination ICMP Echo (Ping) Request
source -> destination ICMP Echo (Ping) Request
....

which I think should not be the case. Those Ping requests have been assembled
from the 2 packets that came from vif0.0. This combined packet is larger than
the MTU (1500) allows and is therefore not passed on to the next device (peth0
or vif1.0 or what ever)

Ping with smaller packets works fine. I see those on all the three devices
involved (vif0.0 -> xenbr0 -> peth0) and the replies are also there.
After I disable the bridge with
/etc/xen/scripts/network-bridge stop
ping with -s 1500 also works.

I find this behaviour rather strange as I thought that the bridge is only
supposed to work on the ethernet level and therefore should not reassemble a
fragmented IP packet.

Strangely I have not been able to reproduce the problem on my other machine
which is running Ubuntu/Breezy. The machine the problem occours is a
Debian/Sarge. Also everything was working fine with the 3.0.0 Release

I'd be happy to hear any comments on this issue.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

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