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