Debian Bug report logs - #673490
serious doubts about /lib/udev/bridge-network-interface

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: serious doubts about /lib/udev/bridge-network-interface

Date: Sat, 19 May 2012 02:14:59 +0200

[Message part 1 (text/plain, inline)]

Package: bridge-utils
Version: 1.5-3
Severity: important

Me and Andrew Shadura, the ifupdown maintainer, have been looking at the 
latest bridge-utils upload, and we have several concerns about it.

For a start, directly calling /etc/network/if-pre-up.d/vlan is a huge 
layering violation.
Anyway, nowadays ifupdown directly manages vlans and the vconfig 
package is deprecated.

I am quite concerned that you decided that a complex script should be 
called for every "auto" interface which appears in the system: this 
could have a serious impact on systems with many interfaces (I have 
firewalls with over hundreds of interfaces configured!).
I also doubt that this is generally a good idea, even if it were not 
causing scalability problems, because interfaces marked "auto" should 
only be configured at boot time.

Last but not least, nowadays iproute is able to create bridges by 
itself, so we should investigate if brctl is still needed.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Santiago Garcia Mantinan <manty@debian.org>

To: Marco d'Itri <md@linux.it>, 673490@bugs.debian.org

Subject: Re: Bug#673490: serious doubts about /lib/udev/bridge-network-interface

Date: Sat, 19 May 2012 13:23:08 +0200

Hi!

Last upload was trying to get in sync with Ubuntu, I didn't see any problems
with that, but let's see your concerns...

> For a start, directly calling /etc/network/if-pre-up.d/vlan is a huge 
> layering violation.
We've been calling /etc/network/if-pre-up.d/vlan for a long time, it is how
we setup the vlan ports of a bridge automatically:

bridge-utils (0.9.6-4) unstable; urgency=low

  * Add support for autoconfiguring VLAN interfaces, idea and patch
    from Paul Slootman. Closes #189386.

 -- Santiago Garcia Mantinan <manty@debian.org>  Thu,  8 May 2003 20:21:14 +0200

> Anyway, nowadays ifupdown directly manages vlans and the vconfig 
> package is deprecated.

Ok, it's been 9 years since we introduced that, maybe we can do it some
other way, now, any pointer on this?

> I am quite concerned that you decided that a complex script should be 
> called for every "auto" interface which appears in the system: this 
> could have a serious impact on systems with many interfaces (I have 
> firewalls with over hundreds of interfaces configured!).

I suppose you are talking about the udev called bridge-network-interface.sh
script. Well, this is one of the parts inherited from Ubuntu, I can see your
concerns here and I agree that on some scenarios this might cause trouble,
I'm wondering if you did test this to see if it really impacted that much on
those scenarios :-?

I cannot test it on one of those real scenarios, but I just run...
INTERFACE=br0 /lib/udev/bridge-network-interface 1000 times on my old amd
Athlon 64@1.8Ghz and it took 19 seconds.

> I also doubt that this is generally a good idea, even if it were not 
> causing scalability problems, because interfaces marked "auto" should 
> only be configured at boot time.

Well, the idea behind this is not bringing up interfaces marked auto, for
that we already have allow-hotplug, but adding interfaces to existing
bridges that have that interface specified as a bridge port.

I can agree however that sometimes having all this done automatically can be
the not wanted action, but I like the posibility that is added with this for
hotpluging stuff to bridges. I'm open to all kind of ideas on how to solve
this posible problems.

For example, we can add /etc/default/bridge-utils and specify there some
variable controlling all this behaviour, I don't know what would be wanted
here, we can implement whatever you feel better there, from a HOTPLUG=false
default (not my favourite) to a HOTPLUG=true (I'd prefer this one) ranging
to some kind of specification of the bridges that can be hotpluged
interfaces into.

What do you think?

> Last but not least, nowadays iproute is able to create bridges by 
> itself, so we should investigate if brctl is still needed.

I'll have to check that, iproute is not known for the documentation included
on the package itself, but I doubt it provides everything brctl does.  I'm
thinking on a "brctl showstp br0" for example.

Well, sorry has worried you, let's see how we can make this less worrying.

Hoping to hear back from you.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Message #15 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Andrew Shadura <bugzilla@tut.by>

To: Santiago Garcia Mantinan <manty@debian.org>

Cc: Marco d'Itri <md@linux.it>, 673490@bugs.debian.org

Subject: Re: Bug#673490: serious doubts about /lib/udev/bridge-network-interface

Date: Sun, 20 May 2012 18:38:34 +0200

[Message part 1 (text/plain, inline)]

Hello,

On Sat, 19 May 2012 13:23:08 +0200
Santiago Garcia Mantinan <manty@debian.org> wrote:

> > For a start, directly calling /etc/network/if-pre-up.d/vlan is a
> > huge layering violation.

> We've been calling /etc/network/if-pre-up.d/vlan for a long time, it
> is how we setup the vlan ports of a bridge automatically:

Sorry for not being able to post more things here now, but at least if
that if-pre-up.d scripts are called by ifupdown itself, you don't need
to call them explicitly.

Hope to add more comments a bit later.

-- 
WBR, Andrew

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Santiago Garcia Mantinan <manty@manty.net>

To: Andrew Shadura <bugzilla@tut.by>

Cc: 673490@bugs.debian.org

Subject: Re: Bug#673490: serious doubts about /lib/udev/bridge-network-interface

Date: Sun, 20 May 2012 21:10:31 +0200

> > > For a start, directly calling /etc/network/if-pre-up.d/vlan is a
> > > huge layering violation.
> > We've been calling /etc/network/if-pre-up.d/vlan for a long time, it
> > is how we setup the vlan ports of a bridge automatically:
> Sorry for not being able to post more things here now, but at least if
> that if-pre-up.d scripts are called by ifupdown itself, you don't need
> to call them explicitly.
Sorry but I don't get it, what we are doing there is call that script so
that it creates the eth0.X interface and we are able to add it to the
bridge, if there is any way for us to call ifupdown itself to do this job
just let me know and I'll gladly make the apropiate changes.

Just to make sure we are talking about the same stuff here, the thing is
that we define a bridge with vlan based ports this way:

       auto br0
       iface br0 inet dhcp
           bridge_ports eth0.123 eth0.234 eth1.500

And the script is called so that eth0.123 eth0.234 eth1.500 is created
automatically without having any definitions for them on
/etc/network/interfaces.

Like I said, if there is some other way to do it following standards just
let me know. The way we are doing this is the way me and the vlan maintainer
agreed back on 2003, I'm sure things have changed much since then, but I
just didn't get to know some other better way to make it.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Message #25 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Andrew Shadura <bugzilla@tut.by>

To: Santiago Garcia Mantinan <manty@manty.net>

Cc: 673490@bugs.debian.org

Subject: Re: Bug#673490: serious doubts about /lib/udev/bridge-network-interface

Date: Sun, 20 May 2012 23:53:44 +0200

[Message part 1 (text/plain, inline)]

Hello,

First of all I think that bringing interfaces up without their prior
declaration isn't a good idea, but well, okay, let's skip this for a
while.

Vlan package is going to be dropped, and in its absence there's nothing
to bring those interfaces up unless you try to configure these vlans on
your own using ip utility. By the way, how about non-vlan interfaces?
How do they get configured without being declared in /e/n/i?

Also, this check: [ ! -d /sys/class/net/$port ] &&
[ -x /etc/network/if-pre-up.d/vlan ] isn't quite correct. If we have
additional options for vlan interface set in /e/n/i, they will be
silently ignored, which is no good. You should check if it's defined
in /e/n/i somehow. For example, you can ifup it first, then check if
interface is available, and if not... Or you could use ifquery for
that, but in it's current shape it's not that easy as I would like it
to be, as it always returns true regardless of interface definition
presense (to be fixed tomorrow).

Also, mkdir -p /var/run/network seems to be unneeded, I'd rather just
check if /run/network exists and quit without doing anything if it
doesn't.

(Hope I didn't forget anything I wanted to say or anything or what we
discussed on IRC.)

-- 
WBR, Andrew

[signature.asc (application/pgp-signature, attachment)]

Message #30 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Anthony DeRobertis <anthony@derobert.net>

To: Debian Bug Tracking System <673490@bugs.debian.org>

Subject: bridge-network-interface breaks resolvconf

Date: Thu, 31 May 2012 17:29:06 -0400

Package: bridge-utils
Version: 1.5-3
Followup-For: Bug #673490

I have another concern with bridge-network-interface. When I rebooted my
system today, suddenly name resolution didn't work. /etc/resolv.conf was
empty.

	auto br0
	iface br0 inet dhcp
		up ip route add 172.16.2.0/24 via 172.16.1.208
		down ip route del 172.16.2.0/24 via 172.16.1.208
		dns-search lan.metrics.net dmz.metrics.net
		bridge_ports lan
		bridge_stp off
		bridge_fd 2
		bridge_maxwait 20

(More ports get added later for kvm vhosts)

I use resolvconf, which should have filled that stuff in. But the boot
order goes udev -> local fs -> resolvconf -> networking, and the
resolvconf init script clears all the resolvconf info. Shouldn't be a
problem, as resolvconf does this before interfaces are brought up.

Well, or at least it is supposed to be. But instead the udev rule
brought up the interface, way too early in the boot process.

I fixed it by changing '--allow auto' to '--allow hotplug' in
bridge-network-interface. (I have no idea how, or if, resolvconf works
with non-bridge hotplug interfaces...)

Message #35 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Stéphane Graber <stgraber@ubuntu.com>

To: 673490@bugs.debian.org

Subject: Event based network initialization in Ubuntu

Date: Wed, 13 Jun 2012 18:29:00 -0400

[Message part 1 (text/plain, inline)]

Hello,

I must admit not being perfectly up to date as to how Debian's
networking stack is working at boot time, so to hopefully try to explain
why Ubuntu did these changes, here's a quick explanation of how things
work on our side.

Ubuntu essentially supports two different tools to initialize the
network. For desktop systems, that's Network Manager (only loopback is
setup by ifupdown) and for servers, that's ifupdown.

As you also know, Ubuntu uses upstart as its init system. Upstart has a
udev bridge that's used to trigger init jobs on hotplug events.

Take my usual test setup as an example:
> auto lo
> iface lo inet loopback
> 
> auto eth0
> iface eth0 inet manual
>     bond-master bond0
> 
> auto eth1
> iface eth1 inet manual
>     bond-master bond0
> 
> auto bond0
> iface bond0 inet static
>     bond-slaves none
>     bond-mode 802.3ad
>     bond-miimon 100
> 
>     address 172.17.0.55
>     netmask 255.255.255.0
>     gateway 172.17.0.1
>     dns-nameservers 2607:f2c0:f00f:2720:e084:d1ff:fe38:c4f5 2001:470:714b:1020:218:51ff:fe5a:9949
> 
> auto br1005
> iface br1005 inet dhcp
>     bridge-ports bond0.1005
>     bridge_stp off
> 
> auto br1005:0
> iface br1005:0 inet static
>     address 192.168.99.1
>     netmask 255.255.255.0

In this example you can see a nice mix of:
 - 802.3ad bonding (eth0 is an onboard e1000e, eth1 is a USB 3com
adapter that's usually NOT plugged in)
 - br1005 depends on bond0.1005 but bond0.1005 itself isn't defined

The boot time sequence on this machine looks like this:
1) Kernel initialize
2) Upstart, udev and udev-bridge start

3) net-device-added is emitted for eth0
  - upstart starts an instance of the network-interface job for eth0
    1) this job runs "ifup --allow auto eth0"
    2) ifenslave pre-up is called by ifupdown, creating the parent bond0
device
    3) net-device-added is emitted for bond0
      - upstart starts an instance of the network-interface job for bond0
        1) this job runs "ifup --allow auto bond0"
        2) ifenslave pre-up configures the bond device, not joining any
slave
        3) The ifup instance configuring bond0 detects that a slave was
added and adds the IP/run dhcp (not possible until a slave is joined)
      - the vlan udev hook detects that bond0 now exists and creates
bond0.10015
        - upstart starts an instance of the network-interface job for
bond0.1015
          1) Nothing to do, it's not defined in /e/n/i
        - the bridge udev hook detects that bond0.1005 now exists,
creates br1005 and joins bond0.1005
          - net-device-added is emitted for br1005
            - upstart starts an instance of the network-interface job
for br1005
              1) this job runs "ifup --allow auto br1005"
              2) ifupdown configures br1005 (starts dhclient)
    4) Now that bond0 is configured (ifenslave pre-up waits for that
state on Ubuntu), join the first slave

4) upstart hits the fallback/legacy networking job and calls "ifup -a"
  - ifupdown brings the remaining "virtual" interfaces, in this case,
br1005:0

5) some time later (days/weeks), net-device-added is emitted for eth1
  - upstart starts an instance of the network-interface job for eth1
    1) this job runs "ifup --allow auto eth1"
    2) ifenslave pre-up is called by ifupdown, joining eth1 to bond0

Numbered items are run sequentially, non-numbered items are typically
run in parallel. Also note, that I wrote these down based on what I
remember from the work I did the past 6 months, it might be slightly
inaccurate.

In this example, not having the udev hooks might (race condition) cause
br1005 to come up with bond0.1005 bridged into it. A similar thing can
happen with the vlan code if an explicit definition of a vlan exists in
/e/n/i and "ifup -a" is hit before the parent interface exists.

I already had multiple users reporting some systems with a lot of
storage and network hardware that'd take up to 5 minutes until all the
udev network events would be emitted, so most of their ethX devices
would appear on the system a long time after "ifup -a" was run.

The only way of properly supporting these systems as well as the hotplug
use cases is to have as much of the network stack as possible brought up
by events and until such time that ifupdown supports bringing up reverse
dependencies when an interface is brought up, these udev hooks will
still be required.

Sorry for it to be so complicated, but that's really the setup that
explains the best what we're supporting in Ubuntu and the kind of setups
we need to deal with.

I hope this all helps explain why we've done these changes in Ubuntu, I
hope that some of that work can be merged in Debian, for anything that's
problematic, I'm certainly happy to continue maintaining that delta in
Ubuntu as regression in that area simply isn't acceptable for us.

An higher level view of the things can be found here:
http://www.stgraber.org/2012/01/04/networking-in-ubuntu-12-04-lts/

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

[signature.asc (application/pgp-signature, attachment)]

Message #40 received at 673490@bugs.debian.org (full text, mbox, reply):

From: Santiago Garcia Mantinan <manty@debian.org>

To: 673490@bugs.debian.org

Subject: Sorry about the delay on this

Date: Fri, 29 Jun 2012 08:20:01 +0200

Hi!

I'm still alive and aware of the freeze coming now but I've been father for
the second time three weeks ago and I'm still not able to find the time
needed to fix all this.

What I'm planning to do with all the stuff we've talked about on this bug:

vlan dependency: leave it like it is for wheezy as we are not dropping the
package yet and the changes I'll need to do are too big for this time of the
release.

hotplug of interfaces: have this behaviour selectable and disabled by
default on a /etc/default/bridge-utils (I know some people won't like this,
but I couldn't get the help on looking at all this that I was hoping for,
so... this is the best I can do for now)

resolvconf issue: there is already another bug for that one (#676183) and
I'll try to reproduce and fix this one.

Any other?

If anybody wants to help in sending patches or whatever he is welcome to do
so, as I'm still having problems in finding time for this and I'm having a
travel soon, so time will even be less.

Regards...
-- 
Manty/BestiaTester -> http://manty.net

Message #45 received at 673490-close@bugs.debian.org (full text, mbox, reply):

From: Santiago Garcia Mantinan <manty@debian.org>

To: 673490-close@bugs.debian.org

Subject: Bug#673490: fixed in bridge-utils 1.5-4

Date: Fri, 29 Jun 2012 23:11:24 +0000

Source: bridge-utils
Source-Version: 1.5-4

We believe that the bug you reported is fixed in the latest version of
bridge-utils, which is due to be installed in the Debian FTP archive:

bridge-utils_1.5-4.diff.gz
  to main/b/bridge-utils/bridge-utils_1.5-4.diff.gz
bridge-utils_1.5-4.dsc
  to main/b/bridge-utils/bridge-utils_1.5-4.dsc
bridge-utils_1.5-4_amd64.deb
  to main/b/bridge-utils/bridge-utils_1.5-4_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 673490@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Garcia Mantinan <manty@debian.org> (supplier of updated bridge-utils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 29 Jun 2012 10:56:51 +0200
Source: bridge-utils
Binary: bridge-utils
Architecture: source amd64
Version: 1.5-4
Distribution: unstable
Urgency: low
Maintainer: Santiago Garcia Mantinan <manty@debian.org>
Changed-By: Santiago Garcia Mantinan <manty@debian.org>
Description: 
 bridge-utils - Utilities for configuring the Linux Ethernet bridge
Closes: 673490 676183
Changes: 
 bridge-utils (1.5-4) unstable; urgency=low
 .
   * Remove mkdir and exit if /run/network doesn't exist. Thanks
     to Andrew Shadura. Closes: #676183.
   * Allow hotplug of ports to be user configurable and default
     to disable. Closes: #673490.
Checksums-Sha1: 
 b9289aa231d6a47367eb008313a8738d017b62c0 1060 bridge-utils_1.5-4.dsc
 8055172e83e8aa22485fafcf55fc070b8807a921 15362 bridge-utils_1.5-4.diff.gz
 65d638caa7debeb87f06846384b802f96db9b4d4 35968 bridge-utils_1.5-4_amd64.deb
Checksums-Sha256: 
 ff858fabde1721de2b0c0469c9f5418db609221059e0e2ecc6a97ce0ccc52bdd 1060 bridge-utils_1.5-4.dsc
 af9365a8b7aeb191a6d6132afd5e0ffa72363d8f62fbac0e72bc1c364a77426e 15362 bridge-utils_1.5-4.diff.gz
 7549be6e21a16b685742156849772615d9f1480db5452b1668b1e61b0a310d43 35968 bridge-utils_1.5-4_amd64.deb
Files: 
 fe2e99810245ffd6ad91e8587159ae03 1060 net optional bridge-utils_1.5-4.dsc
 2b53a667fe6e9f9905da45b76ec1088c 15362 net optional bridge-utils_1.5-4.diff.gz
 6bd18363f9ccd8438151feef584d5177 35968 net optional bridge-utils_1.5-4_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAk/uLgcACgkQcv3CBfajKo4RcQCdGI7M9JNK0X8yJfwZ2dmPhhn3
VzoAoIEi3ddHjYovqLIaFMwbWLU9oaZg
=tJFj
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.