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.
