Dropping ports on new WS, what is wrong with my setup?

[bmv]

Well this is what I would do if I experienced anything similar:
1) Upgrade to v1.4.0rc16 not because it fixes this issue (we think it may be a UBNT issue) I just like it better and it does fix some other issues.
I am running v1.4.0rc16 on my WISP towers, it is fine. In fact I think it is our best firmware yet. Just leave Discovery Disabled on the Device/Configuration Tab.

2) DISABLE Flow Control on any port going to an AF radio.

3) Leave Flow Control ENABLED for all other ports not connected to AF radios.

Try these suggestions and see if your problems go away.

Will try disabling FC when we have this issue again.
It sounds like 1.4.0rc16 won't fix this from reading all the other posts, but if we have a maintenance window to do this, we will consider it.

Can anyone else confirm whether this issue is at a site where you may have a large flat network with multiple AF5X radios?
For us, this is probably the single largest factor at this POP compared to our many other POPS with Netonix switches and AF5X radios.

[adairw]

Ok wow. I got way behind here.
The forum stopped sending me email updates.

Since disabling flow control we have 2 days up time on one switch and 4 days up time on the other. There are 4 AF5X radios involved between these two problem switches and each of them is running 3.2.

We do see CRC errors from time to time on various AF5X links, been trying to track that down. Was wondering if it was the surge modules we use..
ALL other services are off on these switches right now too. I'm going to give it a few more days and turn back on a few things like SMNP, NTP, Cisco and UBNT discovery and go a few more days. If that works well I'll turn flow control back on for everything else except the AF5X ports.

We have AF5X 3.2 all over the network on netonix switches. The one thing that differs on this part of the network is that we span between three sites with four switches and four radios all layer 2. In other words, Router>Switch 1>Switch 2>AF5X><AF5X>Switch 3>AF5X><AF5X>Switch 4. Where pretty much every other part of the network is radio to switch mid span to router, or Router>Switch-mid-span>AF5X><AF5X>Switch

[sirhc]

We have AF5X 3.2 all over the network on Netonix switches.
Where pretty much every other part of the network is radio to switch mid span to router, or Router>Switch-mid-span>AF5X><AF5X>Switch

The one thing that differs on this part of the network is that we span between three sites with four switches and four radios all layer 2.

In other words, Router>Switch 1>Switch 2>AF5X><AF5X>Switch 3>AF5X><AF5X>Switch 4.

I agree with this assessment, it has something to do with AF links between switches. I can not see how this is us but we have not ruled anything out.

I honestly think is has to be the AF firmware somehow? The reason I say this as so many people go switch <other radio link> switch <other radio link> switch and so on in large flat networks segments including airMAX radios and have no problems????

I notified UBNT of this thread we shall see what their response is?

[mayheart]

Ok wow. I got way behind here.
The forum stopped sending me email updates.

Since disabling flow control we have 2 days up time on one switch and 4 days up time on the other. There are 4 AF5X radios involved between these two problem switches and each of them is running 3.2.

We do see CRC errors from time to time on various AF5X links, been trying to track that down. Was wondering if it was the surge modules we use..
ALL other services are off on these switches right now too. I'm going to give it a few more days and turn back on a few things like SMNP, NTP, Cisco and UBNT discovery and go a few more days. If that works well I'll turn flow control back on for everything else except the AF5X ports.

We have AF5X 3.2 all over the network on netonix switches. The one thing that differs on this part of the network is that we span between three sites with four switches and four radios all layer 2. In other words, Router>Switch 1>Switch 2>AF5X><AF5X>Switch 3>AF5X><AF5X>Switch 4. Where pretty much every other part of the network is radio to switch mid span to router, or Router>Switch-mid-span>AF5X><AF5X>Switch

CRC errors are a known "bug" The CPU will randomly spit out an invalid packet.

http://community.ubnt.com/t5/airFiber/AF24-RX-CRC-RX-FCS-errors-with-ping-watchdog-or-ping-tool/m-p/1424277

This affects all of the AF lineup, a fix is going to be released for AF5X line-up in 3.3. There's a post about it on the AF Beta forum.

[adairw]

the last response from Ubiquiti was in December of 2015 and we still don't have a fix?

[sirhc]

viewtopic.php?f=6&t=1618&p=11960&hilit=CRC#p11960

[IntL-Daniel]

Did you try to send your post above to UBNT AF team Chris? :-)

[nickwhite]

I posted a new thread here regarding the Flow Control issue: https://community.ubnt.com/t5/airFiber/ ... -p/1556296

[zrob_12]

Are you all disabling Flow Control on both the Netonix and the AF ?
If that "fixes" the issue, can you attempt making a change to the remote side of the link that drops the link temporarily? During the drop period, do you incur errors?

[sirhc]

Are you all disabling Flow Control on both the Netonix and the AF ?
If that "fixes" the issue, can you attempt making a change to the remote side of the link that drops the link temporarily? During the drop period, do you incur errors?

You should only need to disable Flow Control on either the AF or the switch port connected to the AF.

If either is disabled then it should not negotiate FC.

Personally I would disable FC on the AF and make sure the switch reports no FC negotiated or active.

Disabling on both is overkill but can't hurt.