Packet Loss zwischen AZs: So beweist du es

Packet Loss zwischen AZs ist eines der unangenehmsten Fehlerbilder in Cloud-Umgebungen: Es tritt oft nur unter Last auf, wirkt sporadisch, verschiebt Latenzen in die Tail (p95/p99) und wird von betroffenen Teams schnell als „Applikationsproblem“ oder „Timeout-Thema“ fehlinterpretiert. Gerade bei Microservices, Datenbanken mit Replikation oder Service-Mesh-Traffic über Availability Zones (AZs) kann schon ein geringer Paketverlust (z. B. 0,1–1 %) massive Auswirkungen haben: TCP-Retransmits, Head-of-Line-Blocking, langsamere Congestion-Control, instabile gRPC-Streams oder aus dem Takt geratene Health Checks. Die größte Hürde im Incident ist aber meist nicht die technische Behebung, sondern der Beweis: Viele Diagnose-Tools zeigen nur „Timeout“ oder „verbindet nicht“, während Stakeholder eine harte Aussage erwarten, ob tatsächlich Netzwerkverlust zwischen AZs vorliegt oder ob Host, Anwendung oder Overload verantwortlich sind. In diesem Artikel lernen Sie, wie Sie Paketverlust zwischen AZs belastbar nachweisen: mit einer sauberen Messstrategie, reproduzierbaren Experimenten, einer klaren Beweiskette aus Metriken und Logs sowie einer Methodik, die zwischen Netzwerkverlust, Queueing, Rate-Limits und Applikationsfehlern unterscheiden kann.

Was „Packet Loss“ im AZ-Kontext wirklich bedeutet

Paketverlust bedeutet, dass ein gesendetes Paket den Empfänger nicht erreicht. Wichtig ist die präzise Einordnung: „Nicht angekommen“ kann auf dem Netzwerkpfad passieren, aber auch auf dem Host (NIC/Driver), im Kernel (Drops in Queues), in einer virtuellen Switch-Schicht oder durch Security-/Policy-Komponenten. In Cloud-Netzen zwischen AZs kommt eine zusätzliche Komplexität hinzu: Der Traffic läuft typischerweise über providerverwaltete Backbones und über logische Abstraktionen (Overlay/Underlay), die Sie nicht direkt sehen.

• Netzwerkpfadverlust: Paket geht unterwegs verloren (Congestion, Fehler, Drops in Switch/Router).
• Hostseitige Drops: Empfangs-/Sendequeues überlaufen, Interrupt/CPU-Limit, Offload/Driver-Probleme.
• Policy/Filtering: Security-Regeln, Firewalls oder NACLs verwerfen Pakete (oft als „Drop“, nicht als „Reject“ sichtbar).
• Applikationsinterpretation: Paketverlust wird als Timeout, Retries oder „sporadischer 5xx“ sichtbar.

Für die Protokoll-Mechanik ist es hilfreich, TCP-Verhalten bei Verlust zu kennen: Retransmissions und Congestion Control sind Kernbestandteil von TCP, beschrieben u. a. in RFC 793. Für UDP-basierte Protokolle gilt: Verlust ist oft „silent“, und die Anwendung muss damit umgehen.

Warum schon kleiner Paketverlust zwischen AZs große Effekte hat

Zwischen AZs haben Sie oft höhere RTT als innerhalb einer AZ. Paketverlust multipliziert sich mit RTT, weil Retransmits Zeit kosten und Window-Growth verlangsamen. Außerdem verschärft Verlust Tail Latency, weil einzelne Flows überproportional betroffen sind. Besonders kritisch ist das bei chatty Patterns (viele kleine Calls) oder bei Protokollen mit starken Abhängigkeiten von stabilen Streams (gRPC, HTTP/2).

• TCP Retransmits: Jeder Verlust kann zu einem oder mehreren Retransmissions führen, je nach RTO/ACK-Mechanik.
• Congestion Control: Verlust wird oft als Stau interpretiert; der Sender reduziert Rate/Window.
• Head-of-Line-Blocking: Bei HTTP/2 können einzelne verlorene Frames die Lieferung nachfolgender Daten verzögern.
• Retry-Verstärkung: Applikationen kompensieren Verlust mit Retries – das erhöht Last und kann Verlust weiter verschlimmern.

Beweisprinzip: Von „Symptomen“ zu „Evidence“

„Es fühlt sich nach Packet Loss an“ ist im Incident nicht ausreichend. Ein belastbarer Nachweis besteht aus mindestens drei Bausteinen, die zusammen eine Beweiskette ergeben:

• Messung am Rand: Sender- und Empfängerbeobachtung (z. B. Retransmits, Drops, Errors).
• Korrelation: Zeitliche Übereinstimmung mit Latenzspitzen, Error Spikes, Region/AZ-Segmentierung.
• Kontrollierte Tests: Reproduzierbare Probes zwischen spezifischen AZ-Paaren, möglichst symmetrisch und identisch konfiguriert.

Das Ziel ist eine klare Aussage: „Zwischen AZ-A und AZ-B liegt in Zeitraum X ein Verlust von Y % (oder eine erhöhte Retransmit-Rate) vor, der nicht durch lokale Host-Drops erklärt werden kann.“

Schritt 1: Scope sauber definieren (AZ-Paare, Pfade, Protokolle)

Bevor Sie messen, müssen Sie den Scope eingrenzen. „Zwischen AZs“ ist zu grob. Unterschiedliche Subnetze, Instanztypen, Nodepools oder Routen können unterschiedliche Ergebnisse liefern.

• AZ-Paare definieren: A↔B, A↔C, B↔C getrennt betrachten.
• Quell- und Ziel-Workloads festlegen: Möglichst identische Hosts/Pods in jeder AZ.
• Protokolle trennen: TCP vs. UDP; auch Port-spezifisch (z. B. 443, 3306, 9092).
• Richtung beachten: Verlust kann asymmetrisch sein (A→B stärker als B→A).

Schritt 2: Packet Loss korrekt berechnen (und nicht mit Latenz verwechseln)

Paketverlust ist eine Rate. Einzelne Timeouts beweisen keinen Verlust, genauso wenig wie hohe Latenz. Für Messungen in definierten Intervallen (z. B. 60 Sekunden) ist die einfache Verlustquote:

$\mathrm{Loss}=\frac{P_{\mathrm{sent}}–P_{\mathrm{received}}}{P_{\mathrm{sent}}}$

In der Praxis messen Sie selten echte „P_received“ auf Netzwerkebene, sondern Proxy-Metriken: ICMP Echo Replies, UDP Sequenzpakete, TCP Retransmits oder Kernel-Drop-Counter. Wichtig ist, zu dokumentieren, welche Proxy-Metrik Sie als Beleg verwenden.

Schritt 3: Synthetische Probes zwischen AZs aufsetzen

Der schnellste Weg zu belastbarer Evidence ist ein kontrollierter, synthetischer Testpfad. Die Idee: Sie erzeugen Traffic zwischen Hosts in unterschiedlichen AZs und messen dabei Verlustsignale. Entscheidend ist die Reproduzierbarkeit.

• ICMP Ping (Basis): Schnell, aber nicht ausreichend allein (ICMP kann anders behandelt werden als TCP).
• UDP mit Sequenznummern: Sehr gut, um Verlust direkt zu quantifizieren (Anzahl fehlender Sequenzen).
• TCP-Tests: Fokus auf Retransmits, RTO, Throughput, sowie „connect latency“.
• Mehrere Payload-Größen: Kleine und große Pakete, um MTU/PMTUD-Probleme auszuschließen.

Warum ICMP allein oft nicht reicht

ICMP ist nützlich als „Smoke Test“, aber Cloud-Umgebungen können ICMP anders priorisieren oder limitieren. Ein grüner Ping beweist daher nicht, dass TCP/UDP stabil sind. Umgekehrt kann ICMP-Rate-Limiting einen „scheinbaren Verlust“ erzeugen, der für Applikationstraffic nicht gilt. Deshalb ist es wichtig, mindestens einen TCP- und/oder UDP-basierten Probe einzusetzen.

Schritt 4: Hostseitige Evidence sammeln (Retransmits, Drops, NIC Errors)

Um „Netzwerkverlust“ von „Host-Überlast“ zu trennen, benötigen Sie Hostmetriken. Wenn der Empfänger Pakete dropt, ist das kein Backbone-Problem, sondern ein Ressourcenproblem. Relevante Kategorien:

• TCP Retransmits (Sender): Steigen Retransmits im gleichen Zeitfenster wie die Symptome?
• Kernel Drops (Empfänger): Drops in Receive Queues, Socket Drops, Buffer Overflows.
• NIC Errors: CRC-Errors, RX/TX errors, dropped packets auf Interface-Ebene.
• CPU/Interrupt Pressure: Hohe SoftIRQ/NetRx-Last kann zu Drops führen, obwohl das Netz „gesund“ ist.

Praktisch ist es sinnvoll, diese Metriken pro AZ zu segmentieren und für „gute“ vs. „schlechte“ AZ-Paare zu vergleichen. Die Beweiskraft steigt stark, wenn Retransmits nur auf Cross-AZ-Flows steigen, während Intra-AZ-Flows stabil bleiben.

Schritt 5: Flow Logs und Netzwerk-Telemetrie richtig interpretieren

VPC/VNet Flow Logs (oder ähnliche Telemetrie) sind hilfreich, aber sie messen nicht immer „Loss“ direkt. Oft sehen Sie nur, dass Verbindungen neu aufgebaut werden, dass Byte-/Packet-Counter von erwarteten Mustern abweichen oder dass bestimmte Flows fehlen. Dennoch sind Flow Logs wichtig für die Beweiskette, weil sie Scope und Richtung verifizieren.

• Richtung und AZ-Zuordnung: Beweisen, dass der Traffic wirklich zwischen den betroffenen AZs läuft.
• Zusammenhang mit Errors: Peaks in Flow-Counts oder Short-Lived-Flows können Retries/Resets widerspiegeln.
• Security vs. Loss: Drops durch Policies sind häufig „REJECT“ oder fehlen als Flow, je nach Plattform.

Als Referenz zur Logik und Grenzen von Flow Logs eignet sich z. B. AWS VPC Flow Logs. Ähnliche Mechanismen existieren in Azure und GCP, die Interpretation bleibt konzeptionell vergleichbar.

Schritt 6: Ein A/B-Vergleich, der überzeugt (Control vs. Treatment)

Ein sehr überzeugender Beweis ist ein A/B-Design: Sie messen gleichzeitig einen Control-Pfad (intra-AZ) und einen Treatment-Pfad (inter-AZ) mit identischen Hosts und identischer Last. Wenn nur der inter-AZ-Pfad Verlustsignale zeigt, ist die Argumentation stark.

• Control: Host A1 → Host A2 (gleiche AZ), gleiche Instanzgröße, gleiche Security Policies.
• Treatment: Host A1 → Host B1 (andere AZ), gleiche Konfiguration.
• Gleiche Testlast: Gleiche Rate, gleiche Paketgröße, gleicher Testzeitraum.
• Gleiches Beobachtungsset: Retransmits, Drops, Latenz, Jitter, Applikationsfehler.

Dieses Muster reduziert Diskussionen über „es ist bestimmt die App“: Wenn die App identisch ist, aber nur Cross-AZ problematisch ist, bleibt wenig Interpretationsspielraum.

Schritt 7: Statistische Sicherheit erhöhen (Konfidenz statt Einzelfall)

Paketverlust ist oft bursty. Ein kurzer Test kann zufällig „gut“ aussehen, obwohl ein Problem existiert. Sie erhöhen die Beweiskraft, indem Sie über mehrere Intervalle messen und Konfidenz ausdrücken. Ein pragmatischer Ansatz ist, jedes Intervall als Stichprobe zu behandeln und Mittelwert sowie Streuung zu reporten.

Wenn Sie eine einfache Abschätzung der Konfidenz für eine Verlustquote benötigen, können Sie (unter vereinfachten Annahmen unabhängiger Bernoulli-Events) die Standardabweichung der Quote p bei n Probes approximieren:

$\sigma \approx \sqrt{\frac{p\times (1–p)}{n}}$

Das ist keine perfekte Modellierung für burstigen Loss, hilft aber, eine Diskussion von „Einmal war’s schlecht“ hin zu „über 30 Minuten zeigen 12 von 30 Intervallen signifikant höhere Verlustsignale“ zu bringen.

Häufige Ursachen für Loss-Symptome zwischen AZs (und wie man sie sauber trennt)

Der Nachweis von Loss ist nur der erste Schritt. Damit der Beweis akzeptiert wird, sollten Sie die häufigsten Alternativerklärungen explizit ausschließen oder separieren.

• Host-Überlast (CPU/IRQ): Drops am Empfänger, steigende SoftIRQ, überlaufende Buffers.
• MTU/PMTUD-Blackhole: „Loss“ nur bei großen Paketen; kleine Probes gehen durch. ICMP/PMTUD-Themen werden oft mit Loss verwechselt.
• Rate-Limiting von ICMP: Ping zeigt Verlust, TCP nicht. Deshalb immer zusätzlich TCP/UDP testen.
• Asymmetrisches Routing: Einseitige Loss-/Retransmit-Signale; Rückweg läuft über andere Pfade oder Appliances.
• Load Shedding / Queue Drops: Der Pfad ist nicht „kaputt“, aber überlastet. Verlust korreliert stark mit Throughput/Peak-Last.

Für PMTUD-/ICMP-Hintergründe sind die RFCs eine solide Basis, etwa RFC 8201 (Path MTU Discovery für IPv6) und RFC 4443 (ICMPv6) – selbst wenn Sie IPv4 nutzen, ist das Prinzip ähnlich: Blockierte „Packet Too Big“-Signale führen zu Blackholes, die wie Loss wirken.

Beweis im Incident: Welche Artefakte Stakeholder überzeugen

Ein guter Nachweis besteht nicht aus einer einzelnen Grafik, sondern aus einem konsistenten Set von Artefakten, das dieselbe Story aus mehreren Blickwinkeln erzählt. Bewährt hat sich folgende Kombination:

• Heatmap nach AZ-Paar: Loss-/Retransmit-Raten pro AZ↔AZ, um den Hotspot sichtbar zu machen.
• Zeitreihe (Korrelation): Loss-/Retransmit-Spike korreliert mit Latenz p99 und Fehlerquote.
• Control-vs-Treatment-Plot: Intra-AZ stabil, Inter-AZ degradierend, gleichzeitig gemessen.
• Hostmetriken: Keine entsprechenden RX-Drops/CPU-Spikes auf dem Empfänger (oder wenn doch: klare Zuordnung als Hostproblem).
• Flow-Log-Segmentierung: Beleg, dass betroffene Flows tatsächlich cross-AZ sind.

Je mehr Ihr Nachweis „überbestimmt“ ist (mehrere unabhängige Signale zeigen dasselbe), desto leichter ist die Eskalation – etwa an ein Plattformteam oder einen Cloud Provider.

Praktische Testgestaltung: Welche Parameter Sie unbedingt variieren sollten

Damit Sie nicht einem Sonderfall aufsitzen, sollten Sie Tests parametrisieren. Das hilft auch, Ursachen einzugrenzen.

• Paketgröße: klein (z. B. 64–256 Byte) und größer (z. B. 1200–1400 Byte), um MTU-Effekte zu erkennen.
• Rate: niedrige Rate (Baseline) und höhere Rate (Stress), um Congestion-/Queue Drops sichtbar zu machen.
• Protokoll: ICMP + UDP + TCP, damit Sie ICMP-Limits und TCP-spezifische Effekte trennen.
• Zeitfenster: mehrere Intervalle, damit burstiger Loss erfasst wird.
• Richtung: A→B und B→A getrennt messen (Asymmetrie ist häufig).

Troubleshooting-Checkliste, wenn „Loss zwischen AZs“ plausibel ist

• AZ-Paar identifizieren: Genau benennen, welche AZ↔AZ-Kombination betroffen ist.
• Intra-AZ als Control messen: Gleiche Hosts/Last, um Host- und App-Faktoren zu neutralisieren.
• Retransmits und Drops trennen: Retransmits ≠ Loss-Beweis allein, aber starkes Signal; Host-Drops können die Ursache sein.
• MTU/PMTUD ausschließen: Größenvariationen, ICMP/Packet-Too-Big-Signale, „klein geht, groß hängt“.
• Flow Logs segmentieren: Sicherstellen, dass die betroffenen Flows wirklich cross-AZ sind.
• Lastkorrelation prüfen: Loss steigt mit Throughput/Peak – Hinweis auf Congestion oder Rate-Limits.
• Evidence paketnah machen: Kurzer Packet Capture oder TCP-Stats kann Retransmit-Pattern belegen, ohne riesige Datenmengen.

Outbound-Links für Hintergrund und Referenz

• RFC 793: TCP – Retransmissions und Zustandsmodell
• RFC 4271: BGP-4 – Routing-Grundlagen (für Pfadwechsel/Asymmetrie relevant)
• AWS VPC Flow Logs – Netzwerk-Telemetrie und Interpretation
• RFC 8201: Path MTU Discovery für IPv6 – Blackhole-Effekte erkennen
• RFC 4443: ICMPv6 – Diagnosesignale und Fehlermeldungen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.