1

I want to make a lab experiment to measure the firewall (a hardware) latency. This firewall can do Deep Packet Inspection (DPI) on some industrial protocols (you can consider as TCP payload inspection). Hence, I want to measure the firewall's latency when inspecting the payload.

Assume I have a sender PC and a receiver PC. The firewall is connected in between. I can build a packet generator on the sender, and use wireshark installed on each PC to confirm whether the packet pass the firewall or not.

Hence, what is the effective way to measure the latency (e.g. xxx ms delay on average by comparing without firewall) that the firewall inspects the packets? (such as existing software)

  • 1
    Most people don't do this; they just look at the specs for things like PPS. The latency on a firewall is a rounding error on the latency of the Internet. – Ron Maupin Dec 6 '16 at 14:33
  • @RonMaupin Not necessarily, I worked with a SonicWall NSA 2600 IIRC at my last job, and the sys-admin had so many rules that it was actually creating a measurable latency (~3ms) against the network traffic on our 100Mbit connection. The solution: install a second NSA and load balance them. – 410_Gone Dec 7 '16 at 6:31
  • @EBrown, a 3 ms latency is just a rounding error on the Internet latency. You will probably see greater than a 3 ms jitter between measurements on the Internet. – Ron Maupin Dec 7 '16 at 14:00
  • I want to test the delay because DPI, which is an application layer inspection, could increase the latency. For example, the firewall inspects the payload of an industrial protocol (e.g. always use TCP port xxx) through signatures. – TJCLK Dec 8 '16 at 8:03
2

I don't know your full circumstances, but if an accurate figure for device latency really mattered to me then I would hire specialised equipment for this task. I'm in the UK and there are specialist suppliers who hire out network analysis equipment like this. You will need a device that can take your payload and generate TCP sessions. I haven't done this for a while so I don't know who sells what any more. I used to use Wandel and Goltermann and Smartbits but it was a long time ago. I also never needed to use real payload myself, but you obviously do.

An alternative would be to use a couple of network taps and a packet broker that can apply hardware time-stamps before handing to a simple Wireshark PC. If the required accuracy is no better than about 100 microseconds, you could even just use two taps and a properly-configured PC with Wireshark. You will have to ensure that NIC interrupts are not coalesced and there may be other settings to optimise. Using Wireshark you just match packets across the two captures, and take the time difference. You can export the capture files to a spreadsheet to match them. You will need to try to assess what the precision you acheive.

  • The alternative way looks good. If I generate unidirectional packets, I have to add two network taps. If I generate server-client traffic (request-response), maybe I can only install wireshark on server side, and compare timestamps difference with/without firewall? I know wireshark have a function to display the timestamp from previous frame, within the same TCP stream index. Do you mean this? – TJCLK Dec 8 '16 at 10:00
  • 1
    No, to measure the latency, you must compare the timestamp from the same data packet as it goes into the firewall and leaves it. So with two captures you have two sets of packets, one taken each side. For each individual packet you find the same packet in the other trace. The time difference provides the latency. You must capture using the same time-source, otherwise you will have top estimate clock difference, and I've found that to be very hit and miss. You will also need real traffic with a full TCP session, not just one-way, presumably the firewall does stateful inspection before DPI. – marctxk Dec 8 '16 at 10:45
  • Note also the captures on the end-devices themselves will have less accurate timestamps than if you dedicate a device to capture. I guess it all depends on what accuracy you need. If I were you I'd decide that first. – marctxk Dec 8 '16 at 10:47
  • @ marctxk: I see. but how to synchronize the time sources of two network taps (or find the time difference)? For the network tap, can use PC with sniffing software like wireshark? – TJCLK Dec 8 '16 at 11:30
  • yes you can so long as you don't need very precise meaasurement. If you use a fast PC and quality NIC, and optimise the config you can probably get time resolution of about 100 microsecs (this is my finger-in-the-air guess). – marctxk Dec 8 '16 at 11:55
2

You could use a tool like iperf to measure throughput and latency on each node with different inspection/filtering features turned on the firewall. This will show how the firewall features affect throughput/latency. See more at iperf's website Keep in mind that there will be other factors like the cabling and each node's resources that can effect these numbers. You might also look into logging/debug features of the firewall to see if there is any information from there you can look into.

  • I just take a look about iperf/iperf3. can it test the firewall latency by sending packets that are written by myself? I need to test the latency on industrial protocol payload inspection. – TJCLK Dec 8 '16 at 7:56
  • You can look into the python tool scapy or maybe ostinato would work. – stets Dec 8 '16 at 14:49
2

I think the easiest way to test real-world latency of your firewall would be to add a second NIC to your sender PC that connects to the external subnet of the firewall, making it the receiver PC as well (you could use physical NICs or VLANs depending on your setup).

Start Wireshark and capture the traffic on both NICs, then start your communication tests. You can easily see the time difference between the sent and received packets b/c both are based on the same clock.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.