qualnet 4.5 network emulation interface model library · network emulation interface model library...

QualNet 4.5Network Emulation Interface

Model Library

February 2008

Scalable Network Technologies, Inc.6701 Center Drive West, Suite 520

Los Angeles, CA 90045

Phone: 310-338-3318 Fax: 310-338-7213

http://www.scalable-networks.com http://www.qualnet.com

QualNet 4.5 Network Emualtion Interface Model Library 1

Copyright Information

© 2008 Scalable Network Technologies, Inc. All rights reserved.

QualNet is a registered trademark of Scalable Network Technologies, Inc.

All other trademarks and trade names used are property of their respective companies.

Scalable Network Technologies, Inc.6701 Center Drive West, Suite 520Los Angeles, CA 90045Phone: 310-338-3318Fax: 310-338-7213http://www.scalable-networks.comhttp://www.qualnet.com

2 QualNet 4.5 Network Emualtion Interface Model Library

Network Emulation Interface Model Library

The IP Network Emulation (IPNE) interface implements a packet sniffer/injector in conjunction with the External Interface API. It sniffs packets from the physical network, sends packets through the QualNet simulation, and injects them back into the physical network. The applications or protocols involved are mostly unaware that there is a virtual QualNet network. Figure 1 shows a brief diagram depicting its operation

FIGURE 1. IP Network Emulator Overview

Simulated Network

SourceComputer

SourceComputer

Node A

Node B

Node C

DestinationComputer

DestinationComputer

IP NetworkEmulator

IP NetworkEmulator


Building the IP Network EmulatorThe IP Network Emulator (IPNE) uses two open source libraries: lipcap and libnet. Both libraries are automatically included for Linux/UNIX.

Building IPNE for Windows requires a few extra steps than building IPNE on a Linux platform. Two additional libraries must be installed: WinPcap 3.0 and the Microsoft Platform SDK. The Microsoft Platform SDK requires Visual Studio .NET or later.

The WinPcap 3.0 installer is included in the QUALNET_HOME/interfaces/ipne directory as "WinPcap_3_0.exe". Use only version 3.0 of WinPcap. If a different version is installed please uninstall it via the "Add or Remove Programs" control panel before installing WinPcap 3.0.

The most recent version of the Microsoft Platform SDK is R2, released March 2006. The previous release of the Microsoft Platform SDK, SP1, is not compatible with many versions of windows. We therefore recommend upgrading to release R2. The Microsoft Platform SDK R2 can be downloaded at

http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en

The recommended installation procedure is to install a custom installation and install only "Microsoft Windows Core SDK" and "Configuration Options." All other components are optional. Installing the "Configuration Options" will modify environment variables to allow the Platform SDK to be included in command line builds. Since it changes environment variables it has the potential to cause unwanted side effects.

The following possible problems may occur when building IPNE on windows:

• “'nmake' is not recognized as an internal or external command, operable program or batch file." The build environment is not set correctly. Please refer to your development tools (Visual Studio) documentation for how to build applications from the command line.

• “..\interfaces\ipne\libpcap\include\pcap-stdinc.h(45) : fatal error C1083: Cannot open include file: 'winsock2.h': No such file or directory." The Platform SDK include files cannot be found. Verify that the environment variables are set properly. The environment variables should have been set while installing the Platform SDK.

• "This application has failed to start because wpcap.dll was not found. Re-installing the application may fix this problem." or "The dynamic link library wpcap.dll could not be found..." Install WinPcap 3.0. The installer is located in the QUALNET_HOME/interfaces/ipne directory.

After the necessary libraries have been installed, check for a correct build environment. Do this by building QualNet without activating the IPNE addon. Open the QualNet prompt and change the directory to QUALNET_HOME/main. Verify the proper makefile is used and compile using the following commands:

nmake cleannmake

Or UNIX:

make cleanmake


Building the IP Network Emulator

If QualNet does not compile, verify that your build environment is correct. Refer to the QualNet Installation Guide for more details on compiling QualNet.

Next, enable the IPNE addon in QualNet. To do this, locate the line:

# INSERT INTERFACES HERE

in the Makefile (QUALNET_HOME/main/Makefile-addon-windows on Windows or QUALNET_HOME/main/Makefile-addon-unix on Linux (UNIX), and add the following line below it:

Windows:

include ../interfaces/ipne/Makefile-windows

Or UNIX:

include ../interfaces/ipne/Makefile-unix

While still in the main directory, if running Windows, type:

nmake cleannmake

Or UNIX:

make cleanmake

When the build process finishes the IPNE module is compiled into QualNet. You may now run scenarios that implement IP network emulation.

A compile time option of “BEST_EXECUTION_SPEED” in QUALNET_HOME/interfaces/ipne/Makefile-common will enable IPNE to use all available CPU cycles for simulation and incoming/outgoing IPNE network traffic, when enabled.

You can run the scenario with IPNE by using a command line in the Simulator, or in the GUI. To use a command line, type

$QUALNET_HOME/bin/qualnet *.config

To use the GUI, right click on the configuration file (*.config) and choose Run Scenario.


Configuration and TerminologyFigure 2 shows the IPNE configuration.

FIGURE 2. Configuration Layout

Host 1 and Host 2 are called Operational Nodes (or Operational Hosts). They are real computers running real protocols and applications.

Node A and Node B are called Emulated Nodes (or Emulated Hosts). They exist entirely in the QualNet simulator.

Node 1 and Node 2 are called Virtual Nodes (or Virtual Hosts). Although they exist in the QualNet simulator, they are the counterpart to an Operational Host. This means that Virtual Nodes act as the interface between Operational and Emulated Hosts.

IPNE can operate in three distinct modes: NatNo, TrueEmulation and NatYes. The modes are described in a later section.

Simulated Network

Host 1 Node 1 Node A Node B Node 2 Host 2


IPNE Configuration Parameters


The IPNE module is configured in the experiment.ipne file. Add the following line to the experiment.config file to enable IPNE:

IPNE YESIPNE-CONFIG-FILE <file>

Set <file> to the experiment.ipne file.

Table 1 shows the parameters that are set in the experiment.ipne file:

TABLE 1. IPNE Parameters

Parameter ExplanationNAT <enabled> Set <enabled> to YES to enable Network Address Translation. Set

<enabled> to NO to disable NAT.

TRUE-EMULATION <enabled> Set <enabled> to YES to enable true emulation.

RECEIVE-DELAY <delay> Set <delay> to a time value such as 1US. This ensures that the IP sniffing code executes at most once every <delay> value. This gives a speed increase, however it adds a slight delay to all sniffed packets.

PRINT-DEVICES <enabled> Set <enabled> to YES to print a list of devices that can be sniffed. The list of sniffable devices will include all Network Interface Cards (NICs) and optionally some pseudo-devices such as the loopback device and "any" which sniffs on all devices.

NUM-DEVICES <number> Set <number> to specify the number of devices that will sniff for packets.

DEVICE <name> Enter one DEVICE line for each specified device. A sniffing device is the operating system's name for a network interface. <name> is the name of the device, such as eth0. A device name may also refer to the list of devices list by entering DEVICE-#, where # is the index of the device in the list.

NUM-VIRTUAL-NODES <number> Set <number> to the number of virtual nodes.


VIRTUAL-NODE REAL-ADDRESS <Real IP address> [PROXY-ADDRESS <QualNet proxy address>] DEVICE <device> [MAC-ADDRESS <MAC interface address>] MULTICAST-TRANSMIT-ADDRESS <multicast IP address> MULTICAST-RECEIVE-REAL-ADDRESS <multicast IP address>

Enter one VIRTUAL-NODE line for each specified virtual node. The 'Real IP address' is the IP address of the operational host. 'device' is the QualNet machine interface on which the operational host corresponding to that virtual node is connected. If running in TrueEmulation mode, specify the MAC-ADDRESS field where 'MAC interface address' is the MAC address of the interface of the operational host which is connected to the QualNet machine. If the MAC address is not present, IPNE resolves it based on the IP address in the REAL-ADDRESS field. The required parameters for each node depend on the mode IPNE is running in. IPNE modes are described in the next section, "IPNE Modes". If running in NatYes mode, specify the PROXY-ADDRESS field. The QualNet proxy address is the IP address of a QualNet node. Each IP address must be unique. If using multiple devices, specify which DEVICE the node corresponds to. If DEVICE is not specified it defaults to the first listed device.

Enter one MULTICAST-TRANSMIT-ADDRESS line for each specified virtual node. The multicast IP address for MULTICAST-TRANSMIT-ADDRESS is used inside QualNet as multicast address for the scenario, and the multicast IP address for MULTICAST-RECEIVER-REAL-ADDRESS is the multicast group that the operational host joins. A packet destined to the multicast IP address for MULTICAST-RECEIVER- REAL-ADDRESS is captured by QualNet and is encapsulated with a multicast IP address in QualNet, which is MULTICAST-TRANSMIT-ADDRESS. For further information, refer to multicast example in NatYes mode in the example real life scenario section. This option is only supported under NatYes mode.

ROUTE-UNKNOWN-PROTOCOLS When running in NatYes mode, this parameter routes unknown protocols directly through QualNet without simulating them. IPNE 4.5 in NatYes mode supports TCP, UDP and ICMP packets. All other IP packet types are unsupported. This parameter is not used in other modes.

DEBUG When set to YES, this prints out useful IPNE debugging information.

PRINT-PACKET-LOG When set to YES, this prints a log of all incoming and outgoing IP packets.

TABLE 1. IPNE Parameters (Continued)

Parameter Explanation



PRINT-STATISTICS When set to YES, this prints statistics describing its operation every three seconds. Example statistics output:

IPNE statistics

real time = 3.003783s sim time = 3.000001s in = 0 jitter = 0.000000 ms

out = 0 pps = 0.00 max int = 21.440 ms avg int = 0.030 ms

real time is the amount of real time that has elapsed since the beginning of the simulation. sim time is the current simulation time. Real time and simulation time should be very close, with simulation time lagging real time by a few milliseconds or less. If simulation time is consistently behind real time it means QualNet is running slower than realtime. In some cases the simulation time may not advance. This will happen if there are no events for QualNet to simulate (there are no sniffed IP packets, application traffic, routing traffic, etc.) and is consistent with QualNet being an event driven simulator. in and out are the number of IP packets received by QualNet and sent from QualNet in the last three seconds. pps is the average number of packets sent per second over the last three seconds. jitter measures the jitter of all sniffed IP packet streams. max int and avg int are the maximum and average intervals between packet sniffing. The packet sniffing intervals measure how often the operating system gives control to the QualNet process.

MULTICAST <enabled> Set <enabled> to YES to enable multicast. This option is only supported under NatYes mode.

OSPF <enabled> Set <enabled> to YES to enable OSPF. This option is only supported under TrueEmulation mode. For more information, refer to OSPF Link Interface Configuration in Protocol-Specific Link Interfaces using the TrueEmulation Mode section.

NUM-OSPF-NODES <number> Set <number> to specify the number of OSPF nodes.

OSPF-NODE-ADDRESS <address> Enter OSPF node address for each OSPF node.

RIP <enabled> Set <enabled> to YES to enable RIP. This option is only supported under TrueEmulation mode. For more information, refer to RIP Link Interface Configuration in Protocol-Specific Link Interfaces using the TrueEmulation Mode section.

NUM-RIP-NODES <number> Set <number> to specify the number of RIP operational hosts.

RIP-NODE-ADDRESS <address> Enter node address for each operational host running RIP.

OLSR <enabled> Set <enabled> to YES to enable OLSR. This option is only supported under TrueEmulation mode. For more information, refer to OLSR Link Interface Configuration in Protocol-Specific Link Interfaces using the TrueEmulation Mode section.

NUM-OLSR-NODES <number> Set <number> to specify the number of OLSR nodes.

OLSR-NODE-ADDRESS <address> Enter OLSR node address for each OLSR node.

OLSR-NET-DIRECTED-BROADCAST <enabled>

Set <enabled> to Yes to enable net-directed broadcast address for OLSR packets. Limited broadcast address (255.255.255.255) is used by default unless otherwise specified.




PRECEDENCE <enabled> Set <enabled> to Yes to enable Precedence option. This option requires the extra parameters such as NUM-PRECEDENCE-PAIRS, PRIORITY, SOURCE-ADDRESS, and DESTINATION-ADDRESS. Users can set preferred precedence value for IP packets based on source/destination pair.

NUM-PRECEDENCE-PAIRS <number>

Set <number> to specify the number of source/destination pairs for precedence configuration.

PRIORITY <value> SOURCE-ADDRESS <address> DESTINATION-ADDRESS <address>

Set <value> to specify the priority level, and enter IP address for source and destination pair.

MAC-SPOOFING <enabled> Set <enabled> to Yes to enable MAC address spoofing feature. This option is only supported under TrueEmulation mode and used to determine the next hop node. With this feature, static next-hop configuration can be omitted. The performance can be downgraded with wireless interface.




IPNE Modes

IPNE Modes

IPNE operates in three distinct modes: NatNo, TrueEmulation, and NatYes. Most users will typically operate IPNE in NatNo mode. TrueEmulation and NatYes are more difficult to configure and are needed only in special circumstances (for example, TrueEmulation would be used to directly exchange routing information between operational and emulated hosts, and NatYes would be used if the forwarding tables or the IP addresses on the operational hosts cannot be modified).

NatNoNatNo is the easiest mode to configure and will work with all typical IPNE scenarios.

IP packets are sniffed/forwarded between pairs of operational hosts. This means that IPNE will emulate any IP traffic sent from an operational host to another operational host.

Network TopologyThe network topology must be determined before creating an emulated IP Network. This includes determining the operational network topology as well as the simulation topology.

Software/System ConfigurationAfter the network topology is decided, follow these steps to configure software components and system:

1. Determine which QualNet nodes are virtual nodes.2. Update each operational host’s routing table to send IP traffic for other operational hosts to QualNet.

QualNet ConfigurationSee “Parameters” in this document for a detailed list of configuration parameters.

1. Specify the packet sniffing device(s).2. Set NAT to NO3. Specify which QualNet nodes are virtual nodes.4. If custom processing needs to be done on a packet (such as address translation in the data segment of

the packet) then QualNet will call a user’s function if the packet matches a certain address/port/socket combination.

ExampleFigure 3 shows the example setup 1.


FIGURE 3. Example Setup 1

Example SetupThere are three operational hosts: Host 1, Host 2, and Host 3. Their IP addresses are 192.168.0.51, 192.168.0.23 and 192.168.0.132 respectively. The QualNet simulation is running on a computer with the IP address 192.168.0.53. There are 3 virtual nodes in the network named QualNet Host 1, QualNet Host 2 and QualNet Host 3 with IP addresses 192.168.0.51, 192.168.0.23 and 192.168.0.132 respectively.

Example ExplanationConsider the following scenario: Host 1 (192.168.0.51) wants to send a UDP packet to Host 3 (192.168.0.132) through the emulated network. Host 1 sends the UDP packet to 192.168.0.132. The UDP packet is forwarded to the QualNet host via Host 1's routing tables and is detected by the IPNE module. The Received UDP packet is added to the QualNet simulation, traveling from QualNet Host 1 to QualNet Host 3. When the packet arrives at QualNet Host 3, the real UDP packet will be injected back into the network.

Example ConfigurationThe following contents of the IPNE file implement the above example.

NAT NOTRUE-EMULATION NONUM-DEVICES 1DEVICE DEVICE-1NUM-VIRTUAL-NODES 3VIRTUAL-NODE REAL-ADDRESS 192.168.0.51 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.23 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.132 DEVICE DEVICE-1

The routing tables of each host must be configured manually. Host 1 must forward packets with a destination IP address of 192.168.0.23 (Host 2) or 192.168.0.132 (Host 3) to 192.168.0.53 (the computer

QualNet Simulation

Host 1192.168.0.51

Host 3192.168.0.132

Host 2192.168.0.23

QualNet Host 2192.168.0.23



192.168.0.53


IPNE Modes

running the QualNet simulation). Host 2 must forward packets with a destination IP address of 192.168.0.51 (QualNet Host 1) or 192.168.0.132 to 192.168.0.53. Host 3 must forward packets with a destination IP address of 192.168.0.51 or 192.168.0.23 to 192.168.0.53. The QualNet host must be configured to not forward IP packets.

TrueEmulationTrueEmulation mode is used when operational hosts communicate directly with emulated hosts and vice versa. If emulated nodes are only used as relay nodes (all IP packets pass directly through the simulation) then NatNo mode should be used instead.

In TrueEmulation mode all IP packets arriving at a virtual node are immediately forwarded to the operational network. A protocol running on a virtual node inside QualNet will not receive any packets -- all packets will be forwarded to the operational network instead. Hence, typically no routing protocols run on virtual nodes in TrueEmulation mode, the routing protocol runs on the operational hosts instead. This means that the IP layer of a virtual node inside QualNet will have no knowledge of any routes. Static routes must hence be used for virtual nodes inside QualNet to forward unicast packets incoming from the real network onto the relevant emulated node. The MAC address spoofing option can be used to deliver the next-hop information with packets from the operational hosts.

In TrueEmulation mode all IP traffic originating from operational hosts is added to the QualNet simulation at the corresponding virtual nodes. This contrasts with NatNo mode where only IP traffic between pairs of operational hosts is added.

Network TopologyThe network topology must be determined before creating an emulated IP network. This includes determining the operational network topology as well as the simulation topology.

Software/System ConfigurationTrue Emulation mode does not require any system configuration.

QualNet ConfigurationFollow these steps to configure the QualNet .ipne file:

1. Specify the packet sniffing device(s).2. Set NAT to NO.3. Set TRUE-EMULATION to YES.4. Specify which QualNet nodes are virtual nodes.5. If custom processing needs to be done on a packet (such as address translation in the data segment of

the packet) then QualNet will call a user's function if the packet matches a certain address/port/socket combination.


Example Figure 4 shows example setup 2.

FIGURE 4. Example Setup 2

Example SetupIn Figure 4, there are three operational hosts: Host 1, Host 2, and Host 3. Their IP addresses are 192.168.0.51, 192.168.0.23 and 192.168.0.132 respectively. The QualNet simulation is running on a computer with the IP address 192.168.0.53. There are 3 virtual nodes in the network named QualNet Host 1, QualNet Host 2 and QualNet Host 3 with IP addresses 192.168.0.51, 192.168.0.23, and 192.168.0.132 respectively. There is also an emulated host with IP address 192.168.0.243. There are other emulated hosts depicted but they are ignored for this example.

Example Explanation #1Consider the following scenario: Host 1 (192.168.0.51) wants to send a UDP packet to QualNet Host 4 (192.168.0.243). Since Host 1 is in the same subnet as 192.168.0.243 it broadcasts an ARP packet requesting 192.168.0.243's MAC address. The IPNE module receives the ARP request, realizes that 192.168.0.243 is an emulated node and responds to the ARP request with the QualNet Host's MAC address. Host 1 receives the ARP response and sends the UDP packet to the QualNet Host using the QualNet Host's MAC address. At this point, the original IP packet is dropped by the computer running QualNet. However, an identical UDP packet is added to the QualNet simulation. The QualNet Host receives the UDP packet and sends it from QualNet Host 1 to QualNet Host 4.

QualNet Host 4 receives the packet and processes it as if it were a packet generated by the QualNet simulation.

Example Explanation #2Consider the following scenario: Host 1 (192.168.0.51) wants to send a UDP packet to Host 3 (192.168.0.132) through the emulated network. At this point we assume that Host 1 has received a route to Host 3 through a routing protocol running on all operational and emulated hosts. The UDP packet is forwarded to the QualNet host via Host 1's routing tables and is detected by the IPNE module. At this point

QualNet Simulation

Host 1192.168.0.51

Host 3192.168.0.132

Host 2192.168.0.23




192.168.0.53



IPNE Modes

the original IP packet is dropped by the computer running QualNet. However an identical UDP packet is added to the QualNet simulation, traveling from QualNet Host A to QualNet Host C. When the packet arrives at QualNet Host C, the real UDP packet will be injected back into the network, reaching Host 3.

Example ConfigurationThe following contents of an experiment.ipne file implements the above example.

NAT NOTRUE-EMULATION YESNUM-DEVICES 3DEVICE DEVICE-1DEVICE DEVICE-2DEVICE DEVICE-3NUM-VIRTUAL-NODES 3VIRTUAL-NODE REAL-ADDRESS 192.168.0.51 DEVICE DEVICE-1 MAC-ADDRESS xx:xx:xx:xx:xx:xxVIRTUAL-NODE REAL-ADDRESS 192.168.0.23 DEVICE DEVICE-2 MAC-ADDRESS xx:xx:xx:xx:xx:xxVIRTUAL-NODE REAL-ADDRESS 192.168.0.132 DEVICE DEVICE-3 MAC-ADDRESS xx:xx:xx:xx:xx:xx

The routing tables of each host should be updated by:

1. static routes, or 2. routing protocol running on operational hosts and the QualNet model of the routing protocol running on

QualNet emulated nodes, but not on virtual nodes.

NatYesNatYes is an IPNE mode that is used only for special circumstances.

IP packets are sniffed/forwarded between pairs of operational hosts. This means that IPNE will emulate any IP traffic sent from one operational host to another operational host.

Network TopologyThe network topology must be determined before creating an emulated IP network. This includes determining the simulation topology as well as determining which hosts are virtual nodes.

Software/System ConfigurationAfter the network topology is decided, follow these steps to configure software components and system:

1. Determine the correspondences between operational host IP addresses and emulated node IP addresses. The operational host IP address is termed as the ‘real address’ and QualNet emulated node IP address is the ‘proxy address’.

2. Configure the real application on one operational host to communicate with the other hosts’ QualNet proxy addresses.

3. Update each operational host’s routing table to send all QualNet proxy traffic to the machine running the QualNet simulation.

4. If the QualNet simulation machine is also running an operational application that is sending traffic, it should instead route all QualNet proxy traffic to a dummy address as the next hop. A good address to use is the real IP address of another operational host taking part in the simulation. The other host


ignores the incoming packets because the destination address is fictitious. This is required because the application sending traffic from the QualNet host must believe that there is a valid route to the destination.

QualNet ConfigurationSee Parameters section in this document for a detailed list of configuration parameters. Follow these steps:

1. Create nodes with IP addresses matching each QualNet proxy address.2. Specify the packet sniffing device(s). 3. Set NAT to YES.4. Specify the correspondences between real addresses and QualNet proxy addresses by specifying the

real address and QualNet proxy address of each virtual node.5. If you need to do custom processing on a packet (such as address translation in the data segment of

the packet), QualNet calls a user’s function if the packet matches a certain address/port/socket combination.

ExampleFigure 5 shows the configuration setup. See “Parameters” for a detailed list of configuration parameters.

FIGURE 5. Configuration Setup

Example SetupIn this example there are three real computers: Host 1, Host 2, and Host 3. Their IP addresses are 192.168.0.51, 192.168.0.23 and 192.168.0.132 respectively. The QualNet simulation is running on a computer with the IP address 192.168.0.53. Each real computer corresponds to a simulated computer in the QualNet simulation: 192.168.0.51 with 100.100.0.51, 192.168.0.23 with 100.100.0.23, and 192.168.0.132 with 100.100.0.132. The IP addresses corresponding to the real IP addresses (100.100.0.51, 100.100.0.23 and 100.00.0.132) are called QualNet proxy addresses. The real applications that communicate through the simulation send their traffic to the QualNet proxy addresses, not the real IP addresses.

QualNet Simulation

Host 1192.168.0.51

Host 3192.168.0.132

Host 2192.168.0.23




192.168.0.53


IPNE Modes

Example ExplanationConsider the following scenario: Host 1 (192.168.0.51) wants to send a UDP packet to Host 3 (192.168.0.132) through the emulated network. Sending the packet directly to Host 3’s IP address 192.168.0.132 will not work because Host 1 and Host 2 are on the same subnet and the UDP packet will be sent directly to Host 3. You must have Host 1 send the UDP packet to QualNet Host 3 (100.100.0.132) with a source address of Host 1 (192.168.0.51). The UDP packet is forwarded to the QualNet host and detected by the IPNE module. At this point, the original IP packet is dropped by the computer running Qualnet. However an identical UDP packet is added to the QualNet simulation, traveling from QualNet Host 1 to QualNet Host 3. When the packet arrives at QualNet Host 3, the real UDP packet will be injected back into the network with a destination of Host 3 (192.168.0.132) and a source of QualNet Host 1 (100.100.0.51). Host 3 receives the UDP packet and processes it as if was sent from QualNet Host 1.

From the perspective of Host 1, QualNet Host 3 is a real computer with IP address 100.100.0.132. Likewise from the perspective of Host 3, QualNet Host 1 is a real computer with IP address 100.100.0.51.

Example ConfigurationThe following contents of the experiment.ipne file implements the configuration in the above example.

NAT YESTRUE-EMULATION NONUM-DEVICES 1DEVICE DEVICE-1NUM-VIRTUAL-NODES 3VIRTUAL-NODE REAL-ADDRESS 192.168.0.51 PROXY-ADDRESS 100.100.0.51 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.23 PROXY-ADDRESS 100.100.0.23 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.132 PROXY-ADDRESS 100.100.0.132 DEVICE DEVICE-1

The routing tables of each host must be configured manually. Host 1 must forward packets with a destination IP address of 100.100.0.23 (QualNet Host 2) or 100.100.0.132 (QualNet Host 3) to 192.168.0.53 (the computer running the QualNet simulation). Host 2 must forward packets with a destination IP address of 100.100.0.51 (QualNet Host 1) or 100.100.0.132 to 192.168.0.53. Host 3 must forward packets with a destination IP address of 100.100.0.51 or 100.100.0.23 to 192.168.0.53. The QualNet host must be configured to not forward IP packets.

Summary of ModesThe IP Network Emulator operates in three distinct modes: NatYes, NatNo, and TrueEmulation. When operating in NatYes mode, operational protocols communicate with a proxy QualNet IP address. The proxy addresses are translated into real addresses by QualNet. In NatNo modes operational protocols communicate directly with the other host's IP addresses. In TrueEmulation mode, operation hosts may communicate with emulated hosts and vice versa. Table 2 shows the advantages and disadvantages of the three modes.


TABLE 2. Advantages/Disadvantages of the Tree

Mode Description

NatYes advantages Allows operational hosts to communicate as if they are part of a virtual subnet. Imposes minimum restrictions on the local network that the real hosts reside in (IP addresses of operational and emulated hosts may be in different subnets). Does not require a dedicated computer to run QualNet. (Machine running real application can also be the QualNet machine.)

NatYes disadvantages Configuration is more difficult than NatNo mode. May not work automatically with some applications or protocols that include IP address information in the data payload. May not work in case of real multihop wireless scenarios

NatNo advantages Configuration is intuitive. Works with all applications or protocols.

NatNo disadvantages Imposes some restrictions on the local network (IP addresses of operational and emulated hosts must be in the same subnet and must not overlap). Requires a dedicated computer to run QualNet.

TrueEmulation advantages Configuration is intuitive. Works with all applications and protocols. Allows real protocols to communicate with simulated QualNet protocols and vice versa.

TrueEmulation disadvantages Configuration is more difficult than NatNo mode. Imposes some restrictions on the local network (IP addresses of operational and emulated nodes must be in the same subnet and must not overlap). Requires a dedicated computer to run QualNet. May interfere with local network. QualNet may add real traffic to the local network, and real traffic may be added to QualNet from the real network.


Application Layer Interoperability

Application Layer InteroperabilityWith TrueEmulation mode in IPNE, QualNet can provide the transparent interoperability in application layer. The application layer emulation enables QualNet to provide the interoperability in application layer, so that application protocol such as FTP, HTTP, and TELNET can be interchanged transparently.

ConfigurationStand-alone servers only receive the request from the operation nodes (outside of QualNet). They support limited functionality, but essential features. For instance, FTP supports the commands for login, listing, and downloading. For security reason, access to the file system can be restricted to specific directory. For more strict security, access to the file system can be prohibited especially for TELNET. Files shown to users should be created in the memory on the fly.

Stand-alone servers are configured by specifying the following parameters in the application configuration (*.app) file:

S_FTP <node ID>S_TELNET <node ID> S_HTTP <node ID> <base directory>

where

<node ID> : ID of the node<Base directory> : Directory that contains the web page


Example Real Life ScenariosIn this section we will look at example IPNE scenarios and generate an IPNE configuration for NatNo, NatYes, and TrueEmulation modes. Example scenarios are available at QUALNET_HOME/scenarios/ipne.

NatNoLocation of scenario: QUALNET_HOME/scenarios/ipne/NatNo

FIGURE 6. IPNE NatNo Real Life Configuration

In Figure 6, there are two operational hosts, 192.168.0.45 and 192.168.0.46. The QualNet simulation is running on a computer with the IP address 192.168.0.100. There are 2 Virtual nodes in QualNet with IP addresses 192.168.0.45 and 192.168.0.46. The routing table on operational nodes should be configured to forward packets to QualNet node.

Simulated Network

Host A192.168.0.1

Host A192.168.0.1

Host B192.168.0.4

Host B192.168.0.4

192.168.0.53




Example Real Life Scenarios

IPNE Configuration

# Configure IPNE to run in NatNo modeNAT NOTRUE-EMULATION NO

# Set a receive delay of 10USRECEIVE-DELAY 10US

# Print out the maximum amount of descriptive informationPRINT-DEVICES YESDEBUG YESPRINT-PACKET-LOG YESPRINT-STATISTICS YES

# Add one sniffing device. DEVICE-1 corresponds to the first device# written in the "PRINT-DEVICES" sectionNUM-DEVICES 1DEVICE DEVICE-1

# Configure 2 virtual nodes 192.168.0.45 and 192.168.0.46. Both# will use DEVICE-1. Nodes with IP addresses 192.168.0.45 and# 192.168.0.46 must exist in the simulator.NUM-VIRTUAL-NODES 2VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.46 DEVICE DEVICE-1

At operation host A (192.168.0.45)

Linux:

>> ifconfig eth0 192.168.0.45 netmask 255.255.255.0>> route add -host 192.168.0.46 gw 192.168.0.100

Windows:

>> route add 192.168.0.46 mask 255.255.255.255 192.168.0.100

At operation host B (192.168.0.46)


Linux:


Windows:

>> route add 192.168.0.45 mask 255.255.255.255 192.168.0.100


NatYes: UnicastLocation of scenario: QUALNET_HOME/scenarios/ipne/NatYes

FIGURE 7. IPNE NatYes Unicast Real Life Configuration

For single interface and single-hop scenario, there are two operational hosts, 192.168.0.45 and 192.168.0.46 in the same subnet. The QualNet simulation is running on a computer with the IP addresses 192.168.0.53. Each operational host corresponds to a simulated node in the QualNet simulation: 192.168.0.45 with 100.100.0.45 and 192.168.0.46 with 100.100.0.46. The IP addresses corresponding to the real IP addresses (100.100.0.45 and 100.100.0.46) are called QualNet proxy addresses. The real applications that communicate through the simulation send their traffic to the QualNet proxy addresses, not the real IP addresses.

Note: As indicated before, the application communicates through the QualNet proxy address, not the real address. In this example, the operational node Host A communicates with Host B through the proxy address (100.100.0.46), not the real address (192.168.0.46).

IPNE Configuration

# Configure IPNE to run in NatNo modeNAT YESTRUE-EMULATION NO

# Set a receive delay of 10USRECEIVE-DELAY 10US

# Print out the maximum amount of descriptive informationPRINT-DEVICES YESDEBUG YESPRINT-PACKET-LOG YESPRINT-STATISTICS YES

# Route unsupported protocols (not TCP, UDP or ICMP) directly through

Simulated Network

Host A192.168.0.45

Host A192.168.0.45

Host B192.168.0.46

Host B192.168.0.46

192.168.0.53





# QualNetROUTE-UNKNOWN-PROTOCOLS YES

# Add one sniffing device. DEVICE-1 corresponds to the first device# written in the "PRINT-DEVICES" sectionNUM-DEVICES 1DEVICE DEVICE-1

# Configure 2 virtual nodes 192.168.0.45 and 192.168.0.46. Both# will use DEVICE-1. Nodes with IP address 100.100.0.45 and 100.100.0.46# must exist in the simulator.NUM-VIRTUAL-NODES 2VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 PROXY-ADDRESS 100.100.0.45 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.46 PROXY-ADDRESS 100.100.0.46 DEVICE DEVICE-1

At operation host A (192.168.0.45)

Linux:


Windows:

>> route add 100.100.0.46 mask 255.255.255.255 192.168.0.53

At operation host B (192.168.0.46)


Linux:


Windows:

>> route add 100.100.0.45 mask 255.255.255.255 192.168.0.53


NatYes: MulticastLocation of scenario: QUALNET_HOME/scenarios/ipne/NatYes-multicast

FIGURE 8. IPNE NatYes Multicast Real Life Configuration

The basic IPNE interface will sniff multicast UDP packets from a multicast stream transmitted from operational node to a multicast address, send packets through the QualNet simulated multicast network, and inject the received multicast packets at the virtual nodes in the multicast member group into the real counterparts.

Each operational node seeking to interact with other operational nodes through the QualNet simulator will specify a unique multicast address as the MULTICAST-RECEIVE-REAL-ADDRESS to which it will send and receive a multicast packet. For example, 10.0.0.1 will specify 225.0.10.1 as the MULTICAST-RECEIVE-REAL-ADDRESS, 10.0.0.2 will specify 225.0.10.2 as the MULTICAST-RECEIVE-REAL-ADDRESS, and so on. This multicast address has a correspondence with the group multicast address in the QualNet simulation. This correspondence is enumerated by declaring this group multicast address as the MULTICAST-TRANSMIT-ADDRESS for the virtual nodes e.g. 10.0.0.1, 10.0.0.2 and 10.0.0.3 will all specify 225.0.0.1 as the MULTICAST-TRANSMIT-ADDRESS.

The IPNE interface identifies packets going to the MULTICAST-RECEIVE-REAL-ADDRESS from the real node, for example 10.0.0.1 goes to 225.0.10.1 and captures it. The incoming packet is then encapsulated with an application header with the new destination address of the encapsulated packet is set to the MULTICAST-TRANSMIT-ADDRESS specified by the mapping (in this case 225.0.0.1) and the packet is then injected into QualNet. When the packet is received by a virtual node (say 192.0.0.2) in QualNet via the multicast routing, it de-encapsulates the packet and replaces the original destination address (225.0.10.1) with the corresponding MULTICAST-RECEIVE-REAL-ADDRESS specified in the mapping for the virtual node (225.0.10.2). This packet is then injected into the real network and the real node 10.0.0.2 receives this packet when it listens to the multicast address 225.0.10.2.

Simulated Network

10.0.0.1mmunicatingn 225.0.10.1


10.0.0.2communicating

on 225.0.10.2

multicast group225.0.0.1



10.0.0.3communicating

on 225.0.10.3



IPNE Configuration

NAT YESTRUE-EMULATION NO

# Enable Multicast. This will only work in the NAT enabled modeMULTICAST YES

PRINT-DEVICES YESPRINT-PACKET-LOG YESDEBUG YESPRINT-STATISTICS YES

# Sniff on 1 deviceNUM-DEVICES 1

# The device. May also be DEVICE-#, where # corresponds to the device# number printed at the start of simulation if PRINT-DEVICES is set to YES.DEVICE DEVICE-1

# Use 3 virtual node for example…NUM-VIRTUAL-NODES 3

# The virtual node, its address and the device it corresponds to. If# NAT is enabled, then REAL-ADDRESS would be the address of the real node# and PROXY-ADDRESS would be the address of the QualNet node.\# If multicast is enabled, then need to specify the MULTICAST-TRANSMIT-# ADDRESS # which is the address of the multicast group INSIDE QualNet to # which the MULTICAST-RECEIVE-REAL-ADDRESS ( also to be specified) is # to be mapped on to.

VIRTUAL-NODE REAL-ADDRESS 10.0.0.1 PROXY-ADDRESS 192.0.0.1 DEVICE DEVICE-1 MULTICAST-TRANSMIT-ADDRESS 225.0.0.1 MULTICAST-RECEIVE-REAL-ADDRESS 225.0.10.1



At QualNet Machine (10.0.0.100):

>> route add 225.0.10.1 eth0// DEVICE on which 10.0.0.1 is specified as the virtual node>> route add 225.0.10.2 eth0// DEVICE on which 10.0.0.2 is specified as the virtual node>> route add 225.0.10.3 eth0// DEVICE on which 10.0.0.3 is specified as the virtual node


Linux:

>> route add 225.0.10.1 eth0// DEVICE on which 10.0.0.1 is specified as the virtual node>> route add 225.0.10.2 eth0// DEVICE on which 10.0.0.2 is specified as the virtual node>> route add 225.0.10.3 eth0// DEVICE on which 10.0.0.3 is specified as the virtual node

Windows:

>> route add 225.0.10.1 mask 255.255.255.255 10.0.0.100 if 2>> route add 225.0.10.2 mask 255.255.255.255 10.0.0.100 if 2>> route add 225.0.10.3 mask 255.255.255.255 10.0.0.100 if 2

At operational host (10.0.0.1)

Linux:

>> route add 225.0.10.1 eth0

Windows:

>> route add 225.0.10.1 mask 255.255.255.255 10.0.0.1 if 2


Linux:

>> route add 225.0.10.2 eth0

Windows:

>> route add 225.0.10.2 mask 255.255.255.255 10.0.0.2 if 2


Linux:

>> route add 225.0.10.2 eth0

Windows:

>> route add 225.0.10.2 mask 255.255.255.255 10.0.0.3 if 2



TrueEmulation: Application InteroperabilityLocation of scenario: QUALNET_HOME/scenarios/ipne/bot

FIGURE 9. IPNE TrueEmulation Application Interoperability Real Life Configuration

There is an operational node (192.168.0.1) and QualNet machine (192.168.0.100). Ten emulated nodes are configured in the scenario. From node 192.168.0.1, users can access the emulated nodes (2 through 10) using TrueEmulation capability provided by IPNE. Three different stand-alone application servers can be enabled on the emulated nodes. In this example, stand-alone application server (HTTP) is enabled on node 2 through 5, stand-alone application server (FTP) is on node 4 through 6, and stand-alone application server (TELNET) is on node 7 through 9. No routing protocol is needed at operational node (192.168.0.1) since all nodes in QualNet are in the same subnet.

For stand-alone application server (FTP), if the base directory is not specified (non file access mode), the file list is created on the fly. In other words, the files shown with the “ls” command are from memory. And the contents of file will be filled with "d". Login ID and password for stand-alone application server (FTP) are ipne/ipne.

Note: Stand-alone application server (FTP) does not support the PASV mode.

Simulated Network

Host A192.168.0.1

Host A192.168.0.1

192.168.0.53



IPNE Configuration

NAT NOTRUE-EMULATION YES

# Call packet sniffing function at most once every 10 microsecondsRECEIVE-DELAY 10US

# Print sniffable devices to stdout at start of simulationPRINT-DEVICES YESPRINT-PACKET-LOG YES

NUM-DEVICES 1

# The device. May also be DEVICE-#, where # corresponds to the device# number printed at the start of simulation if PRINT-DEVICES is set to YES.DEVICE DEVICE-1

NUM-VIRTUAL-NODES 1

VIRTUAL-NODE REAL-ADDRESS 192.168.0.1 DEVICE eth1

Ping and TraceroutePing is a computer network tool used to test whether a particular host is reachable. Ping works by sending ICMP "echo request" packets to the target host and listening for ICMP "echo response" replies. Using interval timing and response rate, ping estimates the round-trip time and packet loss (if any) rate between hosts.

Traceroute is a computer network tool used to determine the route taken by packets across an IP network. The Traceroute interoperability feature's primary function is to identify UDP packet with low time-to-live (TTL) and initiate ICMP time exceeded message if a host is not the final destination. A destination host transmits back ICMP host unreachable message. ICMP implementation is not limited to support IPNE. When a node receives UDP packet that should be forwarded, it decreases TTL by one. If TTL is equal to zero (this is checked at forwarding function at network layer), then packet is dropped, and ICMP message of time-exceeded is transmitted back to the originator. If UDP packet arrives at the destination node, a node looks for the port number of UDP packet to process. However, the port number of UDP packet for traceroute is not supported, and a node transmits ICMP message of destination unreachable (port unreachable) back to the sender.

Only TrueEmulation mode supports Traceroute and Ping since packets are forwarded in network layer. As shown in Figure 10, PING is useful tools to test whether a particular Emulated host is reachable. With Traceroute, the route from an Operational host to an Emulated node can be determined.



FIGURE 10. Ping in TrueEmulation Mode

OSPF Link Interface ConfigurationLocation of scenario: QUALNET_HOME/scenario/ipne/TrueEmulation

The OSPF interface allows emulated hosts and operational hosts to share routing information through the OSPF protocol. OSPF is distributed as beta software. Figure 11 illustrates how the OSPF module functions.

FIGURE 11. OSPF Model

Simulated Network

Host A192.168.0.1


Echo ResponseEcho Request

Emulated Node


In Figure 11, there are 3 OSPF routers. One is running on an operational host (Host 1) and two are running on emulated hosts (QualNet Host 2 and QualNet Host 3). All 3 OSPF routers are neighbors and will share routing information.

IPNE ConfigurationConfigure IPNE to TrueEmulation mode: NAT NO, TRUE-EMULATION YES.

Determine which node will be the virtual node whose operational counterpart is running OSPF. There are 2 requirements for this virtual node:

• It must use the first interface listed in the IPNE configuration file.• It must not run OSPF in its QualNet configuration (only its operational counterpart should run OSPF).

To configure OSPF, do the following:

• Set <enabled> to YES to enable OSPF. Set <enabled> to NO to disable OSPF.OSPF <enabled>

• Set <number> to number of virtual nodes running OSPF.NUM-OSPF-NODES <number>

• For each virtual node running OSPF specify:OSPF-NODE-ADDRESS <address>

• Set <address> to the virtual node that is running OSPF. The virtual node must use the device listed in the IPNE configuration file.

The sample IPNE configuration file is shown below.

NAT NOTRUE-EMULATION YESRECEIVE-DELAY 10USPRINT-DEVICES YESNUM-DEVICES 1DEVICE DEVICE-1NUM-VIRTUAL-NODES 1VIRTUAL-NODE REAL-ADDRESS 192.168.0.46 DEVICE DEVICE-1 MAC-ADDRESS xx:xx:xx:xx:xx:xxOSPF YESNUM-OSPF-NODES 1OSPF-NODE-ADDRESS 192.168.0.46

OLSR Link Interface ConfigurationLocation of scenario: QUALNET_HOME/scenarios/ipne/TrueEmulation-olsr

The OLSR interface allows emulated hosts and operational hosts to share routing information through the OLSR protocol. The OLSR-IPNE interface uses the NAT disabled mode with TRUE EMULATION set to YES. The OLSR-IPNE interface allows emulated hosts running OLSR and operational hosts running OLSR to share routing information.



Figure 12 illustrates how the OLSR interface functions.

FIGURE 12. OLSR Model

In Figure 12, there are 2 OLSR operational hosts Node 1 and 2 running olsrd. Each of them has virtual node counterpart in the QualNet simulation. The Virtual Node 1 is in Subnet 1 and there exists only one emulated QualNet OLSR node in range of the Virtual Node 1. This emulated QualNet OLSR node has another interface running OLSR belonging to another subnet. Thus Virtual Node 1 can only communicate with all other nodes through the emulated QualNet OLSR Node 3 and vice-versa. A similar setup exists for Virtual Node 2.

IPNE ConfigurationThe first task is to determine which node will be the virtual node whose operational counterpart is running OLSR. The following MUST be true for the virtual node selected.

• The virtual node MUST be able to communicate with ONLY one QualNet emulated node running OLSR. This can be guaranteed by allowing a unique channel and subnet for the virtual node-Qualnet emulated node link, or having all other QualNet emulated nodes out of communication range of the virtual node.

The settings for the virtual node are modified as follows:

• The virtual node in QualNet must not run OLSR; only its operational counterpart should run OLSR. This can be done by disabling the routing protocol for the virtual node in the experiment.config file. One way of doing this is not specifying any routing protocol for the subnet the virtual node belongs to, but instead specifying the routing protocol as OLSR-INRIA only for the QualNet emulated node connected to the virtual node.

• A default route should be added in the <experiment name>.routes-static files if MAC_SPOOFING is disabled

<Virtual Node ID> N32-0.0.0.0 <IP Address of the QualNet emulated node allowed to communicate with the virtual node>

To configure OLSR, do the following:

• Add the following lines to set up the OLSR-IPNE interface:OLSR <enabled>Set <enabled> to YES to enable. NUM-OLSR-NODES <number of OLSR virtual nodes >

• Add the following line for each OLSR virtual node:

Simulated Network

Operational node 1

Subnet 2

Virtual node 1

Subnet 1 Subnet 3

Operational node 2Virtual node 2


OLSR-NODE-ADDRESS <address>

Set <address> to the address of the OLSR virtual node.


NAT NOTRUE-EMULATION YESRECEIVE-DELAY 10USPRINT-DEVICES YESNUM-DEVICES 1DEVICE DEVICE-1DEVICE DEVICE-2NUM-VIRTUAL-NODES 2VIRTUAL-NODE REAL-ADDRESS 192.168.0.52 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 10.0.1.3 DEVICE DEVICE-1

# Enable OLSR interfaceOLSR YES

#define number of operational hosts running OLSRNUM-OLSR-NODES 2#List the addresses of the operational hosts running OLSROLSR-NODE-ADDRESS 192.168.0.52OLSR-NODE-ADDRESS 10.0.1.3

OLSR-IPNE Interface Compatibility with olsrdThe OLSR-IPNE interface developed is compatible with olsrd version 0.45.0 (Linux), and 0.4.10 (Windows) which are downloadable from http://www.olsr.org. The olsrd daemon runs on the operational host machine. This daemon is responsible for adding the routes learnt by the OLSR protocol to the operational host's IP routing table. The command 'route -n' on Linux (‘route print’ on Windows) - typed on the console prompt will display the IP routing table on the operational host. The olsrd daemon reads in settings from a config file: olsrd.conf. The user should set the Ip4Broadcast address in this config file to broadcast address of QualNet (255.255.255.255 by default. You can use the net-directed broadcast address by selecting the OLSR-NET-DIRECTED-BROADCAST option in *.ipne) for the olsrd daemon to communicate with the QualNet OLSR-IPNE interface.

RIP Link Interface ConfigurationLocation of scenario: QUALNET_HOME/scenarios/ipne/TrueEmulation-RIP

The RIP interface allows emulated hosts and operational hosts to share routing information through the RIP protocol. Figure 13 illustrates how the RIP module functions.



FIGURE 13. RIP Link Interface

IPNE ConfigurationConfigure IPNE to TrueEmulation mode: NAT NO, TRUE-EMULATION YES.

Determine which node will be the virtual node whose operational counterpart is running RIP. There are two requirements for this virtual node:

• It must use the first interface listed in the IPNE configuration file.• It must not run RIP in its QualNet configuration (only its operational counterpart should run RIP).

To configure RIP, do the following:

• Set <enabled> to YES to enable RIP. Set <enabled> to NO to disable RIP.RIP <enabled>

• Set <number> to number of virtual nodes running RIP.NUM-RIP-NODES <number>

• For each virtual node running RIP specify the address. Set <address> to the virtual node that is running RIP. The virtual node must use the device listed in the IPNE configuration file.

RIP-NODE-ADDRESS <address>



NAT NOTRUE-EMULATION YESRECEIVE-DELAY 10USPRINT-DEVICES YESNUM-DEVICES 1DEVICE DEVICE-1NUM-VIRTUAL-NODES 1VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 DEVICE DEVICE-1 MAC-ADDRESS xx:xx:xx:xx:xx:xxRIP YESNUM-RIP-NODES 1RIP-NODE-ADDRESS 192.168.0.45


Parallel IPNE

Parallel IPNE

ArchitectureParallel IPNE support is currently limited to a specific architecture for parallel operation. This architecture requires all the virtual nodes in IPNE to lie on the same partition when configured in the .config file, thus setting up the same processor to handle all IPNE virtual nodes. Figure 14 illustrates this.

FIGURE 14. Parallel IPNE Architecture

In addition to this, all operational hosts must interface with QualNet using interfacing devices which lie on the same processor that is handling the partition containing the IPNE virtual nodes.

Configuring Scenarios1. Identify the IPNE virtual nodes and make sure to place them on the first partition in the .config file. A

sample format is shown to illustrate how this can be done. The following lines set up partitions for Nodes 1 to 10 in a scenario where Nodes 1 and 2 which are IPNE virtual nodes. Nodes 1 (192.168.0.45) and 2 (10.0.0.1) are set up on Partition 0 and the remaining nodes are set up on Partition 1.

PARTITION-SCHEME MANUAL[1 thru 2] PARTITION 0[3 thru 10] PARTITION 1

2. For the .ipne file, make sure that the devices that are referred to lie on the first processor machine. e.g. in the above case, the devices on which the operational hosts lie on should be on the same processor

Simulated Network

Operational host 1

Partition 0

Operational host 2

Operational host 3

Partition 1 Partition 2

Virtualnode 1

Virtualnode 2

Virtualnode 3


machine that handles Partition 0. Thus DEVICE-1 and DEVICE-2 mentioned in the .ipne file as shown below lie on the same processor machine.

VIRTUAL-NODE REAL-ADDRESS 10.0.0.1 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 DEVICE DEVICE-2

ExecutionRun QualNet by passing the extra argument to the executable:

qualnet <input-filename> -np < number of processors>


IPNE Error and Warning Messages

IPNE Error and Warning MessagesTable 3 lists the error and warning messages users are likely to encounter during configuration and running.

TABLE 3. IPNE Error and Warning Messages

Message Reason SolutionError in file ../interfaces/ipne/src/ipnetworkemulator.cpp:4050

No device is available for DEVICE-1 Make sure that the interface device is up and running

Invalid DEVICE "DEVICE-1", must not use "any" or "lo" device

Abort

Error in file ../interfaces/ipne/src/ipnetworkemulator.cpp:797

Error opening adapter: bind: Network is down (Make sure QualNet is running with root access)

No network device is configured 1. Make sure that the interface device is up and running

2. Verify the interface name in configuration file (*.ipne).

Assertion (numDevices > 0) failed in file ../interfaces/ipne/src/ipnetworkemulator.cpp:4144

No interfaces found!

Abort

PRINT-DEVICES is enabled, but no interface is found to print out.

1. Make sure that the interface device is up and running

2. Verify the interface name in configuration file (*.ipne).


Error calling ioctl on device

Abort

ioctl error Ensure that the IP address is assigned


Fail to get Node ID from Address 192.163.0.46

Abort

Failed to get Node ID from IP address

Verify the IP address in configuration (*.ipne).

Assertion ((gotNat == TRUE) && (gotDevices == TRUE)) failed in file ../interfaces/ipne/src/ipnetworkemulator.cpp:4613

IPNE NAT and all DEVICE parameters must be specified before VIRTUAL-NODE

Abort

NAT is not configured or DEVICE is not correctly configured.

1. Make sure if NAT id configured

2. Verify the number of devices (NUM-DEVICES) and DEVICE configuration (DEVICE)


Assertion (deviceIndex < data->numDevices) failed in file ../interfaces/ipne/src/ipnetworkemulator.cpp:4520

Too many devices specified! (NUM-DEVICES not specified properly, or too small)

Abort

The number of devices is smaller than DEVICE configurations.

Verify the number of devices (NUM-DEVICES) and DEVICE configuration (DEVICE)

Assertion ((data->trueEmulation == TRUE) && (data->nat == TRUE)) failed in file ../interfaces/ipne/src/ipnetworkemulator.cpp:5100

TrueEmulation mode is enabled with NAT

Abort

NAT and TRUE-EMULATION are configured YES.

1. For true emulation mode, set NAT no. Both should not be YES.

2. For NatYes mode, set TRUE-EMULATION no.


MAC address resolution timed out or VIRTUAL-NODE MAC-ADDRESS is not explicitly specified

Abort

Failed to resolve the MAC address of IP address defined in VIRTUAL-NODE

1. In True emulation mode, IPNE tries to resolve MAC address based on IPE address in REAL-ADDRESS field if MAC address is not configured. The address resolution failed after 3 retries.

2. Verify IP address in REAL-ADDRESS

3. Ensure the connectivity between operational node and QualNet machine. QualNet machine should be on the same subnet.

Assertion (nat == TRUE) failed in file ../interfaces/ipne/src/ipnetworkemulator.cpp:4257

PROXY-ADDRESS only used for NAT=YES

Abort

PROXY-ADDRESS is configured with NAT set to NO.

NO proxy address is used for NatNo mode. Verify NAT configuration.

Assertion (!nat) failed in file ../interfaces/ipne/src/ipnetworkemulator.cpp:4309

No proxy address is configured with NatYes mode

Abort

Proxy address (PROXY-ADDRESS) should be configured with NatYes mode.

1. Verify PROXY-ADDRESS configuration for NatYes mode.

2. Check NAT configuration for NatNo mode.


Node: 49 -> all virtual nodes should be on partition 0

Abort

All virtual nodes should be on parition 0 in parallel execution.

Make sure that virtual nodes are on partition 0 in the partition configuration (*.config)

TABLE 3. IPNE Error and Warning Messages (Continued)

Message Reason Solution


IPNE Error and Warning Messages

Error in file ../main/application.cpp:3973

Unknown application type S_HTTP:

S_HTTP 2 $QUALNET_HOME/scenarios/ipne/webfiles

IPNE module is not included. Recompile with IPNE library included.


pcap_findalldevs returned nothing

No interface is available Make sure that the interface device is up and running

Warning in file ../interfaces/ipne/src/ipnetworkemulator.cpp:2399

libnet error:

Failed to transmission a packet using libnet.

1. Make sure that the interface device is up and running

2. Verify that the IP address is configured correctly.

TABLE 3. IPNE Error and Warning Messages (Continued)

Message Reason Solution


Troubleshooting IPNE ScenariosThis section describes an approach for troubleshooting IPNE scenarios. It is divided in three subsections: Verify IPNE receives packets, Verify IPNE correctly process packets, and Verify destination host receives packets. This guide will identify most IPNE configuration errors. If this guide does not identify the problem. contact QualNet support.

Verify IPNE Receives PacketsCheck Routing Table on Source HostOpen a terminal window on the source host. If it is UNIX-based, enter the command "routen" and hit enter. If it is Windows-based, enter the command "route print" and hit enter.

Linux (UNIX) output:

Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface100.100.0.45 192.168.0.47 255.255.255.255 UGH 0 0 0 eth0192.168.0.45 192.168.0.47 255.255.255.255 UGH 0 0 0 eth0192.168.0.0 * 255.255.255.0 U 0 0 0 eth0127.0.0.0 * 255.0.0.0 U 0 0 0 lodefault 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Windows output:

Active Routes:Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.46 20 100.100.0.45 255.255.255.255 192.168.0.47 192.168.0.46 1 192.168.0.45 255.255.255.255 192.168.0.47 192.168.0.46 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 169.254.0.0 255.255.0.0 192.168.0.46 192.168.0.46 30 192.168.0.0 255.255.255.0 192.168.0.46 192.168.0.46 20 192.168.0.45 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.0.255 255.255.255.255 192.168.0.46 192.168.0.46 20 224.0.0.0 240.0.0.0 192.168.0.46 192.168.0.46 20 255.255.255.255 255.255.255.255 192.168.0.46 192.168.0.46 1Default Gateway: 192.168.0.1

If running in Nat-Yes mode you should see a route for the QualNet proxy address (100.100.0.45) to the QualNet host (192.168.0.47). If running in Nat-No or True-Emulation modes you should see a route for the destination host address (192.168.0.45) to the QualNet host (192.168.0.47).

Add the route if it is not present. On Linux (UNIX), switch users to root, then enter the following command substituting the proper IP addresses for your network:

route add 100.100.0.45 gw 192.168.0.47

On Windows:

route add 100.100.0.45 mask 255.255.255.255 192.168.0.47

Double check the routing table.


Troubleshooting IPNE Scenarios

Verify packets are being sent to proper destinationCheck that the source host is sending packets to the proper destination. For Nat-Yes scenarios the packets should be sent to the QualNet proxy address of the destination host (100.100.0.45 in our example). In Nat-No and True-Emulation scenarios the packet should be sent to the address of the destination host (192.168.045 in our example).

Run Ethereal on QualNet hostEthereal is a useful network analysis tool. It is used frequently when troubleshooting IPNE scenarios. Make sure Ethereal is installed on all hosts involved in an IPNE scenario. Ethereal may be downloaded from http://www.ethereal.com/.

Begin executing the IPNE scenario. Then begin capturing IP traffic using ethereal. Next begin sending the traffic that IPNE will emulate. After several packets have been captured end the ethereal packet trace. Examine the output. Figure 15 shows a packet trace for a Nat-Yes scenario.

FIGURE 15. NatYes Scenario Packet Trace

Figure 15 shows that many IP packets have been sniffed. We are interested in the IP packets sent from the source host to the destination host. In this case the source address is 192.168.0.46 and the destination address is 100.00.0.45. If this was a Nat-No or True-Emulation scenario the destination address would be 192.168.0.45.


Verify that the source address and the destination addresses are correct. Also verify that the source and destination ethernet addresses are correct. In this case the source ethernet address is 00:20:e0:6a:46:ea which is the ethernet address of the source host. The destination ethernet address is 00:11:43:18:c9:a6 which is the ethernet address of the QualNet host. Additionally check that the destination ethernet address is the proper network card if the QualNet host has multiple network cards. If the destination ethernet address is the ethernet address of the destination host then the IP packets will reach the destination host without being simulated by IPNE. If the destination ethernet address is incorrect the packet will not be emulated at all and will be dropped.

You may check the MAC address of a machine by entering the command "ifconfig" on Linux (UNIX) and "ipconfig /all” on Windows.

Check IPNE configurationNext double check that IPNE is configured properly.

The Nat-Yes configuration is as follows:

NAT YESTRUE-EMULATION NO

NUM-DEVICES 1DEVICE DEVICE-1

NUM-VIRTUAL-NODES 2VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 PROXY-ADDRESS 100.100.0.45 DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS 192.168.0.46 PROXY-ADDRESS 100.100.0.46 DEVICE DEVICE-1

Pay careful attention to the real address and proxy address of each virtual node. If the QualNet host has multiple network cards make sure IPNE is using the correct network card.

Nat-No:

NAT NOTRUE-EMULATION NO


NUM-VIRTUAL-NODES 2VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.46 DEVICE DEVICE-1

If the QualNet host has multiple network cards make sure IPNE is using the correct network card.

True-Emulation:

NAT NOTRUE-EMULATION YES


NUM-VIRTUAL-NODES 2



VIRTUAL-NODE REAL-ADDRESS 192.168.0.45 MAC-ADDRESS 00:02:3f:94:98:cd DEVICE DEVICE-1VIRTUAL-NODE REAL-ADDRESS 192.168.0.46 MAC-ADDRESS 00:20:e0:6a:46:ea DEVICE DEVICE-1

Check that the mac address of each virtual node is correct. The mac address should be the mac address of the source or destination host, not the mac address of the QualNet host. If the QualNet host has multiple network cards make sure IPNE is using the correct network card.

Check IPNE packet filterIn the IPNE configuration file (i.e., default.ipne) add the line "DEBUG YES". Run the scenario. The packet filter will be printed to stdout.

Nat-Yes should look something like this:

filter = "((ether dst 00:11:43:18:c9:a6 and ether proto \ip) and (dst 100.100.0.45 or dst 100.100.0.46) and (src 192.168.0.45 or src 192.168.0.46))"

This filter receives IP packets being sent to the QualNet host mac address if they are sent to a QualNet proxy address from an operational host's address.

Nat-No:

filter = "((ether dst 00:11:43:18:c9:a6 and ether proto \ip) and (dst 192.168.0.45 or dst 192.168.0.46) and (src 192.168.0.45 or src 192.168.0.46))"

This filter receives IP packets being sent to the QualNet host if they are sent between operational hosts.

TrueEmulation:

filter = "((ether dst 00:11:43:18:c9:a6 and ether proto \ip) or (ether proto \arp))"

This filter accepts all IP packets being sent to the QualNet host as well as any ARP packets.

Verify IPNE Correctly Processes PacketsIn True-Emulation Mode, Make Sure Packet Types are SupportedIf running in True-Emulation mode, most typical IP packets will travel through the emulated IP network. There are no known exceptions to this.

True-Emulation mode becomes complicated when operational hosts communicate directly with emulated hosts and vice versa. The scenario developer must take special care to make sure the QualNet protocol and the operational protocol are compatible. This is out of scope for the troubleshooting guide since this compatibility depends on the protocol.

In Nat-Yes, Make Sure Packet Types are SupportedIPNE Nat-Yes mode supports UDP and TCP application layer traffic. To check if unsupported Nat-Yes packets (such as ICMP) are being received enable IPNE debugging by adding the line "DEBUG YES" to the IPNE config file (i.e., default.ipne). The following output shows unsupported protocol output for ICMP:


Current Sim Time[s] = 45.002155746 Real Time[s] = 45 Completed 5%Unknown transport protocol: 1 (packet NOT routed)Unknown transport protocol: 1 (packet NOT routed)Unknown transport protocol: 1 (packet NOT routed)

IPNE will route unsupported IP packets if ROUTE-UNKNOWN-PROTOCOLS is set to YES in the IPNE config file (i.e., default.ipne). This will result in unsupported packets being injected directly to the network without traveling through the emulated IP network. The following output shows an example of this (DEBUG set to YES and PRINT-PACKET-LOG set to YES):

>>> ROUTING IP packet (not simulated) ----------------------------------------- source: 100.100.0.46 protocol: 1 tos: 0x0 dest : 192.168.0.45 id : 0 ttl: 64 via : ROUTING offset : 0 payload: 64---------------------------------------------------------------------------->>>Unknown transport protocol: 1 (packet routed)>>> ROUTING IP packet (not simulated) ----------------------------------------- source: 100.100.0.46 protocol: 1 tos: 0x0 dest : 192.168.0.45 id : 0 ttl: 64 via : ROUTING offset : 0 payload: 64---------------------------------------------------------------------------->>>Unknown transport protocol: 1 (packet routed)

Verify Destination Host Receives PacketsCheck Routing Table on QualNet HostTo run an IPNE scenario the routing table of the QualNet host does not need to be modified. It is possible, however, that the routing table may be corrupt. Verify that the routing table is not preventing the flow of packets between hosts. This may also be accomplished by pinging the source and destination hosts from the QualNet machine.



Run Ethereal on Destination Host

FIGURE 16. Verify Packets are Received

Run an ethereal trace on the destination host while running the IPNE scenario. If previous steps of this troubleshooting guide were followed you have already verified that the QualNet host receives IP packets.

The next step is to look for the IP packets sent from IPNE to the destination host. These will look very similar to the original IP packets sent to the QualNet host by the source host. If running in Nat-Yes or True-Emulation mode the IP portion of the packet will be identical. If running in Nat-Yes mode (as in the example) the IP addresses will be swapped from operational addresses to proxy addresses and vice versa. The most important difference for this troubleshooting step is that the ethernet addresses have changed in the Ethernet portion of the packet. Now the source ethernet address (00:11:43:18:c9:a6 in this example) is the mac address of the QualNet host and the destination ethernet address (00:02:3f:94:98:cd) is the mac address of the destination host. If these packets are present but communication is not successful continue with the next steps. If these packets are not present then proceed to the step "Verify emulated IP packets reach destination in simulated QualNet network."

If Nat-Yes, Verify That Addresses are Swapped ProperlyIf the IPNE scenario is Nat-Yes, verify that the proxy and real addresses are swapped properly for outgoing IPNE packets. In our example the original IP packets are sent from 192.168.0.46 (source address) to 100.100.0.45 (destination proxy address). After leaving IPNE the IP packets are sent from 100.100.0.46 (source proxy address) to 192.168.0.45 (destination address). This can be verified from the Ethereal packet trace.


If Nat-Yes, Verify That Protocol Works with NATProtocols that embed IP addresses in the data portion of an IP packet do not work well with NAT. Examples of protocols that do not work will with NAT are FTP and SIP. This is unavoidable, but can be worked around.

The best solution is to use Nat-No mode instead of Nat-Yes mode. If this is not an option then IPNE needs to identify the protocol's packets and swap the addresses. See IPNE's treatment of H.323 as an example.

Verify TCP/UDP Checksums are Correct

FIGURE 17. Verify TCP/UDP Checksums are Correct

In the same packet trace conducted in "verify packets are received" open the TCP or UDP portion of the packets that were sent to the destination host. Check that the Checksum field is correct.

Verify Emulated IP Packets Reach Destination in Simulated QualNet NetworkThis section of the troubleshooting guide should be followed if IP packets are entering the QualNet simulation through IPNE but not leaving it. This is most likely caused by packet drops in the simulated network. To identify where the packets are dropped we will generate a packet trace for all QualNet packets. This section will give a brief introduction to packet tracing. For more information see the "QualNet Packet Tracer" chapter in the QualNet 4.5 User's Guide.

Edit the scenario configuration file (i.e., default.config). Add the lines "PACKET-TRACE YES" and "TRACE-ALL YES". This will configure QualNet to generate a packet trace. Next run the IPNE scenario. A



file called "experiment.trace" will be created. Open the file in the GUI to examine the packet trace. Figure 18 shows an example trace of a True-Emulation scenario:

FIGURE 18. Example TrueEmulation Trace Scenario

In the diagram an IP packet is sent from Node 2 (192.168.0.45) to Node 1 (192.168.0.46). This can be seen in the right hand side of the diagram where several events are seen occurring on Node 2 as it prepares to send the packet, then on Node 1 as it receives the packet. The left hand side of the diagram shows the contents of the IP packet, which in True-Emulation mode would be the same as the IP packet sent from the source host. In Nat-Yes and Nat-No modes the contents of the IP packet on the left side of the diagram will currently not match the real IP packet. This happens because the real IP packet is encapsulated in a QualNet IP packet.

Verify that the incoming IP packets reach their destination. If the IP packets do not reach their destination then the network should be analyzed and the problem identified.


qualnet 4.5 network emulation interface model library · network emulation interface model library...

Documents