While ChannelFly is a truly remarkable technology, I'm wondering if people have found that it's usable in real-world scenarios.
For better or worse, Wi-Fi environments tend to be BYOD almost by definition, so we don't have too much control over what users show up with. And while one could work with people individually to update drivers, or have discussions about "It's not us it's them", the end result, in our experience has been end users saying "your Wi-Fi sucks", which is obviously the opposite of what we're trying to accomplish with a Ruckus deployment. (And according to Tom's Hardware it's supposed to be the other way around). In public Hotspot scenarios we'll never even hear from people whose connections didn't work, they just won't come back....
So I'm looking for guidance here from both Ruckus and from other VARs/Customers. Have you found that in anything but a completely controlled environment you safely turn on ChannelFly and have a high success rate with end users? If not, do you see this changing over time?
Either way it seems like it might be a good idea for Ruckus to put a whitepaper out there with this discussion. Customers or new VARs that are deploying this for the first time who end up with ChannelFly on by default are going to get an extremely negative first impression of Ruckus, which is really too bad because the technology overall is truly remarkable, but this one checkbox, in our experience, can change the overall experience dramatically.
Jeff
For better or worse, Wi-Fi environments tend to be BYOD almost by definition, so we don't have too much control over what users show up with. And while one could work with people individually to update drivers, or have discussions about "It's not us it's them", the end result, in our experience has been end users saying "your Wi-Fi sucks", which is obviously the opposite of what we're trying to accomplish with a Ruckus deployment. (And according to Tom's Hardware it's supposed to be the other way around). In public Hotspot scenarios we'll never even hear from people whose connections didn't work, they just won't come back....
So I'm looking for guidance here from both Ruckus and from other VARs/Customers. Have you found that in anything but a completely controlled environment you safely turn on ChannelFly and have a high success rate with end users? If not, do you see this changing over time?
Either way it seems like it might be a good idea for Ruckus to put a whitepaper out there with this discussion. Customers or new VARs that are deploying this for the first time who end up with ChannelFly on by default are going to get an extremely negative first impression of Ruckus, which is really too bad because the technology overall is truly remarkable, but this one checkbox, in our experience, can change the overall experience dramatically.
Jeff
Posted 6 years ago
Primož Marinšek, AlphaDog
Bill Burns, AlphaDog
I use this command on syslogged traffic to see AP channel-change events.
fgrep -C0 -i -e interference -e "switch from channel"
Often what I see is an individual AP hopping back and forth between channels.
I do not use channelfly and I still have issues with APs changing channels. (due to "interference")
I have about 66 APs and I see 14 AP channel changes so far today. (between 4:30am and 1:50pm)
As far as I can tell, the Ruckus controller is not consulted and/or not very aware of where the APs are in relation to each other.
If it was, I'd prefer the controller to come up w/ a reasonable channel-plan and only make changes when the wireless environment changes significantly.
(When new APs show up or disappear)
Instead, whether ChannelFly is enabled or not, APs seem to make these channel-hopping decisions on their own, without regard to what the other APs on the controller are doing.
ChannelFly changes can be made in response to relatively short-term bandwidth usage changes. (like a large video download)
This results in unstable channel assignments where one APs channel change can trigger a channel change in an adjacent AP and in turn, that AP's channel change can trigger a change in the next AP, and the next.
(if anyone has a different understanding of this, please let me know)
I already hard-coded channel assignments in 8 APs in one building to cut down on this.
Once I turned on channel-fly (for a few hours) and the number of AP channel changes became ridiculous.
I did not get any end-user compaints but (as Keith points out) this is no proof that problems did not result.
Ruckus says this should calm down after a day, or a few days.
IMHO: ChannelFly is more of a "carrier" type feature, useful in metro-wifi deployments, or in known "dirty" wifi environments where you'd expect to be competing w/ other wireless APs, where momentary client outages are expected/reasonable, and having your APs pick non-standard wifi channels is a reasonable strategy.
In a "cleaner" "corporate" "enterprise" type environment, ChannelFly seems undesirable.
Speaking of metrics... I did a search on keith's name and "metrics" and got no significant results.
Also, I talked to a few resellers before making my Ruckus purchase re: some way (any way) to get an objective measure of how Ruckus wifi performed in my environment vs how the existing cisco stuff performed.
Other than the "you should try a whole bunch of clients at the same time" style of stress test I got no useful feedback.
(for example, how do I *know* that an auditorium full of clients is working or not when I *know* I can't count on any of them bothering to report a problem?)
If anyone has suggestions re: gathering metrics for Ruckus, cisco or other wifi networks, please let me know.
-Bill
fgrep -C0 -i -e interference -e "switch from channel"
Often what I see is an individual AP hopping back and forth between channels.
I do not use channelfly and I still have issues with APs changing channels. (due to "interference")
I have about 66 APs and I see 14 AP channel changes so far today. (between 4:30am and 1:50pm)
As far as I can tell, the Ruckus controller is not consulted and/or not very aware of where the APs are in relation to each other.
If it was, I'd prefer the controller to come up w/ a reasonable channel-plan and only make changes when the wireless environment changes significantly.
(When new APs show up or disappear)
Instead, whether ChannelFly is enabled or not, APs seem to make these channel-hopping decisions on their own, without regard to what the other APs on the controller are doing.
ChannelFly changes can be made in response to relatively short-term bandwidth usage changes. (like a large video download)
This results in unstable channel assignments where one APs channel change can trigger a channel change in an adjacent AP and in turn, that AP's channel change can trigger a change in the next AP, and the next.
(if anyone has a different understanding of this, please let me know)
I already hard-coded channel assignments in 8 APs in one building to cut down on this.
Once I turned on channel-fly (for a few hours) and the number of AP channel changes became ridiculous.
I did not get any end-user compaints but (as Keith points out) this is no proof that problems did not result.
Ruckus says this should calm down after a day, or a few days.
IMHO: ChannelFly is more of a "carrier" type feature, useful in metro-wifi deployments, or in known "dirty" wifi environments where you'd expect to be competing w/ other wireless APs, where momentary client outages are expected/reasonable, and having your APs pick non-standard wifi channels is a reasonable strategy.
In a "cleaner" "corporate" "enterprise" type environment, ChannelFly seems undesirable.
Speaking of metrics... I did a search on keith's name and "metrics" and got no significant results.
Also, I talked to a few resellers before making my Ruckus purchase re: some way (any way) to get an objective measure of how Ruckus wifi performed in my environment vs how the existing cisco stuff performed.
Other than the "you should try a whole bunch of clients at the same time" style of stress test I got no useful feedback.
(for example, how do I *know* that an auditorium full of clients is working or not when I *know* I can't count on any of them bothering to report a problem?)
If anyone has suggestions re: gathering metrics for Ruckus, cisco or other wifi networks, please let me know.
-Bill
Urgh? "Speaking of metrics... I did a search on keith's name and "metrics" and got no significant results. "
I'm 1.9 meters tall for the record.
I'm 1.9 meters tall for the record.
Bill Burns, AlphaDog
I was searching "Keith Parsons", but thanks for the initial data point.
When comparing to other manufacturers, should I prefer wireless reps who are taller or shorter than 1.9 meters?
When comparing to other manufacturers, should I prefer wireless reps who are taller or shorter than 1.9 meters?
I think you want: http://www.wlanpros.com/wi-fi-stress-...
(Further to the record I am slightly taller than the other Keith..but he is much wiser)
(Further to the record I am slightly taller than the other Keith..but he is much wiser)
Bill Burns, AlphaDog
Thanks for the link.
That's useful info. (which I've seen before)
But, as-per the doc:
"This test is NOT the best possible way to evaluate access points"
"This is a simple test"
"This isn’t reflective of real-world"
Did one of my posts get lost here?...
Let me try to reconstruct it:
What I'm really looking for (re: metrics) is something that will tell me how *my* wifi network is working.
I gather a lot of data, but actionable results are hard to come by.
Ideally (when I was comparing products and asking resellers about this) I would have found a tool that provided information like:
how many clients are associated, how many clients are trying to associate (but can't), how many clients are sleeping/power-saving/not-talking, how many clients are working well, how many clients are getting poor throughput/performance.
Bonus points for protocol or spectrum analysis that was correlated to these things.
Ideally, I'd be able to take a 3rd party tool like this, test w/ one set of AP gear, then test w/ another set of AP gear, compare results and then make a purchasing decision.
I'm pretty sure I'd have given my business to whatever reseller could have provided an objective testing method like this.
(as opposed to the "why don't you test with a lot of clients" kind of stress test)
I hear that wireless intrusion prevention tools may provide some of these features, but I have no specific info.
(and would like to hear more about it if anyone has this knowledge)
Now that I'm post-purchasing-decision, I'd still like to gather information to monitor the health+performance of my network because I know I can't count on my users to report wifi problems.
That's useful info. (which I've seen before)
But, as-per the doc:
"This test is NOT the best possible way to evaluate access points"
"This is a simple test"
"This isn’t reflective of real-world"
Did one of my posts get lost here?...
Let me try to reconstruct it:
What I'm really looking for (re: metrics) is something that will tell me how *my* wifi network is working.
I gather a lot of data, but actionable results are hard to come by.
Ideally (when I was comparing products and asking resellers about this) I would have found a tool that provided information like:
how many clients are associated, how many clients are trying to associate (but can't), how many clients are sleeping/power-saving/not-talking, how many clients are working well, how many clients are getting poor throughput/performance.
Bonus points for protocol or spectrum analysis that was correlated to these things.
Ideally, I'd be able to take a 3rd party tool like this, test w/ one set of AP gear, then test w/ another set of AP gear, compare results and then make a purchasing decision.
I'm pretty sure I'd have given my business to whatever reseller could have provided an objective testing method like this.
(as opposed to the "why don't you test with a lot of clients" kind of stress test)
I hear that wireless intrusion prevention tools may provide some of these features, but I have no specific info.
(and would like to hear more about it if anyone has this knowledge)
Now that I'm post-purchasing-decision, I'd still like to gather information to monitor the health+performance of my network because I know I can't count on my users to report wifi problems.
Unfortunately, I'm not sure any sort of predictive analysis is possible.... no matter what you capture during testing the air space won't be a constant and so there's no way to exactly simulate during a test what will happen druing live scenarios. Unless it's a high security installation where people check all RF devices at the door, there's no way to predict what will the air will look like one day to the next in terms of people showing up with MiFi AP's, Bluetooth, etc.. Or when everyone in the room will suddenly turns their ipad sideways because the presenter asks them too.... And then there's the variable of Mac/Win driver versions and ios/android versions... each of these is going to change hour by hour, forever. And of course in the process, Heisenberg's Uncertainty Principle kicks in: by the very act of poling individual devices or installing log capture agents you're modifying the environment so you're still not capturing what would have been happening if you weren't monitoring.
But more importantly, I don't think it would really be possible to even do a definitive ongoing analysis of the environment. it would require an agent on every device to capture both client and AP side logs and/or SNMP data and then to cross-reference them which would be impractical in all but the most controlled environments.
In my experience in a variety of different environments, WiFi has become very much an Art+Science endeavor again. The best we've been able to do is do extensive testing during installation to confirm throughput (ruckus ios tool works well for this). Post install we regularly look for clients with poor RSSI/SNR or to ensure that we've got sufficient coverage over the noise floor where the clients are operating.
Ruckus has posted a detailed SNMP monitoring best practices document, but we haven't spent too much time investigating this yet. Syslog parsing would be interesting, but there's currently a bug/feature that spams the syslog with cluster events, so that's tough to do. Hoping that gets fixed someday. (Right now there's a funny tech note that says if you don't want 25,000 messages per hour telling you the cluster is OK, just set the log level to critical only so you don't see error messages https://support.ruckuswireless.com/an... ).
All this being said, we've been EXTREMELY successful with well configured Ruckus gear. Where other vendor's solutions have left end users with constant frustration, post Ruckus deployment the wireless just works.
But more importantly, I don't think it would really be possible to even do a definitive ongoing analysis of the environment. it would require an agent on every device to capture both client and AP side logs and/or SNMP data and then to cross-reference them which would be impractical in all but the most controlled environments.
In my experience in a variety of different environments, WiFi has become very much an Art+Science endeavor again. The best we've been able to do is do extensive testing during installation to confirm throughput (ruckus ios tool works well for this). Post install we regularly look for clients with poor RSSI/SNR or to ensure that we've got sufficient coverage over the noise floor where the clients are operating.
Ruckus has posted a detailed SNMP monitoring best practices document, but we haven't spent too much time investigating this yet. Syslog parsing would be interesting, but there's currently a bug/feature that spams the syslog with cluster events, so that's tough to do. Hoping that gets fixed someday. (Right now there's a funny tech note that says if you don't want 25,000 messages per hour telling you the cluster is OK, just set the log level to critical only so you don't see error messages https://support.ruckuswireless.com/an... ).
All this being said, we've been EXTREMELY successful with well configured Ruckus gear. Where other vendor's solutions have left end users with constant frustration, post Ruckus deployment the wireless just works.
Bill Burns, AlphaDog
re: predictive analysys:
That's not what I'm looking for.
I want point-in-time analysis, either by SNMP/syslog or by way of some external tool. An external tool could be a wifi sniffer type device, and/or something that analyzes traffic coming through the wired ports the APs are connected to.
re: RSSI
Unless there's been a very recent update, the reported "RSSI" values are actually SNR values, which hoses-up geo-location if you're expecting real RSSI.
(maybe that's what you were referring to by "RSSI/SNR"?)
re: SNMP best practices:
Huh? What?
I'm not aware of an SNMP best practices document.
Is this included in some other document?
Please send me a link if you have one.
I've been using the scripts here:
https://github.com/bot779
to gather SNMP data and analyze logs.
ruckus-zdroamers (reads syslog data, takes a long time to run) and shows me what devices are roaming the most.
There's certainly a large volume of syslog messages, but aside from having to wait for results, I haven't found that to be an issue.
If I first specify an individual client or AP for analysis, the results appear very quickly.
getruckus (uses snmp) and shows me what clients are associated to what APs.
I schedule this via cron to log the number of clients I have per AP over time.
ruckusconf and buildclientos.txt
automated the downloading of arbitrary ruckus command output and builds a list of client MAC addresses, showing the operating system running on each client.
The ruckus wifi situation here is relatively good (judging by user feedback) but I'm still chasing methods to "prove" that's the case since I can never count on users giving adequate feedback.
(example being an auditorium of 200 to 300 ppl w/ flakey pre-ruckus wifi but no "complaints")
That's not what I'm looking for.
I want point-in-time analysis, either by SNMP/syslog or by way of some external tool. An external tool could be a wifi sniffer type device, and/or something that analyzes traffic coming through the wired ports the APs are connected to.
re: RSSI
Unless there's been a very recent update, the reported "RSSI" values are actually SNR values, which hoses-up geo-location if you're expecting real RSSI.
(maybe that's what you were referring to by "RSSI/SNR"?)
re: SNMP best practices:
Huh? What?
I'm not aware of an SNMP best practices document.
Is this included in some other document?
Please send me a link if you have one.
I've been using the scripts here:
https://github.com/bot779
to gather SNMP data and analyze logs.
ruckus-zdroamers (reads syslog data, takes a long time to run) and shows me what devices are roaming the most.
There's certainly a large volume of syslog messages, but aside from having to wait for results, I haven't found that to be an issue.
If I first specify an individual client or AP for analysis, the results appear very quickly.
getruckus (uses snmp) and shows me what clients are associated to what APs.
I schedule this via cron to log the number of clients I have per AP over time.
ruckusconf and buildclientos.txt
automated the downloading of arbitrary ruckus command output and builds a list of client MAC addresses, showing the operating system running on each client.
The ruckus wifi situation here is relatively good (judging by user feedback) but I'm still chasing methods to "prove" that's the case since I can never count on users giving adequate feedback.
(example being an auditorium of 200 to 300 ppl w/ flakey pre-ruckus wifi but no "complaints")
GT Hill, Employee
Primož Marinšek, AlphaDog
For 24/7 network monitoring and performance I would suggest you check this out
http://www.7signal.com/
http://www.7signal.com/
Bill Burns, AlphaDog
I opened another question here:
https://forums.ruckuswireless.com/ruc...
Please add whatever experiences you have with 7signal there.
Thanks.
https://forums.ruckuswireless.com/ruc...
Please add whatever experiences you have with 7signal there.
Thanks.
There may be a "best of both worlds" opportunity in that 9.7 adds a feature to have ChannelFly take effect when the AP first boots and then shut down after n minutes (user selectable). See below
Monnat Systems, AlphaDog
there should be something similar for standalone AP's too...
I use this option for a while like Keith suggested with good results. I use 1 hour
I cannot find the "Turn off channelfly if APs uptime is more...." option in 9.8.2.0 build 15
Anyone?
Anyone?
Max O'Driscoll, AlphaDog
In ZD GUI Configure, Acess Points, Access Point Groups...choose group, edit...18th item is ChannelFly setting.
Bill Burns, AlphaDog
I'm wondering if some of this behavior is hardware dependent. I've found recently that the 7363's seem to completely ignore the mtbc command. This is a big deal in standalone units since you can't turn channelfly off. We run into this when we're doing 1 or 2 AP's in very small SMB installs or executive residential installs where a ZD isn't practical.
Is there a CLI equivalent for the turn off after x minutes in the standalone AP's? If so I'll give it a try.
Is there a CLI equivalent for the turn off after x minutes in the standalone AP's? If so I'll give it a try.
Doesn't look like there's a CLI equivalent. Are you running the latest release? You can assign static channels - which has the effect of turning ChannelFly off.
