Run vJunos in containerlab: Boot Times and 6 Traps

Q: What is the containerlab kind for vJunos?

juniper_vjunosrouter for vJunos-router and juniper_vjunosswitch for vJunos-switch. Interfaces use Junos names such as ge-0/0/0 in the topology file, and containerlab maps ge-0/0/0 to the container's eth1.

vJunos is the free way to get real Junos into a containerlab topology, and most guides stop at the deploy. The deploy is the easy part. It takes a second. Then comes a boot that takes longer than the docs say, a health check that reads unhealthy for most of it, and a healthy that does not mean ready.

This post covers the build, a two-router lab and the traps, with output from a real run of vJunos-router 26.2R1.7 on containerlab v0.77.0. The lab is in our public juniper-labs repository.

What vJunos is

Juniper's vJunos page offers it "at no cost for non-production test environments only", with no time limit. vJunos-router is "built using vMX as a reference Juniper router", and it shows. Our router reports itself as a vMX:

admin@r2> show version | match "Model|Junos:|Hostname"
Hostname: r2
Model: vmx
Junos: 26.2R1.7
 
admin@r2> show chassis hardware
Hardware inventory:
Item             Version  Part number  Serial number     Description
Chassis                                VM6AE50438F0      VMX
Midplane
Routing Engine 0                                         RE-VMX
CB 0                                                     VMX SCB
FPC 0                     BUILTIN      BUILTIN           Virtual FPC
  CPU            Rev. 1.0 RIOT-LITE    BUILTIN
  MIC 0                                                  Virtual
    PIC 0                 BUILTIN      BUILTIN           Virtual

	vJunos-router	vJunos-switch	vMX
Reference	vMX	EX9214	MX Series
Cost	Free	Free	60-day trial for current customers
Shape	One VM, nested	One VM, nested	Control plane VM plus forwarding plane
Throughput	100 Mbps total	100 Mbps total	Set by license
containerlab kind	`juniper_vjunosrouter`	`juniper_vjunosswitch`	`juniper_vmx`

Each node wants 4 vCPU and 5 GB. Our routers used 5.1 GiB and 3 to 3.5 cores each once they were up.

Build the image

Download the qcow2 from Juniper's page, accept the license there, and build with vrnetlab. The directories moved, so older guides point to the wrong path:

git clone https://github.com/srl-labs/vrnetlab
cd vrnetlab/juniper/vjunosrouter
cp ~/Downloads/vJunos-router-26.2R1.7.qcow2 .
make

Use juniper/vjunosswitch for the switch. The current Makefile also patches the image with AMD SVM flags, so AMD hosts no longer need a separate step. Your host needs /dev/kvm:

$ docker images --format '{{.Repository}}:{{.Tag}} {{.Size}}' | grep -i junos
vrnetlab/juniper_vjunos-router:26.2R1.7 4.54GB

Deploy two routers

name: jncia-lab
topology:
  nodes:
    r1:
      kind: juniper_vjunosrouter
      image: vrnetlab/juniper_vjunos-router:26.2R1.7
      startup-config: r1.txt.partial
    r2:
      kind: juniper_vjunosrouter
      image: vrnetlab/juniper_vjunos-router:26.2R1.7
      startup-config: r2.txt.partial
  links:
    - endpoints: ["r1:ge-0/0/0", "r2:ge-0/0/0"]

The .partial suffix tells containerlab to merge your snippet on top of the default config. The snippet is Junos hierarchy format:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.0.12.1/30;
            }
        }
    }
}

The full lab adds two Linux hosts. Deploy returns almost at once:

$ sudo containerlab deploy -t jncia-practice.clab.yml
│ clab-jncia-lab-r1 │ juniper_vjunosrouter                      │ running            │ 10.189.15.2    │
│                   │ vrnetlab/juniper_vjunos-router:26.2R1.7   │ (health: starting) │ N/A            │

The boot, measured

The docs say 5 to 10 minutes for the router. This is what we measured for two routers on a 16 vCPU cloud VM with nested virtualization, with 29 containers from other labs running beside them:

Elapsed	r2	r1
1.5 min	Docker `unhealthy`	Docker `unhealthy`
18 min	Junos loading modules	Junos loading modules
21 min	`Startup complete`, `healthy`	still `unhealthy`
24 min		`Startup complete`, `healthy`
29 min	SSH works, FPC `Present`	SSH times out
31 min	FPC `Online`	SSH works, FPC `Present`
37 min		FPC `Online`

Earlier runs on a VM of the same size reached usable in about 18 minutes for one to three nodes, and 31 to 33 minutes for four or five. So plan for 20 to 40 minutes, and start the lab before you need it. The node that finishes last sets the time.

Six traps

1. unhealthy is not a fault. Docker reads unhealthy until vrnetlab logs this:

2026-10-30 20:54:51,709: launch  INFO Startup complete in: 0:20:48.668343

The qemux86-64 login: prompt in docker logs is the outer Linux VM, not Junos. Follow the log and leave it alone.

2. healthy is not ready. After healthy, our tool's connections kept failing for several minutes:

"error": "Timed out connecting to host"

Then SSH worked, but the FPC was still coming up:

admin@r2> show chassis fpc 0
                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer
  0  Present          Testing

Until it reads Online, ge-0/0/N may not exist, pings fail and protocols do not form. Poll this command. None of that is a config fault, so do not redeploy.

  0  Online           Testing  12         0       11      4      1    1023       21          0

3. A startup config is all or nothing. One statement that Junos rejects fails the whole boot config, and the node comes up Amnesiac with no login. Keep startup files small, and push risky changes live with commit check first. A startup config leaves no commit of yours, so verify with show configuration, never commit history. Ours shows as by root via other.

4. Never docker restart a node. It comes back healthy with no data interfaces. On vJunos-router, request system reboot is worse: the node comes back with no fxp0 and SSH times out for good. The only recovery from either is a lab redeploy, so a restart costs you the whole boot again. Both come from earlier project runs, not this one.

5. CPU sets the lab size, not memory. At 4 vCPU per node, a 16 vCPU host runs four nodes before it has nothing left. Use only as many vJunos nodes as the topic needs, and give host and client roles to Linux containers, which start in seconds.

6. Nested virtualization works, but it is on you. Juniper's docs say vJunos "cannot be used in any deployments that launch the instances from within a VM". vrnetlab's docs say to enable nested virtualization on a VM host. We ran on a cloud VM with kvm_intel nested set to Y, and everything in this post worked, at the boot times above. If you have bare metal, use it.

What is different on vJunos-switch

The kind is juniper_vjunosswitch, and the image builds the same way from juniper/vjunosswitch. containerlab's docs say about 15 minutes to boot. We did not boot the switch for this post, so these come from our earlier project records:

Ports run ge-0/0/0 to ge-0/0/55.
No Virtual Chassis: show virtual-chassis answers the virtual-chassis-control subsystem is not running. Use EVPN ESI-LAG for dual-homing.
Interface MTU tops out at 9192. In a startup file, 9216 drops the stanza at boot.
RSTP runs only on the ports you name under it, so write interface all.

On NetPilot

NetPilot runs containerlab on a private cloud VM, and this post's run used it. You download vJunos from Juniper, upload it once under Images, and the build runs for you. vJunos needs a Large lab VM (16 vCPU). Each node takes 4 vCPU and 5 GiB and boots a VM inside a VM, on the timeline above.

Build two vJunos routers with OSPF between them and a Linux host behind each, then prove the hosts can ping each other.

The agent knows the wait. It tells you the expected time for the node count, polls Online, and only then configures and verifies, so you do not need to watch the log. The console to every node is there when you want to work by hand.

If you came here because vLabs is closing, see Juniper vLabs alternatives. If you are studying, use the JNCIA-Junos practice lab. For cross-vendor EVPN, see debugging Cisco and Juniper EVPN interop.

FAQ

How long does vJunos take to boot in containerlab?

Plan for 20 to 40 minutes on a shared cloud VM. containerlab's docs say 5 to 10 minutes for vJunos-router and about 15 for vJunos-switch, but each node is a VM inside a VM. We measured 21 and 24 minutes to Startup complete for two routers, and 31 to 37 minutes until both read Online. Earlier runs on the same VM size reached usable in about 18 minutes.

Why does my vJunos node show unhealthy?

That is normal while it boots. Docker reads unhealthy until vrnetlab logs Startup complete. Healthy is not ready either: SSH and the FPC come up after it. Poll show chassis fpc 0 until it reads Online before you test anything.

Does vJunos need a license?

No. Juniper offers vJunos free for non-production test environments with no time limit, and show system license reports no usage. Commits may print a warning such as requires 'L2 and L3 Filters' license. Juniper's docs say to ignore license check messages, and the filter worked in our test.

Can vJunos run inside a VM?

Juniper's docs say it cannot be used in deployments that launch the instances from within a VM, and containerlab repeats that. In practice it runs with nested virtualization turned on, which is how we ran this post on a cloud VM with kvm_intel nested enabled. It is not a setup Juniper supports.

What is the containerlab kind for vJunos?

juniper_vjunosrouter for vJunos-router and juniper_vjunosswitch for vJunos-switch. Interfaces use Junos names such as ge-0/0/0 in the topology file, and containerlab maps ge-0/0/0 to the container's eth1.

Try NetPilot Free