Gratuitous ARP

[mhoppes]

Is there anyone to disable Gratuitous ARP on the Netonix switches?

Situation:

Netonix1----airFiber24-----airFiber24-----Netonix2

Traffic is flowing from 1 to 2. Something happens that the Ethernet connection is terminated between airFiber24 and Netonix2. For a few seconds, Netonix1 will gratuitously ARP and carry on trying to figure out where Netonix2 and its hosts went. This causes a momentary network outage.

I'm aware the airFibers can be setup to drop Ethernet port if the RF side fails, and when the Ethernet goes down, the GARP doesn't happen.

[sirhc]

As far as I know our switches do not actively send out a lot of Arps looking for stuff when an event like your describing occurs?

What makes you think this Matt, please describe your observation and maybe Eric will also weigh in on this?

However when an AF link drops or its buffers fill possibly from the link modulating down below the capacity needed to carry the traffic the AF will send out non solicited Pause Frames one after another as fast as it can. I do not agree with this behavior.

[mhoppes]

Right. But that will only cause a pause on that port correct?

I'm still formulating data and not on a computer to type out a long reply but essentially what I've seen is if you drop the far end Ethernet port without dropping the local end, the local switch will lose all connectivity to anything for a few seconds.

I'm only guessing it's a GARP trying to make sense of the world vanishing without the port going down.

[sirhc]

Disable Flow Control on both sides of the airFIBER link or on the AF radios themselves and problem will go away.

This has been gone into far detail here on this forum and on the UBNT forum.

UBNT AF team admits they have an issue with Flow Control and as of yet have not fixed it to my knowledge?

What version of firmware are you running on the switch Matt?

If you upgrade to v1.4.5rc7 which you should be on then we implements a Flow Control Storm protection that will alert you to a Pause frame storm from the AF and then automatically disables Flow Control on the port facing the AF radio.

You can read some of the posts here and get a refresher
search.php?keywords=%2BFlow+%2BControl+%2Bbug+%2Bstorm+%2Bpause+%2Bframe&terms=all&author=sirhc&sc=1&sf=all&sr=posts&sk=t&sd=d&st=0&ch=300&t=0&submit=Search

[sirhc]

It was also discussed how this AF pause frame bug can basically seize up a switches ability to pass any traffic as it causes the switch to fill up all its buffers.

The switch is not locked up just stuck hold packets and unplugging the AF radio causing the traffic jam will immediately free up access to the switch.

Read this post Matt then skim the entire thread:
viewtopic.php?f=17&t=1654&hilit=Flow+Control+bug+storm+pause+frame&start=100#p12556

[mhoppes]

I'll read and reply later once I get done with today's tower work.

Would a pause frame traverse between two netonix switches?

Router---switch---switch---AF---AF---router

The first switch in the chain is the one that stops passing traffic.

[sirhc]

I'll read and reply later once I get done with today's tower work.

Would a pause frame traverse between two netonix switches?

Router---switch---switch---AF---AF---router

The first switch in the chain is the one that stops passing traffic.

No but read the thread.

If most of your traffic is going to say Port 1 from all your other ports and the device on port 1 is sending non stop pause frames to port 1 eventually the switch will fill its buffers up trying to hold packets coming in from the other ports that want to go out port 1. Once the shared packet buffer memory is full the switch will start issuing pause frames out the other ports to prevent more data from coming in those ports. Now what you have is a switch that can not send data out port 1 as the AF is sending non stop pause frames to port 1, the switch buffers are full so it is sending out pause frames on all other ports that have data destined to port 1 which is probably all ports since port 1 is the back haul so for all intense purposes the switch is packet locked BUT NOT LOCKED UP. Simply remove the cable from port 1 and all those packets in memory being held to go out port 1 are dropped and traffic can no resume and you can access the switch again.

PAUSE FRAMES ARE SPECIAL BPDU TYPE PACKETS THAT "SHOULD" NOT TRAVERSE PAST AN INTERFACE BUT THEIR AFFECT CAN SORTA TRAVERSE A LINK TO THE OTHER SIDE IN THAT THE SWITCH ON THE OTHER SIDE IS NOW RECEIVING NON STOP PAUSE FRAMES FROM THAT AF RADIO "PROBABLY" AS THE LINK IS INSUFFICIENT TO CARRY THE LOAD AND WHAT UBNT DOES IS SEND NON SOLICITED PAUSE FRAMES OUT THEIR INTERFACE ANY TIME THEIR BUFFERS ARE FULL AND THE AF RADIOS HAVE A VERY SMALL AMOUNT OFF BUFFERS.

As I said if you are seeing weird issues this is what I would do:
Upgrade your firmware to v1.4.5tc7 which is what you should be using anyway as all v1.4.5rc7 has over v1.4.4 is bug fixes reported in v1.4.4 including security patches which you definitely want. And v1.4.5rc7 has Pause Frame Storm protection and will disable Flow Control on the port if it encounters a Pause Frame Storm from an AF and send you an alert and put it in the log.