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 bug in xen 4.0.0 ?

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] Networking bug in xen 4.0.0 ?
From: "S.M.R. Mahdavian" <mahdavian@xxxxxxxxxxx>
Date: Tue, 13 Jul 2010 11:33:47 +0430
Delivery-date: Tue, 13 Jul 2010 05:44:28 -0700
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: Thunderbird 2.0.0.24 (Windows/20100228)

Hello all.

I have observed a strange behaviour in xen 4.0.0 networking. I Compiled xen on
an Ubuntu 9.10 and created two virtual machines on it ("Router" and "Server")
with the following network configuration:




           Xen host  192.168.1.5

     ################################################
     #                                              #
     #                                              #
     #                                              #
     #      Server                                  #
     #    192.168.2.20               Router         #           Client
     #                         192.168.2.1          #         192.168.1.10
     #    ##########                   192.168.1.1  #
     #    #        #                                #         ##########
     #    #        #     ###     ##############     #         #        #
     #    #        #     # #     #            #     # host    #        #
     #    #        #     # ####### eth1       #     # eth0    #        #
     #    #        #     # #     #       eth0 ################# eth0   #
     #    #   eth0 ####### #     #            #     #         #        #
     #    #        #     # #     #            #     #         #        #
     #    #        #     ###     #            #     #         #        #
     #    #        #             ##############     #         #        #
     #    ##########    Linux                       #         ##########
     #                  Bridge                      #
     #                  (sw0)                       #
     #                                              #
     #                                              #
     #                                              #
     #                                              #
     ################################################




Both "Router" and "Server" are Ubuntu 9.04 with 2.6.24-27-xen kernel. The two
domU's have an old-style xen kernel, whereas dom0 has a new 2.6.31.13 pvops
kernel. As can be seen from the figure above, "Router" has two interfaces.
One interface is connected to the "host's" eth0 and the other one is
internally connected to "Server" via a created linux bridge named sw0. IP
forwarding is enabled on "Router" so that packets coming from the external
"Client" can be forwarded to "Server". "Client" is running Windows XP.

The strange behavior is that packets are forwarded correctly from "Client" to
"Server" when packet sizes are small, but if they are larger than a certain
size, then packets coming out of Router's eth1 do not reach the Server or the
linux bridge. I fact tcpdump suggests that these packets do not make it to
vif1.1 (assuming that Router id number is 1). This happens only if packets
are *forwarded* by "Router". If packets are *generated* within Router, then
no problem is observed. Therefore pinging "Server" from "Client" using large
size packets fails, whereas pinging "Server" from "Router" is OK regardless
of the size of the packet.

I suspect that this is a bug in either xen 4.0.0 or the pvops kernel that
comes with it. Has anyone experienced something similar? Any recommendations?

Regards,
-- Mahdavian

P.S. The following shows some of the results from the experiment:

root@xen-host:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  3023     2     r-----     36.9
router                                       1   256     1     -b----      5.8
server                                       2   256     1     -b----      5.7

root@xen-host:~# brctl show
bridge name     bridge id               STP enabled     interfaces
eth0            8000.002354cd2c7f       no              peth0
                                                        vif1.0
sw0             8000.feffffffffff       no              vif1.1
                                                        vif2.0

# Ping from "Client" using packet size of 157 bytes (that's the limit!):
C:\Documents and Settings\Admin>ping -l 157 192.168.2.20

Pinging 192.168.2.20 with 157 bytes of data:

Reply from 192.168.2.20: bytes=157 time<1ms TTL=63
Reply from 192.168.2.20: bytes=157 time<1ms TTL=63
Reply from 192.168.2.20: bytes=157 time<1ms TTL=63
Reply from 192.168.2.20: bytes=157 time<1ms TTL=63


# Ping from "Client" using packet size of 158 bytes:
C:\Documents and Settings\Admin>ping -l 158 192.168.2.20

Pinging 192.168.2.20 with 158 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.


# tcpdump suggests that packets do leave the router interface:
root@router:~# tcpdump -n -v -i eth1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:18:02.787099 IP (tos 0x0, ttl 127, id 560, offset 0, flags [none], proto 
ICMP (1), length 186) 192.168.1.10 > 192.168.2.20: ICMP echo request, id 512, 
seq 6400, length 166
11:18:07.785175 arp who-has 192.168.2.20 tell 192.168.2.1
11:18:07.785280 arp reply 192.168.2.20 is-at 00:16:3e:1e:67:9f
11:18:08.043239 IP (tos 0x0, ttl 127, id 564, offset 0, flags [none], proto 
ICMP (1), length 186) 192.168.1.10 > 192.168.2.20: ICMP echo request, id 512, 
seq 6656, length 166
11:18:13.516628 IP (tos 0x0, ttl 127, id 566, offset 0, flags [none], proto 
ICMP (1), length 186) 192.168.1.10 > 192.168.2.20: ICMP echo request, id 512, 
seq 6912, length 166
11:18:19.003203 IP (tos 0x0, ttl 127, id 568, offset 0, flags [none], proto 
ICMP (1), length 186) 192.168.1.10 > 192.168.2.20: ICMP echo request, id 512, 
seq 7168, length 166


# tcpdump suggests that the link between the frontend and the backend interface
# is broken:
root@xen-host:~# tcpdump -n -i vif1.1
tcpdump: WARNING: vif1.1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif1.1, link-type EN10MB (Ethernet), capture size 96 bytes
11:18:07.552453 ARP, Request who-has 192.168.2.20 tell 192.168.2.1, length 28
11:18:07.552524 ARP, Reply 192.168.2.20 is-at 00:16:3e:1e:67:9f, length 28


# No problem is observed when packets are *generated* rather that *forwarded*
# by "Router".
root@router:~# ping -c 4 -s 1400 192.168.2.20
PING 192.168.2.20 (192.168.2.20) 1400(1428) bytes of data.
1408 bytes from 192.168.2.20: icmp_seq=1 ttl=64 time=0.885 ms
1408 bytes from 192.168.2.20: icmp_seq=2 ttl=64 time=0.068 ms
1408 bytes from 192.168.2.20: icmp_seq=3 ttl=64 time=0.066 ms
1408 bytes from 192.168.2.20: icmp_seq=4 ttl=64 time=0.068 ms

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
<Prev in Thread] Current Thread [Next in Thread>