From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Lu=EDs?= Silva Subject: ARP problems with xen 4.0 with pvops kernel Date: Wed, 02 Jun 2010 01:38:58 +0100 Message-ID: <1275439138.2202.27.camel@luis-port> Reply-To: luis.silva@axiomasoft.pt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1134482154==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1134482154== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SFkTEXLuyWm0UlrtbRSU" --=-SFkTEXLuyWm0UlrtbRSU Content-Type: multipart/alternative; boundary="=-0b1utSwlY7waytRvuGkt" --=-0b1utSwlY7waytRvuGkt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Finally I managed to get a xen 4.0 working on ubuntu 10.04 with pvops kernel and libvirt. However I am having some problems with networking... after initial installation with netinstall image in hvm mode, when I transform the vm in xen pv (via pygrub with the current ubuntu kernel), networking startEd to act weird... Basically I'm not using a network script from xen. I define a bridge (manually or via libvirt, the result is the same) and I use vif-bridge to connect the vif to it. But now the weird part comes: I can communicate from domU to dom0, but not the other way around, unless I keep a ping running from domU to dom0... That's right, weird... while trying the ping from dom0 to domU, I used tcpdump both on the bridge, on the vif and on the eth0 in the domU. The arp packets never get to domU, but they appear both in the bridge and the vif sniff's... Here is the bridge: ifconfig virbr0 virbr0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff =20 inet addr:192.168.120.254 Bcast:192.168.120.255 Mask:255.255.25= 5.0 inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:226 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0=20 RX bytes:952 (952.0 B) TX bytes:13953 (13.9 KB) brctl show bridge name bridge id STP enabled interfaces virbr0 8000.feffffffffff no vif5.0 tcpdump -i virbr0 -vv -n tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture size 96 = bytes 01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 1, le= ngth 64 01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 2, le= ngth 64 01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 3, le= ngth 64 01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 4, le= ngth 64 01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 5, le= ngth 64 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 6, le= ngth 64 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 7, le= ngth 64 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP= (1), length 84) 192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 8, le= ngth 64 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 tcpdump -i vif5.0 -vv -n tcpdump: WARNING: vif5.0: no IPv4 address assigned tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), capture size 96 = bytes 01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16= 8.120.1 tell 192.168.120.254, length 28 Forwarding and iptables don't seem to be the problem, because if I initiate a ping from domU (at the same time as the failing one from dom0), the ping in dom0 starts to work. As soon as I stop the ping in domU, the one in dom0 starts failing again... Is anyone having the same problem? Is this a bug in the kernel? In dom0 or domU?=20 Thanks in advance, Lu=C3=ADs --=-0b1utSwlY7waytRvuGkt Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello,

Finally I managed to get a xen 4.0 working on ubuntu 10.04 with pvops kerne= l and libvirt. However I am having some problems with networking... after i= nitial installation with netinstall image in hvm mode, when I transform the= vm in xen pv (via pygrub with the current ubuntu kernel), networking start= Ed to act weird...

Basically I'm not using a network script from xen. I define a bridge (manua= lly or via libvirt, the result is the same) and I use vif-bridge to connect= the vif to it. But now the weird part comes: I can communicate from domU t= o dom0, but not the other way around, unless I keep a ping running from dom= U to dom0... That's right, weird... while trying the ping from dom0 to domU= , I used tcpdump both on the bridge, on the vif and on the eth0 in the domU= . The arp packets never get to domU, but they appear both in the bridge and= the vif sniff's...

Here is the bridge: 

ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff=
 =20
          inet addr:192.168.12=
0.254  Bcast:192.168.120.255  Mask:255.255.255.0
          inet6 addr: fe80::7c=
ee:4bff:fe82:e63f/64 Scope:Link
          UP BROADCAST RUNNING=
 MULTICAST  MTU:1500  Metric:1
          RX packets:16 errors=
:0 dropped:0 overruns:0 frame:0
          TX packets:226 error=
s:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueue=
len:0=20
          RX bytes:952 (952.0 =
B)  TX bytes:13953 (13.9 KB)


brctl show
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.feffffffffff	no		vif5.0


tcpdump -i virbr0 -vv -n
tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture size 96 =
bytes
01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 1, length 64
01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 2, length 64
01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 3, length 64
01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 4, length 64
01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 5, length 64
01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 6, length 64
01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 7, length 64
01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP=
 (1), length 84)
    192.168.120.254 > 192.168.120.1: ICMP echo request, i=
d 10317, seq 8, length 64
01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28


tcpdump -i vif5.0 -vv -n
tcpdump: WARNING: vif5.0: no IPv4 address assigned
tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), capture size 96 =
bytes
01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28
01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.16=
8.120.1 tell 192.168.120.254, length 28


Forwarding and iptables don't seem to be the problem, because if I initiate= a ping from domU (at the same time as the failing one from dom0), the ping= in dom0 starts to work. As soon as I stop the ping in domU, the one in dom= 0 starts failing again...

Is anyone having the same problem? Is this a bug in the kernel? In dom0 or = domU?

Thanks in advance,
Luís --=-0b1utSwlY7waytRvuGkt-- --=-SFkTEXLuyWm0UlrtbRSU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkwFqB0ACgkQXSU0BM8MHj+CQACfdZNaDx7nloufItJDHYT92BUw RP0AoIoh2r0UpUHk+1OnYIeiKyFA4MEO =uBAB -----END PGP SIGNATURE----- --=-SFkTEXLuyWm0UlrtbRSU-- --===============1134482154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1134482154==--