Asymmetrisches Routing am Edge: Auswirkungen auf Firewall/CGNAT

Red Snapper

1 month ago

Asymmetrisches Routing am Edge ist eines der häufigsten „mysteriösen“ Problemfelder in Provider-Netzen – vor allem dann, wenn am Netzrand stateful Systeme stehen: Firewalls, CGNAT, Carrier-Grade-Load-Balancer, DPI oder Security-Gateways. Der Kern des Problems ist einfach: Hinweg und Rückweg eines Flows nehmen unterschiedliche Pfade. Für reines IP-Forwarding ist das oft unkritisch. Für stateful Systeme ist es dagegen potenziell katastrophal, weil Zustände (Sessions, NAT-Mappings, Policy-Entscheidungen) in der Regel auf dem Gerät liegen, das den ersten Teil des Flows gesehen hat. Kommt die Antwort dann über ein anderes Gerät oder eine andere Instanz zurück, fehlt der Zustand: Pakete werden gedroppt, Verbindungen resetten, Timeouts häufen sich, und das Fehlerbild wirkt zufällig („nur manche Kunden“, „nur manche Ziele“, „nur zu Peak-Zeiten“). Besonders am ISP-Edge ist asymmetrisches Routing kein Ausnahmefall, sondern eine natürliche Folge aus ECMP, Multi-Homing, BGP-Policy, Peering-Design und Lastverteilung. Dieser Artikel erklärt praxisnah, wie Asymmetrie entsteht, welche Auswirkungen sie auf Firewall und CGNAT hat, welche typischen Failure Modes auftreten, wie man das Problem mit Telemetrie beweist und welche Design- und Mitigation-Optionen in Provider-Umgebungen realistisch sind.

Was bedeutet asymmetrisches Routing am Edge?

Asymmetrisches Routing bedeutet, dass Pakete eines Kommunikationspaares (typischerweise Client → Server und Server → Client) nicht über denselben Pfad laufen. In einem ISP-Edge ist das häufig die Regel, weil der Hinweg (Outbound) durch Policies, ECMP und NAT-Gateways beeinflusst wird, während der Rückweg (Inbound) durch BGP-Entscheidungen des Internets, Anycast-Services, unterschiedliche Peerings oder unterschiedliche IGP-Kosten in das Netz zurückkommt.

Symmetrie: Hinweg und Rückweg laufen über dieselbe Edge-Instanz (gleiche Firewall/CGNAT-Box bzw. gleiche Cluster-Instanz).
Asymmetrie: Rückweg landet auf einer anderen Instanz oder umgeht das stateful Gerät teilweise.

Warum ist Asymmetrie für Firewalls und CGNAT so problematisch?

Firewalls und CGNAT sind stateful. Sie führen typischerweise eine Session-Tabelle (State Table) und treffen Entscheidungen basierend auf dem Kontext (z. B. „SYN gesehen“, „NAT-Mapping angelegt“, „Policy matchte auf Interface/Zone“, „Timeout läuft“). Kommt ein Paket ohne passenden Zustand, gibt es drei typische Reaktionen: Drop, RST/ICMP, oder Re-Learning/Neue Session (wenn erlaubt). In Provider-Edges ist „Re-Learning“ häufig nicht möglich oder nicht gewollt, weil es Security- und Abrechnungslogik verletzt.

Firewall: erwartet üblicherweise, dass beide Richtungen einer Session durch dieselbe Instanz laufen (stateful inspection).
CGNAT: erwartet, dass Rückverkehr zum gleichen NAT-Mapping zurückkehrt (translation state).
Operative Folge: Asymmetrie äußert sich als sporadische Verbindungsabbrüche und schwer reproduzierbare Tickets.

Wie asymmetrisches Routing am ISP-Edge entsteht

Es gibt mehrere, oft gleichzeitig wirkende Ursachen. Entscheidend ist, dass Asymmetrie häufig nicht „ein Bug“ ist, sondern ein emergentes Verhalten aus Routing- und Load-Design.

Ursache 1: ECMP im Backbone und unterschiedliche Hash-Zuordnung

ECMP verteilt Flows über mehrere Pfade. Wenn der Hinweg über einen Pfad zur NAT/Firewall-Instanz A geht, kann der Rückweg über einen anderen Pfad in der Nähe der Instanz B ankommen, besonders wenn das Edge-Design mehrere gleichwertige Wege anbietet. Multipath-Themen werden in RFC 2991 und RFC 2992 diskutiert.

Ursache 2: Multi-Homing, Hot-Potato-Routing und BGP-Policy

Im Internet entscheidet nicht Ihr IGP, sondern die globale BGP-Topologie. Outbound wählen Sie häufig den „nächsten“ Exit (Hot-Potato). Inbound entscheiden andere ASNs anhand ihrer Policies. Selbst wenn Sie inbound Traffic „steuern“ (Communities, Prepends, MED), bleibt es probabilistisch. Das führt dazu, dass Rückverkehr oft an einem anderen Edge-PoP landet als der Hinweg.

Outbound-Asymmetrie: Ihr Netz wählt Exit A, weil er IGP-näher ist.
Inbound-Asymmetrie: Das Internet wählt Peering/Transit B, weil es dort für den Sender günstiger aussieht.

Ursache 3: Anycast am Edge (DNS, CGNAT, Security-Services)

Anycast-IPs können Asymmetrie verstärken: Ein Client erreicht Anycast-Instanz X, aber Antworten laufen über Y, wenn das Netz den Rückpfad anders bewertet oder wenn ein Anycast-Prefix anders propagiert wird. Für Anycast-Betrieb ist RFC 4786 eine gute Referenz.

Ursache 4: Unterschiedliche Pfadkosten (IGP) und Policy-Based Routing

Schon kleine Änderungen in IGP-Metriken, SR-Policies oder PBR-Regeln können die Symmetrie brechen. Besonders riskant ist eine Kombination aus PBR (z. B. „bestimmter Traffic muss durch Firewall“) und ECMP/TE, wenn nicht explizit sichergestellt ist, dass der Rückweg denselben Servicepfad nimmt.

Ursache 5: Stateful Cluster ohne konsistente Session-Verteilung

Viele Firewalls/CGNATs laufen als Cluster. Wenn der Cluster nicht state-sharing-fähig ist oder wenn das State-Sync-Design nicht zum Routing passt, kann Asymmetrie bereits innerhalb eines PoPs auftreten: Hinweg trifft Member 1, Rückweg Member 2. Das ist häufig ein „Split-Brain“-ähnliches Symptom auf Datenebene, auch wenn die Cluster-Control-Plane „gesund“ wirkt.

Typische Auswirkungen auf Firewalls

Firewalls sind besonders empfindlich, weil sie häufig mehr als nur NAT machen: Zone-Based Policies, Application Inspection, IDS/IPS, TLS-Inspection, Rate-Limits. Asymmetrie führt daher zu einer breiten Palette von Symptomen.

Session Miss / No State: Rückpakete werden gedroppt, weil kein State vorhanden ist.
RST/ICMP Responses: manche Systeme senden aktiv zurück (kann als „Server reset“ wirken).
Policy-Mismatch: gleiche 5-Tuple, aber anderes Interface/Zone → andere Policy-Entscheidung.
Logging-Verwirrung: Logs zeigen nur eine Richtung, was Debugging erschwert.

Typische Auswirkungen auf CGNAT

CGNAT hält NAT-Mappings (z. B. private:port → public:port) und oft zusätzliche State-Informationen (Timeouts, ALG, Port-Block-Allocation). Wenn Rückverkehr nicht zur Instanz zurückkehrt, die das Mapping angelegt hat, ist das Mapping „unbekannt“ und Pakete werden verworfen.

Mapping Miss: Rückpakete finden kein Mapping → Drop.
Port-Block-Inkonsistenz: bei Port-Block-Allocation kann eine zweite Instanz nicht erraten, welche Ports vergeben wurden.
Asymmetrie-Spikes nach Failover: wenn Traffic auf andere NAT-Instanzen umschwenkt, ist der Cache/Mappingset dort kalt.
ALG-Probleme: Protokolle mit zusätzlichen Port-Verhandlungen (z. B. bestimmte VoIP/Legacy) reagieren besonders empfindlich.

Warum „nur manche Kunden“ betroffen sind

Asymmetrie tritt nicht immer gleichmäßig auf. Drei Faktoren erklären die selektive Wahrnehmung:

Flow-Hashing: ECMP verteilt Flows deterministisch; einige Kunden landen häufiger auf Pfadkombinationen, die asymmetrisch sind.
Destination-Mix: Bestimmte Ziele/ASNs kommen über andere Inbound-Pfade zurück (Peering-spezifisch).
Traffic-Klasse: Echtzeit- und kurzlebige Sessions (Gaming, VoIP, DNS) zeigen Asymmetrie schneller als Bulk-Traffic.

Beweisführung mit Telemetrie: Asymmetrie sicher nachweisen

Asymmetrisches Routing ist im Incident nur dann lösbar, wenn Sie es sauber beweisen: welcher Teilpfad geht über welche Instanz, und wo geht der Rückverkehr verloren. Dafür reichen „Traceroutes“ selten aus; Sie brauchen ein kombiniertes Set aus Flow-, Session- und Routing-Telemetrie.

Telemetrie-Baustein 1: Stateful Counters (Firewall/CGNAT)

Session-Create Rate: steigt die Session-Neuanlage ungewöhnlich (Retry-Effekt)?
Session Miss / No-State Drops: Drops explizit wegen fehlendem State sind der stärkste Beweis.
NAT Allocation Failures: Port-Exhaustion vs. Mapping Miss klar trennen.
State Sync Health: wenn vorhanden: Sync-Latenz/Drop-Raten zwischen Cluster-Members.

Telemetrie-Baustein 2: Flow-Daten (NetFlow/IPFIX)

Einseitige Flows: viele „one-way flows“ (nur outbound gesehen) sind ein starkes Asymmetrie-Indiz.
Top Talkers nach Destination-AS: Impact oft AS-spezifisch (bestimmte Inbound-Entscheidungen).
Port-/Protokoll-Klassen: TCP vs. UDP, kurze Flows vs. lange Flows.

Telemetrie-Baustein 3: Routing- und Pfadtelemetrie

BGP Inbound/Outbound Pfade: welcher Exit wird outbound genutzt, welcher Ingress kommt inbound?
IGP/TE-Kosten: warum wird intern zu Instanz A statt B geroutet?
ECMP/LAG Member Health: Drops/Errors auf einzelnen Members können Asymmetrie „triggern“ (Flows weichen aus).

Asymmetrie-Indikator über Richtungssicht (MathML)

AsymmetryIndex = flows_one_way flows_total

Dieser Index ist kein perfekter Beweis, aber ein praktischer Frühindikator. Wenn er im Incident stark steigt, ist asymmetrisches Routing ein sehr wahrscheinlicher Faktor.

Typische Failure Modes als Mustererkennung

Die folgende Mustererkennung hilft, schneller von Symptom zu Ursache zu kommen.

Muster: Viele „No-Session“-Drops, Sessions werden ständig neu aufgebaut

Wahrscheinlich: Rückweg umgeht das stateful Gerät oder landet auf anderer Instanz.
Erste Maßnahme: Routing/Policy prüfen: Wie wird Return Traffic gelenkt? Ist Reverse Path konsistent?

Muster: Nur bestimmte Ziele/ASNs betroffen

Wahrscheinlich: Inbound-Pfadwahl im Internet führt Return Traffic an anderen PoP/Edge.
Erste Maßnahme: Inbound TE (Communities/Prepends) prüfen, ggf. temporär vereinheitlichen.

Muster: Probleme nach Failover/Recovery oder nach Maintenance

Wahrscheinlich: Traffic shiftet auf andere Instanz, State/Mappings sind „cold“, oder Cluster-Statesync hinkt.
Erste Maßnahme: kontrollierter Traffic-Shift, Warm-up/State-Sync prüfen, schrittweise Re-Enable statt „alles auf einmal“.

Mitigation-Strategien: Was im ISP-Edge realistisch funktioniert

Es gibt nicht die eine Lösung, weil Architektur und Produkte variieren. Dennoch haben sich im Provider-Umfeld bestimmte Strategien bewährt.

Strategie 1: Symmetrie erzwingen (Stateful Service Chaining)

Ansatz: Routing und Policies so bauen, dass Hin- und Rückweg denselben Servicepfad nehmen (z. B. über gleiche Service-Edges).
Vorteil: reduziert State-Miss drastisch.
Nachteil: kann Traffic Engineering einschränken und ist in Multi-Homing-Umgebungen nicht immer vollständig kontrollierbar.

Strategie 2: Stateful Cluster mit robustem State Sharing

Ansatz: Cluster so designen, dass Sessions zwischen Members synchronisiert werden (Active/Active mit State Sync).
Vorteil: toleriert interne Asymmetrie innerhalb des Clusters.
Nachteil: State Sync hat Grenzen (Latenz, Bandbreite, Failure Modes), und nicht jedes Produkt unterstützt das gleich gut.

Strategie 3: Deterministische Session-Stickiness

Ansatz: Hashing/Load-Balancing so gestalten, dass ein Flow deterministisch auf eine Instanz „sticky“ bleibt (z. B. consistent hashing, NAT hashing).
Vorteil: reduziert Cross-Node-Asymmetrie.
Nachteil: bei Topologieänderungen kann Rehashing viele Flows umlegen (Burst/Second Outage Risiko).

Strategie 4: Fail-Open vs. Fail-Closed bewusst entscheiden

Manche Provider wählen für bestimmte Dienste Fail-Open (Traffic darf bei Stateful-Problemen durchrutschen) oder Fail-Closed (Sicherheit vor Verfügbarkeit). Für CGNAT ist Fail-Open meist nicht realistisch, für bestimmte Firewall-Funktionen kann es aber als Notfallmodus diskutiert werden. Entscheidend ist, dass diese Entscheidung dokumentiert und getestet ist.

Strategie 5: Inbound Traffic Engineering und PoP-Lokalisierung

Ansatz: Return Traffic stärker an den PoP binden, an dem Outbound NAT/Firewall stattfindet (z. B. per Communities/Prepends, PoP-spezifische Prefixe, Anycast mit Health-Withdraw).
Vorteil: reduziert inter-PoP-Asymmetrie.
Nachteil: Inbound TE ist nie vollständig deterministisch, weil externe ASNs entscheiden.

Runbook: Schnelle Diagnose-Checkliste für NOC/On-Call

Diese Checkliste ist bewusst auf „Minuten“ optimiert. Ziel ist schnelle Klassifikation und erste Mitigation.

1) Scope: Welche Region/PoP? Welche Ziele/ASNs? v4/v6? UDP/TCP?
2) Stateful Drops: steigen „No-Session“/Mapping-Miss-Drops auf Firewall/CGNAT?
3) One-way Flows: nimmt der Anteil einseitiger Flows zu (IPFIX/NetFlow)?
4) Pfadkorrelation: welcher Outbound Exit wird genutzt, welcher Inbound Ingress kommt zurück?
5) Cluster/Stickiness: werden Sessions zwischen Nodes verteilt oder brechen sie an Node-Grenzen?
6) Mitigation: temporär Symmetrie erhöhen (TE vereinheitlichen), defekte Instanz withdraw, State Sync prüfen.
7) Validation: Success Rate, Retransmissions, Drop-Counter und Kundensymptome stabilisieren.

Evidence Pack: Pflichtdaten für RCA und Vendor-/Peer-Eskalation

Zeitfenster (UTC): Start, Peak, Mitigation, Stabilitätsfenster.
Betroffene Beispiele: 3–5 Flow-IDs (5-Tuple) und dazugehörige Logs.
Stateful-Indizien: No-Session/Miss-Drops, NAT-Mapping-Miss, Session-Create Rate, State-Sync-Status.
Routing-Indizien: Outbound Exit, Inbound Ingress, BGP-Path-Info für betroffene Ziele.
Traffic-Shift: Auslastung an PoP-Kanten, ECMP/LAG Member-Health.
End-to-End-Probes: bidirektionale Messungen (Loss/Latency), v4/v6 getrennt.

Outbound-Ressourcen

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.