netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Krzysztof Olędzki" <ole@ans.pl>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
Date: Sun, 04 Sep 2011 19:12:21 +0200	[thread overview]
Message-ID: <4E63B175.6020106@ans.pl> (raw)
In-Reply-To: <20110904093634.685d7c56@nehalam.ftrdhcpuser.net>

On 2011-09-04 18:36, Stephen Hemminger wrote:
> On Sun, 04 Sep 2011 09:35:10 +0200
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>  wrote:
>
>> Le 04/09/2011 06:14, Stephen Hemminger a écrit :
>>
>>>> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
>>>> following condition are true at the same time :
>>>>
>>>> - The bridge have no port.
>>>> - At least one IP address is setup on the bridge.
>>>> - The two above conditions are true for more than a configurable amount of seconds, with a default
>>>> of 10, for example.
>>>>
>>>> This would only delay carrier on for a few seconds for the regression and keep the current behavior
>>>> (carrier off until at least 1 port is on) for DHCP.
>>>
>>> This fails on two counts:
>>> 1. Bridge's often run without IP addresses!
>>> 2. DHCP won't try and send out request until carrier is true.
>>
>> Sorry, I missed to say that we should of course also assert carrier on if one port has carrier on.
>>
>> And rethinking about it, the delay is probably useless :
>>
>> bridge_carrier_on = at_least_one_port_has_carrier_on | (bridge_has_no_port&  bridge_has_at_least_one_ip)
>>
>> That way :
>> - for those using bridge without any port, manually setting the IP will assert carrier on. (By the
>> way, why don't they use a dummy device instead?)
>>
>> - for those using bridge with ports:
>> -- Using any kind of autoconfig will work as expected. Carrier will only be asserted at the time
>> first port get carrier.
>> -- Using static IP confifiguration, carrier will possibly be erroneously reported as on during the
>> small time gap between IP address configuration and first port is added to the bridge. This time gap
>> may be removed by simply configuring the IP after the first port is added. This is probably already
>> true for most distribs. And anyway, this time gap is probably not a problem.
>> -- Carrier will also be erroneously reported as on after removing the last port, if the bridge still
>> has an IP. (But we can arrange for this not to happen).
>>
>> And in order to ensure user really understand why carrier is on of off, we can simply issue an INFO
>> message for the non-natural case (bridge_has_no_port&  bridga_has_at_least_one_ip).
>>
>> I consider all this reasonable.
>>
>> 	Nicolas.
>
> Any bridge behaviour based on IP address configuration is a
> layering violation and won't work.  The problem is related to dynamic issues
> with IPv6 and DHCP and needs to be addressed at that level.

Maybe we can simply add a switch controlling if a bridge with no 
attached ports has carrier off (default) or on.

For example:
  echo {0|1} > /sys/devices/virtual/net/brX/bridge/orphaned_carrier

  brctl orphaned_carrier brX {on|off}

Best regards,

				Krzysztof Olędzki

  reply	other threads:[~2011-09-04 17:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110902172220.830228928@vyatta.com>
2011-09-02 17:22 ` [PATCH 1/2] bridge: leave carrier on for empty bridge Stephen Hemminger
2011-09-02 21:39   ` Nicolas de Pesloüan
2011-09-02 22:11     ` Stephen Hemminger
2011-09-03  2:15       ` Ang Way Chuang
2011-09-03  6:30         ` Stephen Hemminger
2011-09-25  8:55         ` Marc Haber
2011-09-03 18:32       ` Nicolas de Pesloüan
2011-09-04  4:14         ` Stephen Hemminger
2011-09-04  7:35           ` Nicolas de Pesloüan
2011-09-04 16:36             ` Stephen Hemminger
2011-09-04 17:12               ` Krzysztof Olędzki [this message]
2011-09-05  4:51                 ` Ang Way Chuang
2011-09-05 17:18               ` Nicolas de Pesloüan
2011-09-05 17:57                 ` Stephen Hemminger
2011-09-05 19:02                   ` Ang Way Chuang
2011-09-05 22:45                     ` Stephen Hemminger
2011-09-06  6:52                   ` Nicolas de Pesloüan
2011-09-25  9:16                     ` Marc Haber
2011-09-25 20:10                       ` Nicolas de Pesloüan
2011-09-25  9:05             ` Marc Haber
2011-09-02 17:22 ` [PATCH 2/2] bridge: set flags in RTM_NEWNEIGH message correctly Stephen Hemminger
     [not found] <20111004041444.793960297@vyatta.com>
2011-10-04  4:14 ` [PATCH 1/2] bridge: leave carrier on for empty bridge Stephen Hemminger
2011-10-06 19:28   ` David Miller

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=4E63B175.6020106@ans.pl \
    --to=ole@ans.pl \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.2p.debian@gmail.com \
    --cc=shemminger@vyatta.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).