> For the complete documentation index, see [llms.txt](https://docs.vex-nx.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vex-nx.com/labs/generate-lab.md).

# Generate Lab

![Generate Lab](https://1807546539-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhgHCHWL3861o2DBW53aA%2Fuploads%2Fk5Xdq1UDIzujZC7G0F9Y%2Fve20261112v5-generate-lab.png?alt=media)

## Goal

Paste one or more device running-configs and create a **new** lab from that text.

## Why Generate Lab exists

Real networks already have configs. Retyping them by hand on a blank canvas is slow and error-prone. Generate Lab is for:

* Turning a production or lab `show run` into a safe practice copy
* Rebuilding a design from emailed configs
* Moving from "configs only" to "topology I can boot"

**Important:** This creates a **new** lab. To push config onto a node that already exists, open that lab -> toolbar **More** -> Apply running-config (see Toolbars and More menu).

## GUI tutorial

### Step 1 - Open Generate Lab

![Generate Lab](https://1807546539-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhgHCHWL3861o2DBW53aA%2Fuploads%2Fk5Xdq1UDIzujZC7G0F9Y%2Fve20261112v5-generate-lab.png?alt=media)

1. Sidebar -> **Labs**
2. Click **Generate Lab**

|                  |                                                     |
| ---------------- | --------------------------------------------------- |
| **What you see** | Generate Lab workspace / dialog                     |
| **Expected**     | Paste area for running-configs and fidelity options |

### Step 2 - Paste configs and create

1. Paste one or more `show run` / running-config texts
2. Pick fidelity (Exact vs Redesign / FRR) as offered
3. Confirm template / image choices
4. Submit to create the **new** lab
5. Open Design / Operate on the result - [Design mode](/labs/design-mode.md), [Operate and consoles](/labs/operate-and-consoles.md)

## What you need before you start

* Pasted configs (Cisco-style `hostname`, Junos `system host-name`, and similar)
* Optional: images already in **Images -> Library** if you will use commercial templates
* Or choose **Redesign** fidelity / FRR templates if you only have Docker seeds

## Fidelity modes

| Mode         | What it does                                                                                                                                                                                                                                                                                                                                                                                                                       |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Remap**    | Align interface names to the lab template; keep operational config text. Production `boot nxos` / `boot system` / flash install lines are **removed or commented** so the guest boots from the VEX-NX Library image. Preview warns and may auto-suggest a matching Library image.                                                                                                                                                  |
| **Map**      | Keep source interface names when they match the target template family. Same boot/image hygiene and Library image suggestion as Remap.                                                                                                                                                                                                                                                                                             |
| **Redesign** | Move to FOSS stand-ins (`frrouting` / `alpine-docker`). Builds a mechanical FRR/alpine startup (ethN + addresses). When Assist LLM is configured, Assist translates each device fully into that dialect; weak/partial output is rejected and the mechanical stand-in is kept. If the paste needs VXLAN/EVPN/NVE or heavy L2, the preview shows a **WARNING** and recommends **Remap** (or Map) with a matching QEMU image instead. |

### Images and boot safety

* The node boots from the **Library image** bound to the node (`ImageID`), not from `bootflash:` paths in the paste.
* Generate Lab sanitizes those boot/image statements on Map/Remap and records notes in the preview.
* After start, VEX-NX best-effort verifies the intended hostname via live CLI when available (`runtimeMeta.configVerify`).

Generate Lab analyzes each paste dynamically (IOS, NX-OS, EOS, Junos, FRR, ...). It does **not** hardcode one demo topology. Empty chassis interface stubs are skipped on large dumps. Overlay/virtual ports (NVE, loopback, SVI, ...) are not treated as canvas data ports (they stay in startup text on Remap/Map).

When Assist is not configured, mechanical detection still runs and notes that Assist-enhanced analysis was skipped.

## Paste format

* Separate devices with a line of `----` (or `====`)
* Optional name headers: `### R1` or `! device: R1`
* Or let `hostname` / `system host-name` be detected automatically

## Recipe: two routers from pasted configs

Example paste:

```
hostname R1
!
interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.252
!
----
hostname R2
!
interface GigabitEthernet0/0
 ip address 10.0.0.2 255.255.255.252
!
```

1. Labs -> **Generate Lab** (dialog title: Create lab from running-config)
2. Lab name: `ospf-from-prod-snippet`
3. **Fidelity:**
   * **Remap** (default) - rewrite interface names to match VEX-NX templates (best for beginners)
   * **Map (1:1)** - keep source names when the template allows
   * **Redesign** - prefer FOSS stand-ins (for example FRR) when you do not have Cisco images yet
4. Leave **Infer links from shared /30-/24 subnets** on so shared subnets become a link
5. Paste both configs -> **Preview devices**
6. Per device: edit name and pick a **template** (`cisco-iosv`, `iosvl2`, `arista-veos`, `juniper-vsrx`, `frrouting`, `alpine-docker`, plus catalog)
7. Review inferred links; uncheck any you do not want
8. **Create lab** -> Design opens

## Expected result

* Design shows the devices (and links when inference worked)
* ScriptPad / imported profiles hold the config text
* You may still need to bind a Library disk if the template is not Docker

## Common mistakes

| Mistake                                       | Fix                                                 |
| --------------------------------------------- | --------------------------------------------------- |
| Pasting without `----` between devices        | One messy device - split with separators or headers |
| Cisco template with no IOS image              | Images -> Import, then bind on the node             |
| Expecting disks inside the paste              | Configs only; images are separate                   |
| Using Generate Lab to update an existing node | Use More -> Apply running-config inside that lab    |

## Related

* [Migrate Lab](/labs/migrate-lab.md) (UNL ZIP)
* [Import Lab](/labs/import-lab.md) (native VEX-NX pack)
* Import images


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.vex-nx.com/labs/generate-lab.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.