We are happy to share with you a customer use case for Wireless Network Monitoring from the Client perspective.
Recently our team received word that several clients in a classroom where disconnecting while doing online benchmark tests. The clients will rename nameless but were of the “lower end” variety. These clients were single band 802.11n devices which have had a bad track record of reliability, no matter what the wireless environment has been. In this particular case, there were roughly 20 of these devices deployed in a classroom each with its own 2nd grader. We had been called to this classroom previously but found no issue with the network. Our laptops had performed flawlessly while accessing the same websites and never had trouble with being disconnected from the network unlike our “lower end” counterparts. Checking the controller showed no issues with channel utilization, retries, or a configuration issue. Sometimes a simple “it’s not the network” isn’t good enough and this was one of those times. We needed data, and we needed it from a client’s perspective.
Wireless network monitoring from the client perspective
We use our Netbeez agents a little bit differently. Most of the time our agents stay on a shelf near my desk waiting to be deployed rather than in a permanent location. We have one agent on constant watch of our datacenter monitoring core equipment and top of rack switches, while the rest await a mission. When we received word of the above-mentioned classroom having trouble we decided to deploy an agent to do some monitoring. We try to place the agent as close to the normal client operating area as possible. I spoke with the teacher and explained what we were doing and what we were leaving behind to monitor. Once the agent was deployed I asked the teacher which online applications and websites she uses on a regular basis. I configured agent tests to the websites and online applications that she gave me and applied it to my newly deployed agent.
I made sure the agent was online and the tests were reporting successful. I also configured the agent to do speedtests every 10 minutes to local servers so I could have a good idea of throughput to the internet. For good measure I also configured an iPerf test from the agent in the classroom to the permanently deployed Beez in our datacenter. I thought having both internet throughput data as well as internal throughput data would be good for comparison.
I monitored the data from the deployed Beez for several days. The teacher continued reporting issues with the “lower end” clients all while the Beez agent had no trouble and maintained a 100% uptime.
All configured tests proved successful during the duration of our monitoring. The tests and resulting data proved that the wireless network was not the problem.
Complementing data from wireless controllers
The data that we can gather from our wireless controller is good data, but you can’t argue with the data from a client’s perspective. A lot of times “wireless trouble” is reported during a very specific time or the “issue” is sporadic. We can deploy a Beez to a classroom and leave it to be monitored until the necessary data is gathered. That may be a few hours or maybe a weeks time. Obviously, we can’t be onsite the whole time so being able to deploy a Beez whenever we need to is very beneficial to us.