Flow control question

[RebusCom]

I have a particular WS-8-250-AC that is fed by an AF5x backhaul and serves multiple individually routed AP's, all GbE with the exception of one old FastE. All have flow control enabled, as indicated by the switch. The switch port to the backhaul AF5x is racking up Tx Pause Frames at a rapid rate at all times of the day. This is new behavior. I would expect that there should be incoming pause frames coming from one or more of the AP radios, indicating as Rx Pause Frames on one or more of the other ports. Oddly, there are almost none. It's as though the switch itself is generating the pause frames. Am I misinterpreting this? Does the switch counter not trigger on incoming pause frames or is the switch vs the radio issuing the pause frames because the radio can't keep up and the switch buffer is filling before the radio issues pause frames? Confused.

[sirhc]

No, this has been discussed many times on the forums already, do some searching.

But crib notes:
If the port facing an AP has it buffers over run trying to send more data than the AP can deliver the switch will issue a Tx Pause Frame on the interface facing the source which would be your router or back haul.

Go watch my 1.5 hour video on YouTube and I also discuss this there.
https://www.youtube.com/watch?v=8JvBEAD4MFM

[RebusCom]

Does the 1.5 hour video describe how to best determine which buffers are overflowing and if more than one by how much?
What is puzzling me presently is why this issue showed up suddenly. There have been no changes in configuration or hardware. It must be traffic related but the client topology has not changed either. At any rate, it would be helpful to determine which port(s) is struggling.

[sirhc]

Does the 1.5 hour video describe how to best determine which buffers are overflowing and if more than one by how much?
What is puzzling me presently is why this issue showed up suddenly. There have been no changes in configuration or hardware. It must be traffic related but the client topology has not changed either. At any rate, it would be helpful to determine which port(s) is struggling.

Your topography may not have changed but your track probably has. Increased usage especially from a bad connection or maybe a BitTorrent started up at a customer location.

I would look at your AP's and look for poor client connections on each AP. The more poor connections you have the more wireless errors you have and errors and retry s are the most common reason port buffers fill up.

Also if you are not shaping at the head end then any time a customer goes to a site with a lot of streams from different sources on the internet the more data that will cram down the pipe and hit the AP interface where it bottlenecks. Going to just about any site these days like CNN will have data coming from MANY MANY different locations from all the adds.

[sirhc]

Pause frames are not a BAD thing, they are needed in the wireless industry. However in my video I discuss why I do not have my back hauls and local tower radios sharing the same path between the router and the switch so back hauls are not affected by local AP pause frames as that data maybe on its way to the next tower.

Also I create a Static LAG between the router and the switch to handle the local radios so that pause frames are split between the interfaces. I talk about this in the video as well.

[RebusCom]

Thanks. We employ dynamic shaping at the head end. We'd be toast without that as our bandwidth utilization is very high. But the high pause frame rate at this one site is perhaps an indicator that shaping could be tuned better to alleviate the choking. BitTorrent is a potential contributor.
I'll check out the information on segregation of multi-hop backhaul from intermediate AP's, but I expect it is not applicable to our present configuration without secondary backhaul or addition of intermediate (local) routers. I assume you've done the latter.