Using Netkit pre-configured labs

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.

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.

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:         [email protected]
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:

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.