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
