## 4 Experimental Results
### Firewall Performance under Controlled Network Traffic  
In the first instance, Ethernet data were provided to the firewall using a packet generator, designed on another KC705 FPGA device, which can generate packets of type ARP, TCP, UDP and ICMP of different sizes and with different data throughputs. A detailed description of the packet generator was presented in [17]. The measurement setup is presented in Figure 5. Two packet generators are connected to the two firewall ports implemented with a Quad SFP28 FPGA Mezzanine Card (FMC) Ethernet module [47]. A PC is used to communicate with the two packet generators and the firewall using the USB-UART interface. Initially, the two packet generators are configured to generate packets of a selected protocol, size and data throughput. Then, the firewall statistics (including the number of received/transmitted packets, the level of occupation of data memory, etc.) are acquired at time intervals of 1 s.  
The firewall performance was evaluated in the case of UDP packets. First of all, the packets were continuously generated (i.e., no delay between packets) to evaluate the maximum data throughput for different sizes of the generated packets. Tests were carried out for five different sizes of UDP packet: 100 bytes, 250 bytes, 500 bytes, 750 bytes and 1000 bytes. The results are reported in Figure 6. As can be seen, the data throughput increases for packets of larger size. In the case of packets of 100 bytes in size, the data throughput is 0.811 Gb/s, which is about 80% of the maximum data throughput of 1 Gb/s. In the case of packets of 250, 500, 750 and 1000 bytes in size, the data throughput was measured as 0.917 Gb/s, 0.959 Gb/s, 0.974 Gb/s and 0.982 Gb/s, respectively. The increase in data throughput for packets of larger size can be easily explained by the fact that an Ethernet frame contains a packet that is preceded by a preamble and start frame delimiter  
Figure 5: Experimental setup for the measurement of the firewall performance under conditions where the network data are generated by an ad-hoc designed packet generator. (8 bytes) and ends with a frame check sequence (4 bytes) used to detect data corruption. Thus, in the case of packets of larger size, this overhead has less impact on the data throughput. As discussed in Section 3, when an Ethernet frame is received at one port of the firewall, its content is stored in the 16 kB data memory before a decision is made if the Ethernet frame must be transmitted or discarded. Thus, the size of the used data memory (i.e., used memory hereafter) was measured at time intervals of 1 s for UDP packets of different sizes and different values of the inter-frame delay. The firewall was designed to receive data as long as the used memory is lower than 12 kB, while, when this threshold is exceeded, the firewall discards the received packets until the used memory decreases below 5 kB. The results showed how, if the inter-frame delay is lower than 13 clock cycles, the used memory increases with time and eventually reaches the critical threshold of 12 kB, while for inter-frame delays of 13 clock cycles or higher, the firewall works continuously without reaching the critical threshold. The measured used memory is plotted vs. time in Figure 7 in the case of UDP packets of a size of 100 bytes and no inter-frame delay. As can be seen in Figure 7, the used memory increases with a constant rate \(\lambda\) until the critical threshold of 12 kB is reached, then the firewall stops receiving packets until the used memory decreases below 5 kB. The used memory increase rate (\(\lambda\)) was measured for UDP  
Figure 6: Data throughput of the proposed firewall for UDP packets of different sizes. Figure 7: Used data memory vs. time in the case of UDP packets of size 100 bytes and no inter-frame delay. packets of different sizes and different values of the inter-frame delay. The experimental results showed no significant correlation between \(\lambda\) and the inter-frame delay.