Kategorie pfSense

Performance-Messungen mit iperf3

Netzwerkanalyse mit Open Source-Tools

Um die Performance einer Netzwerkstrecke zu messen gibt es viele Möglichkeiten. Eine derer – und aus meiner Sicht die verlässlichste und gleichzeitig einheitlichste Methode – möchte ich heute vorstellen. iperf3 ist ein Open Source-Tool, was auf nahezu jedem Betriebssystem lauffähig und daher sehr universell einsetzbar ist. Zudem bietet es einige Konfigurationsoptionen, die viele Szenarien abdecken.

Öffentliche iperf3-Server

Standorte öffentlicher iperf-Server (Quelle: https://iperf.cc/de/ )

Um einen einfachen Test zu definierten Servern im Web zu starten, kann man sich vorerst ohne einen eigenen Server aufzusetzen bei den frei verfügbaren Servern ausprobieren. Diese finden sich hier.

Mit dem folgenden Befehl kann man bereits mit iperf3 im Clientmodus testen. Es können bei Bedarf weitere Parameter angegeben werden. Beim Windows-Client muss ggf. die Dateiendung “.exe” nach iperf3 ergänzt werden.

iperf3 -c [iPerf-Serveradresse]

Man sollte dabei allerdings bedenken, dass die angegebene Bandbreite viele Hops und längere Strecken durchläuft und jedes Mal einer Momentaufnahme entspricht. Wie man im eigenen Netz per iperf

Private iperf3-Server

Wie bereits erwähnt kann es ggf. nicht zielführend sein, einen öffentlichen Server anzufragen. Warum? Möglicherweise liegt die Ursache für eine schlechte Performance nur auf einem Teilstück der Strecke – zum Beispiel bei einem ausgelasteten Switch, langsam ausgehandelten Ports oder auch an einem ausgelasteten Speichersystem oder Virtualisierungshost. Um solchen Plagegeistern auf den Zahn zu fühlen, kann auch im lokalen Netz ein iperf3-Server installiert werden und die Strecke zum Standort dessen gemessen werden.

Installation von iperf3

Die Installation kann auf nahezu jedem Betriebssystem stattfinden. Wichtig ist, dass nach Installation eingehende und ausgehende Ports (Standard: TCP/UDP 5001-5009) in der lokalen Firewall und ggf. auf dem Weg liegenden Firewall erlaubt worden sind.

Die Binaries für eine Installation finden sich hier.

Testszenario mit iperf3 auf Ubuntu (64-Bit)

In meinem Testszenario habe ich iperf3 auf einem Ubuntu-Server mit 64 Bit laufen lassen. Üblicherweise genügt eine aktuelle Installation und aktuelle Paketquellen:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install iperf3

Starten im Servermodus

iperf3 muss nun noch im Servermodus gestartet werden und wartet dann auf Anfragen der iperf3-Clients:

iperf3 -s

Die Übertragung wird mit genauen Messwerten auf Client und Serverseite gemessen und am Ende der Messung abgeglichen.

Auswertung der Messergebnisse

Nun erhält man am Ende Ergebnisse der Messungen. Doch wie sind diese zu interpretieren? Was muss dabei beachtet werden?

  • Ausstattung der VM oder des Rechners (RAM/CPU-Kerne)
  • Physikalische Netzwerkkarte und maximaler physikalischer Datendurchsatz
  • Virtuelle Netzwerkadapter (bei VMware z.B. e1000 vs. vmxnet3)

Je nach Infrastruktur können die Ergebnisse variieren, als Richtwerte sollten aber ca. 90-97% der physikalisch verfügbaren Durchsätze dienen:

  • Fast-Ethernet: 100 Mbit/s netto > ca. 90-97 Mbit/s brutto
  • Gigabit-Ethernet: 1.000 Mbit/s netto > ca. 900-970 Mbit/s brutto
  • TenGigabit-Ethernet: 10.000 Mbit/s netto > ca. 9.000 – 9.750 Mbit/s brutto

Wie kommt es zur Reduzierung der physikalischen Maximalwerte? Ganz einfach! Der Betriebssystemkernel, die Netzwerkdienste und Treiber der Karten und Schnittstellen, sowie ggf. auch intern langsamere Verbindungen führen zur Absenkung der Brutto- in Nettowerte.

pfSense: Interface-Konfiguration

Interface-Konfiguration auf pfSense

Um auf einer pfSense eine Netzadresse zu vergeben, muss vorher das physikalische Interface dem Netz zugeordnet worden sein. Nun sollte das Interface über “Enable” aktiviert werden und ein Name vergeben werden. Ich vergebe die Namen auf Basis der VLAN-ID, sodass sie auch geordnet in den Menüs aufgerufen werden können. Geschmacksache. Finde ich besser so. Jedem das Seine.

Interface-Konfigurationsarten

Um die Konfiguration fortzusetzen, muss nun eine Auswahl getroffen werden. Neben statischen Adressen können für IPv4-Adressierungen auch PPP, PPPoE, PPTP, L2TP und DHCP genutzt werden. IPv6 bietet an der Stelle DHCP6, SLAAC, 6rd-Tunnel, 6to4-Tunnel und die Option (für WAN-Interfaces), den Traffic zu tracken. In diesem Beispiel habe ich die – vermutlich meistbenutzte  Konfigurationsart (statische IPv4-Adresse) gewählt.

Spoof it, or don´t – that´s the question!

Gibt man unter “MAC Address” eine andere als die maskierte MAC-Adresse an, spooft die Firewall automatisch mit dem Interface die angegebene MAC und erscheint so mit fremder Identität in den ARP-Tables der umliegenden Switche, Router und Rechner. Ohne speziellen Anwendungsfall sollte hier keine Änderung vorgenommen werden. Durch die Angabe der MTU-Größe können auch größere Pakete angenommen und verschickt werden. Auf den meisten Switchen muss dafür speziell der Support von Jumbo-Frames aktiviert werden, damit die Frames weitergeleitet werden.

IPs, Subnetzmaske, Upstream-Gateway, Speed und Duplex-Einstellungen

Über die Speed-/Duplex-Settings kann man händisch die vom (physikalischen) Interface vorgegebenen Geschwindigkeiten und Duplexsettings wählen. Bei VLANs gibt es hier keine Auswahlmöglichkeit. Im nächsten Schritt wird die IP-Adresse definiert. Durch die Angabe der Subnetzmaske in für Unix typischer Schreibweise (Bitcount)  wird die Netzgröße definiert. Für WAN-Interfaces oder Interfaces, hinter denen sich noch weitere Routing-Hops befinden, kann noch ein Upstream-Gateway angegeben oder erstellt werden. Für interne Netze wird hier kein Eintrag benötigt!

Networking/Security: LLDP, CDP, EDP, NDP auf pfSense

Um die üblichen Netzwerkdiscovery-Protokolle zu unterstützen, muss bei der Open-Source-Firewall über die Paketinstallation nachgeholfen werden. Die Paketinstallation ist über das Top-Menu via System>PackageManager zu finden. Aus den verfügbaren Anwendungen ist ladvd auszuwählen. Nach der Installation wird ein sehr breites Portfolio an Protokollen von der pfSense verstanden und gesprochen:

  • LLDP (Link Layer Discovery Protocol)
  • CDP (Cisco Discovery Protocol)
  • EDP (Extreme Discovery Protocol)
  • NDP (Nortel Discovery Protocol)

Damit Daten ausgetauscht werden können, muss der Switch, an den die pfSense angeschlossen ist natürlich auch das Protokoll sprechen (können) und aktiviert haben. Mein Switch spricht auf der Gegenseite aktuell LLDP.

Link-Discovery-Protokolle

Was sind eigentlich diese Protokolle und was tun sie? Kurz gesagt geben sie dem angeschlossenen System folgende Informationen mit und erhalten als “Gegenleistung”, sofern das Protokoll dafür konfiguriert wurde, eben solche Informationen des Gegenüber:

  • System/Chassis-Namen
  • Lokal verbundenes Interface
  • Remote-Interface, über das das System verbunden ist
  • Location-Information
  • Informationen zur verwendeten Hardware bzw. zur Geräteklasse

Konfiguration

Um ladvd zu konfigurieren, muss im Top-Menu über Services>ladvd navigieren.

Service aktivieren und konfigurieren

Der Dienst muss über eine Checkbox aktiviert werden und die dafür aktiven Interfaces ausgewählt werden. Schließlich möchte ich an meinem WAN- oder DMZ-Port beispielsweise bewusst keine Discovery-Protokolle verwenden, damit die Informationen nicht missbraucht werden können.

Per default horcht die pfSense auf allen möglichen Kanälen. Auch dies kann wenn gewünscht über eine Checkbox inaktiv gesetzt werden. Im Silent-Mode werden aktiv keine Pakete gesendet sondern nur empfangen. Schade, dass das nur global geht. Hier sehe ich einen Use-Case wie o.g. für WAN- und DMZ-Interfaces.

Das Management-Interface muss ein physikalisches Interface sein und darf kein VLAN, eine Link-Aggregation oder ähnliches virtuelles Interface sein. Über den Input “System Location” kann ein Freitext für den Standort der pfSense vergeben werden.

Nun müssen noch die Dienste aktiviert werden, auf denen gehorcht werden soll. In meinem Fall sind das LLDP und CDP,  da ich bisher mit Extreme und Nortel kaum Berührungspunkte hatte. CDP wird mittlerweile übrigens auch von HP-ProCurve-Geräten und Brocade-Systemen gesprochen und verstanden.

Output

Über die Web-GUI wie über die CLI erhält man folgenden Output. Darin ist zu erkennen, dass über das Protokoll LLDP das lokale Interface re2 verbunden ist mit der Port-ID eth 4 auf Switchseite. Sofern der Hersteller bzw. der Admin die Information pflegen, erkennt man über die Capability auch, um welche Geräteklasse es sich handelt. Bei Enterprise-Geräten ist hier gewöhnlich der Capability Code gepflegt. Bei meinem Switch leider nicht.

Wofür die Informationen?

Ist ein Netzwerk nicht ausreichend dokumentiert oder unterliegt es viel Dynamik, kann so recht einfach nachvollzogen werden, wie die Systeme miteinander verbunden sind. So kann man sich nach und nach von einem zum anderen Gerät hangeln und eine immer umfangreichere Topologie-Dokumentation anlegen.

Skip to content