[lxc-devel] hwaddr tuning in templates

[Michael H. Warfield]

On Tue, 2013-12-24 at 15:32 +0100, Stéphane Graber wrote: 
> On Tue, Dec 24, 2013 at 03:01:38PM +0100, Guillaume ZITTA wrote:
> > Hi,
> > 
> > I'm coding a new template (for gentoo).
> > 
> > I saw this kind of tweak in many templates :
> > 
> >     if [ "$nics" -eq 1 ] && ! grep -q "^lxc.network.hwaddr"
> > $path/config; then
> >         # see http://sourceforge.net/tracker/?func=detail&aid=3411497&group_id=163076&atid=826303
> >         hwaddr="fe:$(dd if=/dev/urandom bs=8 count=1 2>/dev/null |od
> > -t x8 | \
> >                       head -1 |awk '{print $2}' | cut -c1-10 |\
> >                       sed 's/\(..\)/\1:/g; s/.$//')"
> >         echo "lxc.network.hwaddr = $hwaddr" >> $path/config
> >     fi
> > 
> > The url no longer exists and I didn't catch the explaination in ML
> > archive.
> > 
> > Someone has a new pointer to the explaination?
> > Was it a workaround for a no longuer existing bug?
> > 
> > Regards,
> > 
> > Guillaume ZITTA

> Yeah, I guess the bug report got lost in the migration to github.

Ooopppsss...

I'm sure I was up to my eyeballs in THAT discussion.

> So let me try to explain what's going on there and why we are doing
> this. Note that it's not really a bug has much as just having to cope
> with the way things work in the kernel.

> We want all containers to have a static mac address for a simple reason,
> it's no fun if your IP addresses change every time you boot it (as if
> not specified, a random one assigned by the kernel will be used).

> On top of that, we can't just use any randomly generated mac address. We
> need one that'll typically be higher than a regular MAC address. That's
> because of the way bridges work in Linux. A bridge has its own mac
> address and whenever that address changes trafic is cut for around 30s
> (STP delay and similar stuff). The Linux kernel always uses the lowest
> MAC address in the bridge for the bridge's own address, so we need to
> make sure our addresses tend to be higher than that.

Ok...  Point of order here.  There are two MAC addresses.  There are the
container MAC addresses and the host facing MAC addresses that face the
host bridge.  Those are independent.

The lxc.network.hwaddr parameter specifies the MAC address in the
container.  That affects the IPv4 dhcp address it receives and the IPv6
stateless autoconf address it calculates from a router advertisement.
It does NOT affect the host bridge MAC.

The host facing MAC addresses are all in the fe: range and don't seem to
be configurable.  Those are the ones that can hose up the hosts bridge
networking in heartbeat beat by altering the bridge MAC.  I think there
was a problem there at one time, at the time of that bug report, and it
may have been fixed in two ways, I'm not sure, by splitting the host
facing MAC and the container facing MAC AND insuring the host facing MAC
was in the fe: range.

I agree we need ways to prevent IP (v4 and v6) address roulette.  Thanks
for reminding me.  I just coded something similar (but supporting
multiple interfaces) into the Fedora and CentOS templates (patch to
follow RSN - I'm doing regression testing now).

> Not all templates care about that though. In Ubuntu we provide a routed
> bridge so we don't have that concern and we instead choose to use the
> Xen MAC range which has the advantage of being properly registered
> specifically for use with VMs and containers.

Anyone check with the Xen people on that?  I thought we were also
setting the "locally managed bit" on the MAC 02:00:00:00:00:00 (i.e.
02:) - meaning it was in nobody's "range" (which is only applicable when
that bit is zero.  So fe: has the 02: bit set and the multicast 01: bit
clear (which is mandatory or all sorts of nastiness results) and all
bets are off with the rest of the bits.  It's really not in the "Xen
range" when that 02: bit is set.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  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-devel/attachments/20131226/cf399f1c/attachment.pgp>