STP updates not propagated to SAI

[HolyShitMan]

If running mstpd in rstp mode on an OpenSwitch VM, the port states won't be propagated to SAI, because cps_created is set to true in nas_stg_create_default_instance().

opx-nas-l2/src/stg/nas_stg_api.cpp

Line 981 in 7e80d39

entry.cps_created = true;

This leads to nas_stg_update_stg_state() returning early and and don't calling nas_update_stp_state().

opx-nas-l2/src/stg/nas_stg_api.cpp

Lines 443 to 451 in 7e80d39

	// If entry has multiple vlans skip the update
	if((entry->vlan_list.size()>1) || (entry->cps_created == true)){
	NAS_STG_LOG(DEBUG, "Skipping kernel update as stg instance has more "
	"than one vlans mapped to it or created via CPS ");
	return STD_ERR_OK;
	}
	if (!nas_update_stp_state(entry, intfindex, state))
	return STD_ERR(STG, FAIL, 0);

Is this intended and if yes, why?

[mikelazar]

An OpenSwitch VM does not support MSTP - since there's no switching ASIC (NPU).
Linux only supports plain STP (no VLANs), and the short answer is that MSTP cannot be supported without an ASIC.

On real HW, there's some optimization done when configuring MSTP (and STP) in general via CPS, thus there's a flag to tell whether a request comes via CPS (vs. netlink events, by making changes using the Linux native API's).

I'll close the issue, but please reopen it if you have more questions.

[HolyShitMan]

An OpenSwitch VM does not support MSTP - since there's no switching ASIC (NPU).
Linux only supports plain STP (no VLANs), and the short answer is that MSTP cannot be supported without an ASIC.

I completely agree, however I'm talking about RSTP. mstpd is just the name of the software supporting both protocols. If RSTP is used this software is using purely the Linux API. Nevertheless the state changes are not propagated to the SAI module because the default STG instance, which is used by mstpd, is marked as cps_created.

How am i able, to change this?

PS: I don't have the privileges to reopen issues in this project but only can create new ones. I suppose this is not what I should do :)

[mikelazar]

I'll leave the issue open for now.

However, please note that VM SAI STP code (all flavors) is mostly a no-op, since there's no NPU to control. Also, in the case of real HW, this is intended behavior.

Would you please clarify what you'd like to do ?

[HolyShitMan]

I'm currently modifying/rewriting the opx-sai-vm driver to control a software switch. I'm fully aware, that the current sai-vm code does not run STP. Nevertheless I ran it, to understand the calls and see how everything works, so that I can build my code from there.

I discovered, that, when running RSTP, nas_update_stp_state(), which later would call the NPU code, is not called, because of the conditions described above. And this seems very strange to me, as the default spanning tree instance is probably used for the bare Linux STP code, too and would run into the same issue (latter I did not try, yet).

Update: I tried simple Linux STP and the same happens:

$ sudo brctl addbr br0
$ sudo brctl stp br0 on
$ sudo brctl addif br0 e101-001-0
$ sudo brctl addif br0 e101-002-0
$ sudo ip l s e101-001-0 up
$ sudo ip l s e101-002-0 up
$ sudo ip l s br0 up

opx_nas_daemon[632]: [NAS_L2:NAS-STG], Skipping kernel update as stg instance has more than one vlans mapped to it or created via CPS