by Jörg Wiebusch
After the first blog entry, I thought to myself, how can it continue? What interesting topics could be tackled next? The contribution regarding the performance in the WLAN was of course also influenced by our last company event or rather “inspired”. Especially the point of performance and motorsport were of course a very good combination. That’s why I would like to create a connection again now and would like to build on the topic of performance. Performance in WLAN was the goal in the last post. What performance is and how to achieve it.
Now, however, I would like to show that it is not only important to achieve the performance in the WLAN, but also to maintain it, to monitor it and, in case of doubt, to detect problems or impairments as quickly as possible and, of course, to eliminate them afterwards (as soon as possible). After all, what good is it to use the latest components or to have perfect planning if this is only seen as a snapshot and cannot be used in the long term? ? Parts of this or both are a very good basis for a really high-performance WLAN system.
I tried to explain all this in a hopefully not entirely unfunny way. Now let’s see if I can do the same with this topic. However, I would like to go a little further for this, because the topic is not highly complex or technical, but I would like to briefly show my view on the topic of monitoring, management and also troubleshooting and analysis. Because a great planning and also a top design are an excellent base,… but,…!
No gizmo in sight
There´s a “but” lying in the air. There is always an obstacle or problem. A sporadic event or source of interference. The pilots in World War II had a term for it: “Gremlin”. The name was coined by the British writer Roald Dahl. No, before the question comes,… no Gizmo, no water and no feeding after midnight.
These “real”, nasty gremlins appear from time to time and cause strange phenomena in technical systems. But why do I come across Gremlins? In the case of WLAN infrastructures, I would even agree with the definition. Gremlins are small invisible goblins who enjoy sabotaging technical systems. Matches Wi-Fi. Not visible, not tangible, incomprehensible and above all very difficult to find.
So! So first of all, I realize and accept that gremlins can exist in any WLAN system. But what to do when these little gremlins strike? Let’s keep in mind, we have a cleanly planned Wi-Fi, latest components, a good design and a correct configuration of the systems. Rounded off with a reasonable management system, WLAN controller or similar. The systems can show me that I have an access point failure, a client is using the wrong key, or critical systems have generally failed. This is really not bad and actually higly recommended for most companies today. Very few administrators today have the time or the technical possibility to get to the bottom of every possible or sporadic error. And even if a state-of-the-art Wi-Fi 6 WLAN infrastructure with centralized management and monitoring exists, the time and distance factor must still be added. What happens if you manage an international network or have implemented a nationwide network a little smaller? The company headquarters may be located in Munich, Berlin or Hamburg,…
And the Gremlin,… ? It strikes in Cologne, London or Paris. What then? In any case, it takes hours until a technician is on site and can carry out possible measurements and tests. Even if an administrator were to leave immediately or even fly, the time difference between the occurrence of the error and the first analyses on site is quite large.
Now in return you can say that with central management and monitoring you already have many analysis options. Of course, these technologies can be used to read out error logs of the access points or, to a certain extent, perhaps even to determine signal strengths and perhaps even to carry out packet or frame analyses. The whole thing may even be possible with a certain forensics – back in time – mostly with cloud systems that provide relatively unlimited storage for it (compared to local systems).
The needle in the haystack
All of these are really good ways to narrow down errors. Far more than just a few years ago. The level of automation, analytics, and level of detail of the data provided by these sophisticated controllers and cloud systems is now very high. However, this complexity also leads to a new situation.
At the beginning of the “Wi-Fi age”, in a galaxy, far, far… uh, in the early 2000s, Wi-Fi was a topic for RF engineers, professors, etc. A short time later, the first devices were on the market, which allowed a relatively simple configuration: “WEP key, channel, SSID, ready – o.k. also add an IP addresses, etc.” But, this configuration very quickly became “very simple” (or at least in the eyes of many). At that time, the possibilities for analysis were also limited. Often, in the event of errors, a new or additional access point was simply installed. The end device is replaced or the error is explained as incompatibility. Do I hear,… “Gremlin”???
Meanwhile, the analysis possibilities in the current systems are very well developed. The systems issue simplified messages or direct recommendations for action. For experts with in-depth knowledge, these systems offer a deeper look into the WLAN protocol level. Thus, we have again reached the point that specialists are again necessary to master this quite complex system in integration or error analyses.
But why these remarks? That’s exactly what you want. Systems that can analyze errors independently, make recommendations and thus make the life of an administrator and also the WLAN expert easier. But…. I already said, strange mistakes, sporadic mistakes,… . (Gremlin….. 😊 )?
The other side of the coin
However, all these possibilities unfortunately do not take into account some small important points. Each of these systems is usually not able to see the “other side”. Hardly any of these systems monitor the WLAN from the client’s point of view. Some of these systems offer the possibility of an “AP test”. This is intended to give the infrastructure the opportunity to “transform” an access point into a client in the event of a fault, for the purpose of troubleshooting, and to test the infrastructure.
However, this method also has disadvantages. The “testing” access point cannot serve a “normal” client at this time, since it is itself a “client”.
Systems that work in this way are therefore also called “integrated monitoring/sensoring/WIPS system”, as the function is integrated into the infrastructure components. The access points record and analyze the WLAN traffic that they process and forward. However, these systems also have the disadvantage that they cannot permanently monitor the WLAN. The main function of these devices is and remains to transport data from the wireless client to the network and vice versa. Thus, such integrated systems can only become aware of errors if they occur during data transport or in the so-called off-channel scans (in the short phases – while the access point is not occupied).
An alternative are so-called “overlay” systems. These systems work with stand-alone sensors that have no direct connection to the actual infrastructure. Again, there are advantages and disadvantages with these systems. The advantage is that these systems can permanently monitor the medium WLAN. However, they cannot “see” and analyze the traffic that is transmitted in the infrastructure. On the one hand, I can monitor 100% of the time, but only a very small proportion of the delivered data traffic. While the integrated systems can usually analyze 100% of the datatraffic, but only a small part of the frequency band.
One point can definitely be certified in both variants. Both systems are extremely helpful in finding and analyzing errors. And from my point of view, especially with distributed systems, it is actually highly recommended if you do not have any personnel on site.
The new Gremlin Trap
But of course I don’t just want to reproduce well-known things and advertise or explain them again. It’s also about looking at new things and perhaps showing new possibilities. We were recently offered the opportunity to test a new variant of an overlay system. The manufacturer has provided us with components of his new solution to take them to an in-depth test. At first you could say why this is something special and why should you write so much about it. In general, the sensors and functions are a cloud-based system. As already stated in advance, cloud-based systems are very well suited, as the analysis functions promise the great advantage thanks to (attention buzzwords) big data and AI functions in all cloud systems.
But what makes this thing special now compared to other systems? Why is it worth taking a closer look at this system? I would like to say right away, this system also “cooks only with water” and is not a “gremlin detector”. However, after this in-depth test, there are some points that impressed me and gave rise to this article. It creates a completely new transparency for the real performance and the processes within the infrastructure to be monitored or analyzed.
I have already presented integrated and overlay systems. In principle these sensors are also such an overlay system. The disadvantage of such a system is usually that it cannot “look” into the data. And this is the difference to the systems of other manufacturers. In principle, it can do everything that a “normal” monitoring system does. The sensors monitor the frequency band for interference and anomalies. It reports as soon as problems occur, and of course, reporting and forensics are also integrated thanks to the cloud.
However, there is a small difference with this particular system. The sensors also act as a client. It is possible to provide them with the appropriate credentials or pre-shared keys to actively connect to the WiFi System as a client. This makes the real difference to conventional monitoring systems. The sensor sees the WLAN from the client’s point of view. I can define performance measurements that show me latencies and availability of critical services, measure and report them in the event of an error.
I want to know if a MS Teams call is reliably possible? Is DNS working properly? What about roaming or spectral analysis? These tests are possible thanks to the “client view”. And even the packet trace (header analysis) is available through the connection (on a wireless level) with the infrastructure as a troubleshooting and analysis function.
Thus, with the solution I have an overlay system, but still the functions that I normally only find within an integrated solution. Due to this view of the system (from the client side), we saw a decisive advantage over most systems on the market after testing the components. Most manufacturer systems can either monitor the spectrum as an overlay system or look into the data stream as an integrated solution. However, the integrates system is only possible with the components of the same manufacturer and does not work with third-party systems.
This is the decisive advantage of the solution. Due to the integration into the WLAN infrastructure as a client, it can be integrated manufacturer-independent and flexible used. Exactly this manufacturer-independent approach is interesting. Perhaps or precisely because we as Wireless.Consulting also want to present this manufacturer-independent solution approach.
With such a sensor technology and monitoring function, it is definitely possible to take a very comprehensive look at any WLAN infrastructure after the first tests. Whether alone, or perhaps even paired with good management (central controller or cloud solution), the hunt for the little gremlins on everyone is easier or at least much more effective. This solution can be used permanently or temporarily. Either as permanent additional monitoring or as a temporary solution for sporadically passing by small technology monsters. This can be perfectly combined with a monitored remote error analysis. A technician who monitors one or more sensors in a problematic area during defined periods of time and thus limits the error. This means that our colleagues are much better able to carry out a remote error analysis. It cannot absolutely prevent an appointment on site from becoming necessary, but it helps with these sporadic mistakes that otherwise have to be searched for for weeks. Thus, I can close the circle between the high-performance WLAN and the preservation of the performance.
With these means, a professional WLAN technician is provided with professional tools to improve error analysis or monitoring of infrastructures. It creates greater transparency of the processes “on site” and within the monitored infrastructure.
Autonomous access points, old device generationsof WLAN components or even state-of-the-art systems can benefit from this. No matter what kind of infrastructure you may have,… such an overlay monitoring system can always be integrated on top. But this one combines the view of the infrastructure with that of the client and currently has a unique selling point (from my point of view), since I am currently not aware of any other system, especially in simplicity of the connection. Perhaps more important is an additional factor, especially for temporary installations and failure analyses, this system is self-sufficient and not connected to the company’s infrastructure. Not in such a way that it has to be integrated into networks / VLANs with further authorizations. It is not embedded in the management level of the network infrastructure and therefore there is no risk that company-owned components can be attacked or hacked.
All this helps us to get the little gremlins off your neck. Give us a call,…
*Funny, why did I get a picture with three guys and an old ambulance in my head,… *😊