Zitat von martin f krafft <[EMAIL PROTECTED]>:
also sprach Adriaan Peeters <[EMAIL PROTECTED]> [2008.04.23.1448 +0200]:
It has been a while but yes, we were running two xen hosts in the same
network. Since they were both standard Debian installs they had the same
MAC address: FE:FF:FF:FF:FF:FF.
The patch from my initial bug report fixes this by assigning a separate
mac address.
I'd say this is fighting symptoms. It's either a kernel bug in the
driver or in xen. I hope to find out more soon.
I maintain more then one xen hosts in the same collision domain myself
but never saw this error before. But I think the reason must be the
following:
peth0 is the real physical interface which is connected to the
network, but peth0 should never be used directly by anybody. peth0 has
this _strange_ mac adress of FE:FF:FF:FF:FF:FF. This is part of the
xen bridge-scripts that are executed when xen(d) is started.
then we have a bridge, normally called xenbr0. peth0 is part of this bridge.
And we have a virtual interface, called eth0, which should be used if
xen's domain0 wants to communicate via network. eth0 is also part of
this bridge. eth0 should have the mac adress of you real network
interface.
As long as eth0 is used, there is no problem, even if you have more
then one xen hosts in your collision domain.
But if peth0 is used as source-interface for connections from your
domain0, then this might lead to problems. If you have more then one
xen host in your network, then this will produce the network error
message you saw.
But the question is why traffic was send via peth0 and not via eth0?
Maybe a wrong routing table? Maybe ipv6 traffic (if eth0 is not
configured properly for ipv6)? Something like this should cause this
problems.
@Adriaan: Can you provide the output of the following commands:
# ip route
# ip -6 route
# ip neigh
# ip -6 neigh
# ip addr
Thanks!
--Ralph
