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

RE: [Xen-devel] bridge + arp [SOLVED]


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Moritz Möller <m.moeller@xxxxxxxxxxxx>
  • Date: Mon, 22 Sep 2008 13:44:45 +0200
  • Delivery-date: Mon, 22 Sep 2008 04:46:29 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Ackaibd2x6RUc2hATrStZ9Z1KWttUgADrKmgADcK+qAATO/3gA==
  • Thread-topic: [Xen-devel] bridge + arp [SOLVED]

The cause of this was that we bridged two VLANs in our router, and so an
outgoing arp broadcast did come back vlan encapsulated on eth0, causing
the FDB of the bridge module to change the port of the mac of the xen
machine from vif1.0 to eth0.

So if you do stuff like bridging two VLANs (we're moving...), first
check if all switches (including the xen hosts) are capable of that.

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Moritz
Möller
Sent: Sunday, September 21, 2008 1:04 AM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] bridge + arp

Tried the xen packages from ubuntu (xen 3.3, kernel 2.6.24-19-xen),
using the supplied network-bridge script, still no success and still the
messages "peth0: received packet with  own address as source address" in
dmesg.

I tested if the problem is that the bridge only forwards broadcasts (arp
request is broadcast, the response is unicast), but non-arp unicast is
forwarded correctly and brctl showmacs shows a matching entry for the
xen domU.

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 10:45 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] bridge + arp

I have tried it with the network-bridge script now (netloop, renaming
eth0 to peth0 and using eth0 via netloop, adding it to the bridge) and
the result is the same - plus that I get a lot of "peth0: received
packet with own address as source address" kernel messages..

A strange thing is - after I do a brctl delif br0 vif1.0 && brctl addif
br0 vif1.0 the network works for a while.


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Moritz
Möller
Sent: Friday, September 19, 2008 8:59 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] bridge + arp

Hi,

this is propably bridge related and not really a xen problem, but it
might help someone:

Some of our domUs are not able to arp. Arp -n show (incomplete), and
doing a tcpdump shows, that on the dom0's eth0 the arp request goes out,
the response comes in, but on the vifX.0 interface the arp response is
gone. 

dom0# tcpdump -ni eth0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni br0
arp who-has 10.32.2.51 tell 10.32.7.70
arp reply 10.32.2.51 is-at 00:30:48:34:44:6c

dom0# tcpdump -ni vif3.0
arp who-has 10.32.2.51 tell 10.32.7.70

Does someone know why the dom0 br0 or vif eats the arp response?

Thanks a lot,

Moritz


ip a l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:30:48:34:13:dd brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue qlen 20000
    link/ether 00:30:48:34:13:dc brd ff:ff:ff:ff:ff:ff
    inet 10.32.2.50/14 brd 10.35.255.255 scope global br0
    inet6 fe80::230:48ff:fe34:13dc/64 scope link
       valid_lft forever preferred_lft forever
5: vif1.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
6: vif2.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever
7: vif3.0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link
       valid_lft forever preferred_lft forever


brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0030483413dc       no              eth0
                                                        vif1.0
                                                        vif2.0
                                                        vif3.0



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

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

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

_______________________________________________
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®.