Hello,

th elinux kernel support vlan aware bridges for a while now.
(cfr.
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConJapan2014_makita_0.pdf)

it would be great to have support in ifupdown for them, with
config stanzas like bridge-vlan-aware, bridge-vid, bridge-pvid,
etc.
(cfr. package ifupdown2)

Please consider implementing.

Bye,

Joerg

reassign 868220 bridge-utils
thanks

Ifupdown itself supports VLANs for any interface, but I think that's not
what you want. You want to assign VLANs to individual bridge ports. It
looks to me this functionality should be added to bridge-utils'
if-pre-up/down.d scripts, therefore I'm reassigning this bug to the
bridge-utils package.

On the other hand, it seems brctl itself is quite limited and doesn't
support any VLAN configuration, you'd have to use the "bridge" command
from iproute2.

Well, ok with that.

Yes, that is my current way of setting up a vlan aware bride.

But them again, vlan interface setup that originally started with
the vconfig tool, is meanwhile part of the iproute2 toolset and
supported directly by ifupdown. Maybe this is also the way for
bridges?

Bye,

Joerg

[...]

It looks to me like iproute2 now provides a superset of vconfig and
brctl, so yes, perhaps it should all be configured using iproute2.
However, the bridge support for ifupdown currently lives in the
bridge-utils package, so that's why I've reassigned the bug there. But
if there is a desire to move the ifupdown integration scripts to the
ifupdown package, I'd not be opposed to that.

Hi!

I've also thinked about this because bridge-utils is basically dead upstream
while iproute2 is integrating more and more stuff, so having the bridge
support on ifupdown and depending on iproute2 instead of bridge-utils may be
the way to go.

If you agree with this we'll have to talk on how we do this.

Regards.

That is fine with me.

To my understanding it is basically translating the the hook scripts that
call brctl now to corresponding call to ip. While at it, adding
vlan-awareness ;-)

Again, having a look at what ifupdown2 does exeactly could help.

Bye,

Joerg

We still haven't talked about how to land bridge setup on ifupdown yet :-(

However recently Benedikt Spranger asked for us to enable vlan filtering
for vlan-aware switches, so next version of bridge-utils will allow enabling
this from the interfaces file.

Regards.

Looks like bridge-utils already does it in:
/lib/bridge-utils/ifupdown.sh

# Activate VLAN filtering on VLAN aware bridges
  if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then
    ip link set dev $IFACE type bridge vlan_filtering 1
  else
    ip link set dev $IFACE type bridge vlan_filtering 0
  fi


the problem is I get operation not supported when setting vlan_filtering 0
on my bridge, does the else really make sense here?


Regards

Hi!

Well, this was added due to bugs.debian.org/950879 reported by Benedikt who
kindly supplied the patch, the patch didn't cause any trouble on the tests I
did and that's why I applied it like he sent it.

I have added Benedikt to my reply for him to comment on this.

As I understand it, Gianluigi, if we remove the else there we won't set vlan
filtering to 0 and thus you won't get the error, right?

We have two options here, one is to remove it and the other to send the
possible errors on the setting to 0 case to /dev/null.

As I see it, maybe the second option is better, as if one has set this to
yes and then sets it to no without rebooting, he wouldn't get the expected
behaviour.

Benedikt and Gianluigi, what do you think?

Regards.

On Wed, 3 Jun 2020 13:50:56 +0200 Santiago Garcia Mantinan <manty@debian.org> wrote:

Hi,

sorry for the trouble.
Unfortunately yes.
The brigde is configured at runtime and can be reconfigured. Without the
else part a user is forced to unset the filtering by hand if set by
try/error/accident.
OK.
May I introduce a third option?
I am not shure, if that pseudo file exists on every supported kernel,
but you got the idea. If that is prefered, i can dig through the kernel
sources and provide a patch.

NOTE: untested!
---8<---
# Activate VLAN filtering on VLAN aware bridges

if [ "$IF_BRIDGE_VLAN_AWARE" = "yes" ]; then
  ip link set dev $IFACE type bridge vlan_filtering 1
else
  if [ -f /sys/devices/virtual/net/$IFACE/bridge/vlan_filtering ]; then
    ip link set dev $IFACE type bridge vlan_filtering 0
  fi
fi
---8<---

I do not like to paper over errors like sending them to /dev/null.
But I prefer that option over droping the else part.

Regards
    Benedikt Spranger

Well, kind of, I mean, on some of the bugs, at least on #868220, we've
have talked about this. And given that upstream has been inactive for
years... we have talked about getting the bridge setup scripts on
ifupdown and leave bridge-utils with just the brctl tool.

I'm crossposting and adding Guus to the mail to see if we can agree on
something here, I don't think it is now the time to do it, it would be
for post Bullseye, but I don't have any problem in rewriting the
scripts to use just iproute2 and maintain those scripts under ifupdown
so that Guus didn't have to take care of more stuff.

Guus, what do you think?

Regards.

whether the bridge-utils package does it or ifupdown doesn't really
matter. At this point, I think it can still be done in bridge-utils,
migrating functionality between packages during the soft-freeze is
probably a no-go.

I did something similar in the past for the ifenslave package: it used
to be a compiled C program from the kernel sources that was shipped, at
some point I replaced it with a shell script that just echoed the right
values into the /sys/class/net/ hierarchy. The brctl command is very
simple, and the same thing could be done there. The hardest part would
be to emulate the output of `brctl show`. For the if-*.d scripts this is
not an issue of course.

ke 24. helmik. 2021 klo 21.04 Guus Sliepen (guus@debian.org) kirjoitti:

To me, from a user perspective, the main advantage of using the
'bridge' command from iproute2 and of merging the functionality into
ifupdown would be to always have bridge control functionality included
with ifupdown and to harmonize the regex syntax in
/etc/network/interfaces. I've filed #982959 on that particular point.

There are probably other advantages of migrating to this e.g. from a
technical perspective, but it's not my department.

Martin-Éric