How to Import a Lab into Cisco Modeling Labs (CML)

Step by step

1. Save the lab's .yaml file somewhere you can find it. A CML topology is one self-contained YAML file describing the nodes, links, and starting configuration.

2. In the CML dashboard, choose Import (or 'Add Lab' → Import) and select the .yaml file. CML reads the topology and creates the lab without you drawing anything.

3. Open the lab and start it. CML boots each node from its image; the first boot of a few routers and switches takes a little time.

4. Once the nodes are up, open a console to any device and you're on real Cisco IOS — configure, verify, and troubleshoot exactly as you would on hardware.

If a node won't start

The most common cause is that your CML instance doesn't have the image the lab references, or you've hit a node limit (common on the free tier). Labs built on free-tier images (IOL/IOL-L2) avoid the image problem; if you hit the node limit, stop other running labs first.

A lab to import every day

Goldfish Networks labs ship as exactly this kind of single-file, license-free YAML, built on CML free-tier images so they import in one click. Grab the free sample, import it with the steps above, and grade your finished config against the answer key.

Sanity-check the import before you build anything

Before you sink an hour into configuration, confirm the topology actually imported the way the author drew it. CML recreates nodes and links exactly from the YAML, but a wrong image mapping or a node that quietly failed to boot can leave you chasing a "bug" that is really a missing device. Start every node, wait for each console to reach a prompt, then walk the box: interfaces first, then neighbors, then any existing config.

Three checks cover most of it. `show ip interface brief` tells you the expected interfaces are present and shows their state; on a fresh, unconfigured router those interfaces are administratively down until you `no shutdown` them, so that is normal, not a fault. Once both ends of a link are up, `show cdp neighbors` confirms you are wired to the devices the diagram promised, and `show running-config` reveals whether the lab shipped any startup config or you are starting clean. A neighbor that is missing — or one you did not expect — means the link map differs from the picture, and that is worth fixing before you route a single packet.

Treat this as a Layer 1/2 gate: nothing you configure at Layer 3 will behave until the underlay matches the intended topology. It takes two minutes and saves you from debugging routing on a link that was never actually connected.

R1# show ip interface brief
Interface              IP-Address   OK? Method Status                Protocol
GigabitEthernet0/0     unassigned   YES unset  administratively down  down
GigabitEthernet0/1     unassigned   YES unset  administratively down  down
Loopback0              unassigned   YES unset  up                     up
!
! after 'no shutdown' on both ends of the link:
R1# show cdp neighbors
Device ID   Local Intrfce   Holdtme   Capability   Platform   Port ID
R2          Gig 0/0         143       R B          IOSv       Gig 0/0

A worked example: finishing a two-router static-routing lab

Here is the whole flow on a minimal lab you might import. R1 and R2 are joined by one point-to-point link on 10.0.12.0/30 — a /30 gives exactly 2^2 − 2 = 2 usable addresses, which is all a point-to-point link needs. R1 takes .1, R2 takes .2, and each router carries a loopback (1.1.1.1 on R1, 2.2.2.2 on R2) standing in for a LAN. Right after import the interfaces are administratively down and unaddressed, so the first job is Layer 3 on the link.

With the link addressed and up, each router can reach its neighbor's connected interface but not the far-side loopback — there is no route to it yet. Add a static route pointing at the neighbor as the next hop. Because you supply a next-hop IP rather than an exit interface, IOS performs a recursive lookup: it resolves 10.0.12.2 to the interface that reaches it, then forwards. You could instead write the route to an exit interface (for example `ip route 2.2.2.2 255.255.255.255 Gig0/0`), which skips the recursion but relies on proxy-ARP to find the next hop — acceptable on a point-to-point link, less predictable on a multi-access segment.

A ping sourced from the loopback is the real test, because it exercises both the forward route (R1 to R2) and the return route (R2 to R1); one-directional static routing is the classic reason a ping fails, so never test without a source. When this passes you have reproduced exactly what a grader checks — reachability between the two loopbacks. That is the point of importing a graded lab: you configure it, verify it the same way the answer key does, and know before you submit whether you actually solved it.

! --- addressing on both ends of the /30 ---
R1(config)# interface Gig0/0
R1(config-if)# ip address 10.0.12.1 255.255.255.252
R1(config-if)# no shutdown
R2(config)# interface Gig0/0
R2(config-if)# ip address 10.0.12.2 255.255.255.252
R2(config-if)# no shutdown
!
! --- static routes to the far-side /32 loopbacks ---
R1(config)# ip route 2.2.2.2 255.255.255.255 10.0.12.2
R2(config)# ip route 1.1.1.1 255.255.255.255 10.0.12.1
!
! --- verify from R1 ---
R1# show ip route static
S    2.2.2.2/32 [1/0] via 10.0.12.2
R1# ping 2.2.2.2 source 1.1.1.1
!!!!!
Success rate is 100 percent (5/5)