Michal Soltys - 2016-06-27

Hi,

(assuming Vitalii is still keeping an eye on this project)

Test setup:

test box (ping / arping target)
|
|     ----- bondA -----
switch                   linux
      ----- bondB -----

Configuration:

IST
MST1: vlan 201
MST2: vlan 202

Both bonds (2 ports each) are trunks with 66 (untagged), 201 (tagged),
202 (tagged) in standard LACP mode.

On linux side, there is one vlan-aware bridge with identical vlan
configuration, running in mstp mode under control of mstpd from:

https://github.com/ocedo/mstpd

(afaik this is basically origina + some fixes/updates)

The test box was another linux connected with single cable, following
the same vlan config.

I have been testing with different bridge and per-tree port priorities and:

CORRECTIONS added 2016-06-28

0/a) IF the linux bridge is the root for every MST instance then eveyrthing seems to be working fine. Packets go through proper links (as per settreeportprio), the switch blocked proper ports as well. No issues (it seems).

0/b) IF for every instance, the linux bridge was not the root, then unfortunately it only worked correctly as per IST port priorities. All remaining MST instances followed IST (in the other words, it roughly behaved as in RSTP case). For example if the switch had prefernece to use bondB for the active link for IST tree, then bondB was used for MST1 and 2 as well - regardless of per-port priorities of respective instances.

1) If linux was the root of IST, then:

Setting the switch to be the root of any other MST instance caused
loops, when any transfer was directed to the vlan handled by that
instance. In the setup outlined above, [ar]pinging vlan 202 instantly
caused issues, if IST's root was linux and MST2's root was switch.

2) If linux was not the root of IST, then:

Setting the linux to be the root of any other MST instance causes behaviour analogous to (0/b) above. The decision over which port to send data is decided by IST priorities (of which switch is the root).

 

Last edit: Michal Soltys 2016-06-28