[Lxc-users] lxcbr0 MAC addr issue

Wed Jun 5 14:23:43 UTC 2013

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);

The bug is still open.  Is this not working?  What version did it go
into?  Someone should probably close that bug with an annotation.  Looks
to have been fixed in the 0.8.0 release.

Seems to be working for me:

ip addr ls 

     ...

7: vethNoBHvN: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lxcbr0 state UP qlen 1000
    link/ether fe:57:fa:34:4c:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc57:faff:fe34:4c35/64 scope link 
       valid_lft forever preferred_lft forever
9: vethFmslRq: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lxcbr0 state UP qlen 1000
    link/ether fe:a8:39:d6:c2:ee brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fca8:39ff:fed6:c2ee/64 scope link 
       valid_lft forever preferred_lft forever
11: vethhw7OZw: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lxcbr0 state UP qlen 1000
    link/ether fe:6b:8e:9d:f2:4f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc6b:8eff:fe9d:f24f/64 scope link 
       valid_lft forever preferred_lft forever

So this shouldn't be happening if all of the host side MAC addresses are
beginning with fe:.  What version of the lxc tools is in play here?
0.7.5 dates back to August of 2011 and would have predated that fix.
There's still a lot of distros with 0.7.5 still running around out
there.

It was also discussed here under these threads here in this forum from
around the time time frame (about a year and a half ago):

Subject: New LXC Creation Script: lxc-ubuntu-x
Subject: seeing a network pause when starting and stopping LXCs - how
do I stop this ?

Yes, I had seen the bug show up.  It causes the network to hang, but
only for a half a minute or less as the ARP caches settle.  If you have
frequent starting and stopping of containers, it can be a PITA.  My
solution was to assign a high "vendor field" (top 3 bytes) using some
safe vendor value that was above my host card vendor value.

I seem to recall some discussion a few years ago about also trying to
get an official MAC vendor code assigned to this project in one of the
earlier discussions.  I don't think that went anywhere and I'm having a
problem finding it now.  I do remember participating in that discussion
as well.  I seem to recall that it was decided not to do this even
though some other projects such as VMware and, maybe, VirtualBox did
chose this route.

> Since you mention lxcbr0, I assume you're using ubuntu?  Until we
> (somehow - netcf?) implement a distro-agnostic lxc bridge upstream, this
> is not an upstream issue, but an ubuntu package issue.

> Have you actually seen a hang as a result of this?  If so, then please
> open a bug at https://bugs.launchpad.net/ubuntu/+source/lxc/+filebug
> as it should be trivially fixable in /etc/init/lxc-net.conf.

See above.  Opened on 09/19/2011 and still open.  You'll find I
commented in the bug the same day.  There's been other discussions in
several forum, including including these.

I believe it has also come up on the OpenVZ forum (and is where a lot of
my earlier information originated) and has been mentioned in some of the
kernel lists, probably the net list.

There is a reason it works that way, mostly because the bridge has to
have an address and it has to be an address on the bridge so the kernel
can know what's on the bridge and what's foreign to the bridge in order
to manage local routing.  So, it has to pick something.  But, if you
delete an interface from the bridge and the bridge is using that
address, it has to pick another.  The rule the followed was to always
choose the lowest.

The only downside to assigning a static bridge address to the bridge is
the chance of that associated interface ever being deleted from the
bridge.  I think you also loose that static state if certain bridge
operations are performed by brctl, based on some discussions I saw.
Certainly shouldn't be a problem in a server hosting environment where
the host MAC is used for the bridge MAC and unlikely to ever be removed
from the bridge.

AFAICT...  This should be fixed in the current releases and no longer a
problem.

> -serge

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/20466b04/attachment.pgp>