Build Your Own Network Lab: A Step-by-Step Guide

Why build your own network lab?

A network lab gives you a place to connect devices, make changes, break a configuration and understand how to recover it. Reading explains the concept; a lab shows what actually happens to interfaces, routes and traffic.

• Practical learning: practise IP addressing, switching, routing and packet analysis.
• Certification preparation: turn the topics in your current exam blueprint into repeatable exercises.
• Experimentation: compare protocols and test unfamiliar features in an isolated environment.
• Career development: keep diagrams, configuration backups and troubleshooting notes that demonstrate your process.

You can begin with a simulator, use virtual network appliances, build a physical rack or combine these approaches. A useful lab has clear learning goals and repeatable tests; it does not have to be expensive.

Step 1: Define your objectives

Choose one outcome for your first session, such as “R1 learns R2’s loopback through OSPF.” Write the starting state, expected result and rollback before adding more nodes. Match the software to the features you need: a simulator may not support the same commands or external automation interfaces as a virtual appliance.

Step 2: Plan your network topology

Sketch routers, switches, firewalls, servers and client machines before installing anything. Label interfaces, networks and the management path. Separate the connection used to administer a device from links you will deliberately break during exercises.

A manageable first topology

The worked lab below uses two routers, a transit link, two loopbacks and a shared management network. It is suitable for basic routing, OSPF and SSH practice. Add switches and endpoints separately for VLAN, trunking and spanning-tree exercises.

• Management: your lab workstation reaches both routers over a dedicated virtual or physical switch.
• Transit: a separate point-to-point link carries routing traffic between R1 and R2.
• Loopbacks: stable test destinations help you distinguish interface reachability from learned routes.

Keep this lab isolated from your production or home LAN. If you later add internet access, design the routing, NAT and firewall policy deliberately. The addressing below uses documentation ranges for the isolated example.

Step 3: Gather your equipment

Hardware for a physical network lab

Depending on your objectives, gather routers, managed switches, a firewall, a workstation and optional servers or client devices. Refurbished equipment can be useful when its software, licences, power requirements and supported features match your plan.

• Ethernet patch leads, labelled console cables and the correct USB-to-console adapter.
• A stable desk or rack, ventilation, suitable power distribution and optional UPS.
• A computer with console software and a way to store configuration backups.

Check port types, noise, electricity use, software access and feature support before buying. Older hardware may be useful for routing fundamentals while lacking newer features or supported security software.

Software for a virtual network lab

Size the host around your appliances

There is no single RAM figure that fits every lab. Add the documented RAM requirement of each running appliance, then leave memory and CPU headroom for the host OS, hypervisor and workstation tools. Two lightweight routers and two firewall appliances can have very different requirements.

Start only the nodes needed for the exercise. If booting is slow or the host swaps heavily, reduce the topology before debugging network protocols. Use images obtained through the vendor’s authorised licensing route; this guide does not include vendor software.

Step 4: Set up your physical lab

1. Position and power: place devices securely, allow ventilation and check the power supply requirements.
2. Connect the console: verify the console cable, serial port and device-specific terminal settings.
3. Record the starting state: note model, software version, existing configuration and interface names. Back up an existing device before changing it.
4. Cable and label: connect management ports and transit links according to your diagram. Label both ends.
5. Build the management path: assign the planned addresses and verify the workstation can reach each device.
6. Configure and verify: apply the lab configuration in small stages, check each result and save a known-good baseline.

If using a hybrid lab, connect physical and virtual networks only through a clearly defined interface. Avoid accidentally bridging a lab DHCP server or switching loop into your normal network.

Step 5: Configure your network with GNS3

1. Install GNS3 using the official instructions for your operating system.
2. If your chosen appliances require it, download the matching GNS3 VM for your supported hypervisor. Import the VM and enable the required virtualization features.
3. Use the setup wizard or preferences to select the local server and/or GNS3 VM. Confirm the selected server is reachable before importing appliances.
4. Import the appropriate appliance template and supply your authorised image. Follow its recommended adapter, CPU and RAM settings.
5. Create a project, add R1 and R2 and connect their transit adapters. Add a management switch and a lab workstation or an isolated host connection.
6. Start the nodes, open their consoles and confirm which actual interface corresponds to each link.
7. Apply the worked configuration below, adapting interface names to your image. Verify management access before testing OSPF.
8. Capture packets on the transit link and save the project plus configuration backups.

A GNS3 project or appliance template is not a licence to the underlying operating system. A built-in Ethernet switch is useful for simple connectivity; it does not provide a full managed-switch CLI for switching certification exercises.

Step 6: Configure your network with EVE-NG

1. Check EVE-NG’s supported platforms and system requirements before choosing a VM or bare-metal installation. Hardware virtualization and, where applicable, nested virtualization must be available.
2. Install EVE-NG, assign its management address and confirm you can access the web interface.
3. Follow EVE-NG’s image-specific instructions for your authorised appliance. Use the required directory and image naming and apply the documented permissions procedure.
4. Create a lab and add two supported router nodes with the resources required by their images.
5. Add the transit connection and a separate shared management network. Map each connection to the correct adapter.
6. Start the devices, open the supported console and apply the same addressing plan used below.
7. Verify the workstation-to-router management path. The EVE-NG web interface being reachable does not automatically make guest router addresses reachable.
8. Save device configurations and export or back up your lab definition and notes.

Keep screenshots of your adapter mapping. If a router fails to boot, first check image compatibility, available resources and virtualization rather than changing its network configuration.

Worked lab: two routers, SSH and OSPF

Platform: Cisco IOS-style syntax. This is an instructional configuration, not a universal import file. Check command support, replace the secret placeholders and map GigabitEthernet1 / GigabitEthernet2 to your actual interfaces before applying it through the console.

No default gateway is needed for the PC to reach router management addresses on this same subnet. To reach loopbacks from the PC, add deliberate routing separately; router-to-router loopback tests below do not require PC routes.

! Isolated lab only. Replace BOTH secret placeholders before applying.
configure terminal
hostname R1
ip domain-name lab.example
username njlab privilege 15 secret REPLACE_WITH_UNIQUE_USER_SECRET
enable secret REPLACE_WITH_UNIQUE_ENABLE_SECRET
ip ssh version 2
interface GigabitEthernet1
 description ISOLATED-MANAGEMENT
 ip address 192.0.2.11 255.255.255.0
 no shutdown
interface GigabitEthernet2
 description TRANSIT-TO-R2
 ip address 198.51.100.1 255.255.255.252
 no shutdown
interface Loopback0
 ip address 203.0.113.1 255.255.255.255
router ospf 1
 router-id 203.0.113.1
 passive-interface default
 no passive-interface GigabitEthernet2
 network 198.51.100.0 0.0.0.3 area 0
 network 203.0.113.1 0.0.0.0 area 0
line vty 0 4
 login local
 transport input ssh
end
! Generate SSH keys using the syntax supported by your image:
configure terminal
crypto key generate rsa modulus 2048
end
copy running-config startup-config

! Isolated lab only. Replace BOTH secret placeholders before applying.
configure terminal
hostname R2
ip domain-name lab.example
username njlab privilege 15 secret REPLACE_WITH_UNIQUE_USER_SECRET
enable secret REPLACE_WITH_UNIQUE_ENABLE_SECRET
ip ssh version 2
interface GigabitEthernet1
 description ISOLATED-MANAGEMENT
 ip address 192.0.2.12 255.255.255.0
 no shutdown
interface GigabitEthernet2
 description TRANSIT-TO-R1
 ip address 198.51.100.2 255.255.255.252
 no shutdown
interface Loopback0
 ip address 203.0.113.2 255.255.255.255
router ospf 1
 router-id 203.0.113.2
 passive-interface default
 no passive-interface GigabitEthernet2
 network 198.51.100.0 0.0.0.3 area 0
 network 203.0.113.2 0.0.0.0 area 0
line vty 0 4
 login local
 transport input ssh
end
! Generate SSH keys using the syntax supported by your image:
configure terminal
crypto key generate rsa modulus 2048
end
copy running-config startup-config

Some images prompt for the RSA key size interactively or use a different key-generation syntax. Check the console response and show ip ssh. If the image has additional VTY lines, apply the same SSH-only login policy to those supported lines as well.

Verify in this order

! On both routers
show ip interface brief
show ip ssh
show ip ospf neighbor
show ip route ospf
! From R1
ping 198.51.100.2
ping 203.0.113.2 source Loopback0
! From the lab workstation terminal
ssh njlab@192.0.2.11
ssh njlab@192.0.2.12

Expect the management and transit interfaces to be up/up, one OSPF neighbour in FULL state and an OSPF route to the other router’s /32 loopback. A neighbour state suffix can vary with the network type and DR election. The sourced loopback ping tests the return route too; a successful management ping alone does not prove OSPF is working.

Step 7: Test and troubleshoot

Start with physical or virtual link state, then addressing, routing, transport access and application behaviour. Change one variable at a time and record what changed.

Practise controlled failures

1. Transit outage: in this isolated lab, shut only the transit interface through the console. Observe the neighbour and remote route disappear; restore it with no shutdown.
2. Area mismatch: deliberately change one transit OSPF area. Compare both sides, restore area 0 and confirm adjacency returns.
3. Missing advertisement: remove one loopback network statement. Observe that adjacency can remain FULL while the remote route is missing. Restore the statement.
4. SSH authentication: test an incorrect password once, then correct it. Distinguish authentication failure from a timeout.
5. Packet analysis: capture the transit link, filter OSPF and ICMP and relate the packets to show-command output.

Use console access for deliberate failures, keep the baseline files available and restore the known-good configuration after each exercise. Do not apply these failure exercises to production equipment.

Step 8: Document your lab

Good documentation makes a lab repeatable. Save your diagram, node inventory, image versions, interface mapping, addressing table, running configurations and test results together. Keep secrets out of shared notes and repositories.

• Before: goal, starting topology and expected behaviour.
• During: commands changed, observations and relevant packet captures.
• After: verification evidence, root cause, rollback and next exercise.

Use dated folders or version control for sanitised text configurations. A hypervisor snapshot can help recover a VM, but also save device configurations and lab definitions separately; a snapshot alone is not a complete portable backup.

Step 9: Expand and upgrade

Expand when you can explain and rebuild the current lab. Each new node should support a specific learning goal.

• Switching: add managed switches and endpoints for VLANs, trunks, spanning tree and inter-VLAN routing.
• Routing: add a third router, redundant links and new areas or protocols. Compare convergence and path selection.
• Security: introduce a firewall, separate zones and test services. Verify policies using both allowed and denied traffic.
• Services: add DNS, DHCP, NTP or a Linux server and document dependencies.
• Observability: add supported monitoring, syslog and packet analysis to explain failures.
• Automation: collect show commands first, then practise backups and controlled configuration changes with validation and rollback.

If you cannot run the appliances locally, compare a suitable remote lab or lab rental service against your required features and access window. Confirm NetworkJourney’s current lab options directly before booking; this guide does not assume availability or a fixed price.

Free lab files and completion checklist

The R1 and R2 downloads are available above. Save this session template with them. These are text configuration and planning files; vendor images and prebuilt GNS3/EVE-NG project files are not included.

NETWORK LAB SESSION RECORD
Date:
Learning goal:
Platform / image versions:
Topology and interface mapping:
Starting configuration backup location:
Changes made:
Expected result:
Actual verification output:
Failure introduced (if any):
Root cause and evidence:
Rollback performed:
Final saved configuration location:
Next exercise:

Checklist progress is available when JavaScript is enabled.

Tick boxes track this visit only. Print or save your notes if you want a permanent record.

Conclusion: make the lab repeatable

Your first network lab does not need every device or protocol. Start with a clear goal, build a topology you understand and verify each layer before expanding. Physical equipment develops cabling and console skills; virtual labs make it easier to repeat experiments. Documentation and troubleshooting turn either approach into lasting experience.

Additional resources

• Official GNS3 documentation — installation, appliances and troubleshooting.
• Official EVE-NG documentation — supported platforms and image preparation.
• Cisco SSH configuration guidance — check syntax against your device release.
• Wireshark documentation — packet capture and analysis.