Communication Simulator with Network Behavior Logging Function for Supporting Network Construction Exercise for Beginners

Abstract

Interconnecting virtual machines realizes computer networks on ordinary personal computers. Such a technique enables each student instead of a group to construct networks in network exercises for beginners. In the exercises, students may ask teachers to judge the correctness/incorrectness of their networks and to support the debugging for their networks. The waiting time of students can be long because the number of teachers is less than the number of students. An effective solution to this problem is to develop a system that can judge whether students’ networks are correct and visualize the behavior of students’ networks as hints. Detail logs of network behavior are necessary for realizing such a system. Here, we propose a communication simulator to record network behavior in detail during request/response communications, which are the transmissions of request data (e.g., icmp echo request) and the corresponding response data (e.g., icmp echo reply).

1 Introduction

It is important to increase the number of network engineers who administer computer networks as an infrastructure to a ubiquitous society and provide new services to the society. The experience of basic network construction is useful for not only network administrators but also network application programmers and network system designers.

Network engineers define network specifications based on the network usage specified by their clients, and then, these engineers construct networks that satisfy these specifications. Therefore, there are network exercises where problems are based on frequent usage examples and students must construct networks for the available examples. We call these examples communication examples; they include “Client A can browse web sites on server B” and “Communications from client C to server A are intercepted by firewall D.”

In traditional exercises for beginners, students are first divided into several groups; then, they construct networks with physical network devices. In recent years, however, it has become possible to realize networks by an interconnection of virtual machines running on an ordinary personal computer because of the performance improvement of personal computers and the evolution of virtual machine technology. We call such networks of virtual machines VMN. VMNs realize an e-learning environment where each student can construct his/her own network without considering time and placement (e.g., [1–5]).

In traditional exercises, each group attempts to construct networks based on exercise problems. When they want to confirm the correctness of their networks or cannot solve certain problems related to these networks, they approach their teachers for help. In e-learning, however, their waiting time is increased because students construct networks individually and the number of teachers is less than the number of students. An effective solution to this problem is to develop a system that can judge whether students’ networks (we call them answers) are correct and visualize the behavior of these networks as hints.

Detail logs of network behavior are necessary for realizing such a system. For example, the logs needed for the judgment system are passing points of communication data (e.g., network interface Y on node X) and a terminated operation (e.g., discarding communication data because of a mismatch of the destination MAC address in the communication data to the MAC address assigned to the network interface that received the communication data). By comparing such data between the answers and the correct answers, the system judges whether the answers are correct. The logs needed for the hint generation system are operations for communication data in each node, one of which is packet forwarding caused by a mismatch of the destination IP address in the communication data to the IP addresses in its received node. It is not possible to gather such data by using packet capturing of tcpdump [6] or by using the trace data of network simulator ns-3 [7].

Therefore, here, we propose a communication simulator to record network behavior in detail during request/response communications, which are transmissions of request data (e.g., icmp echo request) and the corresponding response data (e.g., icmp echo reply). Fourteen proposed operations realize request/response communication in the simulator. The simulator receives network configurations and communication attributes (e.g., source node and destination IP address) as its input and then, computes the transmission of request data and response data. During such computation, the simulator writes the executed operations into a file (called log file) one by one. The simulator has the following features:

• The target of simulation is limited to the transmissions of requests and responses because it is used for judging whether the communication examples are successful in the networks.

• Each operation uses a few configurations as its input in order to obtain detailed relations between configurations and the success/failure of the communication examples.

2 Preparation

This section describes the operators to operate data structures.

• operator []: It returns a sequence whose elements are its arguments. The arguments are of variable length and are separated by commas. For example, “[1, 2, 3]” returns a sequence whose first element is “1,” whose second element is “2,” and whose last element is “3.”

• operator $<>$: It returns a structure whose elements are its arguments. The arguments are of variable length and are separated by commas.

• operator {}: It returns a set whose elements are its arguments. The arguments are of variable length and are separated by commas.

• operator +: It returns a merged sequence between its arguments. For example, “[1] $+$ [2] $+$ [3]” returns a sequence whose first element is 1, whose second element is 2, and whose last element is 3.

• operator .: It accesses the value of a member valuable in a structure. For example, when a structure s has a member variable e and there is a variable y and whose data type is s, “y.e” accesses the value of valuable e.

3 Network Construction Exercise

3.1 Exercise Purpose

The target students have studied TCP/IP but have never constructed networks. The exercise target involves the students getting accustomed to designing networks that satisfy the following requirements and construct networks based on these designs.

• 1. IP address and subnet mask

• 2. IP network in a segment

• 3. Default route

• 4. Static routing

• 5. Server services (web page publishing on WWW)

Table 1 Data structure used by network devices

Table 2 Data structure of network

Table 3 Actions of network devices

3.2 Network

Tables 1, 2, and 3 list the specifications of networks in the exercise.

3.3 Structure of Exercise Problem

Exercise problems consist of communication examples and configuration requirements. The former is an example of communication available in students’ networks. The latter consists of nodes that must be installed into networks, and setting values that must be set in nodes, and cables that must connect the assigned nodes.

Communication examples consist of items in Table 4. Configuration requirements have the same data structure as the network, as given in Table 2. Node identifiers (e.g., the node identifier of host $hs_0$ is $hs_0.nd$) and network interface names (e.g., the network interface name of router $rt_0$ is $ni_0.name (ni_0\in rt_0.ni)$) must be concrete values, and the other items can be either ‘$*$’ (denoting arbitrary values) or concrete values.

Table 4 Data of communication example

3.4 Example of Exercise Problem

Communication examples are expressed using natural language in actual exercise problems. For example, when a communication example consists of the following values, it is expressed by sentences given at the top of Fig. 1.

• kind $k=$“$icmp-echo$”

• source $s=$“svr1”

• destination $d={<}\,$“”, “”, “192.168.0.2”, “icmp”, “”>

• communication route $R=<v_0, V, E, L, F>, V=[v_0, v_1, v_2, v_3, v_4, v_5, v_6, v_7, v_8, v_9, v_{10}], E=\{\{v_0, v_5\}, \{v_5, v_2\}, \{v_5, v_3\}, \{v_5, v_4\}, \{v_6, v_{10}\}, \{v_{10}, v_7\}, \{v_{10}, v_8\}, \{v_{10}, v_9\}, \{v_1, v_7\}\}, L=[$“svr1”, “svr2”, “svr3”, “svr4”, “rpt1”, “svr1”, “svr2”, “svr3”, “svr4”, “rpt1”$], F(V_i) returns L_i$

• process reception information $P=\{{<}v_1,$“kernel”${>}, {<}v_6,$ “client”${>}\}$

Configuration requirements are expressed using natural language and figures in actual exercise problems. For example, when configuration requirements $cr=<hs, rt, sw, rp, cb>$ consist of the following values, they are expressed by a figure given at the bottom of Fig. 1, where letters at the top of the squares denote node type and letters at the bottom represent the node identifier.

• $hs=\{n1, n2, n3, n4\}$, $rt=\{\}$, $sw=\{\}$, $rp=\{n5\}$, $cb=\{l1, l2, l3, l4\}$

• $n1={<}$“svr1”, $* , * , * , * , *>$, $n2={<}$“svr2”, $* , * , * , * , *>$, $n3={<}$“svr3”, $* , * , * , * , *$>, $n4={<}$“svr4”, $* , * , * , * , *>$, $n5={<}$“rpt1”, $* , 5{>}$

• $l1={<}$“svr1”, $* ,$“rpt1”, $*{>}$, $l2={<}$“rpt1”$, * ,$“svr2”, $*{>}$, $l3={<}$“rpt1”, $* ,$“svr3”,$*{>}$, $l4={<}$“rpt1”, $* ,$“svr4”, $*{>}$

Fig. 1

Exercise problem

3.5 Exercise Process

Each student constructs networks with physical devices and virtual devices on the basis of exercise problems. Then, they write reports on the executed steps and configurations in the constructions. After solving all problems, they submit their reports to their teachers. In the case they cannot comprehend certain sections of the exercises, they approach their teachers or teaching assistants for help.

4 Communication Simulator

4.1 Function Definition

The deta structure of communication data pkt used in the following functions is a structure (protocol name prot, destination IP address dip, source IP address sip, destination port number dp, source port number sp, payload pl, destination MAC address dmac, source MAC address smac).

4.1.1 Functions to Get Data from Configurations

• RT(nd): It returns a routing table from the node whose identifier is nd.

• AT(nd): It returns an ARP table from the node whose identifier is nd.

• MAC(nd): It returns a set consisting of structures (ni, mac), where ni is a network interface name in the node whose identifier is nd, and mac is its MAC address.

• IP(nd): It returns a set consisting of structures (ni, ip), where ni is a network interface name in the node whose identifier is nd, and ip is its IP address.

• NI(nd): It returns a set consisting of all network interfaces in the node whose identifier is nd.

• PROC(nd): It returns a set consisting of listening processes in the node whose identifier is nd.

• WORK(nd): It returns the working state of the node whose identifier is nd.

• ARP(nd, ni, ip): If the node whose identifier is nd gets a MAC address corresponding to an IP address ip by an ARP communication at the network interface whose name is ni, it returns the MAC address; otherwise, it returns “”.

• KIND(nd): If the node of nd is a host, it returns “hs”; else, if the node of nd is a router, it returns “rt”. Further, if the node of nd is a switching hub, it returns “sw”; else, if the node of nd is a repeater hub, it returns “rp”.

• PairNI(nd, ni_name): Here, nd denotes a node identifier, and ni_name representes a network interface name. It returns a tupple $(nd_{pair}, ni\_name_{pair})$ whose $ni\_name_{pair}$ is the name of the network interface connected to a network interface whose name is ni_name in the node whose identifier is nd, and whose $nd_{pair}$ is an identifier of the node that has the network interface $ni\_name_{pair}$.

4.1.2 Functions Consisting Operations in Node

Every function writes its name, its inputs, and its outputs at the end of a log file during its execution.

• ReqPkt(prot, pl, dip, dp): Here, prot denotes the protocol name; pl, the payload; dip, the destination IP address; and dp, the destination port number. If $prot=$“tcp” is true, it inputs at random an ephemeral port number into source port sp; otherwise, it sets $sp=$“”. Then, it returns ${<}prot, dip,$ “”,$\,dp, sp, pl,$ “”, “”${>}$ as the communication data.

• RepPkt(proc, pkt): Here, proc denotes a process name and pkt represents the communication data. If $proc=$“apache” $\wedge pkt.pl =$ “$HTTP\ GET\ REQUEST$” is true, it sets $pl =$ “$HTTP\ GET\ RESPONSE$”; else, if $proc=$“kernel”$\wedge \,pkt.pl =$ “ICMP$\ ECHO\ REQUEST$” is true, it sets $pl =$ “$ICMP\ ECHO\ REPLAY$”. Then it returns ${<}pkt.prot, pkt.sip, pkt.dip, pkt.sp, pkt.dp, pl,$“”, “”> as the communication data.

• ChkDIP(dip, nd): Here, dip denotes the destination IP address and nd represents the node identifier. If there is i whose $i.ip = dip (i\in IP(nd))$ is true, it returns true; otherwise, it returns false.

• ChkDMac(dmac, nd, ni): Here, dmac denotes the destination MAC address; nd, the node identifier; and ni, the network interface name. If there is m whose $m.ni=ni\wedge m.mac=dmac (m\in MAC(nd))$ is true, it returns true; otherwise, it returns false.

• Proc(prot, dp, dip, nd): Here, proc denotes the process name; dp, the destination port number; dip, the destination IP address; and nd, the node identifier. If there is proc whose $proc.prot=prot\wedge proc.port=dp\wedge proc.ip=dip$ in $proc\in PROC(nd)$ is true, it returns proc.name; otherwise, it returns “”.

• L1Rtng(nd, ni): Here, nd denotes the node identifier and ni represents the network interface name. It returns a queue whose elements are ni and whose $ni\ne ni_s\wedge WORK(nd_{adj})=true\wedge nd_{adj}\ne$ “” is true in $(nd_{adj}, ni_{adj})=PairNI(nd, ni_s) (ni_s\in NI(nd))$. The elements are sorted in an ascending order by $nd_{adj}$ as the first key and $ni_{adj}$ as the second key.

• L2Rtng(dmac, ni, nd): Here, dmac denotes the destination MAC address; ni, the network interface name; and nd, the node identifier. If there is $ni_s$ whose $m.ni=ni_{adj}\wedge m.mac=dmac\wedge ni\ne ni_s\wedge WORK(nd_{adj})=true\wedge nd_{adj}\ne$ “” in $m=MAC(nd_{adj}), (nd_{adj}, ni_{adj})=PairNI(nd, ni_s), ni_s\in NI(nd)$ is true, it returns a queue whose elements are $ni_s$ sorted in the ascending order by $nd_{adj}$ as the first key and $ni_{adj}$ as the second key; otherwise, it returns L1Rtng(nd, ni).

• L3Rtng(dip, nd): Here, dip denotes the destination IP address, and nd represents the node identifier. If it finds $rtable\in RT(nd)$ whose rtable.ip matches dip by the longest prefix match or whose rtable.nw and rtable.mask match dip by the longest prefix match, it returns a tupple (rtable.nh, rtable.ni); otherwise, it returns a tupple (“”, “”).

• Rcv(proc, pkt): Here, proc denotes a process name and pkt represents communication data. If $(proc=$“apache” $\wedge \,pkt.pl =$“$HTTP\ GET\ REQUEST$”$) \vee (proc={}$“kernel”$\wedge pkt.pl=$“$ICMP\ ECHO\ REQUEST$”) is true, it returns false; otherwise, it returns true.

• SIP(nd, ni): Here, nd denotes the node identifier and ni represents the network interface name. If there is i whose $i.ni=ni (i\in IP(nd))$ is true, it returns i.ip; otherwise, it returns “”.

• DMac(ni, dip, nd): Here, ni denotes the network interface name; dip, the destination IP address, and nd, the node identifier. If $record.mac\ne$ “” $(record\in AT(nd))$ is true, it returns record.mac; otherwise, it returns ARP(nd, ni, dip).

• SMac(nd, ni): Here, nd denotes the node identifier and ni represents the network interface name. If there is m whose $m.ni = ni (m\in MAC(nd))$ is true, it returns m.mac; otherwise, it returns “”.

• Transmit(nd, ni): Here, nd denotes the node identifier and ni represents the network interface name. It returns PairNI(nd, ni).

• Dsc(pkt): Here, pkt denotes the communication data. It discards pkt. It returns nothing.

4.2 Pesudo Code

Procedures 1–4 show the pesudo code of the simulator. When you execute simulation by this simulator on the basis of communication example E, you execute function Communicate(d.prot, pl, dip, d.port, s), where d denotes the destination of E; pl is set as “HTTP GET REQUEST” (type of E is “web-get”); pl is set as “ICMP ECHO REQUEST” (type of E is “icmp-echo”); dip is set as “d.ip” (d.nd=“”); dip is set as $ni.ip(ni\in IP(d.nd))$ ($d.nd\ne$ “”); and s is source of E.

Fig. 2

Log file

5 Prototype System

5.1 Communication Simulator

Let us consider an incorrect network for the exercise problem described in Sect. 3.4. Its incorrect configurations are the IP addresses of svr4 (192.168.0.2) and svr2 (192.168.0.254). Figure 2 shows a part of the log file generated by our simulator by using the network. Each line consists of a function name, input values, and output values. The symbol “\\” on the right side denotes hyphenation.

The first log implies that the execution of function ReqPkt with prot $=$ “icmp,” pl $=$ “icmp-echo,” dip $=$ “192.168.0.2,” and dp $=$ “” as its input arguments returned communication data (prot $=$ “icmp,” dip $=$ “192.168.0.2,” sip $=$ “”, dp $=$ “”, sp $=$ “”, pl $=$ “icmp-echo,” smac $=$ “”, and dmac $=$ “”). The second log implies the execution of function L3Rtng, and in particular, the log stores the node information of its argument nd.

5.2 Application Example of Log

The visualization of communication is helpful for students to debug their networks. We visualized the executed operations during communication by getting several data from the log file. Figure 3 expresses the executed operations, their orders, and their nodes by a directed graph. The vertices consist of “an operation name,” “@,” and “identifier of its execution node.” The direction of the edges denotes the execution order of the operations on the vertices. This network is incorrect because svr4 receives communication data while the exercise problem requires that svr2 receives the data according to the graph.

Fig. 3

Graph of execution operations

6 Evaluation Experience

This experience aims at clarifying the basic performance of our simulator. We implemented our simulator in C++, and executed it with ping executions of several networks on a computer with an Intel core i7-3770K 3.50-GHz CPU and 4-GB main memory. Table 5 shows the result. “Transmissions” denotes all counts at which the nodes transmitted communication data. “Routing entries” representes the counts of the routing table entries in all nodes. According to the result, we conclude that our simulator is available for beginners’ exercises because the number of routers in the exercises is less than 10, and the consumption of the computer resources in the case is enough small to current computers.

Fig. 4

Network for the experiment. It is possible to transmit data between svrL and svrR

Table 5 Measurement result

7 Conclusion

In this paper, we proposed a simulator that stores network behavior for request/response communications. We consider that the stored data are useful for the correct/incorrect judgment and hint generation. We showed a graph to express network behavior as an example of hints. We carried out an evaluation experiment where we measured the basic features of the simulator. According to its result, we concluded that the simulator can sufficiently work on computers with ordinary performance in computing small networks that beginners construct in the exercises. Our future works include an expansion of the simulation target, e.g., firewalls and NAT.