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] domU sending frames larger than MTU

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] domU sending frames larger than MTU
From: "Brian J. Murrell" <brian@xxxxxxxxxxxxxxx>
Date: Mon, 2 Mar 2009 14:39:45 +0000 (UTC)
Delivery-date: Mon, 02 Mar 2009 06:52:01 -0800
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
User-agent: Pan/0.132 (Waxed in Black)
I have a machine running a couple of domUs in a private (i.e. not bridged 
with any real ethernet devices) virtual network where the host machine is 
a router between the domUs and the physical network.

I have been observing, via tcpdump, the following behaviour:

14:36:26.777823 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6992256:6996300(4044) 
ack 1 win 362 <nop,nop,timestamp 58407492 129250939>
14:36:26.777922 IP 192.168.0.254 > 192.168.0.1: ICMP 10.75.22.151 unreachable - 
need to frag (mtu 1500), length 556
14:36:26.977726 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6992256:6993604(1348) 
ack 1 win 362 <nop,nop,timestamp 58407543 129250939>
14:36:26.978635 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 6993604 win 499 
<nop,nop,timestamp 129251018 58407543>
14:36:26.979418 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6993604:6994952(1348) 
ack 1 win 362 <nop,nop,timestamp 58407543 129251018>
14:36:26.979420 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6994952:6996300(1348) 
ack 1 win 362 <nop,nop,timestamp 58407543 129251018>
14:36:26.980336 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 6994952 win 499 
<nop,nop,timestamp 129251019 58407543>
14:36:26.980411 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 6996300 win 488 
<nop,nop,timestamp 129251019 58407543>
14:36:26.981657 IP 192.168.0.1.988 > 10.75.22.151.1022: P 6996300:6996448(148) 
ack 1 win 362 <nop,nop,timestamp 58407543 129251019>
14:36:26.982100 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 6996448 win 502 
<nop,nop,timestamp 129251019 58407543>
14:36:27.018003 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6996448:7000492(4044) 
ack 1 win 362 <nop,nop,timestamp 58407553 129251019>
14:36:27.018068 IP 192.168.0.254 > 192.168.0.1: ICMP 10.75.22.151 unreachable - 
need to frag (mtu 1500), length 556
14:36:27.221735 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6996448:6997796(1348) 
ack 1 win 362 <nop,nop,timestamp 58407604 129251019>
14:36:27.222682 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 6997796 win 499 
<nop,nop,timestamp 129251079 58407604>
14:36:27.223523 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6997796:6999144(1348) 
ack 1 win 362 <nop,nop,timestamp 58407604 129251079>
14:36:27.223524 IP 192.168.0.1.988 > 10.75.22.151.1022: . 6999144:7000492(1348) 
ack 1 win 362 <nop,nop,timestamp 58407604 129251079>
14:36:27.224438 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 6999144 win 499 
<nop,nop,timestamp 129251080 58407604>
14:36:27.224506 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 7000492 win 488 
<nop,nop,timestamp 129251080 58407604>
14:36:27.225682 IP 192.168.0.1.988 > 10.75.22.151.1022: P 7000492:7000640(148) 
ack 1 win 362 <nop,nop,timestamp 58407604 129251080>
14:36:27.226097 IP 10.75.22.151.1022 > 192.168.0.1.988: . ack 7000640 win 502 
<nop,nop,timestamp 129251080 58407604>

As you can see, for whatever reason, the TCP session on that port pair is 
trying to send 4044 byte TCP frames, much in excess of the MTU of the 
downstream network (hence the ICMP need-fragmentation messages), but more
importantly in excess of the MTU of the virtual interface on the domU:

eth0      Link encap:Ethernet  HWaddr 00:16:3E:73:F6:BE  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::216:3eff:fe73:f6be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3567098 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3471796 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1508328213 (1.4 GiB)  TX bytes:2016647487 (1.8 GiB)

Is this a bug or intended behaviour?  If intended, can I prevent it somehow?

Cheers,
b.


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

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