Testing Zyxel vs Ubiquiti Access Points
When you choose something for yourself - you try to choose the best (preferably not very expensive, of course, but something good). And you try to choose it yourself. No one can take his word for it - only personal experience, testing and testing. And, truly, you can sometimes get amazing results, it would seem, from quite ordinary things. Amazing both in a bad and in a good way.
This article describes a part of the comparative testing of two access points, which were selected for specific cases. Anyone who is interested - Wellcome under the cat.
Point models: Zyxel NWA1123-AC PRO and Ubiquiti UniFi AP AC PRO
Both points are from the same price range and are designed for solving the same tasks.
For auxiliary equipment, which was used in the tests:
The iperf server is a regular desktop computer with a gigabit network card. Nothing special.
The wi-fi client is the second hp probook 430 g4 laptop. With wi-fi module able in 5GHz.
Router - c9 arcer.
')
The test bench topology is as simple as possible:
Everything that comes into our hands, we run through the standard protocol. We have certain developments on which we rely. Some items vary from one TK to another, but the main functionality remains practically unchanged regardless of the task. There are critical points, the lack of which immediately puts an end to the use of such devices on the network (for example, if there is no ssh or snmp), but there are optional items, the presence of which will be in the plus of the device when summing up the results of testing. For example, the presence of the console port. There is - well, no - well, I didn’t really want to.
Some items will be commonplace, but, unfortunately, they really have to check. Not once or twice there were devices for which the specification claims to support this or that functionality and these checkboxes of settings are even present in the webcam, but do not work.
For example, traffic prioritization. You turn on the necessary tick in the settings, you start to collect packets with a traffic analyzer, and in them, in fact, nothing has changed in the headers. Sadly
In this case, both points did a great job. There are no complaints, and the whole basis of the functionality that was required was implemented. Even somehow boring. This is not a low-pick segment, where you can see the “segmentation fault” from nslookup (yes, there are some places like this).
After checking the main functionality, it would not be bad to find something interesting. It is necessary to check not only the presence of a specific functionality, but also the absence of "unnecessary".
Run by nmap at both points:
At both points, ssh is open, which is good. On Ubiquiti, only ssh is nothing superfluous. Only hardcore. On Zyxel - ftp, ssh, http (standard set) and something unknown on 40713 / tcp.
As it turned out later, this is a centralized service for managing access points (not only them, but also other available equipment) through the Nebula cloud. In general, I liked even more than the web of the point itself. A few screenshots to understand approximately (the scale on the first one was specially greatly reduced so that everything would fit):
The default login and password for Zyxel is not specified anywhere on the point itself, so they simply used the jellyfish (standard utility for brut in Kali linux). We received a login / password pair - 'admin / 1234', and from Ubiquiti we already know the standard log-logs in the form of 'ubnt / ubnt'.
It turned out that at this Ubiquiti point there is no web server. Totally. Management only through the controller and a special utility. The folder / www is just empty and nothing is spinning on port 80/8080. But here at least the standard busybox (and quite free on commands), unlike Zyxel. There is a step to the left, a step to the right - execution.
We walked through both points with a vulnerability scanner (Nessus). He did not show anything supercritical. Below are the results and a detailed description of what is found.
192.168.0.196 - Zyxel
192.168.0.126 - Ubiquiti
Ubiquiti:
One and not critical. Consider nothing found.
Zyxel:
Here it is more interesting, if briefly: the use of the old unsafe versions of SSL and the standard public snmp community, which in the settings you are invited to immediately change, at startup.
First, let's look at the network around. Watch only on 5 GHz band. For scanning, I used Acrylic, The points themselves were included one by one, so as not to interfere with each other. Plus, for the purity of the experiment, turned off another router adapter.
As a result, later, I had to conduct more tests, but in a different, more peaceful place, because In the first case, around someone's corporate network was deployed from just a huge number of points on a very wide range of channels (it can be seen on the screens below, many did not fit).
Traffic chased iperf'om, in 5 streams. At first I tested for 60 minutes, but then I realized that it was not quite informative and left the load for 4 hours.
What came out of it below in the spoilers:
Maximum value: 300 Mbps (rests on this ceiling and no longer issues)
The minimum value: 228 Mbps
Average value: 296.5 Mbit / s
C - stability. Good smooth connection at all times. There are short-term drawdowns, but they are minor.
Statistics for the time of work:
(CPU yellow, blue - memory + traffic)
Maximum value: 584 Mbps
The minimum value: 324 Mbit / s
Average value: 426 Mbit / s
But the CPU load was a little surprised:
At the time of the test start, the download jumped to 91%. I didn’t notice any particular problems when using the point: the point didn’t heat up, the webcam didn’t lag, there were no packet losses.
The test was for the maximum possible performance and, despite the fact that it is not quite a standard situation, when a huge amount of traffic is driven through for a long period of time, we have such a case. (Access to servers with a large amount of data for “mobile” clients) I believe that the test was successfully passed. In any case, the question was asked to support Zyxel and are currently negotiating on this situation.
CPU / Memory statistics:
Having summed up the interim result, I can say that the Zyxel point looks more attractive in terms of use for the tasks we needed. With a relatively identical function, the choice will always be for stability over a long period of time and, of course, performance.
Unfortunately, it is impossible to completely cover everything with laboratory tests, to emulate all possible situations that can occur in production and to foresee everything. Therefore, further, both points, necessarily, are waiting for field testing in networks as close as possible to the combat conditions.
This article describes a part of the comparative testing of two access points, which were selected for specific cases. Anyone who is interested - Wellcome under the cat.
Point models: Zyxel NWA1123-AC PRO and Ubiquiti UniFi AP AC PRO
Both points are from the same price range and are designed for solving the same tasks.
For auxiliary equipment, which was used in the tests:
The iperf server is a regular desktop computer with a gigabit network card. Nothing special.
The wi-fi client is the second hp probook 430 g4 laptop. With wi-fi module able in 5GHz.
Router - c9 arcer.
')
The test bench topology is as simple as possible:
Functional testing
Everything that comes into our hands, we run through the standard protocol. We have certain developments on which we rely. Some items vary from one TK to another, but the main functionality remains practically unchanged regardless of the task. There are critical points, the lack of which immediately puts an end to the use of such devices on the network (for example, if there is no ssh or snmp), but there are optional items, the presence of which will be in the plus of the device when summing up the results of testing. For example, the presence of the console port. There is - well, no - well, I didn’t really want to.
By the way about the console
At the Zyxel point, access to the console port is on the case.
This is undoubtedly a plus. On Ubiquiti, the console port is in the same place as the majority of manufacturers (which is absolutely not surprising - many people do this, but they don’t even have legs here):
You can separately arrange a holivar on the topic that: “on a normal device, access to the console port should not be needed in principle”, but I tend to think that it will not be better, than, suddenly, it will be needed and it is not there ( just like with contraception).
This is undoubtedly a plus. On Ubiquiti, the console port is in the same place as the majority of manufacturers (which is absolutely not surprising - many people do this, but they don’t even have legs here):
You can separately arrange a holivar on the topic that: “on a normal device, access to the console port should not be needed in principle”, but I tend to think that it will not be better, than, suddenly, it will be needed and it is not there ( just like with contraception).
Some items will be commonplace, but, unfortunately, they really have to check. Not once or twice there were devices for which the specification claims to support this or that functionality and these checkboxes of settings are even present in the webcam, but do not work.
For example, traffic prioritization. You turn on the necessary tick in the settings, you start to collect packets with a traffic analyzer, and in them, in fact, nothing has changed in the headers. Sadly
In this case, both points did a great job. There are no complaints, and the whole basis of the functionality that was required was implemented. Even somehow boring. This is not a low-pick segment, where you can see the “segmentation fault” from nslookup (yes, there are some places like this).
Functional list
1. Support multi-SSID. The ability to raise at least two networks with different SSID + the ability to raise a hidden network.
2. Support 802.11i (security, support AES encryption).
3. Support 802.11q (the ability to transfer tagged traffic).
3. Support Vlana management.
4. The ability to change the signal strength of the radio transmitter.
5. Support for QOS and 802.1p (the ability to prioritize traffic).
6. Ability to limit the maximum number of clients connected to the access point.
7. Point management via telnet / ssh / webGUI.
8.Support monitoring and control of the access point by snmp.
9. The ability to work points in a centralized / offline mode.
10. Support LLDP discovery.
11. The presence of a point in the internal log of system events and the ability to send logs to a remote server.
12. The presence of an internal traffic analyzer at the point (optional and optional, but present at both points).
13. The presence of a spectrum analyzer and the ability of the access point to detect other points working next to it.
2. Support 802.11i (security, support AES encryption).
3. Support 802.11q (the ability to transfer tagged traffic).
3. Support Vlana management.
4. The ability to change the signal strength of the radio transmitter.
5. Support for QOS and 802.1p (the ability to prioritize traffic).
6. Ability to limit the maximum number of clients connected to the access point.
7. Point management via telnet / ssh / webGUI.
8.Support monitoring and control of the access point by snmp.
9. The ability to work points in a centralized / offline mode.
10. Support LLDP discovery.
11. The presence of a point in the internal log of system events and the ability to send logs to a remote server.
12. The presence of an internal traffic analyzer at the point (optional and optional, but present at both points).
13. The presence of a spectrum analyzer and the ability of the access point to detect other points working next to it.
After checking the main functionality, it would not be bad to find something interesting. It is necessary to check not only the presence of a specific functionality, but also the absence of "unnecessary".
Run by nmap at both points:
Ubiquiti
Zyxel
Here the 21st open port for ftp did not hit the screen.
Here the 21st open port for ftp did not hit the screen.
At both points, ssh is open, which is good. On Ubiquiti, only ssh is nothing superfluous. Only hardcore. On Zyxel - ftp, ssh, http (standard set) and something unknown on 40713 / tcp.
As it turned out later, this is a centralized service for managing access points (not only them, but also other available equipment) through the Nebula cloud. In general, I liked even more than the web of the point itself. A few screenshots to understand approximately (the scale on the first one was specially greatly reduced so that everything would fit):
The default login and password for Zyxel is not specified anywhere on the point itself, so they simply used the jellyfish (standard utility for brut in Kali linux). We received a login / password pair - 'admin / 1234', and from Ubiquiti we already know the standard log-logs in the form of 'ubnt / ubnt'.
It turned out that at this Ubiquiti point there is no web server. Totally. Management only through the controller and a special utility. The folder / www is just empty and nothing is spinning on port 80/8080. But here at least the standard busybox (and quite free on commands), unlike Zyxel. There is a step to the left, a step to the right - execution.
We walked through both points with a vulnerability scanner (Nessus). He did not show anything supercritical. Below are the results and a detailed description of what is found.
192.168.0.196 - Zyxel
192.168.0.126 - Ubiquiti
Ubiquiti:
One and not critical. Consider nothing found.
Zyxel:
Here it is more interesting, if briefly: the use of the old unsafe versions of SSL and the standard public snmp community, which in the settings you are invited to immediately change, at startup.
tyk
- The remote service accepts connections encrypted using SSL 2.0 and / or SSL 3.0. These versions of SSL are affected by several cryptographic errors.
- The X.509 server certificate cannot be trusted. The X.509 certificate chain for this service is not signed by a recognized certificate authority. If the remote host is a public host, this negates the use of SSL, since anyone can set up a man-in-the-middle attack against the remote host.
- The remote host has IP forwarding enabled. An attacker could use this to route packets through the host and potentially bypass some firewalls / routers / NAC filtering.
- Default snmp community (public).
- The SNMP daemon responds with a large amount of data to a “GETBULK” request with a more than normal value for “max-repetitions”. A remote attacker can use this SNMP server to conduct a deployed distributed denial of service attack on an arbitrary remote host.
Stress Testing
First, let's look at the network around. Watch only on 5 GHz band. For scanning, I used Acrylic, The points themselves were included one by one, so as not to interfere with each other. Plus, for the purity of the experiment, turned off another router adapter.
As a result, later, I had to conduct more tests, but in a different, more peaceful place, because In the first case, around someone's corporate network was deployed from just a huge number of points on a very wide range of channels (it can be seen on the screens below, many did not fit).
Traffic chased iperf'om, in 5 streams. At first I tested for 60 minutes, but then I realized that it was not quite informative and left the load for 4 hours.
What came out of it below in the spoilers:
Ubiquiti
Maximum value: 300 Mbps (rests on this ceiling and no longer issues)
The minimum value: 228 Mbps
Average value: 296.5 Mbit / s
C - stability. Good smooth connection at all times. There are short-term drawdowns, but they are minor.
Statistics for the time of work:
(CPU yellow, blue - memory + traffic)
Zyxel
Maximum value: 584 Mbps
The minimum value: 324 Mbit / s
Average value: 426 Mbit / s
But the CPU load was a little surprised:
At the time of the test start, the download jumped to 91%. I didn’t notice any particular problems when using the point: the point didn’t heat up, the webcam didn’t lag, there were no packet losses.
The test was for the maximum possible performance and, despite the fact that it is not quite a standard situation, when a huge amount of traffic is driven through for a long period of time, we have such a case. (Access to servers with a large amount of data for “mobile” clients) I believe that the test was successfully passed. In any case, the question was asked to support Zyxel and are currently negotiating on this situation.
CPU / Memory statistics:
Results
Having summed up the interim result, I can say that the Zyxel point looks more attractive in terms of use for the tasks we needed. With a relatively identical function, the choice will always be for stability over a long period of time and, of course, performance.
Unfortunately, it is impossible to completely cover everything with laboratory tests, to emulate all possible situations that can occur in production and to foresee everything. Therefore, further, both points, necessarily, are waiting for field testing in networks as close as possible to the combat conditions.
Source: https://habr.com/ru/post/427581/
All Articles