v1.4.6 Bug reports and Comments

[mblfone]

If you upgrade to the latest firmware and Enable Pause Frame Storm Protection on the Device/Configuration Tab is should catch a Pause Frame Storm and automatically disable Flow Control on the port preventing the switch from seizing up so you do not have to unplug the AC radio to get the switch back.

I was hoping to disable the Flow Control on our AC devices over the weekend. I just had another event that recorded excessive pause frames and then our bonded LACP interfaces dropped thereby dropping many A/Ps from service. I have 1.4.6 firmware and the Enable Pause Frame Storm Protection was enabled at the time.

I agree that this is not a Netonix issue, but seeing as the Pause Frame Storm Protection has been developed to manage the unsolicited pause frames, additional tweaks to prevent the LACP interface from going offline and disabling flow control for the offending A/P only would be awesome. I am starting a new conversation on the UBNT website to see what their progress is and if I can get some priority developer attention to address this. Any help in adding urgency to this by replying to the post would be appreciated. This is a HUGE (Donald Trump) problem.

Scott

[sirhc]

Simply turn Flow Control OFF on the ports facing airMAX AC and AF radios if you are using LACP on that switch, no need to wait until the weekend as this is a momentary disruption.

You could use STATIC LAGs between the switch and the router as a paused port will not affect a STATIC LAG in that manor like it can on a LACP LAG.

However LACP should recover on its own even if the LACP port is paused too long and interrupts LACP and forces the port to drop out of the LAG.

[mblfone]

Sadly that isn't the case here. I'm looking at the Rx Pause metric run non-stop right now, and the traffic across the ethernet link is all of 8-10 Mbps. This particular AP has 8 clients connected and all are perfectly stable at 144Mbps modulation. There doesn't seem to be any correlation with traffic load in this particular case.

An interesting observation on the ubnt AC Beta forum... I am going to check this tonight, but it seems as pause frames may be generated without full buffers on UBNT's end.

[jjonsson]

Thanks Chris, I know about flow control story and I also have a prove that AC radios have the same problem. But I never saw any message that UBNT has confirmed this as issue and works on fix :-( Instead I saw some threads where Chuck (or someone else from UBNT) says that it is an issue of Netonix.

No this is not a Netonix issue as people have reported this issue on other switches even Cisco with AF radios and airMAX AC radios.

It is NOT standard to throw unsolicited Pause Frames as fast as you can generate them when your buffers are full which is what they are doing.

If it's NOT standard, you should be able to prove it to them. There must be some draft that states it's not or ?

[sirhc]

If it's NOT standard, you should be able to prove it to them. There must be some draft that states it's not or ?

I fail to see why this is our responsibility to convince another manufacturer they are not following the standard?

If you want to learn how Flow Control is supposed to work simply Google Flow Control as defined by IEEE 802.3x.

Here is a good place to start:

https://en.wikipedia.org/wiki/Ethernet_flow_control

http://www.ieee802.org/1/files/public/d ... oposal.pdf

http://blog.ine.com/2008/07/08/802-3x-flow-control/

http://www.trincoll.edu/Academics/Major ... hernet.pdf

[jjonsson]

@SirHc, have you sent them above links ?
It's not you, it's them. If they don't believe you ask them to read above links....

[tma]

Sadly that isn't the case here. I'm looking at the Rx Pause metric run non-stop right now, and the traffic across the ethernet link is all of 8-10 Mbps. This particular AP has 8 clients connected and all are perfectly stable at 144Mbps modulation. There doesn't seem to be any correlation with traffic load in this particular case.

Sounds similar to what I've described a few times and summarized HERE as "the 8/15 issue".

I've seen LACP ports going down and up occasionally too - triggering RSTP relearning. This was logged as "restarting vtss_appl" by /usr/bin/monitor if I remember correctly. The reason I haven't investigated further is because 1.3.9 is the version we have standardized on and bug reports for that version are no longer accepted.

[mblfone]

As per Sirhc's recommendation, I have turned off Flow Control on the switch and the Access Points. I have not changed from LACP to static on the bonded interfaces yet. So far so good. This has been running solid for over a week.

I can't get UBNT to respond to a thread which has been open for some time: https://community.ubnt.com/t5/airMAX-AC ... -p/1568041

I absolutely hate this form of support. I enjoy the forums, but unfortunately this is how technical support works in the new millennium. Post enough and hope you get a response! I am considering opening up a chat and point them to the UBNT forum to see if I can initiate even an unofficial reply. This flow control problem MUST get addressed soon!

[tma]

7 hours ago, UBNT released firmware V4.0beta1 which has in its changelog:

- X radios - Flow control pause frame flood issue fixed

The question to be asked is what that means to AF5 (AF5 beta1 is delayed for a few days and so is its specific changelog) and AF24 (which doesn't mention FC fixes in its specific changelog).

[Digitexwireless]

Anybody having issue with a complete reboot of the Netonx after upgrading to 1.4.6? I have a site which has run flawlessly for months, then i did the upgrade from one of the RC's and now i get it rebooting. When it reboots, it takes all links down. In the log i see reference to a cold boot. Should i downgrade?

Tommy