Loading...

XML

Word

Printable

Type: Bug
Resolution: Unresolved
Priority: Undefined
Fix Version/s: None
Affects Version/s: None
Component/s: os-net-config
Labels:
None

Epic Link:
OSPRH-21321
Blocked:
False
Blocked Reason:

Hide

None

Show
None
Ready:
False
Docs Approval:
?
AssignedTeam:
rhos-connectivity-nfv
Regression:
None
Intelligence Requested:
Market:
PX Impact Score:

Severity:
Low

SFDC Cases Counter:
SFDC Cases Open:
SFDC Cases Links:

ovs_options field parameter of ovs_bridge type seems to be the optional arguments for ovs-vsctl add-br command. According to OVS doc:

   Bridge Commands
       These commands examine and manipulate Open vSwitch bridges.


       [--may-exist] add-br bridge
              Creates a new bridge named bridge.  Initially the bridge will have no ports (other than bridge itself).

              Without --may-exist, attempting to create a bridge that exists is an error.  With --may-exist, this command does nothing if bridge already exists as a real bridge.

       [--may-exist] add-br bridge parent vlan
              Creates a ``fake bridge'' named bridge within the existing Open vSwitch bridge parent, which must already exist and must not itself be a fake bridge.  The new fake bridge will be on 802.1Q VLAN vlan, which must be an integer between 0 and 4095.  The parent bridge must not  already  have  a  fake
              bridge for vlan.  Initially bridge will have no ports (other than bridge itself).

              Without --may-exist, attempting to create a bridge that exists is an error.  With --may-exist, this command does nothing if bridge already exists as a VLAN bridge under parent for vlan.

So manually we can configure the bridge and the fake bridge like this:

[root@compute-1 ~]# ovs-vsctl add-br br0

[root@compute-1 ~]# ovs-vsctl add-br br-vlan137 br0 137

[root@compute-1 ~]# ovs-vsctl show
f5fae7d2-ea5d-4859-af5d-5a05a26a8f1c
    Bridge br0
        Port br-vlan137
            tag: 137
            Interface br-vlan137
                type: internal
        Port br0
            Interface br0
                type: internal
    ovs_version: "3.5.2-33.el9fdp"

[root@compute-1 ~]# ovs-vsctl br-to-parent br-vlan137
br0

However, if we try to configure that with os-net-config we would need something like this:

network_config:
- name: br0
  type: ovs_bridge
- name: br-vlan137
  ovs_options: br0 137
  type: ovs_bridge

Problem 1. Loading that config raises this verification error (for both providers):

2025-10-15 11:36:03.655 ERROR os_net_config.get_iface_config Config file failed schema validation at network_config/1:
    {'type': 'ovs_bridge', 'name': 'br-vlan137', 'ovs_options': 'br0 137'} is not valid under any of the given schemas
  Sub-schemas tested and not matching:
  - items/oneOf/ovs_bridge/ovs_options/oneOf: 'br0 137' is not valid under any of the given schemas
  -- items/oneOf/ovs_bridge/ovs_options/oneOf/ovs_options_string/pattern: 'br0 137' does not match '^((?:[a-zA-Z][a-zA-Z0-9: _-]*)=(?:[a-zA-Z0-9:._-]+)[ ]*)+$'
  -- items/oneOf/ovs_bridge/ovs_options/oneOf/param/oneOf: 'br0 137' is not valid under any of the given schemas
  --- items/oneOf/ovs_bridge/ovs_options/oneOf/param/oneOf/0/type: 'br0 137' is not of type 'object'
  --- items/oneOf/ovs_bridge/ovs_options/oneOf/param/oneOf/1/type: 'br0 137' is not of type 'object'
2025-10-15 11:36:03.655 ERROR os_net_config.main Schema validation failed for network_config with error: 
Config file failed schema validation at network_config/1:
    {'type': 'ovs_bridge', 'name': 'br-vlan137', 'ovs_options': 'br0 137'} is not valid under any of the given schemas
  Sub-schemas tested and not matching:
  - items/oneOf/ovs_bridge/ovs_options/oneOf: 'br0 137' is not valid under any of the given schemas
  -- items/oneOf/ovs_bridge/ovs_options/oneOf/ovs_options_string/pattern: 'br0 137' does not match '^((?:[a-zA-Z][a-zA-Z0-9: _-]*)=(?:[a-zA-Z0-9:._-]+)[ ]*)+$'
  -- items/oneOf/ovs_bridge/ovs_options/oneOf/param/oneOf: 'br0 137' is not valid under any of the given schemas
  --- items/oneOf/ovs_bridge/ovs_options/oneOf/param/oneOf/0/type: 'br0 137' is not of type 'object'
  --- items/oneOf/ovs_bridge/ovs_options/oneOf/param/oneOf/1/type: 'br0 137' is not of type 'object'

The reason is ovs_options expect to have something like key=value in the string.

Problem 2. Trying incorrect ovs_options: "br0 tag=137" for ifcfg provider creates the br0 bridge and incorrect network-scripts files.

So having a config like this:

network_config:
- type: ovs_bridge
  name: br0
- type: ovs_bridge
  name: br-vlan137
  ovs_options: "br0 tag=137"

We get this output (error messages but not os-net-config error):

[root@compute-1 ~]# os-net-config -p ifcfg -m /var/tmp/os-net-config_tests/mapping.yaml -c /var/tmp/os-net-config_tests/config-ovs_bridge_error.yaml --exit-on-validation-errors -d
...
2025-10-15 11:38:08.475 INFO os_net_config.execute running ifdown on bridge: br0
2025-10-15 11:38:08.497 ERROR os_net_config.execute stderr : usage: ifdown <configuration>

2025-10-15 11:38:08.498 INFO os_net_config.execute running ifdown on bridge: br-vlan137
2025-10-15 11:38:08.520 ERROR os_net_config.execute stderr : usage: ifdown <configuration>

2025-10-15 11:38:08.520 INFO os_net_config.write_config Writing config /etc/sysconfig/network-scripts/ifcfg-br0
2025-10-15 11:38:08.520 INFO os_net_config.write_config Writing config /etc/sysconfig/network-scripts/ifcfg-br-vlan137
2025-10-15 11:38:08.521 INFO os_net_config.execute running ifup on bridge: br0
2025-10-15 11:38:10.752 ERROR os_net_config.execute stderr : WARN      : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated.
WARN      : [ifup] 'network-scripts' will be removed from distribution in near future.
WARN      : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.

2025-10-15 11:38:10.753 DEBUG os_net_config.execute stdout : INFO      : [ipv6_wait_tentative] Waiting for interface br0 IPv6 address(es) to leave the 'tentative' state
INFO      : [ipv6_wait_tentative] Waiting for interface br0 IPv6 address(es) to leave the 'tentative' state

2025-10-15 11:38:10.753 INFO os_net_config.execute running ifup on bridge: br-vlan137
2025-10-15 11:38:11.205 ERROR os_net_config.execute stderr : WARN      : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated.
WARN      : [ifup] 'network-scripts' will be removed from distribution in near future.
WARN      : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.
ovs-vsctl: no row "br-vlan137" in table Bridge

2025-10-15 11:38:11.206 DEBUG os_net_config.execute stdout : ERROR     : [/etc/sysconfig/network-scripts/ifup-eth] Device br-vlan137 does not seem to be present, delaying initialization.

2025-10-15 11:38:11.206 INFO os_net_config.config_provider ifcfg: Successfully configured network_config
2025-10-15 11:38:11.206 INFO os_net_config.main ifcfg: Configured network_config successfully

We observe that only br0 created:

[root@compute-1 ~]# ovs-vsctl show
f5fae7d2-ea5d-4859-af5d-5a05a26a8f1c
    Bridge br0
        fail_mode: standalone
        Port br0
            Interface br0
                type: internal
    ovs_version: "3.5.2-33.el9fdp"

And ifcfg-br-vlan137 file created:

[root@compute-1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-br-vlan137 
# This file is autogenerated by os-net-config
DEVICE=br-vlan137
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSBridge
OVS_OPTIONS="br0 tag=137"
OVS_EXTRA="set bridge br-vlan137 other-config:mac-table-size=50000 -- set bridge br-vlan137 fail_mode=standalone -- del-controller br-vlan137"

We can modify that config (setting OVS_OPTIONS="br0 137" and removing OVS_EXTRA) and restart network to get the expected config:

[root@compute-1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-br-vlan137
# This file is autogenerated by os-net-config
DEVICE=br-vlan137
ONBOOT=yes
HOTPLUG=no
NM_CONTROLLED=no
PEERDNS=no
DEVICETYPE=ovs
TYPE=OVSBridge
OVS_OPTIONS="br0 137"

[root@compute-1 ~]# systemctl restart network

[root@compute-1 ~]# ovs-vsctl show
f5fae7d2-ea5d-4859-af5d-5a05a26a8f1c
    Bridge br0
        fail_mode: standalone
        Port br-vlan137
            tag: 137
            Interface br-vlan137
                type: internal
        Port br0
            Interface br0
                type: internal
    ovs_version: "3.5.2-33.el9fdp"

# Fake bridge br-vlan137 properly created
[root@compute-1 ~]# ovs-vsctl br-to-parent br-vlan137
br0

Problem 3. Trying incorrect ovs_options: "br0 tag=137" for nmstate provider creates the br0 and br-vlan137 with an invalid configuration.

Loading this config apparently you don't see any error :

[root@compute-0 ~]# cat /var/tmp/os-net-config_tests/config-ovs_bridge_error.yaml 
network_config:
- type: ovs_bridge
  name: br0
- type: ovs_bridge
  name: br-vlan137
  ovs_options: "br0 tag=137"

[root@compute-0 ~]# os-net-config -p nmstate -m /var/tmp/os-net-config_tests/mapping.yaml -c /var/tmp/os-net-config_tests/config-ovs_bridge_error.yaml -d --exit-on-validation-errors 
...
2025-10-15 12:00:00.612 DEBUG os_net_config.impl_nmstate.apply Updated the interfaces: br0-if br-vlan137-if br0 br-vlan137
2025-10-15 12:00:00.612 INFO os_net_config.config_provider nmstate: Successfully configured network_config
2025-10-15 12:00:00.613 INFO os_net_config.main nmstate: Configured network_config successfully

But we have two bridges configured br0 and br-vlan137 instead of the bridge (with the tagged port) and the fake bridge:

[root@compute-0 ~]# ovs-vsctl show
bf9dfa0a-663a-4af5-a860-0e08c8da34ac
    Bridge br0
        fail_mode: standalone
        Port br0
            Interface br0
                type: internal
    Bridge br-vlan137
        fail_mode: standalone
        Port br-vlan137
            Interface br-vlan137
                type: internal
    ovs_version: "3.5.2-33.el9fdp"

[root@compute-0 ~]# ovs-vsctl br-to-parent br-vlan137
br-vlan137

Problem 4. Unexpected behavior for both providers (also not aligned) when you try to configure STP in ovs_options instead of ovs_extra.

For ifcfg when we load this config we can see some errors in the log but no os-net-config error:

[root@compute-1 ~]# cat /var/tmp/os-net-config_tests/config-ovs_bridge_error.yaml
network_config:
- type: ovs_bridge
  name: br0
  ovs_options: "set bridge br0 stp_enable=true"

[root@compute-1 ~]# os-net-config -p ifcfg -m /var/tmp/os-net-config_tests/mapping.yaml -c /var/tmp/os-net-config_tests/config-ovs_bridge_error.yaml --exit-on-validation-errors -d
...
2025-10-15 12:42:26.514 INFO os_net_config.execute running ifdown on bridge: br0
2025-10-15 12:42:26.539 ERROR os_net_config.execute stderr : usage: ifdown <configuration>

2025-10-15 12:42:26.539 INFO os_net_config.write_config Writing config /etc/sysconfig/network-scripts/ifcfg-br0
2025-10-15 12:42:26.540 INFO os_net_config.execute running ifup on bridge: br0
2025-10-15 12:42:26.982 ERROR os_net_config.execute stderr : WARN      : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated.
WARN      : [ifup] 'network-scripts' will be removed from distribution in near future.
WARN      : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.
ovs-vsctl: 'add-br' command takes at most 3 arguments

2025-10-15 12:42:26.983 DEBUG os_net_config.execute stdout : ERROR     : [/etc/sysconfig/network-scripts/ifup-eth] Device br0 does not seem to be present, delaying initialization.

2025-10-15 12:42:26.983 INFO os_net_config.config_provider ifcfg: Successfully configured network_config
2025-10-15 12:42:26.983 INFO os_net_config.main ifcfg: Configured network_config successfully

However, the bridge is not created:

[root@compute-1 ~]# ovs-vsctl show
f5fae7d2-ea5d-4859-af5d-5a05a26a8f1c
    ovs_version: "3.5.2-33.el9fdp"

For nmstate when we load this config apparently we don't see any error in the log:

[root@compute-0 ~]# cat /var/tmp/os-net-config_tests/config-ovs_bridge_error.yaml 
network_config:
- type: ovs_bridge
  name: br0
  ovs_options: "set bridge br0 stp_enable=true"

[root@compute-0 ~]# os-net-config -p nmstate -m /var/tmp/os-net-config_tests/mapping.yaml -c /var/tmp/os-net-config_tests/config_remove-ovs_bridge_error.yaml -d --exit-on-validation-errors 
...
2025-10-15 12:50:24.923 DEBUG os_net_config.impl_nmstate.apply Updated the interfaces: br0-if br0
2025-10-15 12:50:24.923 INFO os_net_config.config_provider nmstate: Successfully configured network_config
2025-10-15 12:50:24.923 INFO os_net_config.main nmstate: Configured network_config successfully

However, although the bridge is created the STP is not enabled (as expected):

[root@compute-0 ~]# ovs-vsctl show
bf9dfa0a-663a-4af5-a860-0e08c8da34ac
    Bridge br0
        fail_mode: standalone
        Port br0
            Interface br0
                type: internal
    ovs_version: "3.5.2-33.el9fdp"

[root@compute-0 ~]# ovs-vsctl get bridge br0 stp_enable
false

I believe an error should be raised.

Assignee:: Karthik Sundaravel

Reporter:: Ricardo Diaz Campos

Team:: rhos-dfg-nfv

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Created:: 2025/10/15 5:36 PM

Updated:: 2025/11/18 10:10 AM

Details

Description

Attachments

Easy Agile Planning Poker

Activity

People

Dates

PagerDuty