lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Aug 2011 15:41:50 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Marc Haber <mh+netdev@...schlus.de>
Cc:	netdev@...r.kernel.org
Subject: Re: Bridge stays down until a port is added

On Thu, 11 Aug 2011 22:54:29 +0200
Marc Haber <mh+netdev@...schlus.de> wrote:

> Hi Stephen,
> 
> On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> > On Thu, 11 Aug 2011 09:06:59 +0200
> > Marc Haber <mh+netdev@...schlus.de> wrote:
> > > Is that a feature? If so, why does the interface stay pingable after
> > > removing the dummy0 interface from the bridge?
> > 
> > Yes, there are no links to send a packet so it seems logical
> > that there would be no carrier.
> 
> Yes, but if I can configure an IP address to the bridge I would expect
> it to be reachable even if there are no interfaces in the bridge.
> "Older" kernels used to behave like that.
> 
> > > New new behavior is somewhat unhandy when one uses the bridge address
> > > for services that the host offers, to save on IP addresses and
> > > networks (for example, when one has only a single IP address and a
> > > single additional network), since one has to take extra measures to
> > > have the addresses on the bridge interface reachable.
> > > 
> > > Or am I doing things wrong?
> > 
> > The goal is to make the bridge behave the same as a vlan or
> > a physical device.  Could you explain better what the application(s)
> > would expect.
> 
> I have a number of housing systems that have only a single IP address
> on their eth0, but an IP network routed to bring virtual machines
> running on these systems online. The virtual machines are all on br0,
> and the host is routing between eth0 and br0. To route, it needs its
> own IP address on br0, and I have not resisted the temptation of
> running servies on the br0 IP address.
> 
> It is unnatural to not have the br0 IP address reachable unless the
> first VM is running. I have, in the mean time, created a dummy0
> interface and am adding dummy0 to br0 just to have the bridge
> operational, but that's a hack. I'd like to have the old behavior back
> as an optional configuration.

I still say why should bridge behave differently than bonding
or a physical device? I wonder if part of the difference is that real
devices have transmit queues and the test for link being up
is done in IP based on transmit queue rather than on carrier state.

On routers, it is common to assign some addresses to loopback device so
they stay up independent of the underlying links.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ