Model Features
Working of an Emulation Application in NetSim
NOTE: The following explanation is provided assuming that you have performed all necessary configuration required to divert network traffic via the system running NetSim Emulator. (This is explained in section 9 of the User Manual.
The following parameters are specific to Emulation Application in NetSim:
Source_Real_IP
Source_Port
Destination_Real_IP
Destination_Port
Unlike Simulation, if users want to connect real devices running live applications to the simulator, then Emulation component is required. The Emulation Application in the traffic generator allows users to pump in real traffic into the Simulator.
The real application is mapped using the source and destination IP addresses that we set in the Emulation Application.
Various combination of Emulation Parameters are as follows:
Device Specific Emulation:
Example 1:
SOURCE_REAL_IP = 192.168.0.151
SOURCE_PORT = 0
DESTINATION_REAL_IP = 192.168.0.202
DESTINATION_PORT = 0
Dispatches all packets with the source real IP 192.168.0.151 and destination real IP as 192.168.0.202, into the Simulator.
Example 2:
SOURCE_REAL_IP = 192.168.0.151
SOURCE_PORT = 0
DESTINATION_REAL_IP = 0.0.0.0
DESTINATION_PORT = 0
Dispatches all packets from source real IP 192.168.0.151 regardless of whatever is the destination real IP, into the Simulator.
Example 3:
SOURCE_REAL_IP = 0.0.0.0
SOURCE_PORT = 0
DESTINATION_REAL_IP = 192.168.0.202
DESTINATION_PORT = 0
Dispatches all packets to destination real IP 192.168.0.202 regardless of whatever is the source real IP, into the Simulator.
Example 4:
SOURCE_REAL_IP = 0.0.0.0
SOURCE_PORT = 0
DESTINATION_REAL_IP = 0.0.0.0
DESTINATION_PORT = 0
Dispatches all packets that are reaching the Emulator Device regardless of whatever is the source or destination, into the Simulator.
Application Specific Emulation
Example 1:
SOURCE_REAL_IP = 192.168.0.151
SOURCE_PORT = 5004
DESTINATION_REAL_IP = 192.168.0.202
DESTINATION_PORT = 6245
Dispatches all packets with the source real IP 192.168.0.151, source Port No 5004, destination real IP as 192.168.0.202 and destination Port No 6245 into the Simulator.
Emulation Specific Metrics
On running an Emulation Application Users can optionally obtain the following log files which are Wireshark compatible .pcap files:
Figure-1: Different Emulation Specific Metrics in Result window
All_Network_Packets - Log of all packets flowing via the system running NetSim Emulator.
Dispatched_To_Emulator - Log of packets for which were sent to NetSim based on Emulation Application is configured in NetSim.
Reinjected_From_Emulator - Log of packets that successfully reached the virtual destination node in NetSim Simulator and was re-injected into the network.
Not_Dispatched_To_Emulator - Log of packets flowing via the system running NetSim emulator but not dispatched to emulator (All_Network_Packets minus Disptached_To_Emulator)
Delay measurement when pinging through NetSim Emulator
Pinging through NetSim emulator takes only one direction delay, if you have set only one application with Ping Source IP and ping Destination IP. This is because PING is a two way application and constitutes PING_REQUEST and PING_REPLY. For ping to take round trip delay users must configure two Emulation Applications, one for forward PING_REQUEST and other for the reverse PING_REPLY.
For example: If you are running a ping from the IP 192.168.0.151 to an IP 192.168.0.202 the time take will normally be around 1ms.
Figure-2: Pinging from one device to other device and total time taken by 1ms
Now we create a network scenario in NetSim similar to the screenshot shown below Figure-3.
Figure-3: Network Topology with Emulation Application
We reset the propagation delay in both the wired links to 5 µs.
Figure-4: Wired Link properties window
We configure an Emulation application between the wired nodes with the source and destination real IP specified, as shown below:
Figure-5: Application properties window for Application 1
On running the simulation, you will observe the variation in the time taken to get the ping reply in the source system, as shown below:
Figure-6: Pinging from one device to other device and total time taken by 11ms and including 10µs additional delay for both the links
Ping packets has experienced an additional delay of 10µs which is a sum of the delay in both the links.
The additional delay experienced by ping packets is not 20µs because, the application that we have configured applies to only the Ping Request Packets which has the Source IP as 192.168.0.151 and Destination IP as 192.168.0.202.
The Ping Reply Packets has the Source IP as 192.168.0.202 and Destination IP as 192.168.0.151, for which we have not configured any application.
For the ping to take the round trip delay, we will have to configure one more application for the reverse traffic. On adding an application for the reverse traffic as shown below:
Figure-7: Application properties window for Second application
We will now be able to see round trip delay being experienced by the PING application, as shown below:
Figure-8: Total round-trip time taken by 20ms
Ping experiences an additional overall delay of 20ms, which is the sum of the delays experienced by Ping Request and Ping Reply (10ms + 10ms).
Jitter in NetSim Emulations
Jitter is defined as a variation in the delay of received packets. Let us suppose at the sending side, packets are sent in a continuous stream with the packets spaced evenly apart. Due to network congestion, improper queuing, or configuration errors, this steady stream can become lumpy, or the delay between each packet can vary instead of remaining constant. This variation in delay is ‘jitter’. While there are many ways of measuring this variation, in NetSim ‘jitter’ is measured as the statistical variance of delay. Variance is defined as the square of deviation from the mean.
Introducing Jitter using Background traffic
Background traffic can be used to test the performance of applications when link bandwidth is consumed by other traffic. It can also be used to induce jitter for testing real-time applications.
The Background traffic in NetSim can be modelled as a Poisson process in which bursts of data of a fixed size are transmitted at an average rate such that the link will be occupied at the specified link utilization rate. Because it is a random process, over short periods the actual background traffic link utilization rate may vary from the configured value. The rate of arrival of background traffic frames affects the jitter. Larger number of background packets induce greater jitter in competing traffic. In NetSim, the way to increase the number of background packets arriving is to reduce the inter-arrival time of that application, as explained in the link https://tetcos.freshdesk.com/support/solutions/articles/14000067807-how-do-i-introduce-jitter-in-netsim-simulations-emulations-