Do I understand correctly that you actually experience the following problem:
1. veth MAC address is lower then your ethX MAC.
2. so brX is assigned min(vethX-MAC, ethX-MAC) which is vethX-MAC.
3. and what is the your problem with that? that host system MAC changes dynamically and networking breaks or what?

I just can't see how fully random 6 bytes MAC can help. Because sometimes it will be "low" enough as well
and you will hit the problem anyway.

If I got your problem right then I can advise you a possible solution - in RHEL5 kernel we have a functionality called
"via_phys_dev" (triggered by BRCTL_SET_VIA_ORIG_DEV ioctl). This forces kernel to work with original
interface ethX (first added to bridge) and pass the traffic to it. This allows to add ethX to bridge w/o need
to propogate it's netfilter rules and other settings to brX.

Thanks,
Kirill


Dietmar Maurer wrote:
> Why I asked is because of that bridge problem:
> 
> http://forum.openvz.org/index.php?t=msg&th=5291&#msg_26576
> 
> A bridge always select the lowest mac address.
> 
> This patch solves the problem, but i am not sure if there are side effects.
> 
> https://lists.linux-foundation.org/pipermail/bridge/2008-June/005895.html
>  
> The SWSOFT OID is quite 'low', so the problem occurs frequently.
> 
> - Dietmar
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: users-bounces@openvz.org 
>> [mailto:users-bounces@openvz.org] Im Auftrag von Kirill Korotaev
>> Gesendet: Mittwoch, 11. Juni 2008 15:47
>> An: users@openvz.org
>> Betreff: Re: [Users] Veth mac generation
>>
>> and yes and no.
>> These upper 3 bytes are reserved for our company, so 
>> selecting them you will never conflict with other devices in 
>> network infrastructure.
>> i.e. the worst what can happen 2 veths will conflict.
>>
>> On the other hand - you are right, 6 bytes are better :)
> 
>