Zyxel Nebula vs TP-Link Omada: comparing centralized network management systems

In large corporate networks with a complex topology, the real hell for the administrator will be the sequential configuration of all connected devices, one by one. In such cases, it is often almost impossible to detect errors in the network or determine its state. Software-defined networks do not have this problem: they automatically allow you to control network functions through a central controller and configure homogeneous devices (for example, access points or switches) in batch mode. A single controller can help with network problems and automatically offer a solution, facilitate troubleshooting, and identify incidents.

Once upon a time, the role of control controllers was assigned to individual devices, which was associated with certain difficulties: first, this is another position in the general nomenclature that needs to be installed and maintained, and secondly, any hardware device is more lossy in comparison with software in terms of flexibility and development opportunities. Third, as soon as you have a software controller among several hardware controllers, the uniformity of the control systems is immediately violated , and sooner or later you will change the hardware for software anyway. And then there will be a choice: use a centralized local solution or a cloud solution?

And let's compare: in the left corner of the ring, we have Zyxel with the already elderly and well-honed Nebula cloud orchestration system, and in the right - TP-Link with the new, but very promising Omada SDN system. Two worlds, two ideologies, let there be a battle!

5 reasons to choose a "cloud" controller instead of a local one

• The client has nowhere to install the local: these can be small hotels and facilities with a limited budget, in which there is simply no way to place a car on which the controller would run.
• Your company maintains several objects on the outsource. Moreover, it is not necessary that these are objects of the same customer: you still have a single point of entry to the settings of all networks and all devices, wherever they are located, while maintaining all confidentiality requirements.
• You need to release the responsibility for the operation of the network controller to the vendor under the terms of the SLA or contract.
• It is important for you to reduce the attack surface for the attacker. Yes, here we should not forget that in the case of Zyxel Nebula, you do not spend time and money on the administration of the operating system and the hypervisor on which the controller is installed. The OS will not require an update and will not reboot as it pleases, leaving you without access to the network.
• You need guaranteed security of the management interface as a ready-made service, with certificates and public tests.
  

Of course, customers may have other reasons to choose a ready-made service instead of deploying their own, but the fundamental point will still be the same: unlike TP-Link Omada, the Nebula cloud from Zyxel is not tied to the "Windows", which is always updated and overloaded, and if you need help, you can contact the Nebula administrator. In the case of Omada, the administrator is you, and the most ordinary patterns of behavior can cause the entire network to stop here, which will be discussed later.

4 reasons to choose a local controller instead of a cloud one

• You have paranoid security requirements. In essence, you are afraid that business-class equipment will collect your data and transfer it to the cloud. In this case, you can close the local controller and hardware access to the network, saving the login through the domain, and then update the firmware manually.
• You are afraid that a centralized Firewall will be installed in your country and access to Amazon and Azure servers will be disabled. That is, at the very moment when everything around you will collapse to hell, it is important for you to maintain control over your network.
• You set up a network in the now fashionable Edge direction (read about peripheral computing here), and somewhere "on a distant station", on a cruise ship or in the remote taiga, you simply do not have a permanent connection to the Internet.
• You need to connect the network controller to some local monitoring and analytics services, such as Elasticsearch or Prometheus, and centrally get the metric from the controller, and not from each of the devices.

In practice, if the client requires a local network controller, then he is either afraid of the iron curtain of the "sovereign Internet", or does not want something to go out of his network somewhere, because he does not trust even the vendor.

Hardware support

According to Zyxel, support from Nebula requires such large-scale changes in the firmware code that network equipment has to be developed from scratch, so both they and TP-Link models with software controller support are placed in a separate category.

At the time of writing this article, the network nomenclature with support for software controllers looked like this for the two vendors

Of course, the Zyxel model range is larger in itself, the cloud management system is developed longer, so in the field of nomenclature, it is the undisputed leader. But for some reason, neither one nor the other has 5G/4G routers, and in Edge conditions they would be very useful.

Ease of deployment

Perhaps, both TP-Link and Zyxel have optimized the process of deploying large-scale installations to the limit. At Zyxel, you just need to pick up a mobile phone, and in the NebulaFlex app, scan the QR codes on the cases or even on the boxes with hardware: you can add several pieces of equipment to your organization at once. Moreover, direct scanning of the QR code is always given priority, and if someone has already added the equipment to your account, you can add it to your mobile phone, so always tear off the QR codes from the cases after installation in crowded places. The disadvantage of this algorithm is that you need a working Internet in your network already at the stage of hardware deployment.

With TP-Link, you simply connect the equipment with network cables, and the controller itself finds all the devices in your network, after which you can start setting up. This algorithm has the disadvantage that you can configure the equipment only in the network to which it is connected, that is, if you have two segments, for example 192.168.1.0 and 10.10.10.0, then first connect the controller to the first network and configure the equipment there, and then repeat this step for another network or configure routing between them.

Naturally, some network must already be working to run Omada SDN. Difficulties arise when upgrading several subnets at once: if you have a common controller, then you need to configure access to all networks, for example, by prescribing routing rules or NAT, and this again may conflict with the company's security policy, or even be impossible.

Ease of maintenance

Convenience is a purely individual parameter, so we will conduct simple tests to see how the tasks typical for business applications are solved, and in the first test, TP-Link Omada failed miserably: the controller ignored the firmware update for the test access point TP-Link EAP660 HD, which left a very good impression in our test, and then suddenly immediately failed. I did not think that in 2021, when you no longer know where to hide from updates, something in this world can fail such a simple task, for example, Zyxel Nebula immediately said that there is a new version of Firmware for the access point.

Just above, I said that everyday problems can completely deprive you of the Omada SDN, and this is what happened to me quite by accident - I forgot the administrative password to the Omada interface. It would seem that an ordinary procedure: here at the bottom of the data entry form is a password reset button, I click - and get an error. I do not know how TP-Link was going to send me a link to change my password, because I did not enter the SMTP server anywhere, but linked my ID in the cloud service omada.tplinkcloud.com, which at the time of writing the article, did not work. I couldn't restore it, because the mail settings in the interface are hidden so far away that you wonder: why not force the user to specify them during the initial installation? The first thing that comes to mind in this case is to reinstall the controller, but the truth is that you will have to manually search and clean the places where Omada stores the password or do a complete reinstall of Windows, and this is half the trouble. The fact is that Omada changes the passwords of the connected devices for management, and when you reinstall the controller, you need to know them, and there is nowhere to take them, so you have to take a paper clip in your hand and go to reset the settings of each piece of hardware, which in itself is some kind of HELL. How in this case it is necessary to act according to the author's idea: whether to write to technical support, or to attend to the waste routes in advance-it is not clear.

Yes, there is no doubt-Omada SDN has a more beautiful interface, and if you are used to Ubiquiti products, it will be easier for you to switch to it, and because of its simplicity, this controller is perceived as something clearer and more logical than Zyxel Nebula, but they love these devices not for their beauty, but for their ability to survive when everything around them has died, and here Nebula cloud of course wins.

Logging

Professional sysadmins prefer to store logs of all events on all devices, and forever, but software network controllers are created for a different purpose - so that you can easily monitor the network status in the web interface, and you can analyze and investigate incidents on the side with other software. Therefore, in both Nebula and Omada SDN, you can configure log export to the Syslog server, and in Zyxel, you can set separate servers for access points, switches, and gateways, as well as enable logging of hotspot traffic. Omada SDN has more modest settings in this regard: you have access to a single Syslog server address, but you can save client device logs to it.

In the basic version, Nebula can store logs for 24 hours, in the Plus version-7 days, and in the Pro version-1 year, Omada SDN has no such restrictions, but before hardcore administrators, Zyxel can trump support for SNMP, which will allow monitoring devices connected to Nebula via Prometheus or Zabbix.

Conclusions

Software controllers are the future, and if your project includes at least 2-3 devices, it already makes sense to choose a solution with a software configurator. Because even on small projects for the sake of an access point with a switch, you will not build a monitoring system from Zabbix + Grafana + ElasticSearch, and the built-in interfaces of network devices were stuck somewhere in the late 90s, apparently for good. And of course, with the growth of the project, the appearance of VPN tunnels, the appearance of malfunctions and hacking attempts, it will be all the easier for you, the more convenient and understandable the unified monitoring and management interface will be.

Both Zyxel Nebula and TP-Link Omada SDN solutions are now ready for use in production, both on your customers ' battle networks and on your infrastructure. Zyxel's solution is a little more mature, which is quite understandable, given that Omada is a week away from the year, and Nebula has been developing since 2017. There are not so many fundamental differences between hosting the controller in the cloud and on the local server, but in all cases, except for Edge, the cloud solution is more flexible and lightweight, and we would very much like Omada SDN to launch its cloud part as soon as possible to match its stronger competitor from Zyxel.

Michael Degtyarev (aka LIKE OFF)
11/05.2021