Proxmox 7.2 overwriting customized bridge-stp setting from GUI

O

oddballracing

New Member
Nov 23, 2022
3
1
3
Let me start by saying that Proxmox VE is a powerful package, getting back into it after many years off the horse. While I'm a big promoter of XCP-ng, KVM brings features that are not quite up to snuff in the Xen project... yet.

Doing some testing with PVE 7.2, came across something undesired. Did a bit of searching and the general consensus on previous instances regarding STP config on bridge interfaces is that it is "an edge case" and WebGUI implementation of STP configuration would not be implemented. fair enough.

The problem I am encountering is that the GUI management of such a bridge interface will overwrite a manual setting of "bridge-stp on" with an explicit "bridge-stp off" statement.

Could the GUI not just ignore/preserve the existing statement for an already created bridge interface so that it won't override settings explicitly configured interface options? I know I'm a minority in using this configuration, But STP is a major component for a configuration that has cascade connectivity between hosts (with redundancy) without using a switch (10GbE for Ceph).

NICs connected as follows (matching numbers are ends of the same DAC SFP+ cable):
P1 P2
[1] [2] HOST1
[2] [3] HOST2
[3] [1] HOST3

Here is the change intent listed to /etc/network/interfaces from a configuration change on an existing bridge on one of my hosts:
--- /etc/network/interfaces 2022-11-22 23:54:34.136856414 -0700
+++ /etc/network/interfaces.new 2022-11-22 23:54:52.797006490 -0700
@@ -34,6 +34,6 @@
iface vmbr1 inet static
address 10.0.0.1/28
bridge-ports enp3s0f0 enp3s0f1
- bridge-stp on
+ bridge-stp off
bridge-fd 0

A perfect example of a scenario where this would require going back into the manual configuration after initial setup would be adding a physical interface to a bridge after initial setup. Yes this could be done manually as well, but the guys on the tools are not always that familiar with the local Linux utilities, and will rely on the GUI, possibly taking configurations out of compliance. These are smaller cluster implementations where the power requirements and heat output of 10Gb switches are not conducive to the environments - not to mention the hardware cost.
 
oddballracing said:
Could the GUI not just ignore/preserve the existing statement for an already created bridge interface so that it won't override settings explicitly configured interface options? I know I'm a minority in using this configuration, But STP is a major component for a configuration that has cascade connectivity between hosts (with redundancy) without using a switch (10GbE for Ceph).
Click to expand...
Yeah, can make sense, can you please open a request over at https://bugzilla.proxmox.com/

Possibly best would be to expose that (and maybe some others) setting in the UI then, probably just as read-only display field, better to convey such important settings that can make the difference between a working network or not.
 
Thank you Gentlemen for the quick response, Bit of a crazy week and just got some time to get back to this one today. After some more testing i could not recreate the original behavior I was seeing above exactly, but definitely seeing the bridge-fd line being removed when adding or removing a member/slave interface to the bridge. I will log this in a bugzilla ticket.
@VictorSTS, while your request definitely relates to the same interface i am experiencing my issue with, I am not a subscriber and can't in good faith request an enhancement at this time. I am just looking to have this behavior return a sane/expected behavior.
 
I just want to provide an update on this.

TL;DR - This appears to be user error on my part.
bug 4366

While I am unable to reproduce the original behavior where 'bridge-stp on' was being replaced by 'bridge-stp off', I opened a bug also stating my concern (assuming the two actions were related to the same 'problem') about bridge-fd 0 being removed from the config when bridge-stp was enabled. I could not have been more wrong. While I have never encountered explicit errors with bridge frame delay set to 0 in /etc/network/interfaces (in Linux scenarios outside of a Proxmox deployment) with STP enabled (always configured via interfaces file directive, and never observed the actual setting in brctl), it was my lack of observation that this was automatically overridden to the minimum allowed value of 2. The logic to handle this is documented through commits pertaining to Bug 2831 (https://bugzilla.proxmox.com/show_bug.cgi?id=2831) as seen here https://git.proxmox.com/?p=pve-common.git;a=commit;h=576dadb1379da130f4ea77f775ea9bb985419616.

Big Thanks to Fabian for clearing this up for me.

I guess this is what happens when I don't keep up with the project and make uneducated assumptions after being out of the Proxmox loop for over a decade (last version I had used was 1.6 prior to testing 7.2 for my needs) and been using XenServer/XCPng for so long. While I am still determined to reproduce the original behavior I encountered in my original post and determine the cause, I am humbled and grateful for the support provided by the Proxmox team.
 
  • Like
Reactions: VictorSTS
You must log in or register to reply here.
Top Bottom