ContainerLab for Network Automation Labs - Part 3: OSPF Topology with Automated Data Collection

ContainerLab for Network Automation Labs – Part 3: OSPF Topology with Automated Data Collection

Milan Zapletal

December 21, 2025

Welcome to the final installment of our comprehensive Containerlab network automation series. In this part, we’ll build a simple lab featuring four routers running simple circular OSPF topology, and we complete it with automated data collection using Nornir. Quick Recap of Our ContainerLab Journey

Before diving into today’s advanced lab, let’s briefly review what we’ve accomplished in this series:

Part 1: Containerlab Foundations introduced us to the basics of ContainerLab installation, simple topology creation, and container networking fundamentals. We learned how ContainerLab revolutionizes network lab creation by using containerized network operating systems.

ContainerLab for Network Automation Labs – Part 1 | Netodata

Learn how to deploy ContainerLab for Network Automation Labs on Google Cloud with nested virtualization for network automation testing. Complete setup guide with modern approaches.

netodata.io

ContainerLab for Network Automation Labs - Part 1 | Netodata

Part 2: NetOps Server and Routing expanded our capabilities by setting up a dedicated NetOps server for automation tasks and implementing advanced routing scenarios between containers. We established the foundation for enterprise-grade network automation workflows.

ContainerLab for Network Automation Labs – Part 2: NetOps Server and Routing | Netodata

Building on our ContainerLab foundation to create a complete network automation environment.

netodata.io

ContainerLab for Network Automation Labs – Part 2: NetOps Server and Routing | Netodata

Today’s Part 3 takes us to the next level with a complex multi-router OSPF topology, complete with automated data collection using Nornir – essential skills for modern network automation engineers.

1. Setting Up Cloud Infrastructure with Google Cloud

Let’s start by launching our lab infrastructure using Google Cloud CLI we prepared in our previous articles. This approach ensures we have sufficient resources for our ContainerLab automation lab.

Starting the ContainerLab and NetOps Server

ShellScript

# Start the NetOps automation server
gcloud compute instances start netops-server

# Start the Containerlab host server
gcloud compute instances start containerlab-server

# Verifying status of GCP instances
gcloud compute instances list
NAME                 ZONE            MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
containerlab-server  us-central1-a   n1-standard-4               10.128.0.5   public_ip     RUNNING
netops               us-central1-a   e2-medium                   10.128.0.4   public_ip     RUNNING

Verifying Infrastructure Connectivity

Ensure both servers can communicate, this should be possible by default:

ShellScript

# Test connectivity between servers
user@netops:~$ ping -c 3 10.128.0.5
PING 10.128.0.5 (10.128.0.5) 56(84) bytes of data.
64 bytes from 10.128.0.5: icmp_seq=1 ttl=64 time=2.02 ms
64 bytes from 10.128.0.5: icmp_seq=2 ttl=64 time=0.312 ms
64 bytes from 10.128.0.5: icmp_seq=3 ttl=64 time=0.291 ms

--- 10.128.0.5 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2019ms
rtt min/avg/max/mdev = 0.291/0.874/2.021/0.810 ms

2. Designing Our Advanced OSPF Lab Topology

Our ContainerLab OSPF topology will consist of four routers (R1-R4) connected in a circular pattern. This design simulates an enterprise network segment.

Network Architecture Overview

4 Arista routers running OSPF Area 0
Circular topology ensuring redundant paths
Automated data collection via Nornir from NetOps server

Creating the Containerlab Configuration

Create the ContainerLab YAML configuration that defines our entire topology:

YAML

name: ospf_lab

topology:
  nodes:
    router1:
      kind: ceos
      image: ceos:4.29.9.1M
      startup-config: router1.cfg
      mgmt-ipv4: 172.20.20.11

    router2:
      kind: ceos
      image: ceos:4.29.9.1M
      startup-config: router2.cfg
      mgmt-ipv4: 172.20.20.12

    router3:
      kind: ceos
      image: ceos:4.29.9.1M
      startup-config: router3.cfg
      mgmt-ipv4: 172.20.20.13

    router4:
      kind: ceos
      image: ceos:4.29.9.1M
      startup-config: router4.cfg
      mgmt-ipv4: 172.20.20.14

  links:
    # Create a ring topology: R1 -- R2 -- R3 -- R4 -- R1
    - endpoints: ["router1:eth1", "router2:eth1"]
    - endpoints: ["router2:eth2", "router3:eth1"]
    - endpoints: ["router3:eth2", "router4:eth1"]
    - endpoints: ["router4:eth2", "router1:eth2"]

We are using traditional approach – building the basic topology with ContainerLab and adding more config for each router with config file. The config file contains:

Authentication
Routing configuration (default route, OSPF)
- default route is important for our NetOps server to lab communication

3. Deploying the OSPF Lab Environment

Now let’s deploy our ContainerLab network automation environment:

Bash

# Deploy the lab topology
containerlab deploy -t ospf-lab.yml

# Verify all containers are running
sudo containerlab inspect -t ospf-lab.yml
╭──────────────────────────┬────────────────┬─────────┬───────────────────╮
│           Name           │   Kind/Image   │  State  │   IPv4/6 Address  │
├──────────────────────────┼────────────────┼─────────┼───────────────────┤
│ clab-arista_ospf-router1 │ ceos           │ running │ 172.20.20.11      │
│                          │ ceos:4.29.9.1M │         │ 3fff:172:20:20::6 │
├──────────────────────────┼────────────────┼─────────┼───────────────────┤
│ clab-arista_ospf-router2 │ ceos           │ running │ 172.20.20.12      │
│                          │ ceos:4.29.9.1M │         │ 3fff:172:20:20::8 │
├──────────────────────────┼────────────────┼─────────┼───────────────────┤
│ clab-arista_ospf-router3 │ ceos           │ running │ 172.20.20.13      │
│                          │ ceos:4.29.9.1M │         │ 3fff:172:20:20::9 │
├──────────────────────────┼────────────────┼─────────┼───────────────────┤
│ clab-arista_ospf-router4 │ ceos           │ running │ 172.20.20.14      │
│                          │ ceos:4.29.9.1M │         │ 3fff:172:20:20::7 │
╰──────────────────────────┴────────────────┴─────────┴───────────────────╯

# Check container status
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
NAMES                      STATUS         PORTS
clab-arista_ospf-router2   Up 6 minutes
clab-arista_ospf-router3   Up 6 minutes
clab-arista_ospf-router4   Up 6 minutes
clab-arista_ospf-router1   Up 6 minutes

4. Implementing Automated Data Collection with Nornir

Before starting the collection straight away, I’d recommend testing connectivity first, you may need to update IPTABLES on the containerlab-server to allow the traffic to 172.20.20.0/24 subnet.

ShellScript

ssh admin@172.20.20.11
(admin@172.20.20.11) Password:
Last login: Wed Jun 11 19:18:21 2025 from 10.128.0.4
router1>

Now comes the exciting part – automated network data collection using Nornir from our NetOps server.

Setting Up the NetOps Environment

Connect to your NetOps server and prepare the automation environment. Keep in mind, that we should already have all our packages on the VM in our netops venv:

ShellScript

# Load netops venv
source /opt/netops/venv/bin/activate

# Clone the Nornir facts repository
git clone https://gitlab.com/netodata/simple-facts.git
cd simple-facts

# Install required dependencies (just in case)
pip3 install -r requirements.txt

Configuring Nornir Inventory, Groups & Defaults

Create the Nornir inventory file for our lab devices:

YAML

#inventory/hosts.yaml
---
router1:
  hostname: 172.20.20.11
  groups:
    - arista_eos
  data:
    container_name: clab-arista_ospf-router1

router2:
  hostname: 172.20.20.12
  groups:
    - arista_eos
  data:
    container_name: clab-arista_ospf-router2

router3:
  hostname: 172.20.20.13
  groups:
    - arista_eos
  data:
    container_name: clab-arista_ospf-router3

router4:
  hostname: 172.20.20.14
  groups:
    - arista_eos
  data:
    container_name: clab-arista_ospf-router4

YAML

#inventory/groups.yaml
---
arista_eos:
  connection_options:
    netmiko:
      platform: arista_eos
      extras:
        global_delay_factor: 2
    napalm:
      platform: eos
  data:
    vendor: arista
    nos: eos
    device_type: router

YAML

#inventory/defaults.yaml
---
username: admin
password: admin
platform: eos
port: 22
data:
  site: ospf-lab

Running Automated Discovery

Execute the Nornir network automation script to collect comprehensive lab data:

ShellScript

# Run the facts collection script inside venv
python3 nornir_facts.py

*** OUTPUT OMMITED ***
^^^^ END Collecting Facts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

✅ Facts collected and saved to /home/milan.zapletal/simple-facts/output/nornir_facts_20250611_193324.json


# Review collected data
ls output/
nornir_facts_20250611_181229.json

# Exploring collection
cat nornir_facts_*.json | jq 'keys[]'
"router1"
"router2"
"router3"
"router4"

cat nornir_facts_*.json | jq '.router1 | keys[]'
"show interfaces"
"show ip interface"
"show lldp neighbors"
"show running-config"
"show version"

# Getting uptime
cat nornir_facts_*.json | jq -r 'to_entries[] | "\(.key): \(.value."show version" | split("\n") | map(select(contains("Uptime"))) | .[0])"'
router1: Uptime: 1 hour and 53 minutes
router2: Uptime: 1 hour and 53 minutes
router3: Uptime: 1 hour and 53 minutes
router4: Uptime: 1 hour and 53 minutes

# Getting version
cat nornir_facts_*.json | jq -r 'to_entries[] | "\(.key): \(.value."show version" | split("\n") | map(select(contains("Software image version"))) | .[0] | split(": ")[1])"'
router1: 4.29.9.1M-38626060.42991M (engineering build)
router2: 4.29.9.1M-38626060.42991M (engineering build)
router3: 4.29.9.1M-38626060.42991M (engineering build)
router4: 4.29.9.1M-38626060.42991M (engineering build)

The script will automatically collect:

Device information (hostname, version, uptime)
Interface details (IP addresses, status)
LLDP neighbors
Running-config

Analyzing Automated Data Collection Results

The Nornir automation script provides valuable insights into our lab environment:

Key Metrics Collected

Network Topology Discovery: Automated LLDP mapping of device interconnections
Interface IP & Status: One time bandwidth usage, error rates, and performance data
Configuration Compliance: Standardization checks can be implemented across all devices

Best Practices for Production Implementation

Scaling Your Containerlab Environment

When implementing containerlab automation labs in production:

Resource Planning: Ensure adequate CPU and memory for larger topologies
Network Segmentation: Use proper VLANs and routing domains
Automation Integration: Connect with CI/CD pipelines for continuous testing
Monitoring Setup: Implement logging and alerting for lab infrastructure

Security Considerations

Access Control: Implement proper authentication for automation scripts
Network Isolation: Separate lab traffic from production networks
Credential Management: Use secure vaults for device passwords
Audit Logging: Track all automation activities for compliance

Troubleshooting Common Issues

Containerlab Deployment Problems

Bash

# Check container logs for issues
sudo docker logs clab-ospf-automation-lab-R1

# Verify network connectivity
sudo containerlab exec -t ospf-lab.yml R1 "show ip interface brief"

# Restart problematic containers
sudo docker restart clab-ospf-automation-lab-R1

OSPF Convergence Issues

Bash

# Clear OSPF processes if needed
sudo containerlab exec -t ospf-lab.yml R1 "clear ip ospf process"

# Check OSPF database consistency
sudo containerlab exec -t ospf-lab.yml R1 "show ip ospf database"

Conclusion and Future Directions

This comprehensive containerlab OSPF lab demonstrates the power of combining containerized network operating systems with modern automation tools. We’ve successfully:

Built a realistic multi-router OSPF topology using Containerlab
Implemented automated data collection with Nornir
Created a foundation for advanced network automation workflows
Established best practices for production deployments

Key Takeaways

Containerlab significantly reduces lab setup time while providing production-like environments
Automated data collection enables rapid network analysis and troubleshooting
Cloud integration offers scalable infrastructure for complex lab scenarios
Modern automation tools like Nornir streamline network operations

Next Steps for Advanced Learning

Explore BGP topologies with ContainerLab for service provider scenarios
Implement network CI/CD pipelines using GitLab and ContainerLab
Advanced Nornir scripting for configuration management and compliance
Integration with network monitoring tools like Prometheus and Grafana

The combination of ContainerLab network automation with modern DevOps practices opens unlimited possibilities for network engineers looking to enhance their automation skills.

Related posts:

Ready to implement your own ContainerLab automation environment? Start with our basic labs and gradually build complexity. The future of network engineering lies in automation, and ContainerLab provides the perfect platform for mastering these essential skills.