Fallstudie 02 — Netzwerkleistung
Wir haben genug Bandbreite — warum ist trotzdem alles langsam?
Geringe Auslastung überall, dennoch Verzögerungen und frustrierte Nutzer. Das Netzwerk war nicht überlastet — es war strukturell defekt.
Ausgangslage
Die Bandbreitenauslastung war gering — auf allen überwachten Leitungen. Keine Sättigung irgendwo im Netzwerk. Dennoch liefen Anwendungen träge, Benutzer waren frustriert, und die Standardüberwachung lieferte keine Erklärung.
Die übliche Reaktion auf solche Beschwerden lautet: mehr Kapazität hinzufügen, Verbindungsgeschwindigkeiten erhöhen. Der Kunde hatte genau das bereits einmal getan. Das Problem kehrte innerhalb von Wochen zurück.
Die verborgene Realität
Das Netzwerk war nicht überlastet — es war strukturell chaotisch. Vier separate architektonische Probleme wirkten zusammen und erzeugten die Leistungsdegradation.
- Flache Netzwerktopologie mit massiven, unkontrollierten Broadcast-Domänen — jedes Gerät empfing Broadcast-Traffic von jedem anderen Gerät im Netzwerk
- Unkontrollierter Ost-West-Verkehr sättigte interne Segmente — Server-zu-Server-Kommunikation konkurrierte mit Benutzer-Traffic auf denselben Segmenten
- Keine Verkehrspriorisierung — VoIP-Gespräche, Videokonferenzen und Datei-Backups wurden identisch behandelt, unabhängig von ihrer Zeitkritikalität
- Das Netzwerk war nicht überlastet — es war strukturell chaotisch, und mehr Bandbreite hätte nur vorübergehend geholfen
In einer flachen Topologie skaliert Broadcast-Traffic mit dem Netzwerkwachstum schlecht. Was bei 50 Geräten noch handhabbar ist, wird bei 200 Geräten ein ernsthaftes Problem — und das Wachstum hatte so graduell stattgefunden, dass keine einzelne Änderung einen offensichtlichen Alarm ausgelöst hatte.
Warum mehr Bandbreite keine Lösung war
Das Kapazitäts-Upgrade hatte kurzzeitig geholfen, weil es vorübergehend den Wettbewerb um Ressourcen verringerte. Aber die strukturellen Probleme blieben. Broadcast-Traffic überflutete weiterhin jeden Segment. Ost-West-Server-Kommunikation konkurrierte weiterhin mit benutzerseitigen Anwendungen. Ohne Priorisierung machte jedes zusätzliche Gerät die Situation geringfügig schlechter, unabhängig von der verfügbaren Bandbreite.
Was FM-NetSec Nordic unternahm
- Ordnungsgemäße Netzwerksegmentierung eingeführt, ausgerichtet an Funktion und Risiko — Trennung von Benutzer-Traffic, Server-Kommunikation und Management-Traffic in klar abgegrenzte Segmente
- Broadcast-Reichweite auf angemessene Grenzen reduziert — die Broadcast-Überflutung beseitigt, die auf jedem Segment Kapazität verbrauchte
- QoS implementiert, um geschäftskritischen Datenverkehr zu priorisieren — zeitkritische Kommunikation erhält unter allen Lastbedingungen eine angemessene Behandlung
- Interne Verkehrsflüsse und Routing bereinigt — unnötige Pfade entfernt, Traffic auf logischen, klar definierten Routen konsolidiert
Ergebnis
- Sofortige, messbare Leistungsverbesserung über alle Standorte
- Stabile und vorhersehbare Anwendungslatenz
- Konsistentes Verhalten unter variierenden Lastbedingungen
„Mehr Bandbreite behebt keine schlechte Architektur."
Die Verbesserung war sofort und signifikant — nicht weil irgendetwas im absoluten Sinne schneller gemacht wurde, sondern weil das strukturelle Chaos beseitigt wurde. Traffic floss dorthin, wo er hingehörte. Kritische Anwendungen erhielten die angemessene Priorität. Broadcast-Rauschen hörte auf, mit produktiver Arbeit um Kapazität zu konkurrieren.
Fragen zu diesem Fall
Wenn die Bandbreitenauslastung niedrig war, warum war die Leistung trotzdem schlecht?
Bandbreitenkapazität und Netzwerkleistung sind nicht dasselbe. Vier strukturelle Probleme interagierten: übermäßiger Broadcast-Traffic, Konkurrenz zwischen Ost-West-Server-Traffic und nutzerzugewandten Anwendungen, fehlende QoS-Priorisierung und suboptimale Traffic-Pfade.
Warum hat ein Bandbreiten-Upgrade das Problem nicht gelöst?
Das Upgrade hat vorübergehend Engpässe reduziert – aber die strukturellen Probleme blieben. Broadcast-Traffic überschwemmte weiterhin alle Segmente. Ohne Priorisierung verschlechterte jedes neue Gerät die Situation marginal, unabhängig von der verfügbaren Bandbreite.
Was war die Lösung?
Ordentliche Netzwerksegmentierung mit VLANs zur Kontrolle von Broadcast-Domänen, QoS-Richtlinien zur Priorisierung latenzsensitiver Traffic-Typen und Traffic-Pfad-Optimierung. Keine zusätzliche Hardware war erforderlich.
Was ist die wichtigste Erkenntnis aus diesem Fall?
Bandbreite ist kein Proxy für Netzwerkgesundheit. Ein Netzwerk kann erhebliche verfügbare Kapazität haben und trotzdem schlecht performen, wenn die Architektur Konkurrenz, Broadcast-Überschwemmung oder falsch gerouteten Traffic erzeugt.
