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

[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

[Xen-users] Do bridges or vif defragment IP-packets?

from [Klose, Dieter] [Permanent Link][Original]
To: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] Do bridges or vif defragment IP-packets?
From: "Klose, Dieter" <dieter.klose@xxxxxxxxxxxxxx>
Date: Tue, 18 May 2010 15:07:49 +0200
Accept-language: de-DE, en-US
Acceptlanguage: de-DE, en-US
Delivery-date: Tue, 18 May 2010 06:10:08 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=dieter.klose@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1274188245; x=1305724245; h=from:to:date:subject:message-id: content-transfer-encoding:mime-version; z=From:=20"Klose,=20Dieter"=20<dieter.klose@xxxxxxxxxxxxxx >|To:=20"xen-users@xxxxxxxxxxxxxxxxxxx"=20<xen-users@list s.xensource.com>|Date:=20Tue,=2018=20May=202010=2015:07:4 9=20+0200|Subject:=20Do=20bridges=20or=20vif=20defragment =20IP-packets?|Message-ID:=20<D5633990FF49D746BFB756B3755 717F30121B002A649@xxxxxxxxxxxxxxxx> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=yl5MkX0cw5RsBgagLr11joZhn9E/qF55Nn+5XjEI1ns=; b=R3WLg6joW60PtdGHnzapuzGXtDLk/qktP4KvBQR8dyiNQemZRlc6lpap 7czYfgTn2rijxeBNct2WXeKlK4wblh1H/K+ZMZiyWzP8h6+EywQfBiug6 QIeN8yNKGMjizB8lNbic3OMxRtPuVnS707NwX2snKRDc7BRbYmwGDk4tZ WjccwRfHxRu2d8EFYnN3SxBGL4CNPE/ZedyE7f1zK+qfMsobZFNy4UfqQ 3nQYlrZJrQ1y4zRU0HRiS1ZbbGMCH;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:acceptlanguage:Content-Type: Content-Transfer-Encoding:MIME-Version; b=uCaxpFgaWTY5+DimvjRYK4w412C2vv93uC6MX1r3Yjmoh1SnAZhuIB4l WWwbOmJxiVipO9+cMGMR2LJrMQs8eMgbjjNonfjXH7QVI31GEK974uUNo 8DnTS6ZZTR1nE8gKql6z6dMgzga+IgnD07wTSCASJ8Zibc7BsWVWmN25y 0A13PD8LOMO2VKIX5iU0EtvLnOdqB9waf+ayNS8McAEnOrje3bZg8K8l4 RsrikQJ1l6DAqAJo1NuSMOTKVylby;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acr2ix4MNzrhhVTxS8292J4q2fKuDg==
Thread-topic: Do bridges or vif defragment IP-packets? 
We have a SLES11 system with XEN 3.3 and configured an internal bridge "intbr1" 
with interfaces "vif2.1" and "vif9.1" to two Linux-guests:

# ifconfig (reduced output)

intbr1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:169 errors:0 dropped:0 overruns:0 frame:0
TX packets:85 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1458368 (1.3 Mb) TX bytes:28192 (27.5 Kb)

vif2.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:600 errors:0 dropped:0 overruns:0 frame:0
TX packets:612 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:751740 (734.1 Kb) TX bytes:757842 (740.0 Kb)

vif9.1 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:198 errors:0 dropped:0 overruns:0 frame:0
TX packets:202 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:32
RX bytes:260680 (254.5 Kb) TX bytes:263558 (257.3 Kb)

# brctl show (reduced output)
bridge name bridge id             STP enabled interfaces
intbr1           8000.feffffffffff   no                vif2.1
                                                                  vif9.1
                            
When we send an ICMP-packet with 6400 data-bytes (ping -s 6400 -c 1 
192.168.39.1) from Linux-guest connected to "vif9.1" to
the other linux-guest connected to "vif2.1" we see with tcpdump connected to 
intbr1, that some instance (intbr1? vif9.1) defragmented
the 5 ip-packets from vif9.1 into 1 ip-packet, though mtu-size for the 
vif-interfaces, intbr1 and eth-interfaces of the guests
are all set to 1500 bytes:

# tcpdump -i intbr1 -v
tcpdump: WARNING: intbr1: no IPv4 address assigned
tcpdump: listening on intbr1, link-type EN10MB (Ethernet), capture size 96 bytes
14:33:12.853741 IP (tos 0x0, ttl 64, id 62828, offset 0, flags [none], proto 
ICMP (1), length 6428) 192.168.39.2 > 192.168.39.1: ICMP echo request, id 2327, 
seq 1, length 6408
14:33:12.853956 IP (tos 0x0, ttl 64, id 62329, offset 0, flags [none], proto 
ICMP (1), length 6428) 192.168.39.1 > 192.168.39.2: ICMP echo reply, id 2327, 
seq 1, length 6408
14:33:17.851500 arp who-has 192.168.39.1 tell 192.168.39.2
14:33:17.851581 arp reply 192.168.39.1 is-at 00:16:3e:02:24:db (oui Unknown)

# tcpdump -i vif2.1 -v
tcpdump: WARNING: vif2.1: no IPv4 address assigned
tcpdump: listening on vif2.1, link-type EN10MB (Ethernet), capture size 96 bytes
14:33:12.853798 IP (tos 0x0, ttl 64, id 62828, offset 0, flags [+], proto ICMP 
(1), length 1500) 192.168.39.2 > 192.168.39.1: ICMP echo request, id 2327, seq 
1, length 1480
14:33:12.853801 IP (tos 0x0, ttl 64, id 62828, offset 1480, flags [+], proto 
ICMP (1), length 1500) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853803 IP (tos 0x0, ttl 64, id 62828, offset 2960, flags [+], proto 
ICMP (1), length 1500) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853805 IP (tos 0x0, ttl 64, id 62828, offset 4440, flags [+], proto 
ICMP (1), length 1500) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853806 IP (tos 0x0, ttl 64, id 62828, offset 5920, flags [none], proto 
ICMP (1), length 508) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853948 IP (tos 0x0, ttl 64, id 62329, offset 0, flags [+], proto ICMP 
(1), length 1500) 192.168.39.1 > 192.168.39.2: ICMP echo reply, id 2327, seq 1, 
length 1480
14:33:12.853948 IP (tos 0x0, ttl 64, id 62329, offset 1480, flags [+], proto 
ICMP (1), length 1500) 192.168.39.1 > 192.168.39.2: icmp
14:33:12.853948 IP (tos 0x0, ttl 64, id 62329, offset 2960, flags [+], proto 
ICMP (1), length 1500) 192.168.39.1 > 192.168.39.2: icmp
14:33:12.853949 IP (tos 0x0, ttl 64, id 62329, offset 4440, flags [+], proto 
ICMP (1), length 1500) 192.168.39.1 > 192.168.39.2: icmp
14:33:12.853956 IP (tos 0x0, ttl 64, id 62329, offset 5920, flags [none], proto 
ICMP (1), length 508) 192.168.39.1 > 192.168.39.2: icmp
14:33:17.851517 arp who-has 192.168.39.1 tell 192.168.39.2
14:33:17.851581 arp reply 192.168.39.1 is-at 00:16:3e:02:24:db (oui Unknown)

# tcpdump -i vif9.1 -v
tcpdump: WARNING: vif9.1: no IPv4 address assigned
tcpdump: listening on vif9.1, link-type EN10MB (Ethernet), capture size 96 bytes
14:33:12.853739 IP (tos 0x0, ttl 64, id 62828, offset 0, flags [+], proto ICMP 
(1), length 1500) 192.168.39.2 > 192.168.39.1: ICMP echo request, id 2327, seq 
1, length 1480
14:33:12.853740 IP (tos 0x0, ttl 64, id 62828, offset 1480, flags [+], proto 
ICMP (1), length 1500) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853740 IP (tos 0x0, ttl 64, id 62828, offset 2960, flags [+], proto 
ICMP (1), length 1500) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853741 IP (tos 0x0, ttl 64, id 62828, offset 4440, flags [+], proto 
ICMP (1), length 1500) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853741 IP (tos 0x0, ttl 64, id 62828, offset 5920, flags [none], proto 
ICMP (1), length 508) 192.168.39.2 > 192.168.39.1: icmp
14:33:12.853967 IP (tos 0x0, ttl 64, id 62329, offset 0, flags [+], proto ICMP 
(1), length 1500) 192.168.39.1 > 192.168.39.2: ICMP echo reply, id 2327, seq 1, 
length 1480
14:33:12.853968 IP (tos 0x0, ttl 64, id 62329, offset 1480, flags [+], proto 
ICMP (1), length 1500) 192.168.39.1 > 192.168.39.2: icmp
14:33:12.853969 IP (tos 0x0, ttl 64, id 62329, offset 2960, flags [+], proto 
ICMP (1), length 1500) 192.168.39.1 > 192.168.39.2: icmp
14:33:12.853970 IP (tos 0x0, ttl 64, id 62329, offset 4440, flags [+], proto 
ICMP (1), length 1500) 192.168.39.1 > 192.168.39.2: icmp
14:33:12.853970 IP (tos 0x0, ttl 64, id 62329, offset 5920, flags [none], proto 
ICMP (1), length 508) 192.168.39.1 > 192.168.39.2: icmp
14:33:17.851500 arp who-has 192.168.39.1 tell 192.168.39.2
14:33:17.851612 arp reply 192.168.39.1 is-at 00:16:3e:02:24:db (oui Unknown)

We also tried to set tso and gso off with ethtool in all interfaces (intbr1, 
vif2.1, vif9.1 and ethx on guest systems), but with no effect.

Does anyone have any idea what instance defragments the ip-packets and why and 
how we can force this instance not to do this?

Thanks!

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [Xen-users] Xen Dom0 performance reporting/monitoring, Mark Adams
Next by Date:  [Xen-devel] How to build a 64 bit xen, lei yang
Previous by Thread:  [Xen-users] Slow IO in VM, Arpan Jindal
Next by Thread:  RE: [Xen-users] Do bridges or vif defragment IP-packets?, James Harper
Indexes:  [Date] [Thread] [Top] [All Lists]
 
   

Copyright , Citrix Systems Inc. All rights reserved. Legal and Privacy