Open networking research lab

Build disaggregated SONiC, FRR, and Nokia SR Linux topologies from a plain-English prompt — real CLIs via SSH, no Docker install.

Try It Free

← Network Research Lab

app.netpilot.io

See It in Action

Watch NetPilot build a 5-node FRR mesh running OSPF, deploy it to the cloud, inject random link loss, and run an end-to-end test — all from one plain-English prompt. Real FRR containers, real Linux endpoints, real protocol behavior.

Open-networking research, without the infrastructure tax

9+
network OSes and growing — SR Linux & FRR built in; SONiC via enterprise
6
FRR protocols in one prompt (BGP, OSPF, IS-IS, Babel, EVPN, SRv6)
~2 min
from prompt to a deployed multi-NOS lab

What makes NetPilot different for open-networking research

Containerlab is the open-source substrate engineers already reach for to emulate SONiC, FRR, and SR Linux. NetPilot is the cloud + AI layer on top — AI-generated open-NOS configs, browser-hosted topologies, and one-shot deployment, with no Docker install and no YAML to author.

Cloud-native

Browser only. Nothing to install.

The alternative

Local SONiC/FRR: Docker host, vrnetlab image pipeline, sonic-vs sourcing, namespace plumbing — hours before the first node boots.

AI-designed

Describe any topology in plain English — AI designs, configures, and deploys it; SSH in to verify.

The alternative

Hand-author Containerlab YAML, frr.conf fragments, and SONiC config_db per node — per-NOS syntax, by hand.

Multi-turn iteration

“Add an Arista spine, move OSPF to area 0.0.0.1” → AI updates across all devices.

The alternative

Edit YAML + per-node configs, redeploy the lab, re-source images for every change.

2 minutes vs days/weeks

~2 minutes from prompt to working multi-vendor lab.

The alternative

Days to stand up a Docker host + image pipeline, then more to wire a multi-NOS SONiC/FRR/SR Linux fabric.

From prompt to open-NOS lab

Describe the open-networking topology, let the AI build it on Containerlab, then SSH into every NOS — FRR vtysh, SONiC CLI, and SR Linux side by side, all real.

Describe or import the topology

Type it in plain English — “SR Linux spine, FRR and SONiC-VS leaves, EVPN-VXLAN overlay, Babel mesh on the FRR nodes” — or bring your own custom FRR or commercial NOS images via BYOI; SONiC and other custom NOS images are built for you on the enterprise plan.

app.netpilot.io

AI designs, configs, and deploys on Containerlab

NetPilot generates per-NOS configs — frr.conf fragments, SONiC config_db, SR Linux config — builds the Containerlab topology, and deploys to cloud in ~2 minutes. No Docker install, no YAML to hand-author, no namespace plumbing.

app.netpilot.io

SSH into every NOS — real CLIs

Click any device to SSH into the real CLI. Run vtysh on FRR (show bgp / show babel neighbor), the SONiC CLI on the SONiC-VS leaves, and the SR Linux CLI on the spine — verify cross-implementation route exchange the way an open-networking testbed should. The agent builds; the CLI is your verification layer.

app.netpilot.io

What you can build and model

Open-networking research scenarios across SONiC, FRR, and Nokia SR Linux — disaggregated, multi-protocol topologies on real NOS containers, designed by AI and deployed to the cloud.

Disaggregated white-box fabric

SONiC-VS leaves + Nokia SR Linux spine + FRR — a disaggregated, vendor-neutral fabric on real NOS containers, designed by AI from one prompt.

Cloud SONiC emulator + testbed

Multi-node community SONiC-VS topology with real SONiC CLI via SSH — a cloud SONiC testbed with no Docker host to stand up.

Six-protocol FRR stack

BGP, OSPF, IS-IS, Babel, EVPN, and SRv6 on FRR in a single topology — full vtysh on every node, all from one plain-English prompt.

Multi-vendor SONiC integration

SONiC against Cisco NX-OS, Arista EOS, and Nokia SR Linux — reproduce the cross-vendor route-target, BUM, and anycast-MAC bugs that single-NOS labs hide.

Babel / OSPF mesh under impairment

12-node FRR mesh, tc netem packet loss, Babel vs OSPF convergence captured side by side — a reproducible open-networking research scenario.

EVPN-VXLAN overlay across implementations

SR Linux spine with FRR and SONiC leaves exchanging EVPN routes — cross-implementation overlay behavior on the wire, not in a slide.

Open-NOS security research

BGP parser robustness and malformed-UPDATE injection via Linux + Scapy against FRR and commercial NOSes — multi-vendor DUT, fuzzer of your choice.

Upstream bug reproduction

Build the exact FRR/SONiC scenario, capture config + traces, and share the lab + Containerlab YAML so maintainers rerun it without sourcing images.

A cloud SONiC emulator without the Docker setup

Most teams looking for a SONiC emulator end up at Containerlab + the community SONiC-VS image on a local Docker host — the canonical open-source path, and the right tool when you want everything local. NetPilot is the cloud + AI layer on that same substrate: describe a SONiC topology in plain English and a working multi-node SONiC testbed deploys in ~2 minutes with real SONiC CLI via SSH — no Docker install, no Containerlab YAML to author, no image sourcing.

Run SONiC against FRR, Nokia SR Linux, and commercial NOSes in one disaggregated fabric to reproduce the cross-vendor integration issues that single-NOS labs can't surface. The baseline is the Linux Foundation community SONiC-VS image under the enterprise plan; SONiC and other custom NOS images are built for you on the enterprise plan. Same real NOS containers as a hand-built Containerlab SONiC lab — plus an AI design layer and cloud hosting on top.

Anchor experiment

FRR Babel vs OSPF in a 12-node mesh under 15% packet loss

A canonical open-networking research scenario: two routing protocols, same topology, same loss profile, different convergence and stability characteristics. Describe it in plain English — "12-node mesh, FRR on each node. Experiment A runs Babel; experiment B runs OSPF (single-area). tc netem injects correlated 15% packet loss on 20% of the links. Capture convergence time, route table churn, and adjacency flap frequency per protocol."

NetPilot builds both experiments in ~2 minutes each, wires the impairment, and hands you vtysh access on every node for show babel neighbor, show ip ospf neighbor, and the route tables. The prompt + configs + impairment script become a reusable artifact — share the prompt and another researcher reproduces the exact experiment.

FRR and open-networking lab tools compared

Honest positioning. NetPilot does not try to replace netlab or ContainerLab — they remain the canonical lab-as-code tools for FRR research. NetPilot is the cloud self-serve complement for teams who want prompt-driven iteration + multi-vendor integration without local infrastructure.

AI-built from plain-English prompt
NetPilot
Yes
netlab (ipSpace.net)
No
Self-hosted FRR + Docker
No
ContainerLab FRR templates
No
NVIDIA Air
No
Cloud self-serve (no local setup)
NetPilot
Yes
netlab (ipSpace.net)
self-hosted
Self-hosted FRR + Docker
local
ContainerLab FRR templates
self-hosted
NVIDIA Air
Yes
Multi-vendor with commercial NOS
NetPilot
Yes
netlab (ipSpace.net)
BYOI
Self-hosted FRR + Docker
DIY
ContainerLab FRR templates
BYOI
NVIDIA Air
Cumulus/SONiC only
6-protocol FRR stack (BGP/OSPF/IS-IS/Babel/EVPN/SRv6)
NetPilot
One prompt
netlab (ipSpace.net)
Yes
Self-hosted FRR + Docker
DIY
ContainerLab FRR templates
template-dependent
NVIDIA Air
Cumulus-focused
Setup time (first-time user)
NetPilot
~2 minutes
netlab (ipSpace.net)
Hours (install + provider)
Self-hosted FRR + Docker
Hours (Docker + FRR)
ContainerLab FRR templates
Hours (ContainerLab + images)
NVIDIA Air
~1 hour
Lab-as-code (YAML-based)
NetPilot
Prompt-based
netlab (ipSpace.net)
strong
Self-hosted FRR + Docker
compose files
ContainerLab FRR templates
YAML topo
NVIDIA Air
simulation files
Authoritative content / thought leadership
NetPilot
Prompt library on GitHub
netlab (ipSpace.net)
ipSpace.net
Self-hosted FRR + Docker
scattered
ContainerLab FRR templates
srl-labs
NVIDIA Air
NVIDIA docs

Cloud complement to self-hosted FRR and netlab

netlab / ipSpace.net wins

  • • Deep lab-as-code — YAML topologies, git-versioned labs
  • • Broadest protocol module library for FRR research
  • • Thought leadership via Ivan Pepelnjak — canonical FRR content
  • • Multi-provider (ContainerLab, Vagrant, libvirt)

NetPilot wins

  • • Zero local setup — cloud-hosted, browser-accessible
  • • AI-built from plain-English prompts, not YAML authoring
  • • Multi-vendor with commercial NOS integration in one lab
  • • Minutes from idea to running lab

Use both. netlab for infrastructure-as-code workflows and the deep content library at blog.ipspace.net. NetPilot for quick multi-node iteration without git-cloning templates or configuring a local provider. The two target different moments in the research workflow.

Use cases for open-networking teams

Four workflows where cloud self-serve + multi-vendor integration matter.

FRR protocol development and testing

Six-protocol FRR stack — BGP, OSPF, IS-IS, Babel, EVPN, SRv6 — in one plain-English prompt. Describe multi-protocol experiments, SSH in via vtysh to inspect bgpd/ospfd/babeld/isisd state, iterate in the cloud. For FRR main-branch or patched FRR research, use BYOI.

FRR cloud lab guide →

SONiC multi-vendor integration

SONiC + Cisco NX-OS + Arista EOS + Nokia SR Linux in one fabric. Reproduce the cross-vendor integration bugs that surface at vendor boundaries — route-target auto-derivation mismatches, BUM replication divergence, anycast MAC handling.

Multi-vendor SONiC walkthrough →

Multi-NOS open-networking labs

FRR interoperating with commercial NOSes, Nokia SR Linux, and community SONiC. Real protocol behavior across implementations — useful for research on cross-implementation edge cases, adjacency behavior, and route exchange semantics that single-NOS labs can't surface.

Network security research on FRR

BGP parser robustness, malformed UPDATE injection via Linux-with-Scapy, public CVE reproduction against FRR and commercial NOSes. The DUT topology is multi-vendor; the fuzzer is your choice.

BGP fuzzing with Scapy →

The six-protocol FRR stack — in one prompt

Most FRR content talks about one protocol at a time. The reality of open-networking research is multi-protocol — a route reflector running BGP, Babel for the mesh, IS-IS for the underlay, EVPN for the overlay, SRv6 for the traffic engineering. Nobody else talks about the full stack in one place.

BGPOSPFIS-ISBabelEVPNSRv6

Describe a mesh. Specify which protocols run where. NetPilot generates the FRR configurations and deploys in ~2 minutes. Real vtysh on every node.

Protocols and NOSes supported

Open-source FRR and Nokia SR Linux ship natively. Commercial NOSes and downstream FRR distributions run under BYOI.

  • FRR: BGP (including BGP-LU, MP-BGP, BGP-LS), OSPF (multi-area), IS-IS (multi-level), Babel, EVPN, SRv6, RIP, PIM
  • SONiC (Linux Foundation community SONiC-VS) — enterprise plan
  • Nokia SR Linux (free, built-in)
  • Cisco IOL / (enterprise) IOS-XR — BYOI
  • Juniper cRPD, Arista cEOS — BYOI
  • Cumulus Linux (NVIDIA), VyOS, DENT — BYOI
  • Linux endpoints with Scapy, tc netem, iperf3
  • Custom FRR builds — BYOI with your container
  • Full vtysh access on every FRR node

Project attribution

NetPilot is an independent commercial platform. FRR is an open-source project under the FRRouting foundation. SONiC is a Linux Foundation community distribution (DENT, similarly, is a Linux Foundation project). Cumulus Linux is owned by NVIDIA. VyOS is an open-source project. NetPilot is not affiliated with any of these projects or their trademark holders.

Bottom line: Containerlab, GNS3/EVE-NG, NVIDIA Air, or NetPilot?

Pick local Containerlab when you need:

  • Fully offline, on a Docker host you own and control
  • You already have a SONiC/FRR/SR Linux image + vrnetlab pipeline
  • CI-driven declarative YAML is central to your workflow
  • NVIDIA Air for Cumulus/SONiC learning; GNS3/EVE-NG for VM-heavy mixed images

Pick NetPilot when you need:

  • A SONiC/FRR/SR Linux lab in ~2 minutes — no Docker install, no YAML authoring
  • AI writes the per-NOS configs and Containerlab topology from plain English
  • Multi-turn iteration across all nodes, plus SSH to every real CLI
  • Cloud-hosted and browser-accessible — no local server to stand up
  • 9+ vendors and growing in one topology, with on-prem available for sensitive research

Verdict:Containerlab is the right open-source substrate for an offline open-NOS lab you own and script from CI — and it is exactly what NetPilot orchestrates under the hood. NetPilot is the cloud + AI layer on top — describe a SONiC, FRR, or SR Linux topology in plain English and get a working testbed in ~2 minutes, with the same real NOS containers and real CLIs via SSH.

Open Networking & FRR FAQ

Scenario-phrased questions from FRR contributors and SONiC developers.

NetPilot runs SONiC as a cloud-hosted SONiC emulator — describe a SONiC topology in plain English and a working multi-node lab deploys in ~2 minutes with real SONiC CLI via SSH, no Docker install and no Containerlab YAML to author. Under the hood it orchestrates Containerlab (the open-source substrate most engineers already recommend for SONiC/FRR/SR Linux), so you get the same real NOS containers plus an AI design layer and cloud hosting on top. The baseline is the Linux Foundation community SONiC-VS image under the enterprise plan; SONiC and other custom NOS images are built for you on the enterprise plan. For a fully local SONiC emulator, plain Containerlab or sonic-vs on your own Docker host is the right tool; NetPilot is the cloud + AI layer for teams that want a SONiC testbed without standing up infrastructure.
Describe it in plain English — for example, 'SR Linux spine, FRR and SONiC-VS leaves, EVPN-VXLAN overlay.' NetPilot generates the per-NOS configs, builds the Containerlab topology, and deploys real SONiC, FRR, and Nokia SR Linux containers in ~2 minutes with SSH into each device. This is the disaggregated, white-box open-networking workflow without local Docker, image sourcing, or namespace plumbing. Nokia SR Linux and FRR are built in; SONiC runs under the enterprise plan with community SONiC-VS as the baseline; commercial NOSes via BYOI.
Yes — SONiC's routing stack is FRR (FRRouting). Its bgpd, ospfd, isisd, and related daemons are the same FRR processes you run in a standalone FRR container, so an FRR lab exercises the exact BGP, OSPF, IS-IS, Babel, EVPN, and SRv6 behavior that powers SONiC. On NetPilot, FRR is built in — build an FRR lab from a plain-English prompt to learn or validate the protocols underneath SONiC, then run a multi-vendor SONiC fabric (community SONiC-VS baseline, under the enterprise plan) when you need SONiC's full dataplane. Same routing substrate, two vantage points.
Describe the topology in plain English — for example, '8-node mesh, each node runs FRR with Babel on eth0, OSPF on eth1, and IS-IS on eth2. tc netem injects 5% packet loss on a subset of links.' NetPilot generates frr.conf fragments per node, deploys the containers in ~2 minutes, and gives you vtysh access to inspect bgpd/ospfd/babeld/isisd state. The six-protocol FRR stack (BGP, OSPF, IS-IS, Babel, EVPN, SRv6) runs out of the box.
Describe it in plain English — for example, 'a 4-router BGP lab on FRRouting: AS 65001-65004 in a full mesh, each advertising a /24, plus an OSPF backbone between two of them.' NetPilot writes the per-node frr.conf, deploys real FRRouting containers in ~2 minutes, and gives you vtysh access to inspect bgpd/ospfd state. It is the FRRouting-on-Docker workflow — NetPilot is a cloud Containerlab GUI on the same open-source substrate — without installing Docker, sourcing the frrouting/frr image, or wiring network namespaces by hand. The whole open-source routing stack (BGP, OSPF, IS-IS, Babel, RIP, PIM) runs out of the box, so a BGP lab, an OSPF lab, or a mixed open source routing lab all start from one prompt.
No — complementary. netlab (from ipSpace.net) is the leading lab-as-code framework for FRR and multi-vendor topologies, with YAML-defined scenarios and deep protocol coverage. Use netlab when you want infrastructure-as-code workflows, git-versioned labs, and the broadest protocol module library. Use NetPilot when you want to iterate in the cloud without git-cloning templates or setting up a local provider. Different workflow shapes; both valuable.
Yes. SONiC + Cisco NX-OS + Arista EOS + Nokia SR Linux in one topology is supported. The three named cross-vendor integration bugs the multi-vendor SONiC blog documents (route-target auto-derivation mismatch, BUM replication divergence, anycast MAC handling) reproduce reliably in NetPilot labs. SONiC runs under the enterprise plan with Linux Foundation community SONiC-VS as the baseline; commercial NOSes (Cisco, Arista) via BYOI.
FRR SRv6 support (including uSID endpoint behaviors) depends on the FRR version in the default container image. NetPilot tracks FRR stable releases; check the current platform documentation for the exact FRR version and supported SRv6 features. For researchers building against the latest FRR main branch, BYOI is available for a custom FRR build.
Yes. Nokia SR Linux is free and built in, and FRR runs natively in every lab, so an SR Linux lab, an FRR lab, and a SONiC testbed can all live in one topology — for example an SR Linux spine with FRR and SONiC leaves exchanging EVPN routes. Describe it in plain English and NetPilot deploys it on real NOS containers in ~2 minutes with SSH access to each device. This is the open-NOS emulator workflow without Docker: no local Containerlab install, no image sourcing, no namespace plumbing.
Self-hosted FRR on Docker is zero-friction for senior engineers and a multi-hour first-run for beginners. NetPilot skips the Docker install, the FRR container version wrangling, the network-namespace plumbing, and the vtysh/config-file dance. Describe the lab in plain English and get a working topology in ~2 minutes. For reproducible local development, keep Docker. For quick multi-node experimentation and sharing, NetPilot is faster.
Yes. NetPilot's FRR image includes babeld. Describe the mesh — for example, '12-node mesh with FRR Babel, tc netem for progressive packet loss, capture convergence per loss rate' — and the lab deploys in minutes. No local server, no Docker, no containerlab install. Babel-specific vtysh commands (show babel neighbor, show babel route) work on every node.
Cumulus Linux (now owned by NVIDIA) is supported via BYOI with your NVIDIA licensing. VyOS is supported similarly for users with licensed images. For the open-source FRR-based distributions, FRR itself runs natively in every NetPilot lab — if your research is fundamentally about FRR protocol behavior, you don't need to BYOI a downstream distribution.
NetPilot tracks FRR stable releases in its default image; the exact version is documented in the platform reference. For researchers needing the latest FRR main branch, patched FRR builds, or custom FRR features not yet upstream, BYOI is available — upload your own FRR image and use it in any lab.
Yes. NetPilot's enterprise plan includes a self-hosted / on-prem deployment for open-networking research projects (SONiC, DASH, distributed systems) running on internal or consortium infrastructure. Cloud-hosted is the default self-serve; on-prem is available via Contact Sales.
No. NetPilot is an independent commercial platform that uses FRR (open source) and SONiC (Linux Foundation community distribution) as two of its supported NOSes. NetPilot is not affiliated with the FRRouting project, the SONiC community, or the Linux Foundation. The project names FRR and SONiC are trademarks of their respective owners.
Yes. Describe the FRR / SONiC scenario in plain English ("FRR advertising IS-IS level-2 LSP with TLV 135 and level-1 adjacency to a SONiC instance") and NetPilot builds the topology on real FRR + SONiC containers in ~2 minutes. Capture the exact config, packet traces, and command output — share the lab URL + ContainerLab YAML in the upstream issue. Community maintainers can rerun the reproduction without sourcing Docker images themselves, which materially lowers the friction to getting the bug accepted.

Ready to build a disaggregated open-networking lab?

Dedicated environments, custom FRR builds via BYOI, SSO, audit, and workflow integration — talk to us about an open-networking research plan. Or spin up a free lab and run a Babel mesh experiment yourself.

Try It Free