Asymetrisches Routing - Ursachen und Auswirkungen?

Es kommt vor, dass ich auf Kunden stoße, die in ihren Netzwerken das haben, was ich als "asymetrisches Routing" definiere. Einfach gesagt, sie haben zwei Gateways im selben IP-Subnetz. Die Clients sind so konfiguriert, dass sie auf ein Gateway zeigen (z. B. 172.16.1.1), aber es gibt ein anderes Gerät (z. B. 172.16.1.2), das eine Verbindung herstellt und an einen anderen Ort weiterleitet. Meistens habe ich diese Art der Einrichtung gesehen, wenn es zwei verschiedene Arten von WAN-Verbindungen gibt: 1 Internetverbindung und 1 Unternehmens-MPLS-Verbindung.

Ich persönlich bin von der oben genannten Art des Netzwerkdesigns nicht angetan: Jedes Subnetz muss nur ein einziges Gateway haben. Aus meiner Sicht kann das obige Szenario einige Probleme für Clients verursachen, da sie ein Paket an ihr Standard-Gateway (172.16.1.1) senden und diese Pakete dann an den anderen Router (172.16.1.2) weitergeleitet werden und wenn sie beantwortet werden bis erreichen sie den Kunden einfach über 172.16.1.2. Die Clients würden oder sollten erwarten, dass die Antwortpakete von 172.16.1.1 stammen, oder irre ich mich hier?

Ich würde mich über Ihre Meinungen und technischen Ansichten zu diesem Thema freuen.

Ich würde empfehlen, dass Sie sich mit First Hop Redundancy Protocols wie HSRP oder VRRP befassen.

Tatsächlich können zwei Gateways ein sehr gutes Netzwerkdesign sein, denn wenn ein Router ausfällt, kann der andere Router etwas nahtlos übernehmen. Wie Sie wissen, ist es jedoch nicht einfach, diesen Übergang durchzuführen, wenn Sie jeden Client in einem Subnetz manuell neu konfigurieren müssen.

Mit Protokollen wie HSRP (oder VRRP, wenn Sie nicht von Cisco stammen) können zwei (oder mehr) Router (oder L3-Switches) in einem Subnetz eine einzige IP-Adresse gemeinsam nutzen. Sie haben Ihren ersten Router mit einer Adresse von .2, den zweiten mit einer Adresse von .3 und einer "virtuellen IP-Adresse" von .1, die beiden Routern durch die Konfiguration bekannt ist. Wenn der primäre Router ausfällt, kann der sekundäre Router dies erkennen und die virtuelle IP-Adresse übernehmen. Dies bedeutet, dass für Ihre Clients nur .1 als Gateway konfiguriert sein muss und Sie loslegen können.

In Bezug auf das Routing-Design würde dies weitgehend vom aktuellen Setup abhängen. Es ist möglich, dass beide Gateways zu demselben Internet-Rand führen. In diesem Fall haben Sie möglicherweise kein Problem. Asymmetrisches Routing kann schlecht sein, vor allem, weil Sie riskieren, dass Pakete in der falschen Reihenfolge zugestellt werden. Dies hängt jedoch wiederum stark von der Topologie ab, über die Sie sprechen.

Viele Designprinzipien sind in dem enthalten, was ich gerade gesagt habe. Ich schlage vor, dass Sie beide Protokolle untersuchen und herausfinden, was für Ihre Umgebung am besten ist. Wenn Sie Cisco-Geräte verwenden, ist HSRP eine weit verbreitete und gut verstandene Methode zur Lösung dieses Problems.

Das gesamte Internet basiert auf asymmetrischem Routing, daher ist es sehr verbreitet. Clients sind an der Schnittstelle interessiert, an der sie das Paket empfangen, und an der Quelle des Pakets, nicht an dem Router, der es an diese Schnittstelle an sie weitergeleitet hat.

Asymmetrisches Routing kann jedoch problematisch werden, wenn Geräte beteiligt sind, die den Status verfolgen (insbesondere Firewalls) und NAT, aber soweit ich das beurteilen kann, ist dies in Ihrem Beispiel nicht der Fall.

Netzwerkclients identifizieren Verkehrsflüsse basierend auf der Kombination von 4 Werten:

• Quelladresse
• Quellport
• Zieladresse
• Zielhafen

Für jede unterschiedliche Verbindung bilden die 4 obigen Werte eine andere Kombination, die verwendet wird, um die Antwortpakete an den richtigen Fluss anzupassen. Wie Sie sehen können, ist die Gateway- oder Next-Hop-Adresse nicht in der Liste enthalten, und daher ist es dem Client egal, ob ein Paket über dasselbe Gateway zurückkommt, mit dem es seine Pakete gesendet hat. Daher interessieren sich Netzwerkclients nicht für asymmetrisches Routing, sobald sie den Datenverkehr vom Remote-Ende empfangen können. Tatsächlich wurde TCP / IP ursprünglich entwickelt, um asymmetrisches Routing zu unterstützen.

Wenn wir uns jedoch auf Netzwerkzwischengeräte konzentrieren, wird assymmetrisches Routing nicht toleriert, sobald Sie ein Gerät / eine Technologie verwenden, bei der alle Pakete in einer Verbindung angezeigt werden müssen, um eine bestimmte Funktionalität bereitzustellen. Zum Beispiel: NAT, Stateful Firewalls oder einige WAN-Optimierer. Ein asymmetrisches Routing in einem solchen Szenario würde dazu führen, dass entweder die beabsichtigte Funktionalität nicht bereitgestellt wird oder, schlimmstenfalls, Pakete verworfen werden, was die Kommunikation unmöglich macht.

Ich stimme den vor mir liegenden Antworten zu, muss aber noch etwas hinzufügen: Wenn auf einem der Gateways oder auf einem Hop, der nur über eines der beiden Gateways geleitet wird, eine Filterung erfolgt, treten wahrscheinlich Probleme auf! (Hops, die über beide Gateways übertragen werden, z. B. den Quellcomputer, den Zielcomputer und alle Hops, die beiden Gateway-Pfaden gemeinsam sind, sind von den folgenden Szenarien nicht betroffen.)

Wenn beispielsweise A Pakete über Gateway1 an B sendet und Pakete über Gateway2 zurückgesendet werden, wird das Antwortpaket höchstwahrscheinlich verworfen, wenn Gateway2 filtert (da dieses Gateway das initiierende Verbindungspaket nicht gesehen hat, also nicht). Ich erwarte keine Antwort. Wenn also das Ziel / der Port des Antwortpakets normalerweise gefiltert wird, wird es gefiltert.)

(Es gibt natürlich viele ähnliche Szenarien)

Andere zwei Bereiche, in denen asymmetrische Routen Probleme verursachen, sind folgende: 1. MTU-Erkennung - Wenn sich die kleinste MTU der beiden Pfade unterscheidet, kann die Endpunkt-MTU-Pfaderkennung zu einer größten der beiden MTU führen, was wiederum zu einem Ausfall führt von Paketen maximaler Größe. Wenn beispielsweise ein Pfad durch einen VPN-Tunnel führt und der andere nicht, hat der VPN-Tunnel eine kleinere MTU. Ping funktioniert einwandfrei, aber die Übertragung großer Dateien schlägt konsistent fehl. 2. Die Behebung von Konnektivitätsproblemen ist schwieriger, wenn einer der beiden Pfade unterbrochen ist, der andere jedoch nicht. Eine gute alte "Traceroute" ist überhaupt keine Hilfe, da sie die Zwischenpunkte des umgekehrten Pfades nicht erkennen kann, es sei denn, sie wird von beiden Seiten der Verbindung ausgeübt, was einen Out-of-Band-Verwaltungskanal erfordert ...