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 | 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
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
