// HEISE ONLINE — HARDWARE & GADGET
Gigabit ist nicht alles: fireperf stresst die Firewall
Wie gut bewältigen Firewalls viele Verbindungen? fireperf prüft das – und benötigt im Benchmark weniger CPU-Zeit als iperf3.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Mit fireperf stellt das IPFire-Projekt ein Netzwerktestwerkzeug für Administratoren, Entwickler und Tester vor. Es misst neben dem Datendurchsatz auch die Rate neuer Verbindungen und prüft, wie Firewalls und Router bestehende Verbindungen verwalten.
IPFire ist eine freie Linux-Distribution für den Einsatz als Firewall und VPN-Gateway. Sie bietet unter anderem VPN- und Intrusion-Prevention-Funktionen, die Verwaltung erfolgt über eine Weboberfläche. fireperf gehört zwar zu dem Projekt, ist aber ein eigenständiges Werkzeug. Eine erste Version hatte IPFire erstmals 2021 angekündigt, wurde aber jetzt offiziell eingeführt.
Während iperf3 vor allem den Datendurchsatz zwischen zwei Rechnern misst, zielt fireperf auf die Belastung zustandsbehafteter Netzwerkkomponenten. Für sie zählt nicht allein die übertragene Datenmenge: Sie müssen außerdem viele neue Verbindungen pro Sekunde verarbeiten und für jede Verbindung einen Eintrag in ihrer Verbindungstabelle verwalten. Das Werkzeug kann Verbindungen mit einer vorgegebenen Rate aufbauen und die Dauer der TCP-Handshakes erfassen. Scheitert ein Verbindungsversuch, unterscheidet es zwischen Zeitüberschreitungen, abgewiesenen Verbindungen und Ressourcenmangel auf dem Testrechner.
Auch bereits aufgebaute Verbindungen untersucht fireperf. Es hält sie offen und prüft regelmäßig, ob sie noch funktionieren. Damit können Administratoren testen, wie viele Verbindungen eine Firewall nach längerer Inaktivität verworfen hat. Hinzu kommen Request-Response-Lastprofile: Statt eines kontinuierlichen Datenstroms lässt sich beispielsweise eine 100 Byte große Anfrage mit einer 10 KByte großen Antwort kombinieren.
Ein fireperf-Server kann mehrere Clients gleichzeitig auf einem Port bedienen, jeweils mit einem eigenen Test. Ein iperf3-Server verarbeitet dagegen nur einen Test gleichzeitig. Bestehende Testumgebungen lassen sich teilweise weiterverwenden: fireperf kommuniziert mit iperf3- und iperf-Servern; umgekehrt können iperf3-Clients gegen einen fireperf-Server testen.
Ein weiteres Ziel der Entwickler war es, den Ressourcenbedarf des Lastgenerators zu senken. In einem Entwickler-Benchmark zwischen zwei virtuellen Maschinen mit jeweils zwei CPU-Kernen, virtio-Netzwerk und acht Verbindungen benötigte fireperf mit io_uring auf der Senderseite 0,071 CPU-Sekunden pro übertragenem GByte. Bei iperf3 waren es 0,505 CPU-Sekunden in der Standardkonfiguration und 0,153 mit --zerocopy. Unter diesen Bedingungen brauchte fireperf damit etwa ein Siebtel beziehungsweise knapp die Hälfte der CPU-Zeit. Es handelt sich hierbei um den Rechenaufwand pro Datenmenge, nicht um einen entsprechend höheren Netzwerkdurchsatz. Der lag im selben Test bei 19,0 Gbit/s für fireperf und 15,9 Gbit/s für iperf3 in der Standardkonfiguration.
Die Design-Dokumentation zu fireperf beschreibt die verwendeten Zero-Copy-Verfahren. Beim epoll-Backend verschickt der Kernel Daten mit sendfile() aus einer speicherbasierten Datei. Beim io_uring-Backend registriert fireperf den Datenpuffer einmal beim Kernel und nutzt ihn anschließend direkt für den Versand. Das vermeidet zusätzliche Kopierarbeit.
Beim fortlaufenden Auf- und Abbau von Verbindungen über Loopback erreichte fireperf laut Entwickler auf einem System mit 16 CPU-Kernen mehr als 230.000 Verbindungen pro Sekunde.