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-devel

Re: [Xen-devel] Xen 3.0 Xend loses network - eth0 -> veth0? (fwd)

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Xen 3.0 Xend loses network - eth0 -> veth0? (fwd)
From: Jurgen Stroo <blurg@xxxxxxxxxxxxxxx>
Date: Thu, 9 Jun 2005 13:59:35 +0200 (CEST)
Delivery-date: Thu, 09 Jun 2005 12:02:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
No one else got this problem with Xen Unstable anyway?

>Hi Keir, and others, I didn't have time last week to further investigate
>the problem, but I'm able to do now.
>
>When I do the network scripts by hand, as I already mentioned,
>things are going well and the interface and routing configuration are
>okay. this means correct routes via veth0 etc. Also eth0 got its
>FE:FF:FF:FF:FF:FF correctly.
>
>The arp table looks good actually:
>
>normal situation without xen:
>megalosaurus:~# cat /proc/net/arp
>IP address       HW type     Flags       HW address            Mask
>Device
>10.0.0.3         0x1         0x2         00:01:02:0A:25:0D     *
>eth0
>10.0.0.142       0x1         0x0         00:00:00:00:00:00     *
>eth0
>10.0.0.141       0x1         0x0         00:00:00:00:00:00     *
>eth0
>10.0.0.254       0x1         0x2         00:13:49:10:0B:E0     *
>eth0
>
>And with Xen and the veth0 interface:
>IP address       HW type     Flags       HW address            Mask
>Device
>10.0.0.141       0x1         0x0         00:00:00:00:00:00     *
>veth0
>10.0.0.142       0x1         0x0         00:00:00:00:00:00     *
>veth0
>10.0.0.3         0x1         0x2         00:01:02:0A:25:0D     *
>veth0
>10.0.0.254       0x1         0x2         00:13:49:10:0B:E0     *
>veth0
>
>
>Looks perfectly right, I don't know what the problem could be actually.
>Everyting looks right and they reply to each others arp requests, that
>means on ARP level they see each other and reply to each other with the
>ARP replies.
>
>:-S
>Jurgen
>

Although very unlikely, it seems Keir Fraser stated on Jun 6 that :

>
> On 5 Jun 2005, at 21:53, Jurgen Stroo wrote:
>
> >
> > The thing is, after I've got the following configuration it is still
> > -NOT-
> > working:
> >
> > megalosaurus:~# ifconfig -a
> > eth0      Link encap:Ethernet  HWaddr FF:FF:FF:FF:FF:FF
>
> The MAC address should be FE:FF:FF:FF:FF:FF. The one above is the
> broadcast address. Not sure if it actually matters, but worth fixing
> anyway as it might confuse the bridge.
>
> I had problems with ARP when I first started testing veth0. It turned
> out that domain0 was not applying the information in ARP packets to the
> ARP cache. Since the ARP cache wasn't kept up to date, I saw very weird
> IP behaviour.
>
> I fixed that particular bug, but maybe there's another one. It is
> perhaps worth looking at /proc/net/arp and seeing how it compares with
> other machines on your network.
>
>   -- Keir
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel