Changing to NetworkManager after discussion with NM team.

To be more precise, we are requesting Reapply support of these options:

 * bridge.ageing-time
 * bridge.forward-delay
 * bridge.group-address
 * bridge.group-forward-mask
 * bridge.hello-time
 * bridge.max-age
 * bridge.multicast-hash-max
 * bridge.multicast-last-member-count
 * bridge.multicast-last-member-interval
 * bridge.multicast-membership-interval
 * bridge.multicast-querier
 * bridge.multicast-querier-interval
 * bridge.multicast-query-interval
 * bridge.multicast-query-response-interval
 * bridge.multicast-query-use-ifaddr
 * bridge.multicast-router
 * bridge.multicast-snooping
 * bridge.multicast-startup-query-count
 * bridge.multicast-startup-query-interval
 * bridge.priority
 * bridge.stp
 * bridge.vlan-filtering
 * bridge.vlan-protocol
 * bridge.vlans

 * 802-3-ethernet.accept-all-mac-addresses
 * 802-3-ethernet.cloned-mac-address
 * 802-3-ethernet.mtu
 * 802-3-ethernet.port

 * ipv4.addresses
 * ipv4.dhcp-client-id
 * ipv4.dhcp-iaid
 * ipv4.dhcp-timeout
 * ipv4.dns
 * ipv4.dns-priority
 * ipv4.dns-search
 * ipv4.gateway
 * ipv4.ignore-auto-dns
 * ipv4.ignore-auto-routes
 * ipv4.may-fail
 * ipv4.method
 * ipv4.never-default
 * ipv4.route-table
 * ipv4.routes
 * ipv4.routing-rules

 * ipv6.addr-gen-mode
 * ipv6.addresses
 * ipv6.dhcp-duid
 * ipv6.dhcp-iaid
 * ipv6.dhcp-timeout
 * ipv6.dns
 * ipv6.dns-priority
 * ipv6.dns-search
 * ipv6.gateway
 * ipv6.ignore-auto-dns
 * ipv6.may-fail
 * ipv6.method
 * ipv6.never-default
 * ipv6.ra-timeout
 * ipv6.route-metric
 * ipv6.route-table
 * ipv6.routes
 * ipv6.routing-rules

Hi Quique Llorente,

Can this be done in RHEL 9 only or you need both for 8 and 9?

(In reply to Gris Ge from comment #2)
> Hi Quique Llorente,
> 
> Can this be done in RHEL 9 only or you need both for 8 and 9?

@bnemec we need the backport to RHEL8 right for standalone operator right ?

Yes. Ideally we would backport to 4.10, which is RHEL 8-based (as is 4.11, I believe 4.12 is when we're planning to move to RHEL 9).

(In reply to Gris Ge from comment #1)
> Changing to NetworkManager after discussion with NM team.
> 
> To be more precise, we are requesting Reapply support of these options:
> 
>  * bridge.ageing-time
>  * bridge.forward-delay
>  * bridge.group-address
>  * bridge.group-forward-mask
>  * bridge.hello-time
>  * bridge.max-age
>  * bridge.multicast-hash-max
>  * bridge.multicast-last-member-count
>  * bridge.multicast-last-member-interval
>  * bridge.multicast-membership-interval
>  * bridge.multicast-querier
>  * bridge.multicast-querier-interval
>  * bridge.multicast-query-interval
>  * bridge.multicast-query-response-interval
>  * bridge.multicast-query-use-ifaddr
>  * bridge.multicast-router
>  * bridge.multicast-snooping
>  * bridge.multicast-startup-query-count
>  * bridge.multicast-startup-query-interval
>  * bridge.priority
>  * bridge.stp
>  * bridge.vlan-filtering
>  * bridge.vlan-protocol
>  * bridge.vlans

It's probably sensible and doable to support reapply of all bridge properties.
In particular, if we have Fernando's rework of setting bridge options via netlink.

>  * 802-3-ethernet.accept-all-mac-addresses
>  * 802-3-ethernet.cloned-mac-address

cloned-mac-address seems not that it should be reapplied. The MAC address is a very fundamental property. Changing it without doing a full re-activation seems difficult -- to a point where we might want to require a full activation. For example, the IPv4 DHCP client-id defaults to the MAC address, if the MAC address changes we will probably get a different IP address too.

Now, during reapply we already restart DHCP, so it's not really a problem that the client-id and the IP address is going to change (in particular, as we already support reapply for enabling/disabling DHCP and changing the client-id). But still...

Is this necessary? 

>  * 802-3-ethernet.mtu
>  * 802-3-ethernet.port

I don't think that "port" is even functional (or useful).

> 
>  * ipv4.addresses
>  * ipv4.dhcp-client-id
>  * ipv4.dhcp-iaid
>  * ipv4.dhcp-timeout
>  * ipv4.dns
>  * ipv4.dns-priority
>  * ipv4.dns-search
>  * ipv4.gateway
>  * ipv4.ignore-auto-dns
>  * ipv4.ignore-auto-routes
>  * ipv4.may-fail
>  * ipv4.method
>  * ipv4.never-default
>  * ipv4.route-table
>  * ipv4.routes
>  * ipv4.routing-rules
> 
>  * ipv6.addr-gen-mode
>  * ipv6.addresses
>  * ipv6.dhcp-duid
>  * ipv6.dhcp-iaid
>  * ipv6.dhcp-timeout
>  * ipv6.dns
>  * ipv6.dns-priority
>  * ipv6.dns-search
>  * ipv6.gateway
>  * ipv6.ignore-auto-dns
>  * ipv6.may-fail
>  * ipv6.method
>  * ipv6.never-default
>  * ipv6.ra-timeout
>  * ipv6.route-metric
>  * ipv6.route-table
>  * ipv6.routes
>  * ipv6.routing-rules

ACK to the rest. Many of those should already work (like all the ipv4/ipv6 settings and the MTU).

These can be bemoved from reapply allowlist:

802-3-ethernet.cloned-mac-address
802-3-ethernet.ports

Thanks.

Bug https://bugzilla.redhat.com/show_bug.cgi?id=2105976 is created to tracking the reapply effort of `802-3-ethernet.cloned-mac-address`.

For `802-3-ethernet.port`, we do not have use case yet.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1296

Hi Lubomir,

The `bridge.vlan-filtering` reapply is not working on NetworkManager-1.39.10-30745.copr.8e8fed433f.el9.x86_64. This is the output:


[fge@c9s ~]$ sudo nmcli c add type bridge ifname br0 bridge.vlan-filtering on connection.id br0
Connection 'br0' (54535fe1-cd78-446e-bd29-a673fa0fa99e) successfully added.
[fge@c9s ~]$ cat /sys/class/net/br0/bridge/vlan_
vlan_filtering       vlan_protocol        vlan_stats_enabled   vlan_stats_per_port
[fge@c9s ~]$ cat /sys/class/net/br0/bridge/vlan_filtering
1
[fge@c9s ~]$ sudo nmcli c modify br0 bridge.vlan-filtering off
[fge@c9s ~]$ sudo nmcli d reapply br0
Connection successfully reapplied to device 'br0'.
[fge@c9s ~]$ cat /sys/class/net/br0/bridge/vlan_filtering
1
[fge@c9s ~]$ sudo nmcli c up br0
Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/20)
[fge@c9s ~]$ cat /sys/class/net/br0/bridge/vlan_filtering
0

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7680