[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Maybe a bug of xen


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: geaaru <geaaru@xxxxxxxxx>
  • Date: Wed, 09 Nov 2005 11:20:59 +0100
  • Delivery-date: Wed, 09 Nov 2005 09:10:20 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=tAXUMjGbCfncCEBKaxlWXilNK3jJP+FMcD7/eK+/HHsU8lwvkQTIVjO5kW5r9/yT/Xj/59l6ZXq1Th81Z52xwmHRs+1NYZe1sKLGqVjxgxhMMWugbG7Puvui9aue2BjiTHoG3Y7mfUe5coMoz0vVVDXPBPJPZzncyr5+bw6USjI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Wed, 2005-11-09 at 11:39 +0900, Horms wrote:
> On Tue, Nov 08, 2005 at 06:53:44PM +0100, geaaru wrote:
> > On Tue, 2005-11-08 at 15:06 +0000, Horms wrote:
> > > geaaru <geaaru@xxxxxxxxx> wrote:
> > > > 
> > > > With mii-tool I can't read eth0, while is unload module of eth0 and the
> > > > reload module e1000 there is a new interface eth2 that mii-tool see
> > > > correctly. While eth0 had always same error message. I don't know!
> > > > On another abnormal of this system is that if I see traffic with
> > > > ethereal from a client see arp request, while from ethereal on server I
> > > > can't see arp request!
> > > > 
> > > > I think that this is a problem of xen, but maybe is a problem with e1000
> > > > kernel module or other. I don't know
> > > > Thanks for your replies.
> > > 
> > > Is e1000 used for eth0 or some other driver. If it is some other driver,
> > > perhaps it doesn't have ethtool support.
> > > 
> > 
> > For eth0 I use e1000 kernel modules. Ethtool works.
> > My problem is that this interface configurate as 0.0.0.0 send a arp
> > request for resolve 0.0.0.0 ip. I want that arp protocol on this
> > interface disabled. 
> > I try with ebtables, ifconfig eth0 -arp, ip link set eth0 arp off, but
> > nothing. It send always arp request for 0.0.0.0. However with ethereal
> > from server Dom0 I can't see this arp request, only from clients.
> > I try with same system without xen and it works. So, i think that it is
> > a problem of xen.
> 
> Can you explain a little more what you are trying to do?
> I'm suspecting that what you realy want is either arptables,
> or to play with the arp_ignore and arp_announce proc values.
> 
> P.S: you forgot to CC xen-devel on your reply, 
> could you please do so if you reply to this message?

Sorry, I fault to send email to mailing list.

However, I try to draw a scheme of my system: 
------------------
| Debian server1 |
------------------             -----------------------------
|  eth0 (vif1.1) | --------->  | xen-br1: virtual bridge   |-----
------------------             | with physical eth0        |    |
| eth1: 10.0.1.30| -----\      -----------------------------    |
------------------ nat  |                                       |
   of traffic from eth0 |                                       |
                        \      -----------------------------    |
                         ----> | xen-br0: virtual bridge   |    |
                               | vif1.2 + vif0.0 + vif2.1  |    |
                        -----> |                           |    |
                        |      |                           |    |
                        |      -----------------------------    |
------------------      |                                       |
| Debian server2  |     |                                       |
-------------------     |                                       |
| eth0  10.0.1.1  | ----/                                       |
-------------------vif2.1                                       |
                                                                |
                                                                |
                                                                |               
                                                
        ===================================================     /
        |       Domain 0: hypervisor (gentoo)    | eth0    | <---
        ============================================== | ==     
        | eth1 192.168.9.59 |                          |  
        =====================           PPPoE clients  |
                               =====================   /
                               | net  172.16.0.0/16 |<-
                               ++++++++++++++++++++++

On Debian_server1-eth0 (vif1.1) there is a server pppoe.
Debian_sever1-eth0 is configured so:
eth0      Link encap:Ethernet  HWaddr xx:00:00:xx:xx:xx
          inet6 addr: xxxx::xxxx:xx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21097 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20677 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1431231 (1.3 MiB)  TX bytes:1296240 (1.2 MiB)

I configurate these iface with "ifconfig eth0 0.0.0.0 up".
This iface does not use arp protocol and so I want disabled it: drop arp
request to eth0 and denied sending arp request from eth0 (vif1.1). 
For do this I try with ebtables (directly from dom-0 and physical eth0);
with "ifconfig ... -arp" and with "ip link set eth0 arp off" but doesn't
work. Same mechanisms to block arp protocol on computer without xen
work. 
I blocked arp protocol but there are always arp request from physical
eth0 for resolve ip 0.0.0.0. These arp requests can be see from pppoe
clients but can't be see (always with ethereal) from dom-0.
So there are this problems:
1) Why I can't see arp request from dom-0 (ethereal) while I can see
them from clients?
2) Why I can't disable arp protocol on physical eth0?
3) Why if I call mii-tool I can't read information about link?
   testing_xen ~ # mii-tool
     SIOCGMIIPHY on 'eth0' failed: Operation not supported
     eth1: negotiated 100baseTx-FD flow-control, link ok
   testing_xen ~ # ethtool eth0
     Settings for eth0:
     No data available

eth0 is a e1000 iface. Moreover, if I execute 
   testing_xen ~ # modprobe -r e1000
   testing_xen ~ # modprobe e1000
then eth0 (physical) isn't removed correctly in fact, from dmesg:
   testing_xen ~ # dmesg | tail
     xen-br0: port 2(peth0) entering disabled state
     Intel(R) PRO/1000 Network Driver - version 6.0.54-k2
     Copyright (c) 1999-2004 Intel Corporation.
     ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 21 (level, low) -> IRQ
21
     e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
There is a new interface eth2 and eth0 is unused.
   testing_xen ~ # mii-tool
       SIOCGMIIPHY on 'eth0' failed: Operation not supported
       eth1: negotiated 100baseTx-FD flow-control, link ok
       eth2: no autonegotiation, 10baseT-HD, link ok
Moreover, from mii-tool it is possible see that eth0 is blocked and
previous physical eth0 (now eth2) can read correctly from mii-tool.
Still:
testing_xen ~ # ethtool eth0
Settings for eth0:
No data available
testing_xen ~ # ethtool eth2
Settings for eth2:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: Unknown! (65535)
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
        Link detected: no

I hope that I'm been light.
Thanks.

P.S. My english is not wonderful, sorry!

Geaaru




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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.