Flow Control..... take 2, 3, 4?

[juanvi]

Thanks. I'll think more about it. A worse TCP would be admisible if VoIP works better in congested situations. We are using only L3 switches at towers doing VLAN routing from APs to core router. Using VLAN Cos QoS at these points.

Is IEEE 802.1p (VLAN Cos) implemented in WS-12-250-DC fw.1.3.9? If yes, how can be configured?

[mike99]

QoS configuration is comming in futur version. I think Chris writed on the forum that it's planned for 1.4.X.

Anyway, with flow control, you should control QoS on the router since this is where the pause frame will be received, to be sure that data is droped instead of voip while the ehternet of the router is paused.

[MyThoughts]

No, if you disable flow control your performance will drop and VOIP will suffer.

I am a WISP as well and have tried all different configurations.

Yes TCP has mechinisums but the pit falls of wireless half duplex links have a much worse impact on L2 traffic as Layer 2 is only aware of physical link state so it thinks that Rocket M5 is 100M-FD and in reality it is variable HD so the port buffers will constantly fill up and start dropping packets which has a much worse impact on TCP throughput then enabling Flow Control.

Yes we under stand a pause frame pauses the ENTIRE interface which is why I always separate back haul radios such as airFIBER 24 to never use the same interface as local small private PTP and PTMP radios at each tower.

Maybe go watch this video https://www.youtube.com/watch?v=8JvBEAD4MFM
Then there is a second video there where I do speed tests from a location off an AP.

I am not going to disagree with your experience in your network, however, without knowledge of the entire structure/layout I am very hesitate to recommend one way or the other.

I can't remember which version of the Netonix introduced the FC default 'on' but that ended up causing us a huge headache. Without going into super detail we installed a Netonix switch at a major distribution point in our network, and shortly thereafter started receiving complaints from clients in a completely separate location. From a L2/L3 standpoint the complaints did not appear to be related to the new switch install. At that time we were experimenting with a hybrid bridge/routed network for our backhauls, which up until that point at been working well. When we put the new Netonix in place, the FC being enabled by default resulted in pause frames getting back to one of our Netonix switches at our head office (coming through a bridged AF24/AF24 setup), this in turn as you can imagine was causing us no end of strange issues. Once we realized the problem we disabled the FC on the new Netonix switch, this resulted in a immediate performance increase areas of our network. We then went back to our good'ol tried and true fully routed network, with QoS on routers present at every tower distribution point in our network. As a result of the changes, FC disabled is the best for us as pause frames are not needed, we are controlling traffic to ensure best case performance via the QoS rules at each tower.

This works for us, and I am very comfortable with our methodology and our network topology. Everything is subjective and in the computing world very rarely is there only one 'the best' way. I have setup a few labs with Mikrotik CCR routers in a chain, netonix switched, and various separate pretend 10 Mbps, 100 Mbps, 1000 Mbps devices, very eye opening on how adjusting a seemingly simple FC checkbox could seriously degrade a network depending on its network layout.

Anyways, test and find what works best in your network, it is the only way to ensure maximum performance.

Cheers

[sirhc]

THis is why I NEVER have local radios and by local radios I mean Tower APs or private PTP links ever going over the same interface as back hauls.

If you go watch my video https://www.youtube.com/watch?v=8JvBEAD4MFM

In that video I expressly warn about having backhaul radios on the same interface as local radios as PTMP and local radios will generate a lot of pause frames and interfere with traffic traversing that tower to the next tower.

However with that said I also have FC turned on for my AF back haul radios and they do sometimes generate pause frames but are not slowed down by the millions of pause frames generated by the local PTMP and private PTP links on each tower.

[amp]

We have a cisco mwr 2941 connected to a netonix. The netonix negotiates flow control both ways. However the cisco always says flow control is off on show interfaces. I don't understand how it can say its off but the netonix says its on. Nor can we get the 2941 to ever say flow control is active connected to anything with it enabled. It also never shows any pause frame activity etc. Any ideas? Cisco documentation seems to be useless.

We try to run mostly a cisco network but between asr 901s which seem to not support flow control and 2941s with questionable flow control activity it really is a pain. And i don't want to toss a 2951 in a outdoor box.

[Patagoche]

I would like to know -since my network is using PPPoE tunnels for user traffic- how this protocol behaves with Flow Control turned on. As far as I know pppoe has no FC control frames, nonetheless when enabling FC on my towers, I see a lot of FC pause frames on my PTMP Access Points.
What I am trying to ask, is: How do pause frames influence pppoe traffic or viceversa in relation to normal TCP/IP packets?
Any insight on this?

[sirhc]

I would like to know -since my network is using PPPoE tunnels for user traffic- how this protocol behaves with Flow Control turned on. As far as I know pppoe has no FC control frames, nonetheless when enabling FC on my towers, I see a lot of FC pause frames on my PTMP Access Points.
What I am trying to ask, is: How do pause frames influence pppoe traffic or viceversa in relation to normal TCP/IP packets?
Any insight on this?

PPPOE does excuse the packet from Flow Control.

You can read about Flow Control with a Google Search: https://www.google.com/webhp?sourceid=c ... %20control

From Wikipedia, the free encyclopedia:
https://en.wikipedia.org/wiki/Ethernet_flow_control

Flow Control is a standard as defined by IEEE 802.1Qbb and as such behaves the same on all switches.

[jjonsson]

Are there still FC issues with v8.0-RC2 and v6.0-RC for airMax AC ?

I'm still seing issues with periodic latency jumps (PING another device in the network and you have nice latency around 2-3 ms, but suddenly hits 400 ms).

[LRL]

It's been a long time since I remember having a discussion about routers dropping packets, but I seem to recall that a router will send back an icmp packet on some instances when it drops a packet.

Congestion controll ICMP 4 and 12 when the ttl is exceeded.

I believe this is what Chris is trying to say routers do.

[sbyrd]

It seems the Airfiber Flow control flood issue of AFX is claimed to be resolved by the AF team via 4.0beta FW.
https://community.ubnt.com/t5/airFiber- ... 8#U1763478

"The old GUI only saved the first 8 characters of the password and ignored the rest. The new GUI does not do this. As a result:
- After upgrade, the new password is the first 8 characters of your old password
- If you save a new, longer than 8 character password on the new GUI, YOU WILL NOT BE ABLE TO LOG INTO THE RADIO if you downgrade back to the old GUI. Recover is possible via ssh/telnet, but, it would be better not to go there Man Happy



New Features:
- All New GUI
- Receive Target Power (control tx power to hit remote receive target)
- Slave Frequency Scanning (autoscan of up to 10 frequencies looking for beacon)
- Immediate changes for Basic Wireless Settings; RF link maintained where possible
- Added strict timing mode for improved co-location



Improvements:
- Full password length now used (not just first 8 characters) for both web and ssh/telnet ***SEE WARNING ABOVE***
- Ethernet Carrier drop now has high and low trigger points, new timers, etc (see upcoming post for full description)

- X radios - Flow control pause frame flood issue fixed
- X radios - Improved RF filtering / adjacent signal rejection

- AF5x - DFS trigger improvements (allows slave unit to use GPS signal) - should configure duty cycle on remote unit
- AF5x - Tighter timing restrictions for NxN to improve registration timing
- AF5x - NxN configurations now support DFS channels
- AF5x - 75% Duty cycle now works correctly with 20MHz and 10MHz bandwidths"