MS350 keeps having BPDU guard activated .....

[thomasthomsen]

I have a MS350 stack, and we are setting up a few new MS120-8 switches connected to it.

But the port just keeps activating BPDU guard, even though we have disabled it on these "downlink" trunk ports.

The port WAS configured with BPDU guard as an access port before. But it just seems that the BPDU guard config is "stuck" on the port somehow. Even though the switch says "up to date".

Has anyone else seen this ?

Switches are on the latest 14.x release.

/Thomas

[thomasthomsen]

PS : Of course only ONE cable is connected from the MS350 to each of the MS120, and no other ports are currently connected to the MS120's  So there is no loop or anything that should trigger "guard".

[thomasthomsen]

Once in a while the ports go briefly "green" but still with the "block" sign on them. Then back to orange with the block sign.

[thomasthomsen]

So apparently I should just be patient ? (like 15 - 20 minutes).

But why ... the config said up-to-date after a short while.

Maybe there is some BPDU guard timeout thing on the switch even when you disable / enable ports after reconfigure ?

The ports now seem to be fine.

*sigh*

[thomasthomsen]

I spoke too soon.

One of the "downlinks" just goes into STP block for no reason that I can see.

Thereby disconnecting the MS120 and its connected clients.

Its very strange.

[PhilipDAth]

Out of desperation, I would try a port cycle.

This sounds like a software defect to me and will need a power cycle of the switch to resolve.  Perhaps consider upgrading the switch to the current stable firmware if it isn't already.

[thomasthomsen]

We have tried multible things.

Port cycle, reconfigured the port for fx. Loopguard ( should no to anything in this one stringed downlink ), disabled spanningbtree on the port entirely and so on and so on.

It seems just to happen all of a sudden.

There is nothing interesting in the event log.

Running the latest and the greatest stable software.

I have not tries a reload of the switch, because I didnt want to disconnect everyone else on it .

I might need to , just to test.

Also created a case, because this is a real mystery. 

[thomasthomsen]

We moved the ms120 switch to another switchport in the stack. - All problems gone.

So there was some strange issue.

Also rebooted another member of the stack because it seemed to disconnect APs that was connected to it (ports where still up and green with the SecureConnect wifi icon on them, so they should be good, but they were not. Same thing happened, here, when we shut / no shut the port, they started working again for a while. After reboot of that stack member, everything seems to be fine).

[cmr]

@thomasthomsen I wonder if 14.32 hadn't properly applied as there was an issue with STP on an earlier (14.29 perhaps) release that was only fixed in 14.31/2 from memory.

Another reason why being able to see the real switch software version running, alongside the configured one, would be very helpful...

[thomasthomsen]

Good question.

As you say, hard to tell.

I was wondering about the bug mentioned where it says something about switches in stacks not refreshing config for the entire stack, or something like that.

[MK2]

Same here, some news?

MS225-48 in stack with MS 14.33.1

Case 08164741

Try to connect the MS to a Cisco SG350 via a copper port.

Does the move to another port solved your problem?

[MK2]

Solved by the magic of coffee.....30 minutes later the port is unblocked 🤣

Still waiting for support, maybe they find something

[thomasthomsen]

I think our original real problem was the issue with config not being pushed (as fast, or updated correctly) to the entire stack.

[MK2]

So you mean the "config state" is useless for stack-config related to STP or some other configurations?

[thomasthomsen]

Indirectly - "yes" ? 🙂

Might have been fixed in later releases. Im almost running 15 on everything these days.