iproute2 package contains bridge control utility for a long time
(maybe since the beginning). It is superior to brctl utility which
is traditionally used to setup bridges on linux.

It is more: these days, bridges are often used with virtual machines,
and there, iproute's bridge is *significantly* better when used
together with vlan tagging, since bridge code in linux can deal with
per-port vlan settings internally and hence we only require single
bridge with everything, compared with a bridge for each vlan as with
bridge-utils.

By providing bridge functionality in the iproute package we'll eliminate
bridge-utils dependency altogether.

And since ip utility can deal with vlans too, while at it we can absorb
vlan package functionality too.

It is interesting that so far this hasn't been done. We switched to
iproute-based bridging several years ago and it was a real game-change
for us.

I have a script to set up bridges using ip utility (including per-port
vlan settings), which looks like this in network/interfaces
(a bit modified real example):
--- cut ---
# this is the bridge interface:
auto brf
iface brf inet manual
 bridge-vids 3 5 8 9 14
 bridge-ports tls-eth
 bridge-fd 5
 bridge-maxwait 0

# this is the physical interface which is part of the bridge
auto tls-eth
iface tls-eth inet manual
 # the same as for brf but tag14 is internal to the host
 bridge-vids 3 5 8 9

# this is actual host's interface in vlan 1
auto tls-mother
iface tls-mother inet static
 vlan 3@brf
 address 192.168.177.15/26
 gateway 192.168.177.5

# other interfaces for virtual machines etc
--- cut ---

The "vlan" works both in bridge mode and with regular interfaces.

But I'd love to have some discussion about how the setup should look like
before sending the actual script.

Also I'm a bit unsure - if this functionality is to be merged into
/etc/network/if-pre-up.d/iproute2, how can we disable the same
functionality in if-pre-up.d/bridge-utils?

Thanks!

/mjt

Hello Michail Tokarev,

Late followup, but here's my personal opinion for the sake of having a
discussion which you asked for.
(JFTR I'm not maintaining this package and my opinion might have 0 value
on this topic.)

The iproute2 collection is generally where to look for utilities
that use modern kernel interfaces for networking, rather than old
tools using old/obsolete ioctl interfaces that exists for backwards
compatibility (and often can not represent the real running configuration).
replaced by a script that simply gives existing users a migration path
*without* adding legacy burden on iproute2!

And speaking as a former iproute2 package maintainer and uploader of
vlan 2.0, the last part was equally important to me! :)

I think bridge-utils should follow the same path as vlan:
By having a new version that provides an upgrade path for existing
users without burdening others who never installed the legacy tools
with legacy migration cruft.

If my previous comments wheren't already spicy enough, here's a hot
take: I consider ifupdown itself to belong on the pile of legacy cruft.

Additionally iproute2 is low-level tools, ifupdown uses it as an
implementation detail. Having iproute2 provide ifupdown glue just
creates a confusing circular relationship. If you want ifupdown to
use more of iproute2, then I say implement it in ifupdown!

Hope that my comments where not too spicy and hopefully some food for
though.

(If it wasn't already obvious: My suggestion is to tags +wontfix this
bug report on the iproute2 side.)

Regards,
Andreas Henriksson