05-07-2021 12:05 AM - edited 07-05-2021 01:16 PM
Hello,
I have basic knowledge of FlexConnect and when it's used - branch offices and remote sites. Recently I've been told by some auditors that we should configure FlexConnect in our local network to increase wireless speed and quality. I've never heard of using it in a local network. Does it make sense to enable FlexConnect in a local network?
Thank you for any feedback.
Btw. we have one WLC and 70 APs.
Solved! Go to Solution.
05-07-2021 08:53 AM
For local campuses scenario i've never deployed flex-connect mode, if there's no special use cases and everything already works fine then don't make any changes. only places have deployed flex in-campus is when there's cloud WLC in place.
Wireless speed and Quality don't change between flex and local mode -it's the same LAN/WAN link at the campus, it's only the uplink datapath that makes the difference.
From a wireless traffic perspective, it's capwap(local-mode) Vs no-capwap(flex-mode) to upstream and it doesn't make big difference in LAN.
Also, there'll be overhead to maintain WLAN-VLAN flex config and relevant switch trunk config needed in the current environment and whenever the network grows.
hope it helps to understand from high-level.
05-10-2021 10:00 AM
Here is my 2cents. Back in the day's when the 2504 came out, folks were worried about the backplane being an issue so some converted to flexconnect. I have seem large environments where the customer had 5508's as an example and only had one port connected to the network. So the myth is, does it really help, I don't really think so unless you are crossing the WAN and you want to have majority of the traffic to stay local. You need to also keep in mind the limitations of flexconnect and make sure that, if you decide to go this route, that the limitations doesn't hurt your design and your existing user experience. Layer 3 roaming is not supported and there is also a limitation on the number of ap's in a flexconnect group. Review the flexconnect guide and make sure you understand the various scenarios and limitations specified in that guide.
You can also test with one ap and actually see if the auditors theory is valid in your situation. Sometimes filks keep what they hear and see in other environments as "the correct way". That is not always the case.
05-10-2021 02:34 PM - edited 05-10-2021 02:34 PM
I'll add my 2 cents worth too ...
While saying flexconnect like Scott says you do need to check the feature matrix because some features you may be using may not be supported in flexconnect mode. But actually I suspect your 'auditor' (quotes intentional because probably just someone with no technical knowledge of WLC just following a tick-list template) is actually saying you should implement flexconnect LOCAL SWITCHING because just changing to flex won't make any difference at all (apart from the aforementioned feature support) - do they realise that?
So assuming you changed to flexconnect local switching there is a theoretical gain to be made:
- traffic is no longer being tunnelled in CAPWAP so you could see 1 or 2 ms reduction in latency (removing encapsulation/decapsulation of the traffic).
- the WLC is no longer a bottleneck for the traffic (like Scott said) but if you're within capacity unlikely to make any difference.
- because the traffic is no longer being tunnelled in CAPWAP you can use a larger TCP MSS (1250 is recommended with local mode or flexconnect central switching, has no effect on flex local switching) which could offer some improvement in throughput and less fragmentation of UDP traffic.
You could test to see how much difference these actually make in practice, and then do a cost (of redesign) vs benefit analysis to make an informed decision. In all likelihood I expect the improvement will be marginal (of the order of 10% my best guess) and likely not justify a redesign. Chances are users would not notice any difference anyway apart from speedtest improving slightly.
05-18-2021 12:16 AM
Do you recommend any? We use Zabbix but I am not able to make it work. Any other alternative? Where can I see these numbers in WLC?
I use Prime Infrastructure. I wouldn't anymore buy this as a new product.
Cisco by now uses a mostly standard netflow format, but make sure your software actually supports Cisco WLC Netflow:
I've made my decision but I am collecting more info for my manager. Now I am going to monitor traffic from/to WLC to verify that WLC uplinks can handle all the traffic. I would test FlexConnect on APs only in case they would insist on configuring it.
As stated many times, FlexConnect is very rarely needed if you don't transfer the data over WAN links. Depending on the size of your network (amount of APs) and the small 3504 WLC, you might saturate the 1 Gbps port. You can work around that by enabling LAG on more ports on the 3504, that way you can increase the throughput further: https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_WLC_3504_Release_8_5_Deployment_Guide.html
Nowadays in most enterprise developments your AP density is fairly high, so that all clients have a strong signal with a short path to the AP. That way you can get a lot of performance out of your network, while providing good roaming. The big downside of this is the channel re-use. For this reason you often have 40 or even 20 MHz channels on 5 GHz, to maximize the amount of free channels. But this will vastly reduce the maximum throughput if no users are there (capable client assumed), but will vastly increase the throughput if many users are there.
In other words, with a 160 MHz 802.11ax channel (which limits you to 2 or 3 available channels), you could have > 1 Gbps of throughput with a single capable client. If you reduce this to 20 MHz you now have around 19 available channels, but a maximum throughput of maybe 250 Mbps. Those numbers are sadly only valid if there are no other wireless devices on the same frequency, which sadly doesn't happen in the real world, unless you are in a cellar
05-07-2021 04:17 AM
> ...to increase wireless speed and quality.
I doubt this, flexconnect only offers user connectivity through local switching when the controller is unavailable , this normally does not happen.
M.
05-07-2021 05:04 AM
Do you see any benefits in configuring FlexConnect in a local network?
05-07-2021 05:14 AM
Personally i do not see any advantage as you mentioned with orginal post.
05-10-2021 08:53 PM
You typically don't, at least I have never seen any slowness. Now with the vWLC, you might want to consider FlexConnect and not local as traffic would tunnel back to your VM host. Best thing you can do is test for yourself. Like I said, you can take a spare AP and configure that for FlexConnect, you will need to create a new SSID so you don't mess with production SSID, unless you are comfortable making changes to the existing to enable local switching.
If you take what many experienced engineers here have provided in your post, none have stated that FlexConnect provides better throughput. Let that sink in for a while and make a decision on what your next steps would be.
05-07-2021 05:19 AM - edited 05-07-2021 05:22 AM
Ok. And any other possible advantages?
Were auditors wrong?
What is your opinion on this in general?
05-07-2021 07:29 AM
>Were auditors wrong?
- Because your locally-switched-intranet , these days , is at least 10xfaster then average wireless speeds -> no advantage.
M.
05-07-2021 08:53 AM
For local campuses scenario i've never deployed flex-connect mode, if there's no special use cases and everything already works fine then don't make any changes. only places have deployed flex in-campus is when there's cloud WLC in place.
Wireless speed and Quality don't change between flex and local mode -it's the same LAN/WAN link at the campus, it's only the uplink datapath that makes the difference.
From a wireless traffic perspective, it's capwap(local-mode) Vs no-capwap(flex-mode) to upstream and it doesn't make big difference in LAN.
Also, there'll be overhead to maintain WLAN-VLAN flex config and relevant switch trunk config needed in the current environment and whenever the network grows.
hope it helps to understand from high-level.
05-08-2021 07:33 AM - edited 05-08-2021 07:35 AM
In general - no reason why flex should make any difference for your scenario but there is 1 reason we configure all our APs as flex - whether we're using them for flex or not. We use "MAC Filtering" with central auth by radius server on some WLANs. As the radius is sometimes proxied to 3rd party radius servers on the other side of the world the client association attempt often fails due to up to 1200 milliseconds for radius response when they're in local mode. There is no config to mitigate this in AireOS according to TAC. But changing the AP to flex mode magically resolves the problem (without changing any other config) so that we no longer have the timeouts and client association failures - problem solved. This was the TAC recommended solution and has worked perfectly for us ever since.
I doubt that this is an issue for you but a useful bit of info for anybody who might have a similar problem in future.
05-08-2021 08:20 AM
this appear to be a bug in code or incorrect config that should be fully isolated, you should ESC the issue within Cisco Engg to properly get it resolved.
05-08-2021 09:06 AM
Like I said the workaround (flex mode) solved it for us with no downside so why would we go to the trouble of raising a feature enhancement bug (if you've ever done that before you'll know why it's best avoided) knowing that it could take months to years to get a release with the enhancement (and only if Cisco decide to implement it). Adding new knobs to tune something is invariably treated as an enhancement not a bug. As far as Cisco were concerned it was working as designed and there was a perfectly palatable workaround. I was just highlighting it for awareness in the context of the question being asked (reason for using flex mode). We are very familar with opening bugs (we've opened dozens and got them fixed) as well as enhancement requests and there is no point in wasting further time and energy on something like this which was not a show-stopper with the workaround. That energy is best expended on the real show-stoppers which do require a fix or enhancement from Cisco. As the saying goes - choose your battles wisely...
05-10-2021 03:53 AM
I agree with you, however, That was a direction/guidelines, its not necessary it should be followed and can be ignored based on the given situation and other requirements. Coming from Cisco, not all Cust will easily take changing the design as soln. for a given critical issue/basic feature. To give an example, let say big retail stores got 1000s of stores and they hit this issue, we don't expect them to change the design for this given issue which is unacceptable. As you said in your case its not needed but that's not the case everywhere and it goes case by case basis.
05-08-2021 09:08 AM
in your setup/design, Challenge/Ask your auditors to prove through demo or Cisco doc that shows Flex better over local -Both deployments works though.
FlexConnect Feature Matrix
https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/112042-technote-wlc-00.html
05-10-2021 01:19 AM
Thank you all for your comments. I appreciate it.
I know both deployments work. I am just trying to understand if configuring FlexConect would be beneficial for us as auditors told us.
@saravlak "it's only the uplink datapath that makes the difference.", "it doesn't make big difference in LAN"
The traffic from/to WLC would reduce but is this change worth it? Would the traffic reduce significantly so it would actually affect the network performance? Is this a reason why we should switch to FlexConnect?
We have 70 APs and each of them usually handles 5-25 clients and a total number of clients don't exceed 450 clients at one time.
05-10-2021 03:30 AM
Local mode is widely deployed model on campus LAN and Cisco doesn't push flex over local mode on Campus LAN for wireless speed/quality reasons, unless its cloud WLC in use period.
in your network, If WLC is not a bottleneck then there is no reason to worry about wireless speed/quality. also, if there's no complaint from end-user from user experience perspective then don't make any change on existing setup.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide