Bug#993290: please provide bridge-utils- compatible /etc/network/if-up-d/ script for ifupdown
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.)
On Mon, Aug 30, 2021 at 12:23:09PM +0300, Michael Tokarev wrote:
> Source: iproute2
> Severity: normal
>
> 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.
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).
>
> 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.
I think vlan package is a good example. The content of the package got
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.
>
> 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.
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.
>
> 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?
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!
>
> Thanks!
>
> /mjt
>
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
Reply to: