Back to Blog
Guide10 min

Building an Air-Gapped Network Lab: Real Multi-Vendor Labs With No Cloud

An air-gapped network lab lets you build and test real multi-vendor networks inside a disconnected environment — no cloud, no phone-home. Here are the options, and how to add an AI agent that designs and validates the labs for you, fully offline.

D
David Kim
DevOps Engineer

Search "air-gapped network simulation" and Google returns a wall of cybersecurity glossary pages — Fortinet, IBM, SentinelOne — all explaining the security sense of an air gap: isolating backups or critical systems from the network. None of them answer the question a network engineer is actually asking: how do I build and test a real network lab inside an air-gapped environment?

This guide answers that one. An air-gapped network lab is an emulation environment that runs entirely inside a disconnected network — you build real multi-vendor topologies, run device CLI, and validate changes, and nothing ever leaves your boundary. Below are the realistic options, and how to add an AI agent that designs and validates those labs for you without breaking the air gap.

What an air-gapped network lab is (and isn't)

It is a lab where every layer runs on infrastructure you own, on a network with no path to the internet: the emulator, the device images, the configs, and — if you want AI in the loop — the model. It's what defense, federal, finance, and critical-infrastructure teams need when a security policy forbids sending a running-config to any external service.

It isn't the backup-isolation meaning of "air gap," and it isn't a cloud lab with a VPN. If a single component phones home — a license check, a telemetry beacon, a model API call — it isn't air-gapped.

The options

Self-hosted DIY emulators

ContainerLab, EVE-NG, GNS3, and Cisco CML on owned hardware are all genuinely air-gapped already. That's their real strength: you run them on your own server, behind your perimeter, with no cloud dependency. The cost is that they're entirely manual — you provision the host, source and stage every device image, drag out the topology, and type every line of config by hand. There's no agent and no AI; you are the one building and validating every lab.

An AI-built air-gapped lab

The newer option keeps the air gap and adds an AI agent. NetPilot On-Prem runs the agent on a local LLM you operate (Ollama, vLLM, or Microsoft Foundry Local), connects it to your own ContainerLab host, and lets you describe a network in plain English and get a real, validated multi-vendor lab back — with no cloud and no phone-home. It's the same offline guarantee as the DIY tools, with the agent doing the building.

How to build one with NetPilot On-Prem

NetPilot On-Prem runs across three Linux VMs on the same LAN, and nothing reaches the cloud at runtime:

  • VM-1 — the NetPilot app (frontend, backend, PostgreSQL) as one Podman/Docker Compose stack, installed from a signed offline bundle.
  • VM-2 — your ContainerLab host plus the NetPilot MCP server that exposes the lab to the agent. You stage your own device images here (BYOI).
  • VM-3 — your local LLM (Ollama / vLLM / Foundry Local). You provide and operate it.

Once the three are wired together, the workflow is conversational. Direct CLI is always there too — the agent is the fast path, SSH is how you verify.

A worked example — air-gapped change validation

Say you need to validate a routing change before it touches a disconnected production network. Describe the lab:

"Build a faithful lab of our core: four routers in a ring running OSPF area 0, two edge routers running eBGP to a transit AS, and redistribute OSPF into BGP on the edges. Then show me what happens to reachability if the link between core-1 and core-2 fails."

The agent designs the topology, writes the per-vendor configs, deploys it on your ContainerLab host, injects the link failure, and reports how reachability and the routing tables respond — all on local infrastructure.

Verify by hand on any device:

# On an edge router (FRR): confirm redistribution and the post-failure path
vtysh
show ip route ospf
show ip bgp
show ip route bgp

You can keep iterating — "now add a second transit provider and prefer it for the default route" — and the agent re-validates. The whole loop, including every model inference, stays inside your network.

Keeping it truly air-gapped

Three rules keep the air gap intact:

  1. Install and update from signed offline bundles. Bring the release across your boundary deliberately; nothing should auto-update from the internet.
  2. Bring your own images (BYOI). Stage device images on the ContainerLab host rather than pulling them at runtime. NetPilot never distributes commercial vendor images — FRR and Nokia SR Linux are built in; Cisco, Juniper, Arista, Palo Alto, and Fortinet are bring-your-own.
  3. Run the model locally. A local LLM is what lets the agent exist without a cloud API. Inference stays on the LAN; no prompt or config leaves.

With those in place there is no telemetry and no outbound connectivity at runtime — the defining property of an air-gapped lab.

FAQ

What is an air-gapped network lab?

A network emulation environment that runs entirely inside a disconnected network — you build real multi-vendor topologies and validate changes with no internet and no cloud. It's the networking sense of "air gap," distinct from the backup-isolation security sense.

Can a network lab run fully offline with no cloud?

Yes. ContainerLab, EVE-NG, and GNS3 already run offline on owned hardware. NetPilot On-Prem adds an AI agent that designs, deploys, and validates the labs, driven by a local LLM — with no cloud and no phone-home.

How do you keep a network lab air-gapped?

Install and update from signed offline bundles, bring your own device images, and run the AI model locally so inference never leaves the LAN. NetPilot On-Prem is built this way.

Is this the same as Cisco CML or EVE-NG on-prem?

Those are proven self-hosted emulators, and they're air-gapped too — but manual, with no AI. NetPilot On-Prem adds the agent and the local LLM on top, and runs real multi-vendor NOS via BYOI. Many teams use both.


Copy-paste ready: The change-validation workflow prompt in our example library is the template for the pre-change lab above.

Related reading: On-Prem AI Network Lab is the full deployment; Run an AI Network Engineer on a Local LLM covers the model side; and Self-Hosted ContainerLab + AI covers wiring the agent to your ContainerLab host.

Building inside an air-gapped or disconnected facility? The On-Prem AI Network Lab page covers it end to end — contact sales to scope your deployment.

Try NetPilot Free

Build enterprise-grade network labs in seconds with AI assistance

Get Started Free