All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sander Eikelenboom <linux@eikelenboom.it>
To: "Luís Silva" <luis.silva@axiomasoft.pt>
Cc: xen-devel@lists.xensource.com
Subject: Re: ARP problems with xen 4.0 with pvops kernel
Date: Wed, 2 Jun 2010 09:10:02 +0200	[thread overview]
Message-ID: <861767359.20100602091002@eikelenboom.it> (raw)
In-Reply-To: <1275439138.2202.27.camel@luis-port>

Hi Luis,

I think i'm using a setup similar to yours:
I'm using debian on my dom0 and domU's, xen4, pvops xen-next kernel for domU.

in /etc/network/interfaces I create a xen_bridge on boot

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The primary network interface
allow-hotplug eth1
iface eth1 inet static
        address 172.16.1.1
        netmask 255.255.0.0

auto xen_bridge
iface xen_bridge inet static
        address 192.168.1.1
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
#       #gateway <your_default_gateway>
#       #pre-up ifconfig eth0 down
        pre-up brctl addbr xen_bridge
#       #pre-up brctl addif xen-bridge eth0
#       #pre-up ifconfig eth0 up
#       #post-down ifconfig eth0 down
#       #post-down brctl delif xen-bridge eth0







On which all the domU's will connect.

in xend-config.sxp, I use:

(network-script network-dummy)
(vif-script     vif-bridge)





In domU config files I specify IP, MAC and the bridge to connect to:

vif         = [ 'bridge=xen_bridge,ip=192.168.1.6,mac=00:16:3E:49:0E:FA' ]



Traffic between bridge and eth0 and eth1 is routed with iptables/ipmasq.


This works fine for me.

--
Sander






> 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  
>           inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.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 
>           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, 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, id 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, id 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, id 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, id 10317, seq 5, length 64
> 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.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, length 64
> 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.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, length 64
> 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.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, length 64
> 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.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.168.120.1 tell 192.168.120.254, length 28
> 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.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? 

> Thanks in advance,
> Luís



-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it

  parent reply	other threads:[~2010-06-02  7:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02  0:38 ARP problems with xen 4.0 with pvops kernel Luís Silva
2010-06-02  1:20 ` Jeremy Fitzhardinge
2010-06-02  8:47   ` [Xen-devel] " Luís Silva
2010-06-02 16:06     ` Jeremy Fitzhardinge
2010-06-02 18:53       ` Luís Silva
2010-06-02 19:26         ` Re: [Xen-devel] " Boris Derzhavets
2010-06-03 10:20           ` [Xen-users] " Luís Silva
2010-06-03 10:59             ` Re: [Xen-devel] " Boris Derzhavets
2010-06-03 23:18               ` [Xen-users] " Luís Silva
2010-06-06 10:19             ` Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel 2.6.32.15 Boris Derzhavets
2010-06-06 16:43               ` [Xen-users] " Jeremy Fitzhardinge
2010-06-02  7:09 ` ARP problems with xen 4.0 with pvops kernel Boris Derzhavets
2010-06-02  7:10 ` Sander Eikelenboom [this message]
2010-06-02  8:00 ` [Xen-users] " Boris Derzhavets
2010-06-03  9:35 ` Boris Derzhavets

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=861767359.20100602091002@eikelenboom.it \
    --to=linux@eikelenboom.it \
    --cc=luis.silva@axiomasoft.pt \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.