The idea behind UNetLab v2 was partly good, but some choices complicated the implementation and negatively impacted system performance. Specifically, managing UNetLab’s network in user space would have caused serious problems, even though it would have made horizontal scalability easier.

Moreover, I had a significant doubt: does it make sense to implement a virtualization system today when several are maintained by companies far better than I could manage? Initially, I considered ESXi , but after the Broadcom acquisition , I leaned towards Proxmox . While ESXi would have required abandoning physical link simulation, Proxmox allows using the same strategy I used with UNetLab.

Using an existing hypervisor significantly simplifies development at the cost of a substantial sacrifice: unsupported systems like IOL and Dynamips would no longer be supported. While this isn’t a big issue for Dynamips, IOL has always been my preferred system for creating lightweight labs.

UNetLab v3 Wishlist

I should divide the list into functional and non-functional requirements, but for now, let’s compile a sort of wishlist together.

In my mind, a hypothetical UNetLab v3 wishlist includes:

• Free, open-source, community-driven
• Ability to easily share labs, template repositories, playbooks
• Support for Ansible, Nornir, NAPALM, Netmiko playbooks
• Unified but focus on network and security labs
• Multi-user, multi-tenant, multi-role (e.g., student/teacher)
• Easy scalability
• API-first approach, with CLI and web interface

Lab Features:

• Each lab is isolated by default.
• Labs can be interconnected.
• Labs can be shared between users.
• A management network is deployed per lab.
• Management network is hidden in topology.
• Management network is reachable by all nodes.
• A DHCP server is deployed per lab.
• An Internet gateway can be deployed per lab.
• A fake internet gateway can be deployed.
• Labs are described by a human-readable YAML file.
• Labs could contain an inventory compatible with Ansible.
• Imported labs should allow selecting alternative templates if the existing ones are not available.
• Labs could be signed by users.
• Live changes (jitter, delay, interface up/down) should immediately reflect in the running lab.
• Marketplace: A place where users and teachers can share labs and learning paths.
• Automation: All relevant nodes within a lab should be reachable by automation software by default.
• Packet capture: Users should be able to capture packets from any specific interface.
• Scale-out: Labs could be run on multiple computing nodes.

Continue reading the post on Patreon .