Asymmetrisches Routing: Häufige Ursachen in der Cloud

Asymmetrisches Routing gehört zu den häufigsten Ursachen für schwer erklärbare Netzwerkstörungen in der Cloud – gerade dann, wenn „eigentlich alles korrekt konfiguriert“ scheint. Typisch sind Symptome wie sporadische Timeouts, abreißende TCP-Verbindungen, unerklärliche 5xx-Fehler hinter Load Balancern oder ein Verhalten nach dem Muster „Outbound geht, Inbound kommt nie zurück“. Das Tückische: Asymmetrie bedeutet nicht, dass Pakete gar nicht geroutet werden. Vielmehr nehmen Hin- und Rückweg unterschiedliche Pfade, sodass zustandsbehaftete Komponenten (z. B. Firewalls, NAT, Proxies, Load Balancer, VPN-Gateways) den Rückverkehr nicht mehr einer bestehenden Session zuordnen können – und ihn dann still verwerfen. In modernen Cloud-Topologien wird dieses Risiko durch Transit-Hubs, mehrere Egress-Wege, hybride Anbindungen, service-spezifische Endpoints und dynamisches Routing (BGP) zusätzlich erhöht. Wer Asymmetrisches Routing sauber beherrschen will, braucht deshalb mehr als eine Route-Table-Kontrolle: Entscheidend sind Evidence aus Flow Logs, eine klare Vorstellung über Pfadwahl (Longest Prefix Match, Präferenzen, Propagation) und ein Design, das „symmetrische Pfade“ bewusst erzwingt oder Asymmetrie technisch toleriert. Dieser Artikel erklärt die häufigsten Ursachen in der Cloud und zeigt, wie Sie sie systematisch erkennen und nachhaltig vermeiden.

Was asymmetrisches Routing konkret bedeutet

Von asymmetrischem Routing spricht man, wenn Pakete für denselben Kommunikationsfluss auf dem Hinweg und Rückweg unterschiedliche Netzwerkpfade nehmen. Das kann vollständig unterschiedliche Hops bedeuten (z. B. Hinweg über Transit Gateway, Rückweg über Peering) oder subtiler sein (Hinweg über NAT Gateway A, Rückweg über NAT Gateway B). Für viele Protokolle ist das grundsätzlich nicht „verboten“. Das Problem entsteht, sobald eine zustandsbehaftete Komponente im Pfad sitzt, die beide Richtungen sehen muss, um Sessions korrekt zu verwalten.

• Stateful Komponenten: Firewalls, NAT, L7-Proxies, viele Load-Balancer-Funktionen, IDS/IPS mit Session-Tracking
• Symptomklasse: SYN geht raus, SYN-ACK kommt nie an; TLS-Handshakes brechen ab; HTTP-Requests hängen in Timeouts
• Warum es „sporadisch“ wirkt: Asymmetrie tritt oft nur für bestimmte Subnetze, AZs, Zielpräfixe oder nach Routing-Änderungen auf

Ein technischer Hintergrund ist das TCP-Zustandsmodell: Wenn Rückpakete nicht den erwarteten Pfad nehmen, sieht der zustandsbehaftete Hop die Verbindung nur „halb“. Als Referenz zur TCP-Mechanik dient RFC 793 (TCP).

Warum Asymmetrie in der Cloud besonders häufig ist

Cloud-Netzwerke sind dynamisch. Workloads skalieren, IPs ändern sich, Verbindungen werden über Hubs, Endpoints oder Services abstrahiert. Gleichzeitig existieren mehrere Routing-Ebenen: Subnet-Route-Tables, zentrale Transit-Routing-Instanzen, peering-spezifische Regeln, Gateway-Routen (VPN/Direct Connect), und oft zusätzlich Appliances oder service meshes. Diese Mehrschichtigkeit erhöht die Wahrscheinlichkeit, dass Hin- und Rückweg anders entschieden werden.

• Mehrere mögliche Exits: Internetzugang über NAT, zentrale Proxies, direkte Public IPs, Private Endpoints
• Mehrere Connectivity-Modelle: Peering und Transit parallel, Hybrid via VPN/Dedicated Link
• Mehrere Zonen/Regionen: Zonale Gateways und AZ-lokale Subnetze mit eigenen Default Routes
• Dynamisches Routing: BGP-Propagation, Präferenzänderungen, Route Flaps

Ursache 1: Mehrere Default Routes und „uneinheitlicher Egress“

Ein Klassiker ist ein uneinheitlicher Default Route-Entwurf: In Subnet A zeigt 0.0.0.0/0 auf NAT Gateway A, in Subnet B auf NAT Gateway B – oder ein Teil der Subnetze nutzt eine zentrale Firewall, ein anderer Teil geht direkt über NAT. Wenn dann Rückverkehr über eine andere Route zurückkommt (z. B. weil Source NAT oder Policy-Routing greift), entstehen asymmetrische Pfade.

• Typische Trigger: Neue Subnetze werden hinzugefügt; IaC-Templates unterscheiden sich; ein Team baut „schnell“ einen zweiten Exit
• Symptome: Probleme nur in bestimmten Subnetzen/AZs; unterschiedliche öffentliche Egress-IPs; Sessions brechen unter Last
• Verifikation: Egress-IP pro Subnet messen und als Metrik loggen; Flow Logs auf Rückweg prüfen

Ursache 2: Transit-Hubs und falsche Route Propagation

Transit-Modelle (Hub-and-Spoke) vereinfachen Skalierung, erhöhen aber die Konsequenzen von Routing-Fehlern. Eine falsch propagierte Route kann dazu führen, dass der Rückweg plötzlich über den Hub statt direkt über Peering läuft – oder umgekehrt. Besonders kritisch ist das, wenn im Hub eine Firewall/Inspection sitzt, die Sessions erwartet, aber nur eine Richtung sieht.

• Typische Trigger: Neue Attachments, neue Propagation-Regeln, Segmentierungsänderungen (Prod/Non-Prod), Inter-Region-Anbindungen
• Symptome: „Seit dem Change gestern“ treten Timeouts auf; Flow Logs zeigen unterschiedliche Next Hops je Richtung
• Verifikation: Routing-Tabellen des Hubs und Spokes vergleichen; Longest Prefix Match gegen Default prüfen

AWS-spezifisch sind Konzepte wie Transit Gateway und Routing-Tabellen zentral: AWS Transit Gateway. In Azure ist das Hub-Prinzip häufig über Virtual WAN/Hubs oder Hub-Spoke-Designs abgebildet: Azure Virtual WAN.

Ursache 3: Peering und „Abkürzungen“ (Direct Peering neben Transit)

Viele Organisationen starten mit Peering und führen später Transit ein. Dann existieren zwei mögliche Pfade zwischen denselben Netzen: direkt (Peering) oder indirekt (Transit). Wenn Routing-Regeln nicht sauber priorisieren, kann ein Teil des Verkehrs den direkten Pfad nehmen, während Rückverkehr über den Hub zurückkommt. Das ist besonders problematisch, wenn eine zentrale Security-Appliance im Hub sitzt und nur eine Richtung sieht.

• Typische Trigger: Migration von Mesh zu Hub-and-Spoke; Sonderpeering für „Low Latency“; temporäre Verbindungen für Projekte
• Symptome: Inkonstante Pfade je nach Zielpräfix; manche Services stabil, andere nicht
• Verifikation: Präfixliste erstellen und pro Präfix Next Hop nachvollziehen; Änderungen in Route Tables korrelieren

Als Einstieg in Peering-Konzepte: AWS VPC Peering und Google Cloud VPC Network Peering.

Ursache 4: Hybrid Connectivity – VPN/Dedicated Link mit falschen BGP-Präferenzen

In hybriden Setups (On-Prem ↔ Cloud) ist Asymmetrie ein Dauerbrenner. Häufig existieren zwei Pfade: ein Dedicated Link (z. B. Direct Connect/ExpressRoute/Interconnect) und ein VPN als Backup. Wenn BGP-Attribute (Local Preference, AS-Path, MED, Communities) nicht konsistent sind, kann der Hinweg über den dedizierten Pfad gehen, während der Rückweg „versehentlich“ über VPN kommt. Stateful Firewalls oder NAT an den Rändern droppen dann Antworten.

• Typische Trigger: Failover-Tests, BGP-Flaps, neue Präfixe, Änderung der Präferenzregeln
• Symptome: Verbindungen hängen während Failover; nach Rückkehr des Primärpfads bleiben Sessions instabil
• Verifikation: BGP-Routingtabellen beidseitig prüfen; Path Selection dokumentieren; Failover-Szenarien synthetisch testen

Für den Einstieg in BGP und Pfadwahl sind die Konzepte hilfreich, auch wenn der Provider konkrete Details variiert: RFC 4271 (BGP-4).

Ursache 5: Zentrale Firewalls/Inspection und Policy-based Routing

Viele Cloud-Designs setzen auf zentrale Firewalls für Inspection (Egress/Ingress oder auch Ost-West). Sobald Policy-based Routing (PBR) ins Spiel kommt, steigt das Asymmetrie-Risiko: Der Hinweg wird bewusst durch die Firewall gelenkt, der Rückweg nimmt aber den „natürlichen“ (kürzeren) Pfad – oder wird durch eine andere Policy umgelenkt. Ergebnis: die Firewall sieht nur eine Richtung und verwirft den Rückverkehr.

• Typische Trigger: Neue PBR-Regeln, neue Subnetze, neue Zielpräfixe, Einführung eines zweiten Firewall-Clusters
• Symptome: Flow Logs zeigen out/accept, aber keine inbound flows; Firewall-Logs zeigen „asymmetric“ oder „no session“
• Verifikation: Pfadkarte erstellen (Hop-by-Hop); auf beiden Seiten Session-Logs prüfen; Rückroute explizit erzwingen

Ursache 6: Load Balancer, Source NAT und unerwartete Source-IPs

Load Balancer können Source-IPs verändern oder zusätzliche Hops einführen. Wenn Backends Antworten nicht über denselben Pfad zurücksenden, den der Load Balancer erwartet, entstehen Drops. Besonders häufig passiert das, wenn Backends eine Default Route in Richtung Internet/NAT haben, aber der eingehende Traffic über den LB aus einer anderen Richtung kam (z. B. über ein peered Network oder über einen Hub).

• Typische Trigger: Umstellung von internal auf internet-facing LB, Wechsel der Target-Architektur, neue Subnet-/Route-Struktur
• Symptome: Health Checks schlagen fehl, aber direkte Verbindung (Pod→Pod) funktioniert; 502/504 am LB
• Verifikation: Source-IP-Verhalten des LBs prüfen; Backend-Route so gestalten, dass Rückweg über denselben Weg erfolgt

AWS-spezifische Einstiegsquelle zum Sicherheits- und Pfadverhalten in Verbindung mit Load Balancern: Security Groups für Application Load Balancer.

Ursache 7: NAT-Gateways und Egress-IP-Wechsel (mehrere NATs, mehrere AZs)

Auch NAT kann Asymmetrie verursachen, wenn die Rückrichtung nicht konsistent ist. In vielen Clouds empfiehlt es sich, pro AZ ein NAT Gateway zu verwenden und Subnetze AZ-lokal zu routen. Wenn jedoch Subnetze über AZ-Grenzen hinweg ein NAT nutzen (Cross-AZ) oder wenn Failover zwischen NATs stattfindet, können Sessions brechen. Zusätzlich können Upstream-Partner oder Security-Policies an Egress-IPs gebunden sein: Ein Egress-IP-Wechsel wirkt dann wie „Traffic droppt“.

• Typische Trigger: AZ-Ausfall, Route-Table-Änderungen, neue Subnetze ohne AZ-lokalen NAT-Pfad
• Symptome: Nur neue Verbindungen scheitern; externe APIs blocken wegen IP-Änderung; p99 steigt bei Connect/TLS
• Verifikation: Egress-IP pro Subnet/AZ messen; Route Tables auf AZ-Lokalität prüfen

Für grundlegende NAT-Konzepte in AWS ist AWS NAT Gateway eine hilfreiche Referenz.

Ursache 8: Multi-Region und Anycast/DNS-basierte Pfadwahl

In Multi-Region-Architekturen entstehen asymmetrische Pfade häufig indirekt über DNS oder Anycast. Ein Client löst eine Region A auf, aber der Rückweg wird über Region B bevorzugt (z. B. weil ein globales Netzwerk, ein Proxy oder eine zentrale egress policy anders entscheidet). Besonders tückisch ist das bei globalen Load Balancing-Setups und bei Failover-Mechanismen, die DNS- oder Routing-basiert arbeiten.

• Typische Trigger: DNS-Failover, TTL/Caching, regionale Maintenance, BGP-Policy-Änderungen
• Symptome: „Nur manche Clients“ betroffen; stark vom Standort abhängig; Probleme verschwinden nach TTL-Ablauf
• Verifikation: Ziel-IP und Region in Logs/Traces erfassen; DNS-Antworten aus verschiedenen Netzen vergleichen

Wie Sie Asymmetrisches Routing zuverlässig nachweisen

Konfigurationsprüfungen sind hilfreich, aber für Asymmetrie brauchen Sie eine Beweiskette. Ziel ist, den tatsächlichen Pfad für beide Richtungen zu zeigen. In der Praxis bewährt sich eine Kombination aus Flow Logs, paketnahen Signalen und systematischer Segmentierung.

• Flow Logs (beidseitig): Sehen Sie Outbound-ACCEPT ohne passende Inbound-Flows, ist Rückwegverdacht hoch.
• Vergleich nach Subnet/AZ: Asymmetrie zeigt sich oft zonal oder nur in bestimmten Route Tables.
• „Guter“ vs. „schlechter“ Pfad: Zwei identische Requests aus zwei Subnetzen vergleichen, die unterschiedlich betroffen sind.
• Session-Logs auf Appliances: Firewalls melden häufig „no session“ oder „asymmetric“ (wenn Logging aktiv ist).

Eine einfache Evidenz-Metrik: Rückantwort-Quote

Wenn Sie z. B. TCP-Connects oder Health Checks messen, kann eine Rückantwort-Quote helfen, Asymmetrie sichtbar zu machen. Vereinfachtes Modell: Anteil der Versuche, bei denen eine Antwort (SYN-ACK/ACK oder Application-Response) gesehen wird.

$\mathrm{ResponseRatio}=\frac{N_{\mathrm{responses}}}{N_{\mathrm{attempts}}}$

Fällt die ResponseRatio nur in bestimmten Subnetzen/AZs ab, ist das ein starker Hinweis auf pfadabhängige Probleme wie Asymmetrisches Routing.

Troubleshooting-Reihenfolge: Vom schnellsten Beweis zur tiefen Ursache

Ein strukturierter Ablauf spart Zeit und verhindert, dass Sie bei Security Groups oder Applikationslogs hängen bleiben, obwohl es ein Routingthema ist.

• Ziel und Quelle fixieren: FQDN, Ziel-IP (A/AAAA), Source-IP, Ports, Zeitfenster.
• Flow Logs auswerten: Outbound vorhanden? Inbound fehlt? REJECT vs. ACCEPT trennen.
• Routing prüfen: Longest Prefix Match, Default Routes, Route Propagation, Peering/Transit-Kanten.
• Asymmetrie-Hops identifizieren: NAT, Firewall, Proxy, LB, VPN/Dedicated Link, Transit Hub.
• Pfad erzwingen (Test): Temporär nur einen Exit zulassen oder Präferenz eindeutig machen, um Symmetrie herzustellen.
• Appliance-Session-Logs prüfen: „no session“, „asymmetric“, Drops nach Timeout.
• Gezielte Paketaufnahme: SYN raus? SYN-ACK zurück? Retransmits? Das trennt Pfad von Applikation.

Design-Prinzipien, um Asymmetrie dauerhaft zu vermeiden

Asymmetrisches Routing ist selten ein „Bug“, sondern ein Designproblem. Die folgenden Prinzipien reduzieren das Risiko deutlich und machen Fehler schneller sichtbar.

• Einheitlicher Egress pro Domäne: Pro Umgebung/Zone klar definierte Default Routes und Egress-Wege, keine ad-hoc Ausnahmen.
• Transit oder Peering – bewusst hybridisieren: Wenn beides parallel existiert, muss Präferenz und Scope klar geregelt sein.
• AZ-lokale Pfade: NAT/Firewalls/Endpoints pro AZ und Route Tables so, dass Workloads in derselben AZ bleiben.
• Routing-Governance: Changes nur über IaC, mit Reviews, Canary und Rollback. Routing ist Shared Infrastructure.
• Symmetrie erzwingen, wenn stateful Geräte im Pfad sind: Rückwege müssen explizit über denselben Hop laufen oder stateful Komponenten müssen so platziert werden, dass sie beide Richtungen sehen.
• Observability by default: Flow Logs, zentrale Dashboards nach Subnet/AZ/Prefix, plus Runbooks für „Outbound ok, inbound fehlt“.

Outbound-Links für vertiefende Informationen

• RFC 793: TCP – Zustandsmodell und Verbindungsaufbau
• RFC 4271: BGP-4 – Grundlagen dynamischer Pfadwahl
• AWS Transit Gateway – Hub-and-Spoke Routing
• AWS VPC Flow Logs – Evidence für Pfadprobleme
• AWS VPC Peering – direkte Verbindungen und Grenzen
• Azure Virtual WAN – zentrale Transit-Topologien
• Google Cloud VPC Network Peering – Konzepte und Einsatz

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.