Netonix Forums

Hi everybody.
I'm making a new MSTP test.
Now Root bridge is a Juniper switch. As you know MSTInstance Vlan must be declared in RootBridge. Topology is a triangle Switch A Juniper (as root bridge) Switch B/C Netonix.
Instances declared at Juniper Switch
MSTInstance 1: 120,140,160
MSTInstance 2: 130,150,170
For Switch A MSTInstance1
For Switch B MSTInstance2
Well seems MSI order in a Juniper or Cisco switch is not problem but in a Netonix is different.
Explication:
CONF 1: THIS CONFIGURATION WORKS FINE!!
Switch A MSI1 Vlan 120,140,160 Switch B MSI1 Vlan 130,150,170
MSI2 Vlan 130,150,170 MSI2 Vlan 120,140,160
CONF 2: THIS CONFIGURATION DON'T WORKS
Switch A MSI1 Vlan 120,140,160 Switch B MSI1 Vlan 120,140,160
MSI2 Vlan 130,150,170 MSI2 Vlan 130,150,170
whith conf 2 all trafic is forwarded to switch C to go switch B
Then i understand MSI Vlan order is important in a Netonix switch. All switch manuals describe configurations like Conf 2 (Cisco, Juniper, HP). MSTP is and standar and i understand must run equal in all switches, but seems devices with embebed linux doesn't runs the same.
Cheked this, my question is: is MSTInstance number priority important? If is , then first instance must be vlans that are used at switch and the others instances will be vlans for backups to other switches.
Thanks alot.

thanks for your cool post, we will be getting back to MSTP soon...

nasked wrote:but seems devices with embebed linux doesn't runs the same.

Which device with embeded linux run MSTP ? Never saw MSTP on linux, only STP/RSTP. STP/RSTP will interact only with CIST, not MST instances.

nasked wrote:
Cheked this, my question is: is MSTInstance number priority important? If is , then first instance must be vlans that are used at switch and the others instances will be vlans for backups to other switches.

MST use a single digest hash calculated from every instance and VLANs so VLANs to be sure config are the same on all switch so the MST config (region name and revision and also VLANs list by instance) must be the same on every switch. If digest don't match, VLANs follow CIST route instead of instance one.

P.S.: Seem there a bug while removing VLANs from VLANs list by insance, digest won't change when you remove a VLAN and a reboot is needed to fix this. Seem like the VLAN is removed from GUI and config but not from vitesse API. The bug have been reported but no answer from Netonix team about this yet.

sorry Mike, you comments have been seen, and we will address them when we get back to MSTP issue..thanks as always.

That not a complain, just a fact. I know tout probably busy on New device.

Sorry:

Maybe I was confused with the interpretation of this post.

https://github.com/mstpd/mstpd

Sometimes my English falls ... :-) Sorry
My experience, at least that I'm doing something wrong in the configuration, is that according to orders the vlan in MSMy experience, at least that I am doing something wrong in the configuration, is that according to orders the vlan in the MST it works or it does not work ...

If you can do the same tests that I did with the configurations. If you can do the same tests that I did with the configurations that I put up and tell me what your results have been.

From: https://github.com/mstpd/mstpd

Important note! MSTP part of the code (as opposed to STP/RSTP part) is mainly untested, so I believe it will behave unexpectedly in many situations. Don't use it in production!

Maybe that why it's not include in any project or open source based product I know of.

I don't think VLANs order will affect the digest calculation. Test a reboot first if you have removed VLANs from the VLAN list. I don't plan to do any test until the digest problem is fix.