[Lxc-users] lxcbr0 MAC addr issue

Michael H. Warfield mhw at WittsEnd.com
Wed Jun 5 15:00:56 UTC 2013


On Wed, 2013-06-05 at 09:30 -0500, Serge Hallyn wrote: 
> Quoting Michael H. Warfield (mhw at 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 |  mhw at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20130605/72aa96a0/attachment.pgp>


More information about the lxc-users mailing list