cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5316
Views
26
Helpful
42
Replies

FlexConnect in a local network

B A
Level 1
Level 1

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.

 

4 Accepted Solutions

Accepted Solutions

saravlak
Spotlight
Spotlight

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.

 

View solution in original post

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.

-Scott
*** Please rate helpful posts ***

View solution in original post

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.

View solution in original post

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:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-8/AVC_8point8_dg.html#pgfId-81615

 

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 For this reason you never really reach the high bandwidth when using 80 or 160 MHz channels, as you have way to much co-channel interference and noise which will lower the real throughput. Please note, those channel numbers are for the USA, there are various regulations over the world. In some places you only have one 160 MHz channel, or two/three 80 MHz ones. 

View solution in original post

42 Replies 42

marce1000
VIP
VIP

 

                                            > ...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.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !

Do you see any benefits in configuring FlexConnect in a local network?

Personally i do not see any advantage as you mentioned with orginal post.

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

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.

-Scott
*** Please rate helpful posts ***

B A
Level 1
Level 1

Ok. And any other possible advantages?

 

Were auditors wrong?

 

What is your opinion on this in general?

 

                                                 >Were auditors wrong?

 - Because your locally-switched-intranet , these days , is at least 10xfaster then average wireless speeds -> no advantage.

 M.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !

saravlak
Spotlight
Spotlight

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.

 

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.

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.

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...

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.

 

 

saravlak
Spotlight
Spotlight

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

B A
Level 1
Level 1

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.

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.

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: