This can be achieved by sourcing incoming traffic from a host generator and sinking the traffic at a node within the network through the use of this worm holing function. This will allow more time for the processing of other routes within the simulation.
3.1.6 Packet Monitoring
This is simply the ability to capture packets from a node within the simulated network.
This is done by transmitting packets that meet set criteria out of a pseudo or real in-terface. This will then allow for existing applications, such as wireshark2 or tcpdump3, to capture on these interfaces and log any data that is deemed important or significant.
This also allows for opening up a pcap interface for injection and sniffing of packets of the node that the interface is bound to, and allows integration with existing tools.
Other more customizable applications can be created through the use of Libpcap in Python, C, C++ or any other programming language that supports this library. One can go further and write Linux kernel modules using the TUN/TAP framework4. TUN/TAP allows for high speed layer 2 and layer 3 interface handles within the Linux kernel. As these access a network interface in a standard manner, the speed of these handles is still measured by standard network conventions, this being in Mbps.
The speed at and accuracy with which data is managed through these handles can only be determined by the capability of the hardware within the host that is requesting use of these handles. One should also take into account other processes requesting use of the resources that TUN/TAP requires at time of access, as this can add extra overheads to the service.
3.2 Packet Handling
This section explains what packet handling means in the context of this implementation, why it is required and how it is done. Simply put, packet handling refers to the method in which packets are received and transmitted in this implementation.
As this is a routing simulator, the actual nodes that generate traffic are not found within the simulation. This is because the focus of this implementation is on routing the packets
2http://www.wireshark.org/
3http://www.tcpdump.org/
4https://www.kernel.org/doc/Documentation/networking/tuntap.txt
3.2. PACKET HANDLING 43
Figure 3.5: Overview of Packet Handling
introduced into the simulation, and not on creating these packets. Internal packet gen-eration would create a need to use up host resources in order to instantiate new network stacks on VMs, or use up CPU time in the event of packet generation specific applications.
Instead packets are brought in from external sources. In order for this to work, one needs to provide sufficient handles to both receive and transmit packets. This is explained in more detail in Section 3.2.1 and Section 3.2.2 respectively.
The simulated nodes and physical hosts undergo a binding process. This is used to direct where traffic from external nodes is placed when received into the simulated network, and where it is sent when a destination in the simulation is reached. This process takes a real IP and MAC address and couples it with a simulated node’s IP and metadata. This then allows for a simple interface between the routing simulator and the physical hosts used in this simulation.
3.2.1 Application of Netfilter and Low Level Sockets
Netfilter is a hook-based implementation within the Linux kernel that allows for external function call backs to occur when a packet traversing the network stack reaches the function’s hook in the network stack (Ayuso, 2010). In practice, one is required to create
3.2. PACKET HANDLING 44
Figure 3.6: Adding a Hook into Netfilter
the netfilter hook, create a pointer to the function, and then set a priority as to where the hook will be placed within the hook stack. Figure 3.6 shows the new hook function being placed in first priority in the function stack. This means that one can set it to be the first hook in the stack and so reduce delays of idling while waiting for every other hook function to complete, a simple performance booster.
All interfaces are watched by netfilter on the host in which it resides. The ability to determine the interface in which a packet was received is provided through the metadata within the struct that the packet is buffered in after it is received on a interface. There are also other useful fields such as packet length, protocol and a whole set of pointers to each header in the packet residing in the buffer (Santa Clara University, 2004). The determining part of the buffer is the interface in which the packet was received. This can be used to separate out multiple networks or simply increase the host’s bandwidth through use of multiple interfaces.
A drawback of netfilter is that it works at layer 3 of the IPv4 stack (Ayuso, 2010). This means that the MAC address at which a packet is received is not stored in the packet buffer as a MAC, and protocol type is layer 2 (Postel, 1981a). This means that when binding between a physical host and simulated node is created, the MAC address for the physical host has to be stored as one cannot obtain this from the packet received through netfilter. This causes a need for knowledge of specifics about a physical host and thus adds to the time taken for set up.