Wenn alle über ein langsames Netz klagen

Erst präzisieren: welche Anwendung, welcher Ort, welche Uhrzeit

Die drei Fragen nach Anwendung, Ort und Uhrzeit schneiden den Suchraum stärker zusammen als jede Messung. Sind alle Anwendungen an allen Orten langsam, liegt die Ursache nahe am Kern, etwa an DNS, an der Firewall oder am Internetanschluss. Ist nur eine Anwendung langsam, liegt sie bei dieser Anwendung oder auf ihrem Pfad. Ist nur ein Ort betroffen, prüfst du dessen Anbindung.

Die Uhrzeit verrät Lastmuster. Langsam um 8 Uhr und zur Mittagszeit spricht für Anmeldungen, Updates und Profilsynchronisation, langsam nachts für Backups und Replikation. Lass dir zwei bis drei konkrete Zeitpunkte nennen, damit du sie im Monitoring wiederfindest.

Bandbreite, Latenz und Paketverlust: drei Größen, drei Messungen

Bandbreite ist die Kapazität eines Links in Bit pro Sekunde, Latenz die Zeit für Hin- und Rückweg, Paketverlust der Anteil, der nicht ankommt. Für TCP hängen die drei zusammen. Der Durchsatz einer einzelnen Verbindung ist durch das Fenster geteilt durch die Laufzeit begrenzt, und jeder Verlust lässt TCP seine Senderate senken. Schon ein Verlust im Bereich von einem Prozent drückt den Durchsatz einer Verbindung auf langen Strecken deutlich.

Für die Rechnung brauchst du das Bandbreiten-Verzögerungs-Produkt. RFC 6349 definiert es als Produkt aus der Kapazität des engsten Links und der Laufzeit. Es gibt an, wie viele Daten unterwegs sein müssen, damit die Leitung voll ausgelastet ist. Ist das Fenster kleiner, wartet der Sender auf Bestätigungen, und die Leitung bleibt teilweise leer.

Bandbreiten-Verzögerungs-Produkt
  100 Mbit/s x 0,025 s = 2.500.000 bit = 312.500 Byte

Höchster Durchsatz mit 64-KiB-Fenster (65.535 Byte) bei 25 ms RTT
  65.535 Byte x 8 / 0,025 s = 20.971.200 bit/s, also rund 21 Mbit/s

Gleiches Fenster im LAN mit 0,5 ms RTT
  65.535 Byte x 8 / 0,0005 s = rund 1,05 Gbit/s

Interface-Zähler lesen: CRC, Drops und Duplex

Die Zähler an den Switchports sind die billigste Messung und werden am häufigsten übersprungen. Cisco ordnet sie so ein: CRC-Fehler entstehen, wenn die Prüfsumme nicht zu den Daten passt, meist durch Kabel, Störungen, einen defekten Port oder einen Duplex-Mismatch. Output Drops zeigen, dass die Ausgangswarteschlange voll war, typisch bei Geschwindigkeitsunterschieden und Überlast. Late Collisions dürfen auf Vollduplex-Ports gar nicht vorkommen.

Ein absoluter Zählerstand sagt wenig, weil er seit dem letzten Neustart läuft. Setze die Zähler mit clear counters für den Port zurück oder notiere den Stand, erzeuge Last und lies erneut. Steigende Werte unter Last sind der Befund. Prüfe immer beide Enden eines Links, denn bei einem Duplex-Mismatch zeigen die beiden Seiten unterschiedliche Fehler.

show interfaces Gi1/0/14 status
show interfaces Gi1/0/14 counters errors
show interfaces Gi1/0/14 | include duplex|CRC|collisions|drops|rate

! Kürzere Mittelwerte für Lastspitzen
configure terminal
interface TenGigabitEthernet1/1/1
 load-interval 30
end
show interfaces Te1/1/1 | include rate|output drops

! Zähler für einen Port zurücksetzen und unter Last neu lesen
clear counters Gi1/0/14

Engpässe an Uplink, WAN, Firewall und WLAN

Ein Engpass ist die Stelle auf dem Pfad mit der kleinsten verfügbaren Kapazität. Im Firmennetz sind es selten die Access Ports, sondern die Stellen, an denen sich Verkehr bündelt: der Uplink vom Etagenswitch, der WAN-Anschluss eines Standorts, die Firewall am Internetübergang und die Funkzelle im WLAN. Für jede gibt es einen eigenen Nachweis.

Beim WAN lohnt ein Blick auf die Richtung. Viele Anschlüsse sind asymmetrisch, und an Standorten, die Daten in die Zentrale oder in die Cloud hochladen, ist der Upload der Engpass. Bei Firewalls zählt nicht der größte Wert im Datenblatt, sondern der für die Funktionen, die tatsächlich aktiv sind: IPS, Anwendungserkennung und TLS-Inspektion kosten jeweils Leistung.

• Uplink: Output Drops und Auslastung mit kurzem load-interval, Überbuchung aus Portzahl und Uplink-Kapazität berechnen

• WAN: Auslastung je Richtung, Latenz und Verlust über den Tag, Vergleich mit der gebuchten Bandbreite

• Firewall: CPU-Last, Sitzungszahl und Durchsatz zur Stoßzeit gegen den Datenblattwert der aktiven Funktionen

• WLAN: Kanalauslastung, Wiederholungsrate, Datenraten und Zahl der Clients je Access Point

• Server-Anbindung: Fehler und Drops am Serverport, Auslastung von Teaming oder Port-Channel

MTU und Fragmentierung als Sonderfall

MTU-Probleme verhalten sich wie kein anderer Fehler: Kleine Pakete gehen durch, große verschwinden. Path MTU Discovery nach RFC 1191 setzt darauf, dass ein Router ein zu großes Paket mit DF-Bit verwirft und eine ICMP-Meldung zurückschickt. Filtert eine Firewall diese Meldung, verliert der Sender große Pakete still. Cisco nennt das gezielte Freigeben dieser ICMP-Meldungen als ersten Lösungsweg und das Anpassen der MSS am Tunnel als zweiten.

Die Größe, die du beim Ping angibst, ist unter Linux und Windows die Nutzlast. Für eine IPv4-MTU von 1500 Byte kommen 20 Byte IP-Header und 8 Byte ICMP-Header hinzu, die größte Nutzlast ist also 1472 Byte. Auf Cisco IOS gibst du dagegen die Größe des gesamten Pakets an, dort testest du direkt mit 1500.

# Linux: 1472 Byte Nutzlast + 28 Byte Header = 1500, DF-Bit gesetzt
ping -M do -s 1472 -c 3 10.50.1.10
ping -M do -s 1372 -c 3 10.50.1.10
tracepath -n 10.50.1.10

# Windows
ping -f -l 1472 10.50.1.10

! Cisco IOS: Tunnel-Interface mit GRE und IPsec
interface Tunnel10
 ip mtu 1400
 ip tcp adjust-mss 1360

Messen mit iperf3, Monitoring-Verläufen und Mitschnitt

iperf3 misst den TCP- oder UDP-Durchsatz zwischen zwei Endpunkten. Laut Dokumentation lauscht der Server auf Port 5201 und ein Test dauert ohne Angabe zehn Sekunden. Miss in beide Richtungen, denn mit -R sendet der Server zum Client, und vergleiche einen Stream mit mehreren parallelen. Bei UDP begrenzt iperf3 ohne Angabe auf 1 Mbit/s, mit -b setzt du die Zielrate. Die Option -O blendet die ersten Sekunden aus, in denen TCP noch hochfährt.

Monitoring liefert den Verlauf, den eine einzelne Messung nicht hat. Wichtig sind 64-Bit-Zähler, also ifHCInOctets und ifHCOutOctets aus der IF-MIB nach RFC 2863, weil 32-Bit-Zähler auf schnellen Links zwischen zwei Abfragen überlaufen können. Ergänze Auslastung um Fehler- und Drop-Zähler und um Latenzmessungen zu festen Zielen. Ein Mitschnitt schließlich zeigt Retransmissions, Fenstergrößen und Antwortzeiten einer konkreten Verbindung.

# Auf dem Server in der Zentrale
iperf3 -s

# Am Standort: 30 Sekunden, erste 3 Sekunden ausblenden
iperf3 -c 10.50.1.10 -t 30 -O 3

# Gegenrichtung und vier parallele Streams
iperf3 -c 10.50.1.10 -t 30 -O 3 -R
iperf3 -c 10.50.1.10 -t 30 -O 3 -P 4

# UDP mit 50 Mbit/s für Verlust und Jitter
iperf3 -c 10.50.1.10 -u -b 50M -t 30

Wenn es doch die Anwendung ist

Am Ende einer sauberen Messreihe steht häufig die Erkenntnis, dass das Netz liefert. Der Mitschnitt zeigt dann ein Muster: Die Anfrage des Clients kommt beim Server an, das TCP-ACK folgt nach einer Millisekunde, die eigentliche Antwort aber erst nach zwei Sekunden. Diese Lücke zwischen ACK und Daten ist Rechenzeit des Servers oder Wartezeit auf eine Datenbank, keine Netzzeit.

Mit diesem Beleg ist das Gespräch mit dem Anwendungsteam sachlich. Nenne die Zeitstempel der Anfrage, der Bestätigung und der Antwort, die Laufzeit im Netz und die Zahl der Anfragen je Vorgang. Zeigt sich, dass die Anwendung für einen Vorgang Hunderte von Anfragen nacheinander stellt, ist die Lösung eine Architekturfrage und keine Leitungsfrage.