Hello,
looks similar like the infamous incorrect checksum error -
http://wiki.xensource.com/xenwiki/XenFaq#head-4ce9767df34fe1c9cf4f85f7e07cb10110eae9b7.
Is there something in the logs of the Dom0?
How recent is the pvops 2.6.31.13 dom0 pvops kernel?
You can check the wrong checksum problem with tcpdump from dom0 (tcpdump -nvvi
interface). In some cases it can be solved with ethtool (ethtool -K eth0 tx
off), in some cases one had to use another Dom0 kernel (latest pvops 2.6.32.x or
patch the one in use).
Regards
Matej
-----Original Message-----
From: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] On Behalf Of S.M.R. Mahdavian
Sent: Tuesday, July 13, 2010 9:04 AM
To: xen-users@lists.xensource.com
Subject: [Xen-users] Networking bug in xen 4.0.0 ?
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,
# tcpdump suggests that the link between the frontend and the backend
interfaceseq 7168, length 166
# 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@lists.xensource.com
http://lists.xensource.com/xen-users