MSTP Not Working

[mhoppes]

Can someone take a look at this thread and offer a solution/insight as to what's going on?

[Stephen]

Hey mhoppes, I'm not seeing a link to a thread. Can you post the url to the thread directly?

[mhoppes]

https://www.facebook.com/groups/1651184 ... 181146182/

Sorry! Thought I posted this.

[JustJoe]

I'm sorry, I have considered facebook to be a malicious #uckerberg spyware/data-mining virus for at lest the last 6 years.

Have you reviewed my MSTP thread which documented several bugs (a couple of which still awaiting a response) ??

viewtopic.php?f=17&t=6787#p33866

I can understand with the new anti forum environment at ubiquiti why people stopped posting there.

But I have never experienced things like firmware problem reports being deleted or edited by moderators here on Netonix to want to post in a closed forum somewhere else.

[Stephen]

Hey mhoppes,

There have been some new bugs fixed in the thread JustJoe posted above.

Basically the bugs involved so far have not been giving VLAN changes/updates to the MSTP controller.

So, any changes (adding/removing/updating tags) on a VLAN where not reflected on the CIST or individual MSTI's.

So, it's very possible you could be seeing that problem because port 3 and 5 may at one point have been on a different VLAN or added to the MSTP instance after MSTP was enabled.

Updating to the latest 1.5.7rc2 should fix that if that is what was happening. But as JustJoe has said there is another one I'm working on next.
If the update doesn't fix it you may want to read through his report at the end of that thread to see if it is relevant.

[mhoppes]

Upgrading to that did not fix it.

It’s simply acting like spanning tree of any form is not triggering on two ports connected when their native VLAN is different.

[JustJoe]

Upgrading to that did not fix it.

It’s simply acting like spanning tree of any form is not triggering on two ports connected when their native VLAN is different.

It may be I'm not completely understanding ...

But as an example, if on the same switch
port7 is "U" on VLANID20,
port9 is "U" on VLANID30 ...

1) STP or RSTP which are not VLAN aware ... cable connect ports 7 & 9 , a "loop" will be detected, one will likely set to forwarding and the other to discarding.

2) MSTP which is VLAN aware ... cable connect ports 7 & 9 , it will correctly not see it as a loop since internally, the switch is treating them as parts of two separate bridges, connected together by their ports. Therefore likely both will stay forwarding.

[mhoppes]

This is what is happening exactly. STP shouts one down.

MSTP does not shut anything down - but it should because there is an inter VLAN loop.

Even if I MSTP between port 2 and 5 which are on the same vlan it doesn’t shut one of them down.

[JustJoe]

This is what is happening exactly. STP shouts one down.

MSTP does not shut anything down - but it should because there is an inter VLAN loop.

Even if I MSTP between port 2 and 5 which are on the same vlan it doesn’t shut one of them down.

Ahhh, OK that's different, once they are on the same VLAN, it should set one to discarding.

Now that is assuming that you did define that VLAN in one of the MSTP instances.

Have you tried following closely in the WS log? You should see that msti X (instance) messages matching up with the physical plugging and unplugging events.

Just as a note, MSTP does not disable the entire port, just that offending VLAN communication through it.

[mhoppes]

Yeah. So what was happening on 4/5 is:

It would disable the vlan for the loop on both ports but would keep them shutdown the entire time.

Part of the confusion may be the terrible interface of the Netonix for MSTP.