|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] DomU PV network problems
I had a similar problem and I got a kind response from Matej, but I was busy and coudn't try what Matej suggested. I haven't tried the latest xen 4/dom0 using a revision control tool, but I suspect that would be the next logical step. I'd appreciate if you shared your findings on this matter. I have attached my previous post. Regards, -- Mahdavian Sauro Saltini wrote: Hi everybody. I've got a strange problem with PV networking on Linux. My current configuration is : - Xen 4.0.0 - DOM0 kernel 2.6.31.13 - DOMU kernels either 2.6.31.13 or 2.6.36-rc3 (vanilla)one of my DomU's is intended to act as a router/firewall for all the other ones.I have configured 2 distinct bridges in Dom0 :br0 - connects the firewall DomU "external" nic to the external faced host NIC (phisical) br1 - connects the "internal" virtual nic of firewall DomU (eth1) with the other DomU's virtual nics.Each "guest" DomU has defined the firewall DomU's "internal" address as default gateway, the firewall by now acts simply as a NAT gateway, with ip_forward active and a single NAT rule to SNAT outgoing packets with his own external IP.I've first installed the fw DomU as an hvm domain (nic's = ioemu) with slackware 13.0 and tried the whole thing connecting from one of the other DomU's to the external network and all worked smoothly.As soon as I've converted the fw DomU's to a PV domain (using either 2.6.31.13 or 2.6.36-rc3 kernels with PV drivers) something changed in a weird way...I can still ping the firewall DomU both from "internal" domU's network and from the external lan, but packets from a DomU can't reach the external network anymore !Running "tcpdump -nvvi" on both firewall's NICs and pinging an external host from one of the other domU's reveals that packets arrive on the firewall, are correctly NATted and appear on the external connected interface, but then simply disappear !on Dom0 "tcpdump -nvvi br0" (br0 = external bridge) never shows up any traffic !I've already tried to configure tx checksum offloading = off (ethtool -K <nic> tx off) on all the involved interfaces without any success.Please help... Many thanks in advance. Sauro Saltini. _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users ------------------------------------------------- This message sent via VFEmail.net http://www.vfemail.net $14.95 Lifetime accounts - 1GB disk, No bandwidth quotas! 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@xxxxxxxxxxxxxxxxxxx [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of S.M.R. Mahdavian Sent: Tuesday, July 13, 2010 9:04 AM To: xen-users@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |