[Users] Re: network problems: eth0: received packet with own
SOLVED and POSSIBLE BUG *WARNING*)
Benoit Branciard
Benoit.Branciard at univ-paris1.fr
Fri May 21 11:56:52 EDT 2010
frank a écrit :
> Hi,
> after a lot of tests I looked at a Xen machine, which also use ethernet
> bridges and veths, and I noticed that it always use MAC
> address FE:FF:FF:FF:FF:FF for the veths. I have test it on VE's
> and...voila! No more mess with the MACs! Now the MAC of the ethernet
> bridge is always the same, the host main ethernet interface one.
>
> I don't know the exact reason for this, but I'm sure it is an important
> BUG for all who use veths with ethernet bridge.
> Please, solve it as soon as you can.
> Thanks.
>
This is a feature (I don't remember where I read it, but it's documented
somewhere): under Linux, a bridge's MAC address takes the numerically
*lowest* value amongst those of the bridged interfaces which belong to it.
FE:FF:FF:FF:FF:FF is the higher possible locally-defined unicast MAC
address value and therefore is the least prone to interfere with the
bridge's MAC (unless there are no other MAC addresses into the bridge).
So the bridge-side of veths (not the VE-side, which will be visible on
the network and should remain unique) SHOULD ALWAYS be FE:FF:FF:FF:FF:FF
for convenience, or at least be chosen higher than any other MACs
present on the system (FE:xx:xx:xx:xx range is a good choice).
To my knowledge, mention about this is extremely sparse in OpenVZ's
documentation, and *not* taken into account by vzctl when automatically
generating MAC addresses with "vzctl --netif-add" with blank MAC
parameters. This may be considered as a bug.
--
Benoit BRANCIARD
Pôle Infrastructures
Centre de ressources informatiques et du réseau (CRIR)
Université Paris 1 Panthéon-Sorbonne
http://crir.univ-paris1.fr
Tel. 01 44 07 89 68
--
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.
More information about the Users
mailing list