https://bugzilla.suse.com/show_bug.cgi?id=1177388 Robert Simai <robert.simai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|wicket sets wrong option |wicked sets wrong option |BRIDGE_FORWARDDELAY='0' |BRIDGE_FORWARDDELAY='0' -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177388 https://bugzilla.suse.com/show_bug.cgi?id=1177388#c1 Knut Alejandro Anderssen González <kanderssen@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kanderssen@suse.com, | |robert.simai@suse.com Flags| |needinfo?(robert.simai@suse | |.com) --- Comment #1 from Knut Alejandro Anderssen González <kanderssen@suse.com> --- (In reply to Robert Simai from comment #0)

My config includes eth0 as slave to br0 which is statically configured through wicked.

I had changed the MTU setting from jumbo frames (9000) back to regular (1500) through yast because of trouble with a network switch. The network didn't come up after that, I found

ifcfg-br0: bridge validation: bridge forward-delay is out of supported range (2.0-30.0)

through journalctl and indeed

/etc/sysconfig/network/ifcfg-br0

contained the invalid parameter

BRIDGE_FORWARDDELAY='0'

I changed it manually to '2' which resolved the problem, network came up again.

I tried to duplicate by changing the MTU size as I did before but couldn't trigger this anymore. However, yast lan must have been nasty. I'm happy to provide more details if you tell me which ones.

When reporting a YaST bug we always suggest to attach YaST logs in order to figure out what happened when we did something wrong. So, would be nice if you are able to reproduce the issue or do you still have the logs when it happened. https://en.opensuse.org/openSUSE:Report_a_YaST_bug Could you also attach the complete bridge configuration? If I'm not wrong the configuration is the one created or suggested by YaST for virtualization and when the MTU is changed it enabled STP which then complained about the FORWARDDELAY settings. The enablement of STP has been already fixed as part of this other bug: https://bugzilla.suse.com/show_bug.cgi?id=1176820 Without logs I cannot be sure but looks like related.. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1177388 https://bugzilla.suse.com/show_bug.cgi?id=1177388#c3 Knut Alejandro Anderssen González <kanderssen@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Knut Alejandro Anderssen González <kanderssen@suse.com> --- (In reply to Robert Simai from comment #2)

Thanks for the pointer to the log file collector. I think we can skip that.

In fact STP was enabled (I overlooked that) which eventually makes the parameter value invalid. I couldn't find any reference to bug 1176820 in yast2-network's changelog (recent 4.2.78 from Sept. 25) but if the code is already fixed, then many thanks for your work and you may consider this fixed or duplicate!

It was fixed in yast2-network-4.2.79, so, hopefully will be soon in Leap-15.2 as it was fixed for SLE-15-SP2 and was already requested a maintenance update. I will close as duplicate by now, but looks like permitting to modify more advanced bridge configuration would be nice to have as most of you are touching it by hand. *** This bug has been marked as a duplicate of bug 1176820 *** -- You are receiving this mail because: You are on the CC list for the bug.