Dateiübertragungen dauern plötzlich zu lang, die Telefonie klingt unruhig, Teams-Meetings stocken, und der Internet-Speedtest sieht trotzdem halbwegs ordentlich aus. In solchen Situationen liegt das Problem oft nicht auf der WAN-Strecke, sondern im eigenen Netzwerk.
Genau dann reicht ein schneller Browser-Test nicht mehr. Ein belastbarer lan geschwindigkeit test in Unternehmen muss reproduzierbar sein, den realen Datenpfad abbilden und so dokumentiert werden, dass die Ergebnisse nicht nur für die Technik, sondern auch für Audits, Risikobewertungen und Cloud-Projekte brauchbar sind.
Wer heute produktive IT betreibt, misst deshalb nicht nur „wie schnell“, sondern auch wo, unter welchen Bedingungen und mit welcher Aussagekraft.
Warum ein professioneller LAN Geschwindigkeitstest entscheidend ist
Fehlersuche beginnt oft beim Provider, ist aber intern selten der richtige erste Ansatz. In Unternehmensnetzen entstehen Leistungsprobleme häufig zwischen Client, Switch, Server, Firewall und Verkabelung. Wer nur die Internetanbindung prüft, misst deshalb oft an der eigentlichen Ursache vorbei.
Für den Betrieb macht dieser Unterschied viel aus. Ein Browser-Speedtest kann trotz langsamer Dateiübertragungen, stockender VoIP-Gespräche oder zäher ERP-Zugriffe noch ordentlich aussehen, weil er nur einen externen Pfad bewertet. Ein professioneller LAN Geschwindigkeitstest prüft dagegen die Strecke, auf der die geschäftskritische Anwendung tatsächlich läuft.
Ein Internet-Speedtest beantwortet nicht die Betriebsfrage
Im Projektalltag will niemand wissen, ob ein Testserver im Internet gerade 300 oder 500 Mbit/s liefert. Die relevante Frage lautet: Erreicht der Arbeitsplatz unter realen Bedingungen die Leistung, die für Fileservices, Virtualisierung, Backups, M365, Teams oder Fachanwendungen nötig ist?
Ein externer Speedtest liefert darauf keine belastbare Antwort. Er zeigt nicht zuverlässig,
- ob Port und Netzwerkkarte korrekt mit 1 Gbit/s oder 10 Gbit/s verhandeln
- ob ein einzelner Uplink am Switch überlastet ist
- ob VLANs, Firewalls oder ACLs internen Traffic ausbremsen
- ob die Störung am Client, am Server oder auf der Strecke entsteht
Für diese Einordnung muss zuerst klar sein, was im eigenen Netz überhaupt als LAN gilt. Eine kurze technische Abgrenzung finden Sie in unserer Erklärung zu was ein LAN im Unternehmenskontext bedeutet.
Praxisregel: Ein externer Speedtest ist für die Provider-Strecke brauchbar. Für die Ursachenanalyse im Firmennetz ist er nur ein Nebensignal.
Saubere LAN-Messungen schaffen belastbare Entscheidungen
Ethernet ist seit Jahrzehnten standardisiert und im Unternehmensumfeld technisch berechenbar. Genau deshalb lassen sich lokale Verbindungen heute reproduzierbar testen und sauber vergleichen, von klassischen 1-Gbit/s-Arbeitsplätzen bis zu schnelleren Server- und Backbone-Strecken. Die technische Entwicklung und Standardisierung von Ethernet ist in der Übersicht zu Ethernet als Standardbasis dokumentiert.
Das ist für Audits und Betriebsverantwortung relevant. Wenn eine sauber aufgebaute Messung deutlich unter dem Soll liegt, spricht das meist für einen konkreten Fehler in Konfiguration, Hardwarezustand, Duplex, Treiberstand oder Lastverteilung. Damit wird aus einem Bauchgefühl ein prüfbarer Befund.
Der Nutzen ist technisch und organisatorisch
Ein professioneller lan geschwindigkeit test ist kein Selbstzweck. Er hilft, Investitionen zu begründen, Störungen schneller einzugrenzen und Risiken nachvollziehbar zu dokumentieren.
| Nutzen | Warum er im Unternehmen zählt |
|---|---|
| Stabile Arbeitsplätze | Langsame Dateiablagen, VoIP-Aussetzer und schlechte Videokonferenzen haben oft interne Ursachen, die sich gezielt messen lassen |
| Cloud-Readiness | Migrationen zu M365, Azure, IONOS oder anderen Plattformen brauchen verlässliche interne Pfade, nicht nur eine schnelle WAN-Leitung |
| Schnellere Fehlersuche | Baselines trennen sauber zwischen Endgerät, Switchport, Uplink, Serverpfad und Sicherheitskomponente |
| Nachweisbarkeit | Dokumentierte Messreihen sind für interne Freigaben, Dienstleistersteuerung und Management-Entscheidungen deutlich belastbarer als Einzelmeldungen von Anwendern |
| NIS-2 und ISO 27001 | Wer Netzwerkleistung und Engpässe nachvollziehbar prüft und dokumentiert, verbessert die technische Grundlage für Risikobewertungen, Betriebsprozesse und Audit-Nachweise |
In regulierten Umgebungen sehe ich noch einen zweiten Effekt. Messungen, die standardisiert durchgeführt und dokumentiert werden, lassen sich später für Audits, Abweichungsanalysen und Maßnahmenpläne wiederverwenden. Das spart Zeit, senkt Diskussionen mit Dienstleistern und verbessert die Planbarkeit für Erweiterungen, Segmentierung und Cloud-Projekte.
Die richtige Vorbereitung für präzise Messergebnisse
Die meisten schlechten Netzwerktests scheitern nicht am Tool, sondern am Aufbau. Ein unvorbereiteter Test erzeugt Zahlen, die technisch korrekt aussehen, aber praktisch wertlos sind.
Der Testaufbau muss einfacher sein als das Produktionsnetz
Starten Sie nie sofort mit einem Test über mehrere Etagen, VPNs und Sicherheitszonen hinweg. Die erste Messung braucht eine klare Baseline. Dafür verbindet man zwei Systeme möglichst direkt im selben Segment, idealerweise physisch am selben Switch.
Das Ziel ist simpel. Sie wollen zuerst die reine Leistungsfähigkeit der lokalen Strecke sehen, nicht die Summe aller möglichen Störfaktoren.
Eine belastbare Vorbereitung sieht so aus:
Zwei geeignete Testsysteme wählen
Nutzen Sie Endgeräte oder Server mit stabilen Netzwerkkarten und genügend CPU-Reserve. Wenn das Testgerät selbst schwach ist, messen Sie den Rechner, nicht das LAN.Verkabelung bewusst prüfen
Für Gigabit-Tests sollte die Strecke sauber aufgelegt und mit Cat 6 oder besser geplant sein. In der Praxis ist das oft der Unterschied zwischen einer klaren Aussage und langem Rätselraten.Gleichen Switch als Startpunkt verwenden
Zwei Geräte am selben Switch geben die sauberste Baseline. Erst danach testet man über Uplinks, Etagenverteiler oder Firewall-Zonen.Produktivlast minimieren
Backups, Synchronisationen, Softwareverteilung und Updates verfälschen Ergebnisse. Für einen professionellen lan geschwindigkeit test gehört ein definiertes Testfenster dazu.
Was vor dem ersten Lauf abgeschaltet oder geprüft werden sollte
Viele Abweichungen lassen sich schon vor dem Start vermeiden. Wer das überspringt, produziert oft Folgearbeit.
Hintergrundprozesse stoppen
Schliessen Sie laufende Datei-Synchronisation, Backup-Agenten und Update-Dienste, soweit das im Testfenster vertretbar ist.Sicherheitskomponenten prüfen
Endpoint-Security, lokale Firewalls oder Inhaltsfilter können Testdaten beeinflussen. Nicht blind deaktivieren, sondern bewusst dokumentieren, welche Schutzmechanismen aktiv waren.Link-Status verifizieren
Prüfen Sie an Switch und Endgerät, ob die Verbindung mit der erwarteten Geschwindigkeit und im richtigen Duplex-Modus steht.Parallele Benutzerlast vermeiden
Ein Fileserver-Test mitten im Tagesgeschäft misst oft eher Benutzeraktivität als Netzqualität.
Wenn Sie zunächst die externe Leitung von der internen Infrastruktur abgrenzen möchten, ist eine saubere Vorprüfung der Internet-Leitung prüfen oft sinnvoll. Danach wissen Sie, ob Sie ein WAN- oder ein LAN-Thema untersuchen.
Saubere Netzwerkdiagnose beginnt nicht mit dem Startbefehl, sondern mit einer kontrollierten Testumgebung.
Eine kleine Checkliste spart viel Zeit
| Prüffeld | Was Sie festhalten sollten |
|---|---|
| Testgeräte | Gerätetyp, Betriebssystem, Netzwerkkarte |
| Anschlussweg | Switchport, Segment, VLAN, Zwischenkomponenten |
| Verkabelung | Kabeltyp, bekannte Patchfelder, Auffälligkeiten |
| Zeitfenster | Uhrzeit, laufende Jobs, bekannte Lastsituationen |
| Sicherheitslage | Lokale Firewall, EDR, Firewall-Pfad, VPN ja oder nein |
Was in der Praxis nicht gut funktioniert
Es gibt einige Muster, die in Projekten regelmässig zu Fehlinterpretationen führen:
- Einzelner Browser-Test am Arbeitsplatz als Beweis für LAN-Probleme
- Dateikopie auf einen ausgelasteten Fileserver ohne Kenntnis der Serverlast
- Messung über WLAN, obwohl ein verkabeltes Problem nachgewiesen werden soll
- Vergleich unterschiedlicher Tageszeiten ohne Dokumentation der Lastsituation
Wer reproduzierbare Ergebnisse braucht, behandelt einen Netzwerktest wie einen technischen Nachweis. Nicht wie einen Schnellschuss.
Die besten Tools für den LAN Geschwindigkeitstest im Vergleich
Die Wahl des richtigen Tools entscheidet, ob Sie eine schnelle Tendenz oder eine auditierbare Diagnose erhalten. In Unternehmensnetzen ist das ein praktischer Unterschied. Wer für einen Fachbereich nur eine erste Einordnung braucht, arbeitet anders als jemand, der Messergebnisse für ein Incident-Review, ein Migrationsprojekt oder eine NIS-2-nahe Dokumentation absichern muss.
Woran sich die Tool-Auswahl orientieren sollte
Ich bewerte Werkzeuge im Projektalltag nach drei Fragen:
- Welcher Pfad soll gemessen werden, internes LAN, Internet-Uplink oder ein Anwendungsprotokoll wie SMB
- Soll das Ergebnis nur eine Auffälligkeit zeigen oder als technischer Nachweis dienen
- Lässt sich der Test wiederholen, dokumentieren und für Audits sauber einordnen
Gerade für ISO 27001 und die Nachvollziehbarkeit technischer Kontrollen ist dieser Punkt relevant. Ein Screenshot aus einem Browser hilft im Audit selten weiter. Ein reproduzierbarer Test zwischen definierten Endpunkten mit dokumentierten Parametern ist deutlich belastbarer.
Vergleich der LAN-Test-Tools
| Tool | Typ | Bester Anwendungsfall | Vorteile | Nachteile |
|---|---|---|---|---|
| iperf3 | Kommandozeile | Punkt-zu-Punkt-Messung im LAN mit klar definierten Parametern | präzise steuerbar, TCP und UDP, gut dokumentierbar | technisch, keine GUI |
| Speedtest.net | Webdienst | Schnelle Einordnung der Internetanbindung oder eines WAN-Problems | sofort nutzbar, kein eigener Messserver nötig | misst primär den Weg ins Internet, nicht isoliert das LAN |
| NetIO | leichtgewichtiges Testtool | Basisvergleich in einfachen oder älteren Umgebungen | schlank, schnell einsatzbereit | weniger Auswertungstiefe |
| LAN Speed Test | GUI-Tool | Sichtprüfung aus Anwendersicht mit dateibasiertem Test | leicht verständlich, gut für Fachabteilungen | Ergebnis hängt stark von Storage und SMB ab |
| nttcp | Spezialtool | Windows-zentrierte Performance-Tests in Microsoft-Umgebungen | sinnvoll für spezielle Windows-Szenarien | in vielen Teams weniger verbreitet als iperf3 |
Welches Tool für welchen Zweck passt
iperf3 ist das Arbeitswerkzeug für technische Ursachenanalyse. Es misst direkt zwischen zwei Systemen und trennt den Netzwerkpfad sauber von Dateisystem, Fileserver und Benutzeroberfläche. Genau das braucht man, wenn ein Switch-Tausch validiert, ein Segment vor einer Cloud-Migration geprüft oder ein Leistungsproblem gegenüber einem Dienstleister belegt werden soll.
Speedtest.net hat trotzdem seinen Platz. Wenn die Frage lautet, ob die Störung im Gebäude oder außerhalb liegt, liefert ein Webtest eine schnelle Zusatzinformation. Für einen ersten Latenz-Check vom Windows-Client aus eignet sich auch ein sauberer Ping-Test per CMD zur Netzwerkanalyse. Das ersetzt keinen LAN-Durchsatztest, hilft aber bei der Abgrenzung.
LAN Speed Test und ähnliche GUI-Werkzeuge sind nützlich, wenn ein Fachbereich die wahrgenommene Langsamkeit eines Dateiablaufs nachvollziehen will. Diese Tools prüfen jedoch keinen reinen Netzpfad. Sie messen immer auch Speicher, Protokolloverhead, Virenscanner und Serverreaktion mit.
Wo grafische Tools sinnvoll sind
In der Praxis setze ich GUI-Tools ein, wenn Akzeptanz im Fachbereich wichtig ist oder wenn ein Anwendungsprozess sichtbar gemacht werden soll.
Für die technische Diagnose gilt eine einfache Regel. Je stärker ein Tool Dateioperationen simuliert, desto weniger klar lässt sich das Ergebnis dem Netzwerk allein zuordnen.
Typische Einflussfaktoren sind:
- lokale SSD- oder HDD-Leistung
- Auslastung des Zielservers
- SMB-Signing, Caching und Dateisystemverhalten
- lokale Sicherheitssoftware wie Virenscanner oder EDR
Deshalb gehören dateibasierte Tests in Berichte als Ergänzung, nicht als Hauptnachweis.
Für Ursachenanalyse zählt ein Tool, das den betroffenen Pfad isoliert und unter gleichen Bedingungen wiederholbar misst.
Wann ein interner Speedtest-Server sinnvoll ist
In größeren Netzen lohnt sich ein fester interner Messpunkt. Das gilt besonders bei mehreren Etagen, verteilten Standorten oder standardisierten Rollouts. Ein zentraler Testserver schafft Vergleichbarkeit. Damit lassen sich Vorher-Nachher-Messungen nach Port-Migrationen, VLAN-Anpassungen oder Firewall-Änderungen sauber dokumentieren.
Auch für Compliance ist das hilfreich. Wer regelmäßig gegen denselben Referenzpunkt testet, kann technische Baselines aufbauen und Abweichungen nachvollziehbar belegen. Das passt gut zu Audit-Anforderungen, bei denen nicht nur ein Einzelwert zählt, sondern die Methode und ihre Wiederholbarkeit.
Was ich in Unternehmen nicht empfehlen würde
Für belastbare Entscheidungen vermeide ich diese Muster:
- Einzeltests ohne Wiederholung und ohne feste Parameter
- gemischte Ergebnisse aus LAN, WLAN, VPN und Internet in einem Bericht
- Dateikopien als alleinigen Nachweis für Netzwerkleistung
- Webtests als Ersatz für interne Punkt-zu-Punkt-Messungen
Ein gutes Tool beantwortet die konkrete Betriebsfrage. Ein geeignetes Tool liefert zusätzlich Ergebnisse, die sich im Störungsfall, im Audit und vor einem Cloud-Projekt sauber verwenden lassen.
LAN Geschwindigkeitstests professionell durchführen
Der typische Einsatzfall im Unternehmen sieht so aus: Ein Standort meldet langsame Dateiübertragungen, Microsoft 365 reagiert träge und vor der nächsten Audit-Runde soll belegt werden, dass die interne Netzbasis sauber arbeitet. Dann reicht kein einzelner Speedtest. Es braucht ein reproduzierbares Verfahren, das technische Ursachen eingrenzt und sich für Betrieb, Cloud-Projekte und Compliance sauber dokumentieren lässt.
Der saubere Baseline-Test mit iperf3
Der erste Lauf misst immer eine klare Referenz zwischen zwei definierten Systemen. Ein Host arbeitet als Server, der andere als Client. Beide sollten per LAN angebunden sein, keine parallelen Backups fahren und nach Möglichkeit nicht unter hoher CPU- oder Storage-Last stehen.
Auf dem Zielsystem starten Sie den Serverprozess:
iperf3 -s
Auf dem zweiten System läuft der Client-Test:
iperf3 -c [Server-IP] -t 30 -P 4
Diese Kombination ist für Unternehmensnetze ein guter Startpunkt. 30 Sekunden sind lang genug, um kurze Schwankungen sichtbar zu machen. Vier parallele Streams vermeiden, dass ein einzelner TCP-Stream den Pfad schlechter aussehen lässt, als er ist. In einem sauber arbeitenden Gigabit-LAN liegen die Praxiswerte meist deutlich unter der nominellen Linkrate, aber klar in einem plausiblen Bereich.
Vor dem ersten Urteil prüfe ich parallel Link-Speed, Duplex, Treiberstand und die Auslastung der beteiligten Systeme. Wer die Erreichbarkeit und Antwortzeiten zusätzlich schnell prüfen will, ergänzt den Test mit einem sauberen Ping-Test per CMD unter Windows. Das ersetzt iperf3 nicht, hilft aber bei der ersten Eingrenzung.
Den ersten Lauf fachlich bewerten
Ein einzelner Spitzenwert ist für einen professionellen LAN Geschwindigkeitstest zu wenig. Relevant ist, ob der Verlauf über die Intervalle stabil bleibt, ob Retransmits auftreten und ob das Ergebnis zur erwarteten Portgeschwindigkeit passt.
Drei Fragen reichen für die erste Einordnung:
- Passt der Durchsatz grundsätzlich zum getesteten Link?
- Bleiben die Intervalle über die Testdauer konsistent?
- Gibt es Hinweise auf Retransmits, Lastspitzen oder eine überforderte Gegenstelle?
Wenn die Intervalle stark schwanken, liegt die Ursache oft nicht am Kabel allein. Häufiger sind Nebenlast auf dem Host, Security-Software, falsch gesetzte Offloading-Optionen oder ein Engpass in der Virtualisierung.
Rückrichtung und UDP gezielt prüfen
Viele Störungen zeigen sich nur in eine Richtung. Das ist im Unternehmensumfeld nichts Ungewöhnliches, etwa bei Fileservern, Terminalservern, Hypervisor-Hosts oder Security-Appliances mit asymmetrischer Verarbeitung.
Für den Reverse-Test nutzen Sie:
iperf3 -c [Server-IP] -t 30 -P 4 -R
Damit sendet der Server zurück zum Client. Dieser Test gehört in jede saubere Messreihe, wenn Anwender nur beim Download oder nur beim Upload Probleme melden.
Für zeitkritische Anwendungen ist auch ein UDP-Test sinnvoll:
iperf3 -c [Server-IP] -u -b 200M -t 30
Mit UDP prüfen Sie nicht nur Bandbreite, sondern auch Verlust und Jitter. Das ist für VoIP, Videokonferenzen, Citrix-Sitzungen und bestimmte Tunnel-Verbindungen deutlich aussagekräftiger als ein reiner TCP-Wert. TCP kann schwankende Bedingungen zeitweise kaschieren. UDP zeigt schneller, ob die Strecke unter Last wirklich stabil bleibt.
Lasttests mit mehreren Clients sauber aufsetzen
Der 1:1-Test bildet die Basis. Produktionsnetze scheitern aber oft erst unter Konkurrenzverkehr. Ein Uplink kann im Leerlauf unauffällig sein und unter parallelen Zugriffen plötzlich einbrechen. Dasselbe gilt für Host-NICs, virtuelle Switches und Storage-nahe Netze.
In Kundenprojekten gehe ich deshalb stufenweise vor:
- Baseline zwischen zwei definierten Endpunkten
- Messung über den realen Produktionspfad mit denselben Parametern
- Parallele Tests mehrerer Clients gegen denselben Zielpunkt
- Wiederholung im geplanten Lastfenster, etwa während Backup- oder Update-Zeiten
So wird sichtbar, ob der Engpass auf dem Pfad selbst liegt oder erst bei gleichzeitiger Nutzung entsteht. Genau diese Unterscheidung ist für Investitionsentscheidungen wichtig. Sonst wird vorschnell ein Switch ersetzt, obwohl die Ursache auf dem Host oder im Hypervisor sitzt.
Jumbo Frames nur in passenden Netzen testen
MTU 9000 ist kein Standardhebel für jedes Unternehmensnetz. In Server-, Backup- oder Storage-Segmenten kann ein gezielter Test sinnvoll sein. In gemischten Office-Umgebungen mit Altgeräten, Druckern, Telefonie und unterschiedlichen Switch-Generationen führt ein uneinheitlicher MTU-Pfad schnell zu schwer nachvollziehbaren Fehlerbildern.
Die Entscheidung ist meist einfach:
| Szenario | Eignung |
|---|---|
| Server zu Server | oft sinnvoll prüfenswert |
| Storage oder Backup-Netz | häufig relevant |
| Normale Office-Arbeitsplätze | meist nachrangig |
| Uneinheitlicher Pfad mit Altgeräten | eher vermeiden |
Jumbo Frames teste ich nur dann, wenn der komplette Pfad bekannt ist und dokumentiert werden kann. Das ist auch für Audits relevant. Eine nicht einheitliche Sonderkonfiguration ohne Nachweis bringt im Betrieb mehr Risiko als Nutzen.
So bleibt der Test im Produktivnetz belastbar
Professionelle LAN Geschwindigkeitstests müssen den Betrieb respektieren. Kurze, definierte Testfenster liefern meist bessere Ergebnisse als lange Belastungsläufe mitten im Tagesgeschäft. Getestet wird pro Pfad, pro Richtung und mit gleichbleibender Methodik. Nur dann lassen sich Vorher-Nachher-Vergleiche nach VLAN-Änderungen, Firewall-Anpassungen oder Standortmigrationen belastbar bewerten.
Für NIS-2 und ISO 27001 ist genau das der Punkt. Nicht der Einzelwert überzeugt im Audit, sondern ein nachvollziehbarer Ablauf mit reproduzierbaren Parametern, klaren Zeitfenstern und eindeutiger Zuordnung zum betroffenen Netzpfad.
Messergebnisse richtig interpretieren und Fehlerquellen finden
Ein Messwert ist erst dann nützlich, wenn er technisch eingeordnet wird. 300 Mbit/s können in einem Szenario völlig okay sein und in einem anderen auf ein massives Problem hinweisen.
Durchsatz ist nur eine von mehreren Wahrheiten
Bei einem lan geschwindigkeit test schauen viele zuerst auf den höchsten Wert. Das ist nachvollziehbar, aber zu kurz gedacht. In der Praxis bewerte ich immer mindestens:
- Durchsatz
- Latenzverhalten
- Stabilität über die Testdauer
- Richtungsunterschiede
- Auffälligkeiten am Endgerät
Selbst ein ordentlicher Durchsatz kann von kurzen Aussetzern begleitet sein, die Telefonie oder Remote-Sessions deutlich stärker treffen als einen Datei-Download.
Warum theoretische Linkrate und Praxiswert nicht identisch sind
Gigabit-Ethernet bedeutet nicht, dass Anwendungen exakt die nominelle Linkrate sehen. Protokolloverhead, Betriebssystemverhalten, Offloading, Sicherheitssoftware und Speichersubsysteme wirken mit.
Darum ist es normal, dass ein sauberer Praxiswert unter der theoretischen Obergrenze liegt. Kritisch wird es erst, wenn die Abweichung ohne nachvollziehbaren Grund gross ausfällt oder stark schwankt.
Häufige Fehlinterpretationen im Unternehmensalltag
Ich sehe in Audits und Störungsanalysen immer wieder dieselben Denkfehler. Diese führen schnell zu falschen Massnahmen.
| Beobachtung | Häufige Fehlannahme | Wahrscheinlicher Blickwinkel |
|---|---|---|
| Dateikopie langsam | das Kabel ist defekt | Storage, CPU, Virenscanner oder Serverlast mitprüfen |
| Nur Home-Office langsam | LAN im Büro ist schuld | VPN-Overhead und Endgerät prüfen |
| Nur eine Richtung schwach | Switch kaputt | Richtungsabhängige Verarbeitung oder NIC-Problem möglich |
| Web-Speedtest gut, Anwendung langsam | Nutzer übertreibt | internes Netz oder Anwendungspfad getrennt testen |
Produktive Systeme dürfen nicht blind gestresst werden
Ein oft übersehenes Thema ist die Auswirkung des Tests selbst. Stresstests können laut der beschriebenen Quelle in 15 Prozent der Fälle temporäre Downtimes verursachen. Gleichzeitig werden seit 2025 rund 70 Prozent der als langsam empfundenen LANs nicht durch Kabel, sondern durch CPU-Bottlenecks auf Endgeräten gebremst. Gigabit-Verbindungen erreichen in der Praxis oft nur 70 bis 80 Prozent der theoretischen Geschwindigkeit. Das gilt besonders für VPN-Tests aus dem Home-Office, weil Verschlüsselung zusätzlichen Overhead erzeugt. Diese Zusammenhänge werden in der Einordnung zu Auswirkungen von Stresstests, CPU-Bottlenecks und VPN-Overhead beschrieben.
Das hat direkte Folgen für die Interpretation. Wenn ein Notebook unter Volllast testet, messen Sie schnell den Prozessor oder die Security-Software, nicht die Verkabelung.
Ein langsamer Test ist kein Beweis für ein langsames Netz. Erst wenn Client, Server und Lastbild mitbetrachtet werden, bekommt der Wert Aussagekraft.
So gehe ich bei auffälligen Ergebnissen vor
Wenn Werte unerwartet niedrig sind, arbeite ich nicht mit Vermutungen, sondern mit Ausschlusslogik:
Client gegen anderen Zielpunkt testen
Bleibt das Problem am Client, ist die Strecke oft unschuldig.Anderen Client gegen denselben Zielpunkt testen
Wandert das Problem nicht mit, ist das erste Endgerät verdächtig.Richtungswechsel prüfen
Ein Reverse-Test zeigt schnell, ob Sende- und Empfangspfad unterschiedlich reagieren.Pfad vereinfachen
Erst gleicher Switch, dann echter Produktionspfad. So verschwindet unnötige Komplexität.Nebeneffekte dokumentieren
CPU-Last, laufende Dienste, VPN, Security-Agenten und Storage-Latenzen gehören ins Bild.
Was oft besser funktioniert als hektisches Tauschen
Viele Teams tauschen zu früh Kabel, Ports oder Switche. Das kann helfen, ist aber ohne Struktur ineffizient.
Besser ist:
- eine Baseline pro Standort
- ein fester Testsatz
- Vergleich von Soll-Pfad und Ist-Pfad
- saubere Trennung von LAN, WAN und Anwendungsebene
So wird aus einem Zahlenwert eine belastbare technische Aussage.
Testdokumentation für NIS-2 und ISO 27001 Compliance
Viele Unternehmen behandeln Netzwerktests noch als rein operative Aufgabe. Für regulierte Umgebungen ist das zu kurz gedacht. Ein dokumentierter lan geschwindigkeit test ist auch ein Nachweis dafür, dass kritische Infrastruktur nicht nur vorhanden, sondern überprüfbar beherrscht wird.
Gerade im Kontext von NIS-2 und einem gelebten ISMS zählt nicht nur, dass gemessen wurde. Entscheidend ist, dass Messung, Rahmenbedingungen, Bewertung und Folgemassnahmen nachvollziehbar festgehalten sind.
Warum die Dokumentation geschäftlich relevant ist
Die grosse Lücke in vielen Anleitungen liegt genau hier. Die Verknüpfung von LAN-Tests mit NIS-2-Anforderungen fehlt oft. Laut einer Bitkom-Studie von 2025 haben 68 Prozent der deutschen KMU Schwierigkeiten bei der Umsetzung. Die Dokumentation von LAN-Tests zur Erreichung von Benchmarks wie über 950 Mbit/s für Gigabit-LAN ist für NIS-2-Audits essenziell, wird aber von vielen Tools nicht direkt unterstützt. Seit Inkrafttreten von NIS-2 stieg die Nachfrage nach automatisiertem LAN-Monitoring bei IT-Dienstleistern um 25 Prozent, wie die Einordnung zu NIS-2, Audit-Dokumentation und automatisiertem LAN-Monitoring beschreibt.
Das zeigt den eigentlichen Punkt. Wer nur testet, aber nicht dokumentiert, kann im Audit kaum belegen, dass Performance-Risiken kontrolliert werden.
Was in ein belastbares Testprotokoll gehört
Ein gutes Protokoll ist weder überladen noch oberflächlich. Es enthält mindestens:
Zeitpunkt und Verantwortliche
Wer hat wann getestet und in welchem Wartungs- oder Produktionsfenster?Testaufbau
Welche Systeme, welcher Pfad, welches VLAN, welche Switchports oder Zonen waren beteiligt?Tool und Parameter
Zum Beispiel iperf3, Testdauer, parallele Streams, TCP oder UDP, Reverse-Test ja oder nein.Rohdaten und Bewertung
Nicht nur das Endergebnis, sondern auch auffällige Teilintervalle und Interpretation.Abweichungen und Massnahmen
Was war unauffällig, was wich ab, welche Folgeprüfung wurde ausgelöst?
Ein Audit will Kontext, keine lose Zahl
Ein einzelner Screenshot ist kein brauchbarer Nachweis. Ein Auditor oder externer Prüfer will erkennen, ob die Organisation wiederholbar arbeitet.
Dazu gehört auch die Einordnung ins Risikomanagement. Wenn ein kritischer Fileserver nur instabile Werte liefert, ist das nicht bloss ein Technikthema. Es betrifft Verfügbarkeit, Wiederanlauf und gegebenenfalls Sicherheitsmassnahmen.
Dokumentierte Messungen sind im Audit weit stärker als mündliche Aussagen wie „das Netzwerk war eigentlich immer schnell“.
Ein einfacher Aufbau für wiederkehrende Nachweise
Ein pragmatisches Muster ist eine standardisierte Vorlage pro Testlauf:
| Feld | Inhalt |
|---|---|
| Systeme | Quelle, Ziel, Rolle |
| Pfad | Segment, Switch, Zone |
| Messung | Tool, Parameter, Richtung |
| Ergebnis | Durchsatz, Auffälligkeiten |
| Bewertung | innerhalb Baseline oder ausserhalb |
| Aktion | keine, beobachten, eskalieren |
So werden technische Messungen zu verwertbaren Compliance-Unterlagen.
Häufig gestellte Fragen zum LAN Geschwindigkeitstest
Reicht ein Internet-Speedtest aus, wenn Nutzer über langsame Netzwerke klagen
Ein Internet-Speedtest hilft nur bei einer sehr engen Fragestellung: Wie gut ist die Verbindung ins WAN. Für Beschwerden über Fileserver, ERP, VoIP, Terminalserver, Backups oder virtuelle Umgebungen im Unternehmensnetz ist er als Nachweis ungeeignet.
In der Praxis prüfe ich zuerst, wo der Engpass überhaupt liegen kann. Liegt das Problem zwischen Client und Access-Switch, zwischen VLANs, am Uplink, an einer Firewall-Policy, am Server oder erst auf dem Weg zum Cloud-Dienst? Ein öffentlicher Speedtest beantwortet diese Frage nicht. Für interne Störungen braucht es Messungen im eigenen LAN mit klar definiertem Quell- und Zielsystem.
Wie oft sollte ein Unternehmen einen lan geschwindigkeit test durchführen
Ein LAN Geschwindigkeitstest gehört in den Betriebsprozess, nicht nur in die Störungsbearbeitung.
Sinnvolle Auslöser sind:
- nach Änderungen an Switches, Firewalls oder VLANs
- vor und nach Cloud-Migrationen
- nach Umbauten in Büroflächen, Etagenverteilern oder Serverräumen
- vor internen oder externen Audits
- bei wiederkehrenden Beschwerden aus einem Standort oder einer Abteilung
Wichtiger als die reine Häufigkeit ist die Vergleichbarkeit. Wer heute mit iperf3 und morgen mit einer Dateikopie misst, bekommt keine belastbare Baseline. Für NIS-2 und ISO 27001 zählt ein wiederholbares Verfahren mit festen Parametern, nicht eine Sammlung von Einzelwerten.
Sollte man in produktiven Zeiten testen
Ja, aber kontrolliert.
Kurze Messungen mit begrenzter Last sind oft vertretbar, wenn das Zeitfenster abgestimmt ist und die betroffenen Systeme bekannt sind. Volllasttests mit vielen parallelen Streams während der Kernarbeitszeit können Fachanwendungen, Storage oder schwächer dimensionierte Firewalls spürbar belasten.
Vor einem Test in der Produktion sollten diese Punkte geklärt sein:
- welches Zeitfenster freigegeben ist
- welche Systeme geschäftskritisch sind
- welche Lastgrenzen akzeptiert werden
- wer auf Betriebsseite informiert ist
- welche Abbruchkriterien gelten
So bleibt die Messung ein Diagnosewerkzeug und wird nicht selbst zum Incident.
Ist eine Dateikopie ein brauchbarer Test
Als schneller Praxischeck ist sie nützlich. Als technischer Nachweis nur eingeschränkt.
Eine SMB-Dateikopie misst immer mehrere Komponenten gleichzeitig: Netzwerk, Datenträger, Protokoll-Overhead, CPU-Last, Virenscanner und die aktuelle Serverauslastung. Wenn die Kopie langsam ist, wissen Sie noch nicht, ob das LAN betroffen ist oder das Storage-System. Für eine saubere Trennung der Ursache ist iperf3 meist die bessere Wahl. Die Dateikopie eignet sich dann als Ergänzung, um die Anwendungsrealität zu prüfen.
Warum sind Werte im Home-Office oft schlechter als im Büro
Weil dort zusätzliche Schichten dazukommen, die im Büro-LAN nicht vorhanden sind. Typisch sind WLAN im Heimnetz, schwankende Internetanbindung, VPN-Verschlüsselung, lokale Endgeräteprobleme oder Überlastungen beim Provider.
Deshalb bewerte ich Home-Office-Messungen nie gegen dieselbe Baseline wie Messungen im internen Netz. Für den Betrieb ist wichtiger, ob der Arbeitsplatz stabil genug für die konkrete Anwendung ist, nicht ob er die Werte eines Büroanschlusses erreicht.
| Umfeld | Wichtiger Fokus |
|---|---|
| Büro-LAN | Switchport, VLAN, Client, Server, Uplink |
| Home-Office mit VPN | Endgerät, WLAN, Tunnel, Internetpfad |
| Hybrid-Arbeitsplatz | gleiche Messmethode, getrennte Baseline |
Welche Kennzahl ist wichtiger als die höchste Mbit/s-Zahl
Für viele Unternehmensanwendungen ist die Stabilität des Durchsatzes wichtiger als der Spitzenwert. Ein kurzer Peak sieht im Bericht gut aus, hilft aber wenig, wenn parallel Paketverluste, Jitter oder starke Schwankungen auftreten.
Das gilt besonders für VoIP, Citrix, RDP, Datenbankzugriffe und Cloud-Anwendungen. Dort zählen reproduzierbare Werte unter Last. Für die Bewertung eines LAN Geschwindigkeitstests schaue ich deshalb nicht nur auf Mbit/s, sondern auf das Gesamtbild aus Durchsatz, Konstanz, Fehlerrate und Testbedingungen.
Wann sollte ein externer Dienstleister eingebunden werden
Ein externer Dienstleister ist sinnvoll, wenn das interne Team Symptome sieht, die Ursache aber nicht trennscharf eingrenzen kann. Das betrifft oft Umgebungen mit mehreren VLANs, standortübergreifenden Verbindungen, Firewall-Clustern, QoS-Regeln oder hybriden Cloud-Pfaden.
Typische Fälle sind:
- wiederkehrende Performance-Probleme ohne klare Ursache
- Cloud-Projekte mit engem Zeitplan
- Audit-Vorbereitung für ISO 27001 oder NIS-2
- kritische Infrastrukturen mit erhöhtem Nachweisdruck
- mehrere beteiligte Dienstleister oder Carrier
Der Vorteil liegt selten nur in der Messung selbst. Er liegt in der sauberen Methodik, der Interpretation und der belastbaren Dokumentation für Betrieb, Management und Prüfer.
Wenn Sie einen lan geschwindigkeit test belastbar für Betrieb, Cloud-Projekte und Compliance aufsetzen wollen, unterstützt Deeken.Technology GmbH bei Analyse, Messkonzept, Dokumentation und technischer Umsetzung in Unternehmensumgebungen. Besonders für KMU mit NIS-2-Anforderungen, Audit-Pflichten und Modernisierungsprojekten lohnt sich ein sauberer Netzwerk-Baseline-Prozess.
