Open-Source Routing and Network Simulation

Home / Open Source Networking / Using Netkit pre-configured labs

Using Netkit pre-configured labs

January 9, 2013

The Netkit open-source network simulator was created by a group of university professors who use it as a tool in their teaching. They created a large
number of pre-configured lab scenarios, each with lecture slides that describe the scenario and the technology used in the scenario, and make
these assets available on the Netkit web site.

Netkit network simulator running the pre-configured single-area OSPF lab

This library of pre-configured lab scenarios and acompanying lecture slides is one of the key benefits of Netkit. In this post, we will explore one of the
prepared labs: the single-area OSPF lab.

Similar to other open-source network simulation tools, Netkit provides a set of commands to create virtual machines that are connected together in a
virtual data network. Netkit uses user-mode linux as its virtualization method, so it can only support virtual machines running Linux. The routing and
networking processes run on the Linux virtual machines which, depending on how each one is configured, will emulate clients, servers, switches and
routers in a network.

Netkit pre-configured labs

A pre-configured Netkit lab is a directory that contains subdirectories for each virtual machine that will be created in the lab, a lab.conf file, files that
define commands executed by each virtual machine as it starts up or shuts down, and other files involved in controlling the lab set up process. More
details about how Netkit works are available in the Netkit Introduction slides available on the Netkit Official Labs web page.

To start a pre-configured Netkit lab, navigate to the lab folder (the folder that contains the lab.info file) and run the command, lstart .

Netkit commands
The Netkit commands are listed below. Commands that start with the letter, “L”, control pre-configured lab scenarios. Commands that start with the
letter, “V”, control and configure individual virtual machines.
Lab commands
lstart — Starts and configures a set of virtual machines that are part of a pre-defined lab scenario. Essentially, a wrapper script for the vstart
command.
lhalt — Gracefully shuts down all virtual machines in a lab scenario. Essentially, a wrapper script for the vhalt command.
linfo — Displays information about the lab without launching the lab scenario. Displays information from the associated lab.conf file. Option “-m”
will create a postscript file showing the lab topology.
lclean — Deletes temporary files created on the host computer while running a Netkit lab.
lcrash — Forcibly shuts down all virtual machines in a lab scenario. Essentially, a wrapper script for the vcrash command. Use only when
necessary.

Virtual Machine commands

vstart — Starts a new virtual machine and connects it to a virtual hub.
vhalt — Gracefully shut down a running virtual machine
vlist — Show information about running virtual machines
vconfig — Attach a new network interface to a running virtual machine.
vclean — Stops all Netkit processes, including virtual machines. Stops hanging processes, deletes temporary files, and deletes unused virtual
hubs.
vcrash — Forcibly shut down a virtual machine. Useful if a VM is frozen.

The Netkit DVD and additional software

In this example, we will run Netkit on a system we installed onto a USB flash drive using the Netkit DVD and the install Knoppix to flash disk
program on the DVD. We configured a persistent file system so we can install software and save files. We then booted a PC from the USB flash
drive.

Next, I installed the Graphviz library. To install this package, just search for “Graphviz” in the Synaptic package manager appication and install it.
This will allow us to generate graphical lab topology maps using the linfo command.

The Single Area OSPF lab

Let’s run the Single Area OSPF pre-configured lab as an example.

The Single Area OSPF lab starts five Linux virtual machines running the quagga routing daemon to create OSPF-enabled routing on each virtual
machine. This first OSPF lab shows OSPF in a simple configuration where all routers are in the same OSPF area. The purpose of the lab is to allow
researchers to see how routers communicate with each other using the OSPF routing protocol to determine the least-cost spanning tree between
each subnet in the network.

First, we must download the slides describing the OSPF lab setup and the lab files. These files are available on the Netkit Official Labs web page in
the Advanced Topics section.

Open the PDF file netkit-labs_ospf.pdf that describes the OSPF labs and review the first 38 slides to get a view of what we will try to accomplish in
the lab.

Netkit OSPF single-area lab network diagram, from the lecture slides

Install the lab files by creating a directory for the Netkit labs and then unarchiving the downloaded lab into the folder. In my case, I chose to create a
folder called, ~/Netkit_labs. You can use Knoppix’s Xarchiver application to extract the archived lab files, or execute the following commands:
 $ cd ~/Netkit_labs
$ mv ~/netkit-labs_ospf.tar.gz .
$ tar xvf netkit-labs_ospf.tar.gz

This creates three new directories, one for each OSPF lab:

netkit-lab_ospf-multiarea
netkit-lab_ospf-singlearea
netkit-lab_ospf-complex

We will run the single area OSPF lab. To run a lab in Netkit, move to the folder containing the lab and execute the lstart command. In my case, I
executed the commands and saw the output as shown in the listing below:

$ cd ~/Netkit_labs/netkit-lab_ospf-singlearea
$ lstart

======================== Starting lab ===========================

Lab directory: /home/knoppix/NetKit_labs/netkit-lab_ospf-singlearea
Version: 1.2
Author: G. Di Battista, M. Rimondini
Email: contact@netkit.org
Web: http://www.netkit.org/
Description:
A network showing the operation of the OSPF routing protocol in a simple scenario with a single area
=================================================================
Starting "bb0"...
Starting "bb1"...
Starting "bb2"...
Starting "bb3"...
Starting "bb4"...

The lab has been started.

=================================================================

This starts and configured five virtual machines, bb0, bb1, bb2, bb3, and bb4. All these VMs are running the OSPF routing protocol. The pre-
configured lab is now set up and running.

We can check the status of all the virtual machines with the vlist command, enter vlist at the command prompt and you will see the following
output:

$ vlist
USER VHOST PID SIZE INTERFACES
knoppix bb0 3057 10984 eth0 @ A, eth1 @ C
knoppix bb1 3855 10984 eth0 @ A, eth1 @ D
knoppix bb2 4676 10984 eth0 @ A, eth1 @ B
knoppix bb3 5463 10984 eth0 @ B, eth1 @ C
knoppix bb4 6282 10984 eth0 @ C, eth1 @ D

Total virtual machines: 5 (you), 5 (all users).

Total consumed memory: 54920 KB (you), 54920 KB (all users).
$

Using this output, one could draw a map of the network (if one did not already have a topology map), or one could verify that the documented
network topology matches what has been set up by the pre-configured lab scenario.

Another way to check the lab setup is to run the linfo command. Using the -m filename option, one can make the linfo command create a
postscript file that shows the lab’s network topology, as defined by the lab files and directories. Note that the created diagram does not show what is
actually running; it just shows the specified topology of the lab. If a virtual machine failed to start, for example, the linfo command will not show the
problem, but the vlist command will.

So, in my case, I entered the following command while in the lab directory:

$ cd ~/Netkit_labs/netkit-lab_ospf-singlearea
$ linfo -m labmap_filename

Then, I opened the file, labmap_filename in a program that can open Postscript files, such as the Gimp image editor. I saw the following network
map:
 Graphviz rendering of the ospf-singlearea lab topology

Quagga VTY shell and OSPF commands

Now that the lab is running, let’s check the router OSPF configuration on each node. Each node is a Linux router that is running the quagga routing
engine. To access the quagga commands, we enter the command vtysh in the xterm window of each virtual machine. This will start the quagga
integrated shell which makes the shell seem more like the command-line interface we would see on the types of routers usually used in large
networks. For example, we execute the show running-config command on bb0 to see all the configurations that have been created on the router.
 bb0:~# vtysh

Hello, this is Quagga (version 0.99.10).

Copyright 1996-2005 Kunihiro Ishiguro, et al.

bb0#
bb0# show running-config
Building configuration...

Current configuration:
!
end
hostname Router
log file /var/log/quagga/zebra.log
hostname ospfd
log file /var/log/zebra/ospfd.log
!
password zebra
enable password zebra
!
interface eth0
ip ospf cost 21
ipv6 nd suppress-ra
!
interface eth1
ip ospf cost 36
ipv6 nd suppress-ra
!
interface lo
!
interface teql0
ipv6 nd suppress-ra
!
router ospf
redistribute connected
network 10.0.0.0/16 area 0.0.0.0
!
ip forwarding
!
line vty
!
bb0#

The show command is used to display configuration information and status information. In the vtysh shell, use the question mark “?” character at
any time to see all the available subcommands. For example, see all available commands by entering ? at the command prompt:

bb0# ?
clear Reset functions
configure Configuration from vty interface
copy Copy from one file to another
debug Debugging functions (see also 'undebug')
disable Turn off privileged mode command
end End current mode and change to enable mode
exit Exit current mode and down to previous mode
list Print command list
no Negate a command or set its defaults
ping Send echo messages
quit Exit current mode and down to previous mode
show Show running system information
ssh Open an ssh connection
start-shell Start UNIX shell
telnet Open a telnet connection
terminal Set terminal line parameters
traceroute Trace route to destination
undebug Disable debugging functions (see also 'debug')
write Write running configuration to memory, network, or terminal
bb0#

As another example, enter ? after any command or set of subcommands. For example, to see what subcommands are available in the show ip
ospf command, enter:
 bb0# show ip ospf ?
border-routers for this area
database Database summary
interface Interface information
neighbor Neighbor list
route OSPF routing table
bb0# show ip ospf

Check routing information

At this point, we can look at all the information available on the virtual Linux routers. We can check the routing tables, the OSPF interfaces, the
OSPF database, and other information. Let’s first check that the routing is working the way that the lab slides say it should.

Let’s look at the routing table on router bb1. There are different ways to look at the routing table. We can use the Linux ip command, and we can
also look at the routing table as it is displayed by the VTY shell commands.

First, examine the Linux routing table by entering the following command at the bash shell prompt on bb1. This shows us the routes that the Linux
kernel will use when it forward packets to the required destination addresses. If you are already in the VTY shell, enter exit to quit the VTY shell,
first.

bb1:~# ip route show

10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
10.0.1.0/24 via 10.0.0.2 dev eth0 proto zebra metric 20
10.0.2.0/24 via 10.0.0.2 dev eth0 proto zebra metric 30
10.0.3.0/24 dev eth1 proto kernel scope link src 10.0.3.1
bb1:~#

Next, examine the same information as displayed in the VTY shell. You will see that the routing table displayed in the VTY shell shows more
information. It shows routes learned from the different routing protocols which, in this case, are OSPF (code 0) and directly connected links (code
C). If we look at the codes associated with each line, we will see that the selected routes (code *) match the routes in the Linux routing table (with
the addition of the system loopback address, which is not listed in the Linux routing table).

bb1:~# vtysh

Hello, this is Quagga (version 0.99.10).

Copyright 1996-2005 Kunihiro Ishiguro, et al.

bb1# show ip route

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, >; - selected route, * - FIB route

O 10.0.0.0/24 [110/10] is directly connected, eth0, 00:45:08

C>;* 10.0.0.0/24 is directly connected, eth0
O>;* 10.0.1.0/24 [110/20] via 10.0.0.2, eth0, 00:44:20
O>;* 10.0.2.0/24 [110/30] via 10.0.0.2, eth0, 00:43:46
O 10.0.3.0/24 [110/40] via 10.0.0.2, eth0, 00:43:46
C>;* 10.0.3.0/24 is directly connected, eth1
C>;* 127.0.0.0/8 is directly connected, lo
bb1#

Let us look at the OSPF database on each Linux router. Each database should be the same. On each router, we execute the VTY shell command,
show ip ospf database . The listing below shos this command executed on bb0, and it will look the same on all the other routers.
 bb0# show ip ospf database

OSPF Router with ID (10.0.2.3)

Router Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# CkSum Link count

10.0.1.1 10.0.1.1 168 0x80000007 0xe1fe 2
10.0.2.2 10.0.2.2 168 0x80000006 0x0acf 2
10.0.2.3 10.0.2.3 194 0x80000006 0x0ea2 2
10.0.3.1 10.0.3.1 195 0x80000006 0x16a2 2
10.0.3.2 10.0.3.2 185 0x80000004 0x468e 2

Net Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# CkSum

10.0.0.1 10.0.3.1 205 0x80000003 0x67aa
10.0.1.2 10.0.2.2 173 0x80000002 0x67bc
10.0.2.3 10.0.2.3 194 0x80000003 0x5dac
10.0.3.1 10.0.3.1 195 0x80000002 0x79a6

bb0#

So now we understand that these virtual Linux routers connected by virtual hubs are running a routing protocol and choosing the best routes
between nodes in the network. the lab is simulating and OSPF network. We could do a lot more investigation but let’s move on to running network
tests.

Network tests
Common network test tools are traceroute and ping . Let us use the traceroute command to verify that packets sent from bb1 to an interface on
bb3 will take the expected route.

For example, we expect that a packet sent from bb1 to IP address 10.0.2.1 should go out interface eth0 and pass through bb2 and bb3 before
terminating on the eth0 interface on bb4, which is configured with IP address 10.0.2.1. Also, we expect that a packet sent from bb1 to IP address
10.0.3.2 should go out interface eth1 and terminat on the eth1 interface on bb4, which is configured with IP address 10.0.3.2. We can make these
prediction by looking at the routing tables. We can verify this with the traceroute command, as shown below.

bb1# traceroute 10.0.2.1

traceroute to 10.0.2.1 (10.0.2.1), 64 hops max, 40 byte packets
1 10.0.0.2 (10.0.0.2) 10 ms 1 ms 0 ms
2 10.0.1.2 (10.0.1.2) 15 ms 1 ms 1 ms
3 10.0.2.1 (10.0.2.1) 21 ms 1 ms 1 ms
bb1# traceroute 10.0.3.2
traceroute to 10.0.3.2 (10.0.3.2), 64 hops max, 40 byte packets
1 10.0.3.2 (10.0.3.2) 4 ms 1 ms 0 ms
bb1#

We can execute more network test commands from different sources, addressed to different destinations.

Modifying router configurations

To further excercise the lab scenario, we can make some modifications to the Linux router’s configuration. For example, we might shut down an
interface using the Linux ifconfig command, to force a change in the routing topology and then look at the impact on the routing tables. Or, we
might make changes to the router configuration. Let’s look at what happens if we add a new interface to bb3.

Adding loopback interfaces to a router is a common way to add test networks in a lab scenario. Loopback addresses may be useful in a test network
where we want to create many networks but do not have as many physical interfaces as we need. First, we will create two new loopback interfaces
on bb3 with the ifconfig command, as shown below:

bb3:~# ifconfig lo:1 inet 10.0.4.1 netmask 255.255.255.0 up

bb3:~# ifconfig lo:2 inet 10.0.5.1 netmask 255.255.255.0 up

Since these are directly connected networks, the network addresses are redistributed into the OSPF protocol and advertised by the OSPF protocol
to other routers in the network. So, other routers will learn about these new networks. Let us look at the routing tables on some of the routers.

On bb3, we see:
 bb3# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, >; - selected route, * - FIB route

O>;* 10.0.0.0/24 [110/17] via 10.0.1.1, eth0, 01:34:32

O 10.0.1.0/24 [110/7] is directly connected, eth0, 01:34:32
C>;* 10.0.1.0/24 is directly connected, eth0
O 10.0.2.0/24 [110/10] is directly connected, eth1, 01:35:16
C>;* 10.0.2.0/24 is directly connected, eth1
O>;* 10.0.3.0/24 [110/20] via 10.0.2.1, eth1, 01:34:49
C>;* 10.0.4.0/24 is directly connected, lo
C>;* 10.0.5.0/24 is directly connected, lo
C>;* 127.0.0.0/8 is directly connected, lo
bb3#

On bb1, we see:

bb1# show ip route

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, >; - selected route, * - FIB route

O 10.0.0.0/24 [110/10] is directly connected, eth0, 01:36:14

C>;* 10.0.0.0/24 is directly connected, eth0
O>;* 10.0.1.0/24 [110/20] via 10.0.0.2, eth0, 01:35:26
O>;* 10.0.2.0/24 [110/30] via 10.0.0.2, eth0, 01:34:52
O 10.0.3.0/24 [110/40] via 10.0.0.2, eth0, 01:34:52
C>;* 10.0.3.0/24 is directly connected, eth1
O>;* 10.0.4.1/32 [110/30] via 10.0.0.2, eth0, 00:18:03
O>;* 10.0.5.1/32 [110/30] via 10.0.0.2, eth0, 00:16:47
C>;* 127.0.0.0/8 is directly connected, lo
bb1#

So we see the networks 10.0.4.0/24 and 10.0.5.0/24 show up as directly connected (code C) on bb3 and networks 10.0.4.1/32 and 10.0.5.1/32 are
learned from OSPF (code O) on bb1. This is because the OSPF protocol will advertise loopback addresses as singe-host /32 networks, as required
by RFC2328.

Halt the lab

The is a lot more we could try in this lab but the time has come to stop. To halt the lab, go to the Terminal, ensure you are in the lab directory, and
then enter the lhalt command.

$ cd ~/Netkit_labs/netkit-lab_ospf-singlearea
$ lhalt

Conclusion
The pre-configured lab scenarios and accompanying lecture slides created by the Netkit development team and other professors who use Netkit as
a teaching tool are a valuable resource that helps make Netkit a very useful and functional network simulator for experimenting with IP routing
technology. In this example, we were able to quickly move on to experimenting with the OSPF routing protocol and did not concern ourselves with
setting up and configuring each element of the lab.

The Netkit man pages provide information about how to build a lab scenario so anyone could create new lab scenarios for either testing or learning
purposes. The Netkit project welcome submissions of new lab scenarios and offers templates and instructions on how to submit new lab scenarios.
The ability to create new pre-configured lab scenarios also makes Netkit useful as a test tool.

Share
this:

   1 

Related Posts:

1. NetKit test drive

2. Installing Netkit
3. Open-source network simulator roundup
4. CORE Network Emulator test drive
5. Testing IPv6 addressing in a network simulator – Part 1
 In Open Source Networking lab, netkit, simulation

Installing Netkit CORE Network Emulator test...

2 responses to Using Netkit pre-configured labs

Yahya April 13, 2013 at 12:12 pm

Hello Brian,

Thank you for brillilant tutorials/explanations.

As I am new to Netkit, I have a query and would greatly appreciate it if you could answer it.

I would like to create, using netkit and quagga a scenario where a studentwill have 1 virtual host (HOST A) and can create
multiple guest vms (quagga routers). The user might connect his network to another user running netkit HOST B with multple
guests vms (quagga routers). It then becomes an AS.

Now what I have heard is that if let’s say Host C wants to connect to HOST A (who is already connected to HOST B), then it will
be impossible as can not connect two group of routers to each other and in fact only 1 router from HOSTA can be connected to 1
router from HOSTB, and there is nat between two routers.

Is there a way to bypass this?

Brian Linkleter April 14, 2013 at 9:47 pm

Hi,

I’d like to help but I am not so proficient in NetKit operation to be able to suggest a solution to this complex problem.

I can suggest a few things to try:

1) On each virtual host (HOST A, HOST B, and HOST C), you could create more than one virtual Ethernet NIC. I use
VirtualBox to create my virtual hosts and I can create more than one virtual Ethernet NIC on each VirtualBox virtual host. Each
virtual NIC should be in “bridged” mode.
2) Then, you could use the standard TAP driver to connect any of the virtual machines that were created by NetKit, and are
running Quagga, to any of the NICs on the virtual host.
3) Then, you could connect the virtual hosts to each other using the different virtual NICs. This would connect the the virtual
quagga routers running in each virtual host to each other through the virtual NICs.

I am sorry I can’t offer more.

Best regards,
Brian

Follow me on Twitter

Join my mailing list

Please type your e-mail address

Subscribe

Network Simulators

Open-Source Network Simulators

Cloonix network emulator

CORE network emulator

GNS3 network emulator

IMUNES network emulator

Marionnet network emulator

Mininet SDN network emulator

Netkit network emulator

NS-3 network simulator

OpenStack all-in-one (DevStack, etc.)

Shadow network simulator

UNetLab and EVE.NG network emulators

VNX and VNUML network emulators

Search this site

Search...

Top Posts

How to emulate a network using VirtualBox

Open-Source Network Simulators

Installing Debian Linux in a VirtualBox Virtual Machine

How to set up the UNetLab or EVE-NG network emulator on a Linux system

Using the OpenDaylight SDN Controller with the Mininet Network Emulator

Recent Posts

Set up a dedicated virtualization server on Packet.net

Install the CORE Network Emulator from source code

Netdev 2.1 conference report

Build a custom Linux Router image for UNetLab and EVE-NG network emulators

How to set up the UNetLab or EVE-NG network emulator on a Linux system

DNS and BIND demonstration using the Cloonix network emulator

OFNet SDN network emulator

Psimulator2 forked, updated

How to emulate a network using VirtualBox

How to build a network of Linux routers using quagga

How To Install dCore Linux in a virtual machine

Mininet-WiFi: SDN emulator supports WiFi networks

OpenStack all-in-one: test cloud services in one laptop

Using the OpenDaylight SDN Controller with the Mininet Network Emulator

Saving a Cloonix network topology

Lenovo Thinkpad T420: Another excellent, inexpensive Linux laptop

Use ImageMagick to quickly and easily process images for your blog

Cloonix Network Simulator updated to v28

KVM Performance Limits for virtual CPU cores

Capture data on open-source router interfaces in GNS3

Using VirtualBox linked clones in the GNS3 network simulator

Using POX components to create a software defined networking application

How to map OpenFlow switches to TCP ports in Mininet SDN simulations

IMUNES on Linux

GNS3 Version 1.3: What’s new for Open-Source Routers

Book review: The Book of GNS3

Install the GNS3 network simulator version 1.x

Build your own network simulator using open-source DevOps tools

CORE Network Emulator updated to 4.8

Cloonix network simulator updated to version 26

Visualizing software defined network topologies using POX and Gephi

Install Gephi on the Mininet VM

Using the POX SDN controller

How to use MiniEdit, Mininet’s graphical user interface

Install Mininet on an Amazon EC2 server

Control an Amazon EC2 server from an Apple iPad using SSH and VNC

Install the CORE Network Emulator on Amazon AWS

How to run GUI applications on an Amazon AWS cloud server

How to set up a new user on your Amazon AWS server

Create a free virtual private server on Amazon Web Services

Archive

Archive

Select Month

Open Source Routing and Network Simulation blog by Brian Linkletter is licensed under a Creative Commons Attribution-NonCommercial 4.0 International
License.

© 2017 Open-Source Routing and Network Simulation — Standard by 8BIT