All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: Mark Trompell <mark@foresightlinux.org>,
	Veaceslav Falico <veaceslav@falico.eu>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	herbert@gondor.hengli.com.au
Subject: Re: bridge not getting ip since 3.11.5 and 3.4.66
Date: Tue, 26 Nov 2013 10:25:23 -0500	[thread overview]
Message-ID: <5294BD63.7020905@gmail.com> (raw)
In-Reply-To: <CAEPa5ym4HWK9vo_BYYZbQsGZXG9r2kfYR2rFGaYjjJqDfkf2uQ@mail.gmail.com>

On 11/26/2013 08:27 AM, Mark Trompell wrote:
> Answering my own mail again and even top posting, sorry, but makes
> more sense to me in that case).
> I reverted bridge related patches from 3.11.5 and it boils down to
> commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date:   Thu Sep 12 17:12:05 2013 +1000
> 
>     bridge: Clamp forward_delay when enabling STP
> 
>     [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ]
> 
>     At some point limits were added to forward_delay.  However, the
>     limits are only enforced when STP is enabled.  This created a
>     scenario where you could have a value outside the allowed range
>     while STP is disabled, which then stuck around even after STP
>     is enabled.
> 
>     This patch fixes this by clamping the value when we enable STP.
> 
>     I had to move the locking around a bit to ensure that there is
>     no window where someone could insert a value outside the range
>     while we're in the middle of enabling STP.
> 
> Causing the issue for me. Reverting that patch and br0 comes up again
> and gets an ip.

yes, that patch introduced a bug where we always used the
max_forward delay value.

you have 2 options:
 1) disable STP.  Since you are just running VMs and you have a single
    physical connection on the bridge, you can safely disable STP since
    your system is a leaf node.

 2) Get the latest stable kernel.  The bug has been fixed there.

-vlad

> 
> On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote:
>>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote:
>>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>>>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66,
>>>>> What information would be helpful and required to find out what's going wrong.
>>>>
>>>> CC netdev
>>>>
>>>> First thing would be to provide the network scheme. Do you use vlans?
>>>> Which network
>>>> cards/drivers are you using? Do you use some kind of virtualization?
>>>> Is bonding involved?
>>>>
>>> Actually this is my desktop machine using kvm for a virtual machine
>>> that uses eth0 which is connected to the bridge
>>> which is used as interface for the host.
>>>
>>> $ ip addr
>>> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
>>> master br0 qlen 1000
>>> ...
>>> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
>>> ...
>>>
>>> Anything else?
>>
>> Okay more about my hardware and configuration:
>> from lspci:
>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
>> Connection (rev 04)
>>
>> /etc/sysconfig/network-scripts/ifcfg-br0
>> DEVICE=br0
>> ONBOOT=yes
>> MACADDR=00:19:99:ac:b3:24
>> TYPE=Bridge
>> BOOTPROTO=dhcp
>> STP=on
>> NM_CONTROLLED=no
>> DELAY=0
>>
>> /etc/sysconfig/network-scripts/ifcfg-eth0
>> DEVICE=eth0
>> HWADDR=00:19:99:cd:a5:e6
>> #BOOTPROTO=dhcp
>> ONBOOT=yes
>> BRIDGE=br0
>> TYPE=Ethernet
>> NM_CONTROLLED=no
>>
>>
>>> Greetings
>>> Mark
> 
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Vlad Yasevich <vyasevich@gmail.com>
To: Mark Trompell <mark@foresightlinux.org>,
	Veaceslav Falico <veaceslav@falico.eu>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	herbert@gondor.apana.org.au
Subject: Re: bridge not getting ip since 3.11.5 and 3.4.66
Date: Tue, 26 Nov 2013 10:25:23 -0500	[thread overview]
Message-ID: <5294BD63.7020905@gmail.com> (raw)
In-Reply-To: <CAEPa5ym4HWK9vo_BYYZbQsGZXG9r2kfYR2rFGaYjjJqDfkf2uQ@mail.gmail.com>

On 11/26/2013 08:27 AM, Mark Trompell wrote:
> Answering my own mail again and even top posting, sorry, but makes
> more sense to me in that case).
> I reverted bridge related patches from 3.11.5 and it boils down to
> commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date:   Thu Sep 12 17:12:05 2013 +1000
> 
>     bridge: Clamp forward_delay when enabling STP
> 
>     [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ]
> 
>     At some point limits were added to forward_delay.  However, the
>     limits are only enforced when STP is enabled.  This created a
>     scenario where you could have a value outside the allowed range
>     while STP is disabled, which then stuck around even after STP
>     is enabled.
> 
>     This patch fixes this by clamping the value when we enable STP.
> 
>     I had to move the locking around a bit to ensure that there is
>     no window where someone could insert a value outside the range
>     while we're in the middle of enabling STP.
> 
> Causing the issue for me. Reverting that patch and br0 comes up again
> and gets an ip.

yes, that patch introduced a bug where we always used the
max_forward delay value.

you have 2 options:
 1) disable STP.  Since you are just running VMs and you have a single
    physical connection on the bridge, you can safely disable STP since
    your system is a leaf node.

 2) Get the latest stable kernel.  The bug has been fixed there.

-vlad

> 
> On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote:
>>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote:
>>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>>>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66,
>>>>> What information would be helpful and required to find out what's going wrong.
>>>>
>>>> CC netdev
>>>>
>>>> First thing would be to provide the network scheme. Do you use vlans?
>>>> Which network
>>>> cards/drivers are you using? Do you use some kind of virtualization?
>>>> Is bonding involved?
>>>>
>>> Actually this is my desktop machine using kvm for a virtual machine
>>> that uses eth0 which is connected to the bridge
>>> which is used as interface for the host.
>>>
>>> $ ip addr
>>> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
>>> master br0 qlen 1000
>>> ...
>>> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
>>> ...
>>>
>>> Anything else?
>>
>> Okay more about my hardware and configuration:
>> from lspci:
>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
>> Connection (rev 04)
>>
>> /etc/sysconfig/network-scripts/ifcfg-br0
>> DEVICE=br0
>> ONBOOT=yes
>> MACADDR=00:19:99:ac:b3:24
>> TYPE=Bridge
>> BOOTPROTO=dhcp
>> STP=on
>> NM_CONTROLLED=no
>> DELAY=0
>>
>> /etc/sysconfig/network-scripts/ifcfg-eth0
>> DEVICE=eth0
>> HWADDR=00:19:99:cd:a5:e6
>> #BOOTPROTO=dhcp
>> ONBOOT=yes
>> BRIDGE=br0
>> TYPE=Ethernet
>> NM_CONTROLLED=no
>>
>>
>>> Greetings
>>> Mark
> 
> 
> 

  reply	other threads:[~2013-11-26 15:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 10:29 bridge not getting ip since 3.11.5 and 3.4.66 Mark Trompell
2013-11-11 11:07 ` Veaceslav Falico
2013-11-11 12:52   ` Mark Trompell
2013-11-12 10:57     ` Mark Trompell
2013-11-26 13:27       ` Mark Trompell
2013-11-26 13:27         ` Mark Trompell
2013-11-26 15:25         ` Vlad Yasevich [this message]
2013-11-26 15:25           ` Vlad Yasevich
2013-11-27  6:46           ` Mark Trompell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5294BD63.7020905@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=herbert@gondor.hengli.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@foresightlinux.org \
    --cc=netdev@vger.kernel.org \
    --cc=veaceslav@falico.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.