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,
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.
- 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
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.
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@example.com 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#
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.
Common network test tools are
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
$ cd ~/Netkit_labs/netkit-lab_ospf-singlearea $ lhalt
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.