[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