In higher education, students, faculty, and staff live and breathe WiFi. So much that network engineers spend most of their time troubleshooting and dealing with tickets related to their wireless networks. The nature of wireless makes monitoring and troubleshooting challenging – engineers have to deal with all the same issues as with wired networks and then some.
Over the past few months, I have had the opportunity to interact with several network engineers in higher education and got to ask them several questions about their wireless networks and how they deal with them. Here are my findings:
Q1: How many network locations do you support?
Many engineers asked us how to define a network location. We wanted to capture what was on their minds as to the number of network sections they had to support so we intentionally didn’t impose a strict definition. For some, a location may be a building, for others, a complex of dorms, and for others still, a satellite campus. This gives us insight into how different engineers and organizations perceive their networks. As you can see, the majority supports more than 50 locations, which can be considered a large and complex network.
Q2: How many troubleshooting tickets do you receive each week?
A network engineer will receive at least one troubleshooting ticket per weekday, with an average or close to 11 per week. This makes it at least two tickets per day and considering that a ticket may take a few hours to resolve, we can derive how much time per day might be spent on troubleshooting wireless.
Q3: When troubleshooting wireless problems, what are some common recurring situations you deal with?
As expected, the root cause is more often on the wireless side than the wired. Something that came as no surprise was that in most case the root cause was related to the end-user’s device. However, we weren’t expecting this to be as high as 84%. Finally, 47% responded that they routinely need to dispatch someone to troubleshoot locally. This becomes even more resource intensive when there are protocols that require IT staff visits at not-public locations (dorms, offices, labs) in pairs. Again, this goes back to how resource intensive it is to troubleshoot issues related to wireless.
Q4: Does your current WiFi monitoring tool provide all information you need for monitoring and troubleshooting?
The answer to this question is good news for network engineers, because it looks like most of them have all the tools they need to monitor and troubleshoot their WiFi. However, it comes in a contrast to the answer in the following and last question.
Q5: If you had information about the wireless end-user experience would you be able to reduce time-to-detection and time-to-repair?
So, although in Question 4 the vast majority of engineers think they generally have all the tools they need to monitor and troubleshoot their network, when we mentioned end-user experience monitoring, an overwhelming 89% admitted that there is room for improvement.
Network engineers that manage large, distributed, and complex networks realize that traditional SNMP tools don’t provide enough information to keep them on top of their game. Packet capturing and netflow tools flood you with a deluge of data, but when it comes to day-to-day monitoring and troubleshooting using them is like hunting a deer with a microscope.
End-user network and application monitoring is gaining momentum not only in wireless monitoring but in the wired space as well. Even more so, in an era when the vast majority of applications run on a datacenter and the network becomes part of the application stack, the user experience depends upon so many factors: the network, the server, the database, the end-user’s device. Monitoring with SNMP or packet-capturing tools is just not enough.
NetBeez adds a layer of end-user monitoring to the network engineer ‘s arsenal. Higher education is a sector that is very sensitive to the quality of wireless performance, since students’ success is compromised if they can’t do their homework, submit their finals, or do their research due to poor connectivity.
If you want to take a close look at NetBeez, sign up for a one-to-one demo here.