Root bridge priority settings do not apply to ustp

[oleg506]

Hi,

Currently, the ustp daemon does not pull the "priority" attribute from the bridge settings, and it does not allow setting this attribute manually via ubus. As a result, the default priority of 32768 (0x8000) is used, which can lead to issues with the correct selection of the root bridge in cases where other switches have a lower MAC address.

It would be great if support could be added for configuring the "priority" attribute through ubus to allow better control over this setting.

Additionally, it would be helpful if the "priority" attribute from the bridge settings in the main configuration (/etc/config/network) could be passed to ustp automatically, so it is consistent with the bridge configuration and can be properly applied when initializing the STP/RSTP/MSTP protocol.

cat /etc/config/network 
config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        option igmp_snooping '1'
        option stp '1'
        option priority '4096'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan2:u*'
        list ports 'lan3:u*'
        list ports 'lan4:u*'

config bridge-vlan
        option device 'br-lan'
        option vlan '1000'
        list ports 'lan4:t'

With ustp enabled

tcpdump -i lan4 -vv stp -etn
44:f7:70:2a:41:cc > 01:80:c2:00:00:00, 802.3, length 39: LLC, dsap STP (0x42) Individual, 
ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], 
bridge-id 8000.44:f7:70:2a:41:cc.8003, length 36

With ustp turned off

44:f7:70:2a:41:cc > 01:80:c2:00:00:00, 802.3, length 38: LLC, dsap STP (0x42) Individual, 
ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, 
Flags [none], bridge-id 1000.44:f7:70:2a:41:cc.8003, length 35

brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          1000.44f7702a41cc       2               phy1-ap0
                                                        lan4
                                                        lan2
                                                        lan3
                                                        phy0-ap0

[DanaGoyette]

I just ran into this... and then when I uninstalled ustp to get back the proper priority, all network connectivity to the router machine died, because the switch was expecting to still see rstp, not plain stp. I ended up having to power cycle the OpenWrt machine. It would be really good to fix this.

It looks like sometime before ustp was imported to git, there was a bridge priority field in the config object, but it was removed because it was supposedly superseded. How can you view the history before the initial import to git?

ustp/mstp.h

Lines 646 to 648 in a85a5bc

	/* Superseded by MSTP_IN_set_msti_bridge_config for the CIST.
	* __u8 bridge_priority;
	* bool set_bridge_priority; */

Despite the comment, it's NOT actually redundant, because the same config object type seems to be used for non-mstp.

ustp/ubus.c

Lines 42 to 47 in a85a5bc

	static bool
	ubus_set_bridge_config(struct blob_attr *attr)
	{
	struct blob_attr *tb[__BRIDGE_CONFIG_MAX], *cur;
	struct bridge_config *cfg;
	CIST_BridgeConfig *bc;

ustp/config.h

Lines 23 to 27 in a85a5bc

	struct bridge_config {
	struct avl_node node;
	uint32_t timestamp;
	CIST_BridgeConfig config;
	};

Here's where the fixed 0x8000 is set for mstp:

ustp/mstp.c

Lines 188 to 189 in a85a5bc

	/* 0x8000 = default bridge priority (17.14 of 802.1D) */
	tree->BridgeIdentifier.s.priority = __constant_cpu_to_be16(0x8000) | MSTID;

It seems like some mstp code paths are taken even if you aren't using mstp.

Apr 22 16:00:47 OpenWrt-dell ustpd[30337]: - Error in br_flush_port at ustp-2023.05.29~a85a5bc8/bridge_track.c:455 verif
ying 0 <= fd. Couldn't open flush file /sys/class/net/vethCBxfVK/brport/flush for write: No such file or directory
Apr 22 16:00:47 OpenWrt-dell ustpd[30337]: - MSTP_OUT_flush_all_fids: br-lan:vethCBxfVK Couldn't flush kernel bridge for
warding database

(Come to think of it, how would one even enable mstp, when there's no /etc/config/ustp?)

I'm not sure which would be easier: adding a separate bridge priority config, or making it respect the priority from the kernel bridge. I'd certainly prefer the latter.

[Bartel-C8]

The mstp.c code is just a fork/copy of the https://github.com/mstpd/mstpd repo.
You might find more git history there.

mstdp has a cli tool for configuring all possible parameters. ustp just does not support this (yet).
As ustp is just the mstp.c code hooked via ubus (as I understand it)

[mundschenk-at]

I just ran into this... and then when I uninstalled ustp to get back the proper priority, all network connectivity to the router machine died, because the switch was expecting to still see rstp, not plain stp. I ended up having to power cycle the OpenWrt machine. It would be really good to fix this.

I have found that ustpd does not seem to work at all, at least not in my setup (TP-Link Omada switches). With kernel STP, root selection works normally, but with ustpd enabled, the device always selects itself as root regardless of the priority. Stopping ustpd necessitates a power cycle to get back connectivity.

[gongtao0607]

but with ustpd enabled, the device always selects itself as root regardless of the priority

Were you using brctl showstp to check root bridge? I realized that brctl is not revealing true stp info when ustpd is running. I found only port state (learning/blocking/forwarding) is usable from brctl. Sadly I didn't find a way to print status info from ustp. My way of checking is tcpdump (tcpdump -ni lan1 ether dst 01:80:c2:00:00:00 -vvvv) and logread.

[mundschenk-at]

Yes. But that's should be the true state of affairs (to the kernel). BPDUs on the interface are just diagnostic datapoints. (At least that's my understanding how user-space STP daemons work.)

[AlbrechtL]

I currently also wondering if ustp works correctly.

I have a test setup of three switches that are connected as a RSTP ring. You can see that switch A and B are reporting the root bridge as 8000-00157E1D5556 while OpenWrt is reporting 1000.603197f209d1.

@KanjiMonster: Do you have an idea?

Switch A
RTSP ports: port 1 and port 2

Switch B
RTSP ports: port 2 and port 4

OpenWrt switch (Zyxel GS1900-8, which uses the Realtek RTL8380M switch SoC)
RTSP ports: lan1 and lan2

root@OpenWrt:~# brctl showstp switch
switch
 bridge id              1000.603197f209d1
 designated root        1000.603197f209d1
 root port                 0                    path cost                  0
 max age                  10.00                 bridge max age            10.00
 hello time                1.00                 bridge hello time          1.00
 forward delay             8.00                 bridge forward delay       8.00
 ageing time             300.00
 hello timer               0.00                 tcn timer                  0.00
 topology change timer     0.00                 gc timer                 227.86
 flags


lan8 (8)
 port id                8008                    state                  disabled
 designated root        1000.603197f209d1       path cost                100
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8008                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan6 (6)
 port id                8006                    state                  disabled
 designated root        1000.603197f209d1       path cost                100
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8006                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan4 (4)
 port id                8004                    state                  disabled
 designated root        1000.603197f209d1       path cost                100
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8004                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan2 (2)
 port id                8002                    state                  blocking
 designated root        1000.603197f209d1       path cost                 19
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8002                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan7 (7)
 port id                8007                    state                  disabled
 designated root        1000.603197f209d1       path cost                100
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8007                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan5 (5)
 port id                8005                    state                  disabled
 designated root        1000.603197f209d1       path cost                100
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8005                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan3 (3)
 port id                8003                    state                  disabled
 designated root        1000.603197f209d1       path cost                100
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8003                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

lan1 (1)
 port id                8001                    state                forwarding
 designated root        1000.603197f209d1       path cost                 19
 designated bridge      1000.603197f209d1       message age timer          0.00
 designated port        8001                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

root@OpenWrt:~# cat /etc/openwrt_version
r34009-ac359c61d2

[AlbrechtL]

I dig a little bit into the ustp code. Here are some finding

1. The priority is not set by ustp. Mostly likely netifd set it. At least netifd is not exposing the priority via ubus.

root@OpenWrt:~# ubus monitor
[...]
<- 6b3139f2 #00000000     add_object: {"objpath":"ustp","signature":{"add_bridge":{"name":3,"proto":3,"forward_delay":5,"hello_time":5,"max_age":5,"ageing_time":5},"bridge_state":{"name":3,"enabled":7}}}
[...]

2. The designed bridge reported by brctl showstp switch shows only the internal Linux STP information. Since RSTP is handled via the user space daemon ustp this information is misleading. Unfortunately I didn't find a method to get this information out of ustp.

3. Now I'm running some experiments with mstpd and an experimental ubus integration (see the code here: https://github.com/AlbrechtL/openwrt/tree/mstpd-ustp-support/package/network/services/mstpd-ubus).

root@OpenWrt:~# mstpctl showbridge
switch CIST info
  stp enabled     yes
  enabled         yes
  bridge id       8.000.50:E0:39:F4:CF:7A
  designated root 8.000.00:15:7E:1D:E6:58
  regional root   8.000.50:E0:39:F4:CF:7A
  root port       lan1 (#1)
  path cost     20000      internal path cost   0
  max age       20         bridge max age       20
  forward delay 15         bridge forward delay 15
  tx hold count 6          max hops             20
  hello time    2          ageing time          300
  force protocol version     rstp
  time since topology change 7392
  topology change count      1
  topology change            no
  topology change port       None
  last topology change port  lan1