Netlab’s architecture represents a fundamental shift from traditional network lab tools. While most solutions focus on graphical interfaces or vendor-specific approaches, Netlab follows a modular, provider-agnostic design that treats network infrastructure as code. This architectural decision brings software development best practices directly into network engineering, creating a more scalable and maintainable approach to lab management.
At its core, Netlab operates on three fundamental layers that work seamlessly together to transform simple YAML descriptions into fully functional network topologies. This separation of concerns ensures that network engineers can focus on what they want to test rather than getting bogged down in the implementation details of how to configure each device.
The configuration layer represents Netlab’s user-facing interface, using declarative YAML syntax to define network topologies in a human-readable format. This approach eliminates the need for network engineers to understand the intricacies of different virtualization platforms or remember vendor-specific command syntax. Instead, you describe your desired network state, and Netlab handles the rest.
Consider this example of a multi-vendor OSPF lab:
# Simple topology of 3 connected routers
provider: clab
defaults.device: eos
defaults.devices.eos.clab.image: ceos:4.29.9.1M
nodes:
- router1
- router2
- router3
module: [ ospf ]
links:
# P2P links forming triangle topology
- router1-router2
- router3-router1
- router2-router3This seemingly simple configuration file creates a simple OSPF topology with automatic area assignments and neighbor relationships. The beauty lies in its simplicity – what would traditionally require hours of manual configuration across different vendor platforms becomes a few lines of readable YAML. Network engineers can version control these files, share them with colleagues, and reproduce identical environments consistently.
The transformation engine serves as Netlab’s brain, orchestrating the complex process of converting abstract topology descriptions into concrete network implementations. This layer performs the heavy lifting that traditionally consumed hours of manual work. The engine intelligently assigns IP addresses using configurable address pools, ensuring no conflicts while maintaining logical addressing schemes that make sense for your specific topology.
As in the example below, the netlab up command generates configuration files and starts the lab.
netlab #> netlab up
┌──────────────────────────────────────────────────────────────────────────────────┐
│ CREATING configuration files │
└──────────────────────────────────────────────────────────────────────────────────┘
[CREATED] provider configuration file: clab.yml
[CREATED] transformed topology dump in YAML format in netlab.snapshot.yml
[GROUPS] group_vars for all
[GROUPS] group_vars for modules
[GROUPS] group_vars for eos
[HOSTS] host_vars for router1
[HOSTS] host_vars for router2
[HOSTS] host_vars for router3
[CREATED] minimized Ansible inventory hosts.yml
[CREATED] Ansible configuration file: ansible.cfgBeyond basic connectivity, the transformation engine generates vendor-specific configurations tailored to each device type in your topology. Whether you’re working with Cisco IOS, Arista EOS, or Juniper Junos, the Netlab architecture understands the nuances of each platform and produces appropriate configurations. It simultaneously creates provider-specific deployment files, whether that’s Docker Compose for containerized environments or Vagrant configurations for virtual machines.
Perhaps most importantly, the transformation engine handles protocol-specific requirements through Netlab’s module system. When you specify OSPF in your topology, the engine doesn’t just enable the protocol – it configures areas, sets up neighbor relationships, and handles the vendor-specific syntax differences automatically.
The provider integration layer represents Netlab’s flexibility in deployment options. Rather than locking you into a specific virtualization platform, this layer provides seamless integration with multiple providers. You can use ContainerLab for lightweight, containerized network devices when you need quick deployment and efficient resource usage. For more traditional approaches, Vagrant integration with VirtualBox or VMware provides full virtual machine environments that more closely mirror production hardware.
Docker integration offers another lightweight option particularly suited for CI/CD pipelines and automated testing scenarios. For organizations embracing cloud-native approaches, Kubernetes integration enables testing at scale within container orchestration platforms. This provider flexibility means you can choose the right tool for each specific testing scenario without learning entirely new lab management approaches.
One of the most time-consuming aspects of traditional network lab setup involves IP address planning and assignment. Network engineers typically spend considerable time calculating subnets, avoiding conflicts, and ensuring logical addressing schemes. Netlab’s automatic IP addressing completely eliminates this tedious process while maintaining intelligent addressing conventions that make sense for network professionals. (IP addressing can be adjusted manually when needed.)
The system automatically assigns /30 subnets to point-to-point links, ensuring efficient address utilization while following industry best practices. LAN segments receive appropriate /24 networks that provide sufficient host addresses for testing scenarios. Loopback addresses are assigned from dedicated pools, maintaining consistency across the topology while avoiding conflicts with link addressing. Below we have an interface output from router2.
router2#sh ip int br
Address
Interface IP Address Status Protocol MTU Owner
----------------- ------------------------ ------------ -------------- ----------- -------
Ethernet1 10.1.0.2/30 up up 1500
Ethernet2 10.1.0.9/30 up up 1500
Loopback0 10.0.0.2/32 up up 65535
Management0 192.168.121.102/24 up up 1500What makes this particularly powerful is the flexibility to override defaults when needed. If your testing scenario requires specific addressing schemes to match production environments, you can easily specify custom addressing while still benefiting from automatic assignment for the remainder of your topology. Imagine deploying a 10-device topology and having it fully addressed in seconds, with zero IP conflicts and logical addressing that follows your organizational standards.
The modular protocol architecture represents Netlab’s most sophisticated feature, transforming complex protocol configuration into simple YAML declarations. This system understands not just the basic protocol mechanics, but also the nuanced differences in how various vendors implement these protocols.
For routing protocols, Netlab provides comprehensive support that goes beyond basic enablement. OSPF implementation includes multi-area support with automatic area assignments based on your topology structure. The intelligent Netlab architecture determines area boundaries and configures appropriate area types, including backbone areas and stub areas where appropriate. BGP support encompasses the full spectrum of implementations, including iBGP mesh configurations, eBGP peering relationships, and complex route reflector hierarchies that mirror real-world service provider environments.
The example below demonstrates routing table output with visible OSPF and Connected routes.
router2#sh ip ro
VRF: default
*** OUTPUT OMMITED ***
Gateway of last resort is not set
O 10.0.0.1/32 [110/20] via 10.1.0.1, Ethernet1
C 10.0.0.2/32 is directly connected, Loopback0
O 10.0.0.3/32 [110/20] via 10.1.0.10, Ethernet2
C 10.1.0.0/30 is directly connected, Ethernet1
O 10.1.0.4/30 [110/20] via 10.1.0.1, Ethernet1
via 10.1.0.10, Ethernet2
C 10.1.0.8/30 is directly connected, Ethernet2The advanced features extend into modern networking technologies that are increasingly important in today’s networks. MPLS support includes both LDP and RSVP-TE implementations, allowing for comprehensive service provider lab scenarios. VRF configuration enables multi-tenant testing environments that mirror cloud and enterprise deployments. VLAN and VXLAN support addresses the growing importance of data center technologies, while SR-MPLS implementations provide access to cutting-edge segment routing capabilities.
Perhaps the most remarkable aspect of Netlab’s architecture is its vendor abstraction layer, which handles the complex differences between network device implementations transparently. This feature addresses one of the most frustrating aspects of multi-vendor environments – the need to understand and configure different syntax for identical functionality across vendors.
Consider this example topology:
# Same config works across all vendors
nodes:
cisco: { device: iosv }
arista: { device: eos }
juniper: { device: vsrx }
module: [ ospf, bgp ]
This single configuration file results in each device receiving vendor-appropriate configurations automatically. The Cisco device gets IOS-style OSPF and BGP configurations with familiar syntax and conventions. The Arista device receives EOS-formatted configurations that take advantage of its Linux-based architecture. The Juniper device gets properly formatted Junos configurations with the hierarchical structure that Juniper engineers expect.
This abstraction extends beyond simple syntax differences to handle fundamental architectural differences between vendors. For example, when configuring BGP, the system understands that Cisco devices typically use router-id auto-assignment differently than Juniper devices, and it handles these nuances automatically while ensuring consistent behavior across the topology.
Understanding how Netlab compares to established network lab tools helps clarify when to choose each solution. Each tool has evolved to address specific needs in the network engineering community, and the choice often depends on your particular use case, organizational requirements, and technical preferences.
EVE-NG has established itself as a popular choice for network labs, particularly among engineers who prefer graphical interfaces and comprehensive device emulation. EVE-NG provides a comprehensive GUI with intuitive drag-and-drop topology building that appeals to visual learners and those who prefer immediate graphical feedback. The platform offers extensive device image support, covering virtually every major network vendor and many specialized appliances. Built-in console access and packet capture capabilities make it particularly attractive for detailed troubleshooting and protocol analysis.
However, EVE-NG’s traditional approach reveals limitations in modern network automation contexts. The platform requires manual IP addressing and configuration for every device, which becomes increasingly time-consuming as topologies grow in complexity. More importantly, EVE-NG lacks native version control capabilities for topologies, making it difficult to track changes, collaborate with team members, or maintain consistent lab environments across different deployments. The limited automation capabilities mean that repetitive tasks remain manual, and licensing costs for advanced features can become significant for larger organizations.
Netlab addresses these limitations with its infrastructure-as-code approach that treats network topologies as versioned, shareable code artifacts. The automatic configuration generation eliminates hours of manual setup work, while vendor-agnostic topology definitions ensure consistency across different device types. Perhaps most importantly, Netlab’s free and open-source nature removes licensing barriers that might limit adoption or scaling.
GNS3 represents one of the oldest and most established network simulation platforms, with a mature ecosystem and large community that has developed extensive resources and documentation. The platform provides excellent device emulation accuracy, particularly for Cisco devices, and integrates seamlessly with Wireshark for detailed packet analysis. The visual topology designer appeals to engineers who prefer graphical network design tools.
Despite these strengths, GNS3 faces challenges in modern network environments. The platform can be resource-intensive for large topologies, often requiring significant CPU and memory resources that limit the size and complexity of testable networks. Setup and maintenance complexity increases with topology size, and the lack of built-in configuration automation means that engineers still spend considerable time on manual device configuration. Topology sharing typically requires manual export and import processes that don’t integrate well with modern development workflows.
Netlab’s lightweight and efficient resource usage allows for larger topologies on the same hardware. YAML-based topologies integrate naturally with Git workflows, enabling seamless sharing and collaboration. Automatic protocol configuration dramatically reduces setup time, while provider flexibility allows you to choose the most appropriate virtualization platform for each specific use case.
Cisco Modeling Labs represents the official Cisco approach to network simulation, providing authentic device behavior and professional support that appeals to organizations heavily invested in Cisco technologies. The platform includes a REST API for programmatic access, enabling integration with automation tools and custom applications. Professional support and comprehensive documentation provide enterprise-grade reliability and assistance.
However, CML’s expensive licensing model, starting at $199 per year for basic functionality, can be prohibitive for individual engineers, small teams, or organizations with budget constraints. The platform remains primarily Cisco-focused, with limited multi-vendor support that restricts its usefulness in heterogeneous network environments. Complex setup requirements for non-Cisco environments and resource-heavy deployment requirements can limit accessibility and scalability.
Netlab’s cost-effective open-source model eliminates licensing barriers while providing true multi-vendor support across all major network vendors. Simpler deployment with minimal system requirements makes it accessible to a broader range of users, while community-driven development ensures rapid feature additions and responsiveness to user needs.
Understanding Netlab’s internal architecture provides insight into why it performs so effectively and how it achieves its remarkable flexibility. The architecture follows software engineering best practices, with clear separation of concerns and modular design that enables extensibility and maintainability.
The configuration processing pipeline represents a sophisticated multi-stage transformation that converts simple YAML descriptions into fully configured network topologies. This process begins with YAML parsing, where Netlab validates your topology file against its schema, catching syntax errors and configuration inconsistencies before any deployment begins. This early validation prevents the frustration of discovering configuration errors after partial deployment.
Node expansion follows, where devices are enhanced with default attributes based on their types and the specified provider. This stage ensures that every device has complete configuration information, filling in defaults for unspecified attributes while preserving any explicit customizations. Link processing analyzes the connections between devices, applying intelligent IP addressing algorithms and ensuring that interface types match between connected devices.
Module integration represents one of the most sophisticated aspects of the pipeline. Protocol modules inject their specific configurations based on the topology structure and device capabilities. For example, when OSPF is enabled, the module analyzes the topology to determine appropriate area assignments, identifies backbone routers, and configures area border routers automatically.
Provider translation converts the abstract topology into provider-specific deployment files. Whether you’re using ContainerLab, Vagrant, or Docker, this stage generates the appropriate configuration files for your chosen platform. Finally, device configuration produces vendor-specific configurations that are ready for deployment to actual devices.
Netlab’s module system follows a plugin architecture that promotes extensibility and maintainability. Each module implements a standard interface that allows it to participate in the configuration generation process while maintaining independence from other modules. This design enables complex protocol interactions while keeping the codebase manageable.
# Simplified module structure
class OSPFModule:
def process_node(self, node):
# Add OSPF-specific node attributes
def process_link(self, link):
# Configure OSPF on link interfaces
def generate_config(self, node):
# Create vendor-specific OSPF config
This modular approach allows for custom module development when you need to support proprietary protocols or vendor-specific features not yet included in the core distribution. The clear interface definition makes it straightforward to contribute new modules back to the community or maintain private modules for organization-specific requirements.
The provider integration framework ensures consistent behavior across different virtualization platforms while accommodating the unique characteristics of each provider. Each provider implements a standard interface that includes validation to check if the required provider tools are available on the system, deployment methods to create the lab infrastructure, configuration application to apply device configurations, and cleanup procedures to tear down the lab environment cleanly.
This standardization means that switching between providers requires minimal changes to your topology files, primarily just changing the provider specification. The framework handles the complexities of different deployment models, whether that’s Docker containers, virtual machines, or cloud instances, while presenting a consistent interface to users.
Override default behaviors with custom Jinja2 templates:
# Use custom OSPF template
defaults.devices.eos.config: [ ospf-custom.j2 ]
Run the same topology across different providers:
# Test with containers
netlab up --provider clab
# Verify with VMs
netlab down
netlab up --provider virtualbox
Netlab’s command-line interface enables automated testing:
# GitHub Actions example
- name: Deploy test topology
run: netlab up
- name: Run network tests
run: ansible-playbook validate-network.yml
- name: Cleanup
run: netlab down
Choose Netlab when you need:
Consider alternatives when you need:
# Install Netlab
pip3 install networklab
# Verify installation
netlab --version
# Create first topology
netlab create simple-bgp.yml
netlab up
netlab create: Generate provider-specific filesnetlab up: Deploy the labnetlab down: Destroy the labnetlab collect: Gather device configurationsnetlab validate: Check topology syntax
