QualNet 4.5 Network Emulation Interface Model Library

Transcription

1 QualNet 4.5 Network Emulation Interface Model Library February 2008 Scalable Network Technologies, Inc Center Drive West, Suite 520 Los Angeles, CA Phone: Fax: QualNet 4.5 Network Emualtion Interface Model Library 1

2 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 Center Drive West, Suite 520 Los Angeles, CA Phone: Fax: QualNet 4.5 Network Emualtion Interface Model Library

3 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 Simulated Network Node B Node A Node C Source Computer FIGURE 1. IP Network Emulator Overview IP Network Emulator Destination Computer QualNet 4.5 Network Emualtion Interface Model Library 3

4 Building the IP Network Emulator The 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 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 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: Or UNIX: nmake clean nmake make clean make 4 QualNet 4.5 Network Emualtion Interface Model Library

5 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: Or UNIX: nmake clean nmake make clean make 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/Makefilecommon 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. QualNet 4.5 Network Emualtion Interface Model Library 5

6 Configuration and Terminology Figure 2 shows the IPNE configuration. Simulated Network Host 1 Node 1 Node A Node B Node 2 Host 2 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. 6 QualNet 4.5 Network Emualtion Interface Model Library

7 IPNE Configuration Parameters 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 YES IPNE-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 NAT <enabled> TRUE-EMULATION <enabled> RECEIVE-DELAY <delay> PRINT-DEVICES <enabled> NUM-DEVICES <number> DEVICE <name> NUM-VIRTUAL-NODES <number> Explanation Set <enabled> to YES to enable Network Address Translation. Set <enabled> to NO to disable NAT. Set <enabled> to YES to enable true emulation. 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. 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. Set <number> to specify the number of devices that will sniff for packets. 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. Set <number> to the number of virtual nodes. QualNet 4.5 Network Emualtion Interface Model Library 7

8 TABLE 1. IPNE Parameters (Continued) Parameter 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> ROUTE-UNKNOWN-PROTOCOLS DEBUG PRINT-PACKET-LOG Explanation 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. 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. When set to YES, this prints out useful IPNE debugging information. When set to YES, this prints a log of all incoming and outgoing IP packets. 8 QualNet 4.5 Network Emualtion Interface Model Library

9 IPNE Configuration Parameters TABLE 1. IPNE Parameters (Continued) PRINT-STATISTICS MULTICAST <enabled> OSPF <enabled> Parameter NUM-OSPF-NODES <number> OSPF-NODE-ADDRESS <address> RIP <enabled> NUM-RIP-NODES <number> RIP-NODE-ADDRESS <address> OLSR <enabled> NUM-OLSR-NODES <number> OLSR-NODE-ADDRESS <address> OLSR-NET-DIRECTED- BROADCAST <enabled> Explanation When set to YES, this prints statistics describing its operation every three seconds. Example statistics output: IPNE statistics real time = s sim time = s in = 0 jitter = ms out = 0 pps = 0.00 max int = ms avg int = 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. Set <enabled> to YES to enable multicast. This option is only supported under NatYes mode. 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. Set <number> to specify the number of OSPF nodes. Enter OSPF node address for each OSPF node. 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. Set <number> to specify the number of RIP operational hosts. Enter node address for each operational host running RIP. 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. Set <number> to specify the number of OLSR nodes. Enter OLSR node address for each OLSR node. Set <enabled> to Yes to enable net-directed broadcast address for OLSR packets. Limited broadcast address ( ) is used by default unless otherwise specified. QualNet 4.5 Network Emualtion Interface Model Library 9

10 TABLE 1. IPNE Parameters (Continued) Parameter PRECEDENCE <enabled> NUM-PRECEDENCE-PAIRS <number> PRIORITY <value> SOURCE- ADDRESS <address> DESTINATION-ADDRESS <address> MAC-SPOOFING <enabled> Explanation 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. Set <number> to specify the number of source/destination pairs for precedence configuration. Set <value> to specify the priority level, and enter IP address for source and destination pair. 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. 10 QualNet 4.5 Network Emualtion Interface Model Library

11 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). NatNo NatNo 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 Topology The 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 Configuration After 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 Configuration See Parameters in this document for a detailed list of configuration parameters. 1. Specify the packet sniffing device(s). 2. Set NAT to NO 3. 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. Example Figure 3 shows the example setup 1. QualNet 4.5 Network Emualtion Interface Model Library 11

12 Host Host QualNet Host QualNet Host QualNet Host Host QualNet Simulation FIGURE 3. Example Setup 1 Example Setup There are three operational hosts: Host 1, Host 2, and Host 3. Their IP addresses are , and respectively. The QualNet simulation is running on a computer with the IP address There are 3 virtual nodes in the network named QualNet Host 1, QualNet Host 2 and QualNet Host 3 with IP addresses , and respectively. Example Explanation Consider the following scenario: Host 1 ( ) wants to send a UDP packet to Host 3 ( ) through the emulated network. Host 1 sends the UDP packet to 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 Configuration The following contents of the IPNE file implement the above example. NAT NO TRUE-EMULATION NO NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 3 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 The routing tables of each host must be configured manually. Host 1 must forward packets with a destination IP address of (Host 2) or (Host 3) to (the computer 12 QualNet 4.5 Network Emualtion Interface Model Library

13 IPNE Modes running the QualNet simulation). Host 2 must forward packets with a destination IP address of (QualNet Host 1) or to Host 3 must forward packets with a destination IP address of or to The QualNet host must be configured to not forward IP packets. TrueEmulation TrueEmulation 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 Topology The 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 Configuration True Emulation mode does not require any system configuration. QualNet Configuration Follow 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. QualNet 4.5 Network Emualtion Interface Model Library 13

14 Example Figure 4 shows example setup 2. Host Host QualNet Host QualNet Host QualNet Host QualNet Host Host QualNet Simulation FIGURE 4. Example Setup 2 Example Setup In Figure 4, there are three operational hosts: Host 1, Host 2, and Host 3. Their IP addresses are , and respectively. The QualNet simulation is running on a computer with the IP address There are 3 virtual nodes in the network named QualNet Host 1, QualNet Host 2 and QualNet Host 3 with IP addresses , , and respectively. There is also an emulated host with IP address There are other emulated hosts depicted but they are ignored for this example. Example Explanation #1 Consider the following scenario: Host 1 ( ) wants to send a UDP packet to QualNet Host 4 ( ). Since Host 1 is in the same subnet as it broadcasts an ARP packet requesting 's MAC address. The IPNE module receives the ARP request, realizes that 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 #2 Consider the following scenario: Host 1 ( ) wants to send a UDP packet to Host 3 ( ) 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 14 QualNet 4.5 Network Emualtion Interface Model Library

15 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 Configuration The following contents of an experiment.ipne file implements the above example. NAT NO TRUE-EMULATION YES NUM-DEVICES 3 DEVICE DEVICE-1 DEVICE DEVICE-2 DEVICE DEVICE-3 NUM-VIRTUAL-NODES 3 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 MAC-ADDRESS xx:xx:xx:xx:xx:xx VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-2 MAC-ADDRESS xx:xx:xx:xx:xx:xx VIRTUAL-NODE REAL-ADDRESS 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. NatYes NatYes 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 Topology The 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 Configuration After 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 QualNet 4.5 Network Emualtion Interface Model Library 15

16 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 Configuration See 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. Example Figure 5 shows the configuration setup. See Parameters for a detailed list of configuration parameters. Host Host QualNet Host QualNet Host QualNet Host Host QualNet Simulation FIGURE 5. Configuration Setup Example Setup In this example there are three real computers: Host 1, Host 2, and Host 3. Their IP addresses are , and respectively. The QualNet simulation is running on a computer with the IP address Each real computer corresponds to a simulated computer in the QualNet simulation: with , with , and with The IP addresses corresponding to the real IP addresses ( , and ) 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. 16 QualNet 4.5 Network Emualtion Interface Model Library

17 IPNE Modes Example Explanation Consider the following scenario: Host 1 ( ) wants to send a UDP packet to Host 3 ( ) through the emulated network. Sending the packet directly to Host 3 s IP address 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 ( ) with a source address of Host 1 ( ). 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 ( ) and a source of QualNet Host 1 ( ). 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 Likewise from the perspective of Host 3, QualNet Host 1 is a real computer with IP address Example Configuration The following contents of the experiment.ipne file implements the configuration in the above example. NAT YES TRUE-EMULATION NO NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 3 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 The routing tables of each host must be configured manually. Host 1 must forward packets with a destination IP address of (QualNet Host 2) or (QualNet Host 3) to (the computer running the QualNet simulation). Host 2 must forward packets with a destination IP address of (QualNet Host 1) or to Host 3 must forward packets with a destination IP address of or to The QualNet host must be configured to not forward IP packets. Summary of Modes The 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. QualNet 4.5 Network Emualtion Interface Model Library 17

18 TABLE 2. Advantages/Disadvantages of the Tree Mode NatYes advantages NatYes disadvantages NatNo advantages NatNo disadvantages TrueEmulation advantages TrueEmulation disadvantages Description 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.) 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 Configuration is intuitive. Works with all applications or protocols. 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. Configuration is intuitive. Works with all applications and protocols. Allows real protocols to communicate with simulated QualNet protocols and vice versa. 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. 18 QualNet 4.5 Network Emualtion Interface Model Library

19 Application Layer Interoperability Application Layer Interoperability With 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. Configuration Stand-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: where S_FTP <node ID> S_TELNET <node ID> S_HTTP <node ID> <base directory> <node ID> : ID of the node <Base directory> : Directory that contains the web page QualNet 4.5 Network Emualtion Interface Model Library 19

20 Example Real Life Scenarios In 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. NatNo Location of scenario: QUALNET_HOME/scenarios/ipne/NatNo Simulated Network QualNet Host QualNet Host Host A Host B FIGURE 6. IPNE NatNo Real Life Configuration In Figure 6, there are two operational hosts, and The QualNet simulation is running on a computer with the IP address There are 2 Virtual nodes in QualNet with IP addresses and The routing table on operational nodes should be configured to forward packets to QualNet node. 20 QualNet 4.5 Network Emualtion Interface Model Library

21 Example Real Life Scenarios IPNE Configuration # Configure IPNE to run in NatNo mode NAT NO TRUE-EMULATION NO # Set a receive delay of 10US RECEIVE-DELAY 10US # Print out the maximum amount of descriptive information PRINT-DEVICES YES DEBUG YES PRINT-PACKET-LOG YES PRINT-STATISTICS YES # Add one sniffing device. DEVICE-1 corresponds to the first device # written in the "PRINT-DEVICES" section NUM-DEVICES 1 DEVICE DEVICE-1 # Configure 2 virtual nodes and Both # will use DEVICE-1. Nodes with IP addresses and # must exist in the simulator. NUM-VIRTUAL-NODES 2 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 At operation host A ( ) Linux: >> ifconfig eth netmask >> route add -host gw Windows: >> route add mask At operation host B ( ) >> ifconfig eth netmask >> route add -host gw Linux: >> ifconfig eth netmask >> route add -host gw Windows: >> route add mask QualNet 4.5 Network Emualtion Interface Model Library 21

22 NatYes: Unicast Location of scenario: QUALNET_HOME/scenarios/ipne/NatYes Simulated Network QualNet Host QualNet Host Host A Host B FIGURE 7. IPNE NatYes Unicast Real Life Configuration For single interface and single-hop scenario, there are two operational hosts, and in the same subnet. The QualNet simulation is running on a computer with the IP addresses Each operational host corresponds to a simulated node in the QualNet simulation: with and with The IP addresses corresponding to the real IP addresses ( and ) 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 ( ), not the real address ( ). IPNE Configuration # Configure IPNE to run in NatNo mode NAT YES TRUE-EMULATION NO # Set a receive delay of 10US RECEIVE-DELAY 10US # Print out the maximum amount of descriptive information PRINT-DEVICES YES DEBUG YES PRINT-PACKET-LOG YES PRINT-STATISTICS YES # Route unsupported protocols (not TCP, UDP or ICMP) directly through 22 QualNet 4.5 Network Emualtion Interface Model Library

23 Example Real Life Scenarios # QualNet ROUTE-UNKNOWN-PROTOCOLS YES # Add one sniffing device. DEVICE-1 corresponds to the first device # written in the "PRINT-DEVICES" section NUM-DEVICES 1 DEVICE DEVICE-1 # Configure 2 virtual nodes and Both # will use DEVICE-1. Nodes with IP address and # must exist in the simulator. NUM-VIRTUAL-NODES 2 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 At operation host A ( ) Linux: >> ifconfig eth netmask >> route add -host gw Windows: >> route add mask At operation host B ( ) >> ifconfig eth netmask >> route add -host gw Linux: >> ifconfig eth netmask >> route add -host gw Windows: >> route add mask QualNet 4.5 Network Emualtion Interface Model Library 23

24 NatYes: Multicast Location of scenario: QUALNET_HOME/scenarios/ipne/NatYes-multicast Simulated Network multicast group mmunicating n QualNet Host QualNet Host QualNet Host communicating on communicating on 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, will specify as the MULTICAST- RECEIVE-REAL-ADDRESS, will specify 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 , and will all specify as the MULTICAST-TRANSMIT-ADDRESS. The IPNE interface identifies packets going to the MULTICAST-RECEIVE-REAL-ADDRESS from the real node, for example goes to 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 ) and the packet is then injected into QualNet. When the packet is received by a virtual node (say ) in QualNet via the multicast routing, it de-encapsulates the packet and replaces the original destination address ( ) with the corresponding MULTICAST-RECEIVE-REAL-ADDRESS specified in the mapping for the virtual node ( ). This packet is then injected into the real network and the real node receives this packet when it listens to the multicast address QualNet 4.5 Network Emualtion Interface Model Library

25 Example Real Life Scenarios IPNE Configuration NAT YES TRUE-EMULATION NO # Enable Multicast. This will only work in the NAT enabled mode MULTICAST YES PRINT-DEVICES YES PRINT-PACKET-LOG YES DEBUG YES PRINT-STATISTICS YES # Sniff on 1 device 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 # 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 PROXY-ADDRESS DEVICE DEVICE-1 MULTICAST-TRANSMIT-ADDRESS MULTICAST-RECEIVE-REAL-ADDRESS VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 MULTICAST-TRANSMIT-ADDRESS MULTICAST-RECEIVE-REAL-ADDRESS VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 MULTICAST-TRANSMIT-ADDRESS MULTICAST-RECEIVE-REAL-ADDRESS At QualNet Machine ( ): >> route add eth0 // DEVICE on which is specified as the virtual node >> route add eth0 // DEVICE on which is specified as the virtual node >> route add eth0 // DEVICE on which is specified as the virtual node QualNet 4.5 Network Emualtion Interface Model Library 25

26 Linux: Windows: >> route add eth0 // DEVICE on which is specified as the virtual node >> route add eth0 // DEVICE on which is specified as the virtual node >> route add eth0 // DEVICE on which is specified as the virtual node >> route add mask if 2 >> route add mask if 2 >> route add mask if 2 At operational host ( ) Linux: >> route add eth0 Windows: >> route add mask if 2 At operational host ( ) Linux: >> route add eth0 Windows: >> route add mask if 2 At operational host ( ) Linux: >> route add eth0 Windows: >> route add mask if 2 26 QualNet 4.5 Network Emualtion Interface Model Library

27 Example Real Life Scenarios TrueEmulation: Application Interoperability Location of scenario: QUALNET_HOME/scenarios/ipne/bot Simulated Network Host A QualNet Host FIGURE 9. IPNE TrueEmulation Application Interoperability Real Life Configuration There is an operational node ( ) and QualNet machine ( ). Ten emulated nodes are configured in the scenario. From node , 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 ( ) 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. QualNet 4.5 Network Emualtion Interface Model Library 27

28 IPNE Configuration NAT NO TRUE-EMULATION YES # Call packet sniffing function at most once every 10 microseconds RECEIVE-DELAY 10US # Print sniffable devices to stdout at start of simulation PRINT-DEVICES YES PRINT-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 DEVICE eth1 Ping and Traceroute Ping 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. 28 QualNet 4.5 Network Emualtion Interface Model Library

29 Example Real Life Scenarios Simulated Network Host A QualNet Host Emulated Node Echo Request Echo Response FIGURE 10. Ping in TrueEmulation Mode OSPF Link Interface Configuration Location 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 QualNet 4.5 Network Emualtion Interface Model Library 29

30 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 Configuration Configure 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 NO TRUE-EMULATION YES RECEIVE-DELAY 10US PRINT-DEVICES YES NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 MAC-ADDRESS xx:xx:xx:xx:xx:xx OSPF YES NUM-OSPF-NODES 1 OSPF-NODE-ADDRESS OLSR Link Interface Configuration Location 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. 30 QualNet 4.5 Network Emualtion Interface Model Library

31 Example Real Life Scenarios Figure 12 illustrates how the OLSR interface functions. Simulated Network Subnet 2 Subnet 1 Subnet 3 Operational node 1 Virtual node 1 Virtual node 2 Operational node 2 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 Configuration The 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> N <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: QualNet 4.5 Network Emualtion Interface Model Library 31

32 OLSR-NODE-ADDRESS <address> Set <address> to the address of the OLSR virtual node. The sample IPNE configuration file is shown below. NAT NO TRUE-EMULATION YES RECEIVE-DELAY 10US PRINT-DEVICES YES NUM-DEVICES 1 DEVICE DEVICE-1 DEVICE DEVICE-2 NUM-VIRTUAL-NODES 2 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 # Enable OLSR interface OLSR YES #define number of operational hosts running OLSR NUM-OLSR-NODES 2 #List the addresses of the operational hosts running OLSR OLSR-NODE-ADDRESS OLSR-NODE-ADDRESS OLSR-IPNE Interface Compatibility with olsrd The OLSR-IPNE interface developed is compatible with olsrd version (Linux), and (Windows) which are downloadable from 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 ( 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 Configuration Location 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. 32 QualNet 4.5 Network Emualtion Interface Model Library

33 Example Real Life Scenarios FIGURE 13. RIP Link Interface IPNE Configuration Configure 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> QualNet 4.5 Network Emualtion Interface Model Library 33

34 The sample IPNE configuration file is shown below. NAT NO TRUE-EMULATION YES RECEIVE-DELAY 10US PRINT-DEVICES YES NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 MAC-ADDRESS xx:xx:xx:xx:xx:xx RIP YES NUM-RIP-NODES 1 RIP-NODE-ADDRESS QualNet 4.5 Network Emualtion Interface Model Library

35 Parallel IPNE Parallel IPNE Architecture Parallel 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. Partition 0 Partition 1 Partition 2 Virtual node 1 Operational host 1 Virtual node 2 Operational host 2 Virtual node 3 Simulated Network Operational host 3 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 Scenarios 1. 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 ( ) and 2 ( ) 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 QualNet 4.5 Network Emualtion Interface Model Library 35

36 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 DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-2 Execution Run QualNet by passing the extra argument to the executable: qualnet <input-filename> -np < number of processors> 36 QualNet 4.5 Network Emualtion Interface Model Library

37 IPNE Error and Warning Messages IPNE Error and Warning Messages Table 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 Solution Error in file../interfaces/ipne/src/ ipnetworkemulator.cpp:4050 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) Assertion (numdevices > 0) failed in file../interfaces/ipne/src/ ipnetworkemulator.cpp:4144 No interfaces found! Abort Error in file../interfaces/ipne/src/ ipnetworkemulator.cpp:302 Error calling ioctl on device Abort Error in file../interfaces/ipne/src/ ipnetworkemulator.cpp:4650 Fail to get Node ID from Address Abort 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 No device is available for DEVICE-1 No network device is configured PRINT-DEVICES is enabled, but no interface is found to print out. ioctl error Failed to get Node ID from IP address NAT is not configured or DEVICE is not correctly configured. Make sure that the interface device is up and running 1. Make sure that the interface device is up and running 2. Verify the interface name in configuration file (*.ipne). 1. Make sure that the interface device is up and running 2. Verify the interface name in configuration file (*.ipne). Ensure that the IP address is assigned Verify the IP address in configuration (*.ipne). 1. Make sure if NAT id configured 2. Verify the number of devices (NUM-DEVICES) and DEVICE configuration (DEVICE) QualNet 4.5 Network Emualtion Interface Model Library 37

38 TABLE 3. IPNE Error and Warning Messages (Continued) Message Reason Solution 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 Assertion ((data->trueemulation == TRUE) && (data->nat == TRUE)) failed in file../interfaces/ipne/src/ ipnetworkemulator.cpp:5100 TrueEmulation mode is enabled with NAT Abort Error in file../interfaces/ipne/src/ ipnetworkemulator.cpp:5669 MAC address resolution timed out or VIRTUAL-NODE MAC- ADDRESS is not explicitly specified Abort Assertion (nat == TRUE) failed in file../interfaces/ipne/src/ ipnetworkemulator.cpp:4257 PROXY-ADDRESS only used for NAT=YES Abort Assertion (!nat) failed in file../ interfaces/ipne/src/ ipnetworkemulator.cpp:4309 No proxy address is configured with NatYes mode Abort Error in file../interfaces/ipne/src/ ipnetworkemulator.cpp:4670 Node: 49 -> all virtual nodes should be on partition 0 Abort The number of devices is smaller than DEVICE configurations. NAT and TRUE-EMULATION are configured YES. Failed to resolve the MAC address of IP address defined in VIRTUAL- NODE PROXY-ADDRESS is configured with NAT set to NO. Proxy address (PROXY-ADDRESS) should be configured with NatYes mode. All virtual nodes should be on parition 0 in parallel execution. Verify the number of devices (NUM- DEVICES) and DEVICE configuration (DEVICE) 1. For true emulation mode, set NAT no. Both should not be YES. 2. For NatYes mode, set TRUE- EMULATION no. 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. NO proxy address is used for NatNo mode. Verify NAT configuration. 1. Verify PROXY-ADDRESS configuration for NatYes mode. 2. Check NAT configuration for NatNo mode. Make sure that virtual nodes are on partition 0 in the partition configuration (*.config) 38 QualNet 4.5 Network Emualtion Interface Model Library

39 IPNE Error and Warning Messages TABLE 3. IPNE Error and Warning Messages (Continued) Message Reason Solution Error in file../main/ application.cpp:3973 Unknown application type S_HTTP: S_HTTP 2 $QUALNET_HOME/ scenarios/ipne/webfiles Error in file../interfaces/ipne/src/ ipnetworkemulator.cpp:4004 pcap_findalldevs returned nothing Warning in file../interfaces/ipne/src/ ipnetworkemulator.cpp:2399 libnet error: IPNE module is not included. No interface is available Failed to transmission a packet using libnet. Recompile with IPNE library included. Make sure that the interface device is up and running 1. Make sure that the interface device is up and running 2. Verify that the IP address is configured correctly. QualNet 4.5 Network Emualtion Interface Model Library 39

40 Troubleshooting IPNE Scenarios This 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 Packets Check Routing Table on Source Host Open 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 table Destination Gateway Genmask Flags Metric Ref Use Iface UGH eth UGH eth * U eth * U lo default UG eth0 Windows output: Active Routes: Network Destination Netmask Gateway Interface Metric Default Gateway: If running in Nat-Yes mode you should see a route for the QualNet proxy address ( ) to the QualNet host ( ). If running in Nat-No or True-Emulation modes you should see a route for the destination host address ( ) to the QualNet host ( ). 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: On Windows: route add gw route add mask Double check the routing table. 40 QualNet 4.5 Network Emualtion Interface Model Library

41 Troubleshooting IPNE Scenarios Verify packets are being sent to proper destination Check 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 ( in our example). In Nat- No and True-Emulation scenarios the packet should be sent to the address of the destination host ( in our example). Run Ethereal on QualNet host Ethereal 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 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 and the destination address is If this was a Nat-No or True-Emulation scenario the destination address would be QualNet 4.5 Network Emualtion Interface Model Library 41

42 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 configuration Next double check that IPNE is configured properly. The Nat-Yes configuration is as follows: NAT TRUE-EMULATION YES NO NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 2 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS PROXY-ADDRESS 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 TRUE-EMULATION NO NO NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 2 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 VIRTUAL-NODE REAL-ADDRESS DEVICE DEVICE-1 If the QualNet host has multiple network cards make sure IPNE is using the correct network card. True-Emulation: NAT TRUE-EMULATION NO YES NUM-DEVICES 1 DEVICE DEVICE-1 NUM-VIRTUAL-NODES 2 42 QualNet 4.5 Network Emualtion Interface Model Library

43 Troubleshooting IPNE Scenarios VIRTUAL-NODE DEVICE DEVICE-1 VIRTUAL-NODE DEVICE DEVICE-1 REAL-ADDRESS MAC-ADDRESS 00:02:3f:94:98:cd REAL-ADDRESS MAC-ADDRESS 00:20:e0:6a:46:ea 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 filter In 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 or dst ) and (src or src ))" 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 or dst ) and (src or src ))" 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 Packets In True-Emulation Mode, Make Sure Packet Types are Supported If 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 Supported IPNE 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: QualNet 4.5 Network Emualtion Interface Model Library 43

44 Current Sim Time[s] = 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: protocol: 1 tos: 0x0 dest : id : 0 ttl: 64 via : ROUTING offset : 0 payload: >>> Unknown transport protocol: 1 (packet routed) >>> ROUTING IP packet (not simulated) source: protocol: 1 tos: 0x0 dest : id : 0 ttl: 64 via : ROUTING offset : 0 payload: >>> Unknown transport protocol: 1 (packet routed) Verify Destination Host Receives Packets Check Routing Table on QualNet Host To 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. 44 QualNet 4.5 Network Emualtion Interface Model Library

45 Troubleshooting IPNE Scenarios 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 Properly If 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 (source address) to (destination proxy address). After leaving IPNE the IP packets are sent from (source proxy address) to (destination address). This can be verified from the Ethereal packet trace. QualNet 4.5 Network Emualtion Interface Model Library 45

46 If Nat-Yes, Verify That Protocol Works with NAT Protocols 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 Network This 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 46 QualNet 4.5 Network Emualtion Interface Model Library

47 Troubleshooting IPNE Scenarios 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 ( ) to Node 1 ( ). 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 Emualtion Interface Model Library 47