<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Francois-Xavier,<br>
Thank you for your feedback.<br>
<br>
I have seen the issue on two systems where STP is turned off.
Here is the /etc/network/interfaces entry for the particular bridge
where I've seen it the most; note the last line:<br>
<br>
<tt>iface br0 inet dhcp<br>
bridge_ports eth0<br>
bridge_fd 9<br>
bridge_hello 2<br>
bridge_maxage 12<br>
bridge_stp off<br>
</tt><br>
(As you can see, on this server I was using DHCP for the
bridge. That is rare, but not unusual. In this case we centrally
manage all fixed IP addresses using an /etc/ethers file on the DHCP
server.)<br>
<br>
I submit that the symptom is not related to STP, but instead is
related to the ARP cache (and network topology) of the equipment you
are connecting through. With my Linux laptop hooked up through two
GigE switches (and no STP), I see the host's network freeze. I've
seen it on Ubuntu 10.04 and 11.04.<br>
<br>
F> <i>If you are using a bridge in a controlled environment, you
really dont need STP anyway.</i><br>
<br>
If using collocation or managed hardware from a data center
provider, you may not have a choice re: STP.<br>
<br>
It is worth noting that the KVM/libvirt folks found the issue
serious enough to fix.<br>
<br>
<br>
Thank You,<br>
Derek Simkowiak<br>
<br>
On 10/24/2011 11:41 AM, Francois-Xavier Bourlet wrote:
<blockquote
cite="mid:CAKi8PJ8C7VtAQHHdBADGK3MgHooDkKq5RzBxHG+oopmmYK-OWw@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
href="mailto:derek@simkowiak.net">derek@simkowiak.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
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 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Lxc-users@lists.sourceforge.net">Lxc-users@lists.sourceforge.net</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://p.sf.net/sfu/cisco-dev2dev" target="_blank">http://p.sf.net/sfu/cisco-dev2dev</a><br>
<div>
<div class="h5">_______________________________________________<br>
Lxc-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Lxc-users@lists.sourceforge.net">Lxc-users@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>