On Wed, 2013-06-05 at 09:30 -0500, Serge Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > On Wed, 2013-06-05 at 07:40 -0500, Serge Hallyn wrote: > > > > Now my question, could not lxc (at boot) setup a fixed MAC addr for the > > > > host port? > > > > > Yeah, given how bad this was for libvirt/qemu I'm surprised I've not seen > > > this happen in lxc - but I haven't, and noone else has reported it. > > > > Actually, this has come up on both the -devel list and here, the last > > time about a year and a half ago: > > > > On the -devel list... > > > > Subject: "Set high byte of mac addresses for host veth devices to 0xfe" > > > > It had a patch and referenced an open bug associated with it: > > > > random veth device MAC addresses cause bridge problems - ID: 3411497 > > https://sourceforge.net/tracker/index.php?func=detail&aid=3411497&group_id=163076&atid=826303 > > > > Christian Seiler included a proposed patch with his original posting to > > the -devel list back in November of 2011 where he set the high order > > byte to FE for a private "locally administered" MAC and some discussion > > ensued. After a couple of bug fixes, it was Acked it on 01/03/2012. > > > > It looks like it was applied. Right around line 3109 of src/lxc/conf.c: > > > > static int setup_private_host_hw_addr(char *veth1) > > > > ... > > > > ifr.ifr_hwaddr.sa_data[0] = 0xfe; > > err = ioctl(sockfd, SIOCSIFHWADDR, &ifr); > > close(sockfd);
> yes and it does this. The point is that lxcbr0 is not tied to any > physical nic. So the first container you start, however high the > macaddr is, lxcbr0 takes its mac. If the next container gets a > lower macaddr, lxcbr0's macaddr drops. > Right now I have: > lxcbr0 Link encap:Ethernet HWaddr fe:02:72:77:79:ff > vethtdjU5K Link encap:Ethernet HWaddr fe:02:72:77:79:ff Oh, yeah... I'm always using bridged mode with the host ethernet address on the bridge, so that's never a problem. You're right. The NAT mode is problematical there because it's not anchored to a physical interface. I think someone, at one point in those earlier threads, was suggesting that they were using a dummy interface or a dummy container as a place holder to lock the interface address for that reason. I just happen to have enough IPv4 addresses, personally, that I bridge everything and never really need to NAT anything where I can avoid it. :-P Of course, in a server environment, where you are hosting a farm of virtual servers, you would almost always want global public addresses on the servers, I would imagine. You're still going to have the problem that, if you shut down the container that the bridge is using for the address, the address is going to shift, static or not. The address of the bridge must be an address of an interface on the bridge or you are going to have routing problems. That was made clear in some discussion on some of the kernel mailing lists. How do you deal with that then? Do you designate a container that must never be shut down or the bridge hangs? You could load the dummy module and bridge a dummy interface to the bridge. That would guarantee a MAC address lower than the fe: private addresses of the bridge and would be "cheaper" than a dummy container. I've done that before a long time ago. (We should still close that old bug, however.) > -serge > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
