The patch looks like a step in the right direction, but it still requires some
manual effort from the sys admin. If there are multiple dom0 systems on a
subnet, the sys admin must edit /etc/xen/scripts/network-bridge and make sure
$macid is unique for the subnet. It would be nice if the network-bridge found a
unique MAC address automatically.

This patch should not be neccessary.
The way Xen networking is setup gives you 4 devices in dom0
- peth0 - the physical device
- xenbr0 - the bridge device
- vif0.0 - a Xen virtual device
- eth0 - a Xen virtual device
The Xen network scripts setup routing so that the default route is 'eth0'. peth0
and vif0.0 are in the bridge, and eth0 is connected to vif0.0. The guest NICs
are also connected to xenbr0.
All traffic going out from the dom0 host originates from 'eth0', which takes
over the MAC address of your real physical NIC. Thus it should not matter that
peth0 has a mac of FE:FF:FF:FF:FF:FF, because it is not the device from which
dom0 network traffic is being routed.
So there's two possibilities
- Your network config is screwed up
- An application has explicitly set itself up to send packets from peth0,
instead of eth0.
As a first step attach the output of the following commands:
- ifconfig -a
- route -n
- brctl show

The ifconfig output indicates that this is a regression of #216504 after the
merge to Xen 3.1.0 where we actually ended up losing the said patch even touhg
it's in upstream 3.1.0.
However the version number in the original report is before the merge. Are you
two on the same machine?
For Jeff, please try the patch in #216504 and see if it helps (you'll need to
reboot after applying the patch). If it doesn't, please post the ifconfig
output again.
Thanks,

Unfortunately as long as there is at least one buggy box on the network you'll
get the error. So you need to patch every box on the broadcast LAN to have an
effect :)
Also, the patch in #216504 only fixes half of the bogus packets. The same thing
needs to be done on peth0 to completely stop the bogus packets. I'll send an
updated patch.

Correction, we don't get bogus packets from peth0 either due to a kernel patch
from Xen. Could you please do a tcpdump on the box that's seeing the bogus
packets to find out what they are?
The packets would be coming from a different box. Unfortunately it won't be
trivial to find out which box they're coming from as they all have the same
source address :)

Created attachment 235281[details]
packet capture
Attached is a packet capture from peth0 on the machine. There's not a lot of
network activity, but one machine is continually arp'ing for an IP address
that's not on the system's subnet... There must be another machine in the lab
that's not configured correctly.

OK so it's not even IPv6. Yes that does look like a misconfigured box. So the
solution here is to find it and fix it :)
Changing the MAC on this box would just be a work-around since the misconfigured
box could eventually get the same upgrade and might still end up with the same
address anyway.
Thanks.