Hi,<div><br></div><div>Here we are using lxc intensively with bridges. Since we don't use STP, the downtime for each a mac@ change is unnoticeable. In fact, we discovered it when reading this mailinglist. After some test I can confirm that most of the time we are spawning/destroying a container, the bridge's mac@ change, but there is no loss of connectivity, since arp tables are instantly refreshed.</div>
<div><br></div><div>So an easy workaround for the moment is to disable STP on the brige (brctl br0 stp off). If you are using a bridge in a controlled environment, you really dont need STP anyway.</div><div><br></div><div>
My 2cents,<br><br><div class="gmail_quote">On Mon, Oct 24, 2011 at 11:09 AM, Derek Simkowiak <span dir="ltr"><<a href="mailto:derek@simkowiak.net">derek@simkowiak.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
     Hello,<br>
     Just following up re: this bug.  I think it's a pretty serious issue.<br>
<br>
     I am looking to work on this, but I am seeking some feedback and<br>
direction from one of the core LXC devs.<br>
<br>
- Do you agree with my analysis?<br>
- Has anyone else worked on this already?<br>
etc.<br>
<br>
<br>
Thanks,<br>
Derek<br>
<div><div></div><div class="h5"><br>
On 10/18/2011 04:31 PM, Derek Simkowiak wrote:<br>
>       There is a behavior in the Linux kernel which can cause a bridge<br>
> device to change MAC address, thus causing a network blackout of several<br>
> seconds (while everybody ARPs the new MAC address flushes the old one).<br>
> This happens when bridging an enslaved interface, like we do with LXC.<br>
><br>
>       The symptom is that the LXC host will black out for several seconds<br>
> when starting or stopping an LXC container.  Your SSH terminal on the<br>
> host will freeze and become unresponsive.  (It is a random symptom,<br>
> because the blackout only happens if the randomly-assigned MAC address<br>
> of the virtual device is lower than that of the physical eth0 device).<br>
><br>
>       This behavior was first observed by the libvirt folks when creating<br>
> virtual machines.  You can read more details about it (and how they<br>
> fixed it) here:<br>
><br>
> <a href="https://www.redhat.com/archives/libvir-list/2010-July/msg00450.html" target="_blank">https://www.redhat.com/archives/libvir-list/2010-July/msg00450.html</a><br>
> <a href="https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/584048" target="_blank">https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/584048</a><br>
><br>
>       I have observed the symptom under LXC, and the workaround for it<br>
> has been independently confirmed for LXC in this bug report (ID: 3411497):<br>
><br>
> <a href="http://sourceforge.net/tracker/index.php?func=detail&aid=3411497&group_id=163076&atid=826303" target="_blank">http://sourceforge.net/tracker/index.php?func=detail&aid=3411497&group_id=163076&atid=826303</a><br>

><br>
><br>
>       The workaround for the bug is to give the virtual device a high MAC<br>
> address, thus discouraging the bridge device from adapting its MAC<br>
> address as its own.<br>
><br>
>       I have mentioned this bug on the list before, however, I was<br>
> confused about which MAC address was causing the problem.  This is NOT<br>
> the mac address specified in lxc.conf, like this:<br>
><br>
> lxc.network.hwaddr = fe:16:3e:fd:5a:5b<br>
><br>
>       That MAC address has nothing to do with the bug; the host's bridge<br>
> device (br0) will never assume a configured LXC MAC address as its own.<br>
> Instead, the MAC address in question is the one of the virtual vethXXXX<br>
> device, as shown with "ifconfig" on the host:<br>
><br>
> veth0IEDlk Link encap:Ethernet  HWaddr 4e:34:7c:dc:92:e8<br>
> [...snip...]<br>
><br>
>       That HWaddr should be given a high prefix to avoid the network<br>
> blackouts, just like they've done for libvirt.  That does not exist in<br>
> any config file anywhere; it must be fixed in the LXC source code.<br>
><br>
>       I looked in network.c for the LXC source code and I think the fix<br>
> should go in lxc_bridge_attach() near line 991.  The fix would put a<br>
> manually-generated MAC address -- one with a high prefix -- into<br>
> ifr.ifr_hwaddr.sa_data and thus replace the random one assigned by the<br>
> kernel.<br>
><br>
>       However, I'm new to the LXC source and would like some input and<br>
> analysis from a more seasoned contributor.  I would be happy to test and<br>
> maybe even contribute a patch, but I'd like some feedback first.<br>
><br>
><br>
> Thank You,<br>
> Derek Simkowiak<br>
><br>
><br>
> ------------------------------------------------------------------------------<br>
> All the data continuously generated in your IT infrastructure contains a<br>
> definitive record of customers, application performance, security<br>
> threats, fraudulent activity and more. Splunk takes this data and makes<br>
> sense of it. Business sense. IT sense. Common sense.<br>
> <a href="http://p.sf.net/sfu/splunk-d2d-oct" target="_blank">http://p.sf.net/sfu/splunk-d2d-oct</a><br>
> _______________________________________________<br>
> Lxc-users mailing list<br>
> <a href="mailto:Lxc-users@lists.sourceforge.net">Lxc-users@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/lxc-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-users</a><br>
<br>
<br>
</div></div>------------------------------------------------------------------------------<br>
The demand for IT networking professionals continues to grow, and the<br>
demand for specialized networking skills is growing even more rapidly.<br>
Take a complimentary Learning@Cisco Self-Assessment and learn<br>
about Cisco certifications, training, and career opportunities.<br>
<a href="http://p.sf.net/sfu/cisco-dev2dev" target="_blank">http://p.sf.net/sfu/cisco-dev2dev</a><br>
<div><div></div><div class="h5">_______________________________________________<br>
Lxc-users mailing list<br>
<a href="mailto:Lxc-users@lists.sourceforge.net">Lxc-users@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/lxc-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>François-Xavier Bourlet<br>
</div>