Interface MAC address assignment
- 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?
Thanks,
Ashley Hatch
Senior Network Engineer - UNLV
Quoted 49 lines · On Mon, 23 Jan 2006 22:48:23 -0800 "Ashley Hatch" <[email protected]> wrote:
- 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 eth1The 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.
Quoted 6 lines
If noone in briding is willing to support it, will someone consider a patch to do it?
Thanks,
Ashley Hatch
Senior Network Engineer - UNLV
In 2.6.15 or later it can be changed to any of the existing interfaces. I allowed that because it won't break the forwarding tables, and only slightly effects STP. (There is a higher risk of STP cycles).
Signature · 2 lines
Stephen Hemminger <[email protected]> OSDL http://developer.osdl.org/~shemminger