Bug 1652910 - [RFE] expose VLAN filtering in linux bridge connection attributes
Summary: [RFE] expose VLAN filtering in linux bridge connection attributes
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: 7.7
Assignee: Beniamino Galvani
QA Contact: Desktop QE
Marc Muehlfeld
URL:
Whiteboard:
Keywords: FutureFeature
: 1605123 (view as bug list)
Depends On:
Blocks: 1654714 NST_77ReleaseNotes 1605123
TreeView+ depends on / blocked
 
Reported: 2018-11-23 13:52 UTC by Dan Kenigsberg
Modified: 2019-06-06 09:17 UTC (History)
12 users (show)

(edit)
.`NetworkManager` now supports VLAN filtering on bridge interfaces

With this enhancement, administrators can configure virtual LAN (VLAN) filtering on bridge interfaces in the corresponding `NetworkManager` connection profiles. This enables administrators to define VLANs directly on bridge ports.
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

Description Dan Kenigsberg 2018-11-23 13:52:39 UTC
Linux bridge's support for VLAN filtering is quite cool, as it allows a hypervisor to connect each guest/container to arptrary VLAN with a single bridge device - much like switches behave.
https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge/

Please expose this knob in NM (and later, in nmstate) so CNV can make use of it.

Comment 2 Thomas Haller 2018-11-23 14:05:17 UTC
I think this is a duplicate of bug 1605123, isn't it?

Comment 3 Dan Kenigsberg 2018-11-28 16:10:39 UTC
actually I only need a single boolean attribute to enable/disable vlan_filtering

ip link set br0 type bridge vlan_filtering 1

Comment 4 Beniamino Galvani 2019-03-25 16:51:38 UTC
I pushed a branch for review at:

 https://github.com/NetworkManager/NetworkManager/pull/322

It adds the following connection properties:

* bridge.vlan-filtering: yes|no
  Enables/disables VLAN filtering.

* bridge.vlan-default-pvid: 0-4094
  The VLAN id assigned to incoming untagged frames. 0 disables the
  default VLAN.

* bridge.vlans: <vid> [pvid] [untagged], ...
  List of VLANs on the bridge, in addition to the default one.

* bridge-port.vlans: <vid> [pvid] [untagged], ...
  List of VLANs on the bridge port, in addition to the default one.

Comment 7 Dan Kenigsberg 2019-04-15 11:29:58 UTC
What should I do to enable vlans 1-4095 on a port named bond0? I realize (quite late) that this is an important piece of our use case. Would my ifcfg have thousands of lines?

Comment 8 Beniamino Galvani 2019-04-15 11:43:52 UTC
(In reply to Dan Kenigsberg from comment #7)
> What should I do to enable vlans 1-4095 on a port named bond0? I realize
> (quite late) that this is an important piece of our use case. Would my ifcfg
> have thousands of lines?

Not thousands of lines, but a single BRIDGE_VLANS= line with thousands of elements.

I think we could implement VLANs ranges to support this use case.

Comment 9 Dan Kenigsberg 2019-04-15 12:04:07 UTC
Yes, having a range in ifcfg, nmcli and dbus API would make this more workable.

Could you include this in 7.7?

Comment 10 Beniamino Galvani 2019-04-16 07:56:27 UTC
(In reply to Dan Kenigsberg from comment #9)
> Yes, having a range in ifcfg, nmcli and dbus API would make this more
> workable.
> 
> Could you include this in 7.7?

Filed merge request:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/114

I hope this will be merged before the NM 1.18 release that will be used in 7.7.

Comment 11 Beniamino Galvani 2019-04-18 09:56:27 UTC
Notes for QE:

Supported properties:

* bridge.vlan-filtering: yes|no

  Enables/disables VLAN filtering.

* bridge.vlan-default-pvid: 0-4094

  The VLAN id assigned to incoming untagged frames. 0 disables the
  default VLAN pvid.

* bridge.vlans: <vid>[-<vid>] [pvid] [untagged], ...

  List of VLANs on the bridge, in addition to the default one set with
  the 'bridge.vlan-default-pvid' property. Each element can be a
  single VLAN or a range. vid must be [1-4094]. Ranges must be valid
  (start < end).  Duplicated VLANs and overlapping ranges are not
  allowed. Only one vlan can have the 'pvid' attribute. If a VLAN is
  pvid, it overrides the default-pvid.

* bridge-port.vlans: <vid>[-<vid>] [pvid] [untagged], ...

  Same as 'bridge.vlans'.

Examples:

==== no pvid ====

$ nmcli connection add type bridge \
      ifname mybr con-name mybr+ \
      bridge.vlan-default-pvid 0 \
      bridge.vlan-filtering yes \
      bridge.vlans "10"

$ nmcli connection add type ethernet \
      ifname ens11 con-name ens11-slave+ \
      master mybr slave-type bridge \
      bridge-port.vlans "4094"

$ bridge vlan
port    vlan ids
ens11
         4094
mybr
         10

==== default pvid (1) ====

$ nmcli connection add type bridge \
      ifname mybr con-name mybr+ \
      bridge.vlan-filtering yes \
      bridge.vlans "10-14 untagged"

$ nmcli connection add type ethernet \
      ifname ens11 con-name ens11-slave+ \
      master mybr slave-type bridge \
      bridge-port.vlans "4 untagged, 5"

$ bridge vlan
port    vlan ids
ens11
         1 PVID untagged         4 untagged      5
mybr
         1 PVID untagged         10 untagged     11 untagged     12 untagged     13 untagged     14 untagged


==== non-default pvid ====

$ nmcli connection add type bridge \
      ifname mybr con-name mybr+ \
      bridge.vlan-filtering yes \
      bridge.vlan-default-pvid 80 \
      bridge.vlans "1-10, 100 pvid, 200 untagged"

$ nmcli connection add type ethernet \
      ifname ens11 con-name ens11-slave+ \
      master mybr slave-type bridge \
      bridge-port.vlans 4000-4010

$ bridge vlan
port    vlan ids
ens11
         80 PVID untagged        4000    4001    4002    4003    4004    4005    4006    4007    4008    4009    4010
mybr
         1       2       3       4       5       6       7       8       9       10      80 untagged     100 PVID        200 untagged

Comment 12 Beniamino Galvani 2019-04-24 14:54:22 UTC
*** Bug 1605123 has been marked as a duplicate of this bug. ***

Comment 15 Beniamino Galvani 2019-05-24 06:17:50 UTC
Looks good, thanks!


Note You need to log in before you can comment on or make changes to this bug.