Netonix Forums

OK, so I have done some searching and have yet to come across an answer that fits our issue.

I have come across this issue numerous times with a variety of Wisp switches, and a variety of firmware versions. In almost all cases this is with a Ubiquiti PTMP AP (generally RP5AC-Gen2) with multiple clients connected. We are running RSTP on our networks.

Most recently today I came across two separate switches on two separate segments of our network where STP is constantly showing discarding / learning / forwarding for a particular port in the logs. Both switches are WS-12-250-DC running 1.5.6.

Code: Select all

Jan 5 14:07:32 STP: msti 0 set port 13 to discarding
Jan 5 14:07:34 STP: msti 0 set port 13 to learning
Jan 5 14:07:34 STP: msti 0 set port 13 to forwarding
Jan 5 14:08:10 STP: msti 0 set port 13 to discarding
Jan 5 14:08:11 STP: msti 0 set port 13 to learning
Jan 5 14:08:12 STP: msti 0 set port 13 to forwarding
Jan 5 14:08:33 STP: msti 0 set port 13 to discarding
Jan 5 14:08:37 STP: msti 0 set port 13 to learning
Jan 5 14:08:37 STP: msti 0 set port 13 to forwarding
Jan 5 14:08:49 STP: msti 0 set port 13 to discarding
Jan 5 14:08:50 STP: msti 0 set port 13 to learning
Jan 5 14:08:51 STP: msti 0 set port 13 to forwarding
Jan 5 14:09:19 STP: msti 0 set port 13 to discarding
Jan 5 14:09:20 STP: msti 0 set port 13 to learning
Jan 5 14:09:21 STP: msti 0 set port 13 to forwarding
Jan 5 14:09:28 STP: msti 0 set port 13 to discarding
Jan 5 14:09:29 STP: msti 0 set port 13 to learning
Jan 5 14:09:30 STP: msti 0 set port 13 to forwarding
Jan 5 14:09:37 STP: msti 0 set port 13 to discarding
Jan 5 14:09:38 STP: msti 0 set port 13 to learning
Jan 5 14:09:39 STP: msti 0 set port 13 to forwarding
Jan 5 14:09:44 STP: msti 0 set port 13 to discarding
Jan 5 14:09:45 STP: msti 0 set port 13 to learning
Jan 5 14:09:46 STP: msti 0 set port 13 to forwarding
Jan 5 14:09:59 STP: msti 0 set port 13 to discarding
Jan 5 14:10:00 STP: msti 0 set port 13 to learning
Jan 5 14:10:01 STP: msti 0 set port 13 to forwarding
Jan 5 14:10:22 STP: msti 0 set port 13 to discarding
Jan 5 14:10:23 STP: msti 0 set port 13 to learning
Jan 5 14:10:24 STP: msti 0 set port 13 to forwarding
Jan 5 14:10:37 STP: msti 0 set port 13 to discarding
Jan 5 14:10:38 STP: msti 0 set port 13 to learning
Jan 5 14:10:39 STP: msti 0 set port 13 to forwarding
Jan 5 14:11:02 STP: msti 0 set port 13 to discarding
Jan 5 14:11:03 STP: msti 0 set port 13 to learning
Jan 5 14:11:04 STP: msti 0 set port 13 to forwarding
Jan 5 14:11:23 STP: msti 0 set port 13 to discarding
Jan 5 14:11:24 STP: msti 0 set port 13 to learning
Jan 5 14:11:25 STP: msti 0 set port 13 to forwarding


Now other posts I have found indicate that this is a ethernet issue, and the link is flapping. This is not the case. There are no port errors, and no physical ethernet issues. I know this for sure because I have found a solution of sorts. One of the clients connected at the far side has a switch connected with STP enabled. These switches are managed by us, and are installed at corporate clients for various uses. In both cases, disabling STP on the radio port on the far end switch has fixed the issue. I have also verified that disabling STP on the port that is STP flapping will also eliminate the issue. In one case it was a ubiquiti edgeswitch, and in another case it was a netonix ws-6-mini (1.5.6). We were seeing ~10% packet loss with the frequent STP flaps on both of these ports. The packet loss was to the AP, and everything beyond.

I am wondering if anyone has some insight on what might be the root cause of this issue? I would like to help in any way possible to get the issue resolved for the future. I'm not sure if the issue lies with the netonix implementation of the STP, or the Uqiquiti airmax devices in between.

Possibly related:
viewtopic.php?f=17&t=6290&p=33166&hilit=STP#p33166

This could b related, however I'm not sure I follow exactly. I know RSTP is not vlan aware like MSTP is, however on our network it should work fine. We have VLAN 1 untagged in most of these cases.

With RSTP traffic not being VLAN aware; is it travelling across a VLAN between devices, or is it travelling outside of a VLAN somehow? I'm wondering if the airmax devices in the middle are screwing with it's propagation? We have zero issues where more transparent bridges such as airfiber are in use.

Maybe mirroring the port and make a capture would allow to find the answer. Is this a port facing customer devices ? If so, you should disable STP on it.

mike99 wrote:Maybe mirroring the port and make a capture would allow to find the answer. Is this a port facing customer devices ? If so, you should disable STP on it.

I actually do not believe that BPDU packets are mirrored. I might be wrong.

Generally we disable STP on client facing ports, however in some circumstances it is still required\ for various reasons. We are slowing moving away from this need though as we implement MPLS.