[Bridge] Interface MAC address assignment
spam at atomtrap.com
Mon Jan 23 22:48:23 PST 2006
- SUMMARY -
It seems like you should be able to assign your MAC on the bridging
interfaces for IP L2 -> L3 mappings, or at least choose which NIC
supplies the MAC.
Since my L2 mapping to my L3 address has nothing to do with my STP
bridge ID, why can't we decouple them and have MAC locking or setting
as an option to BRCTL and the kernel module so that brctl could
prefer a NIC or ifconfig could set it for the purposes of IP?
- END SUMMARY -
Presently the system choose the lowest MAC for the purposes of STP
and also assigns this MAC for the purposes of IP. This is fine for
STP but certainly unnecessary for IP. The bridge ID and the IP/MAC do
not need to be the same and in some cases certainly should not be
(unless I'm missing something obvious).
I have looked through the code of brctl and the ethernet bridging
code in the kernel and I have not found a way to resolve the
following issue short of recoding it, and I can't seem to get a
google search to help either.
When I create a bridging interface doing something like this:
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
The resulting MAC address of the interface br0 is the lowest of all
MACs. From an STP standpoint, this makes sense. I am using VMWARE
virtual interfaces on a few machines, and these MACs are lower than
some of my real NICs. They are not unique however. So when I bridge
my virtual net and vmnet I sometimes get non-unique MACs on my real
L2 network and the machines with the non-unique MAC of course cannot
communicate. What I am doing to get around this is assign my REAL NIC
MACs from OUIs which make them lower than the vmnet OUI. That feels
tacky and wrong.
I thought to myself, "I'll just assign BR0 the MAC of my NIC (which
is higher than VMNET2)." Alas
ifconfig br0 hw ether aa:bb:cc:dd:ee:ff
Gives an ioctl error, and indeed is insupported in the kernel as far
as I can tell. A buddy of mine and I are trying to hack it in, but it
seems like something that should be in the mainline of the kernel.
If noone in briding is willing to support it, will someone consider a
patch to do it?
Senior Network Engineer - UNLV
More information about the Bridge