Freigeben über

Netzwerk in mehreren Regionen mit Azure Route Server

Anwendungen mit hohen Anforderungen an Hochverfügbarkeit oder Notfallwiederherstellung müssen häufig in mehr als einer Azure-Region bereitgestellt werden. In solchen Fällen müssen virtuelle Spoke-Netzwerke (VNets) in verschiedenen Regionen miteinander kommunizieren können. Eine Möglichkeit, diese Kommunikation zu ermöglichen, besteht darin, ein Peering zwischen allen erforderlichen Spoke-VNets einzurichten. Bei diesem Ansatz werden jedoch alle zentralen virtuellen Netzwerkgeräte (Network Virtual Appliances, NVAs) wie Firewalls in den Hubs umgangen. Eine Alternative besteht darin, benutzerdefinierte Routen (User-Defined Routes, UDRs) in den Subnetzen zu verwenden, in denen Hub-NVAs bereitgestellt werden, aber die Verwaltung von UDRs kann eine Herausforderung darstellen. Azure Route Server bietet eine dynamische Alternative, die sich automatisch an Topologieänderungen anpasst, ohne dass ein manueller Eingriff erforderlich ist.

Topologie

Das folgende Diagramm zeigt eine Architektur mit zwei Regionen, in der in jeder Region eine Hub-and-Spoke-Topologie vorhanden ist und die Hub-VNets über Global-Peering von VNet miteinander verbunden sind.

Diagramm für den Entwurf mehrerer Regionen mit Azure Route Server.

Das NVA in jeder Region lernt die Präfixe des lokalen Hubs und der Spoke-VNets über den Azure Route Server und teilt sie über BGP mit dem NVA in der anderen Region. Um Routingschleifen zu vermeiden, ist es wichtig, diese Kommunikation zwischen den NVAs mithilfe einer Kapselungstechnologie wie IPsec oder Virtual eXtensible LAN (VXLAN) herzustellen.

Damit Azure Route Server die Präfixe der Spoke-VNets für die lokalen NVAs ankündigen und die gelernten Routen wieder in die Spoke-VNets einschleusen kann, ist es wichtig, die Einstellung Gateway oder Routenserver des virtuellen Remotenetzwerks verwenden für das Peering zwischen den Spoke-VNets und dem Hub-VNet zu verwenden.

Die NVAs kündigen die aus der Remoteregion gelernten Routen an ihren lokalen Route Server an, der diese Routen dann in den lokalen Spoke-VNets konfiguriert und entsprechend Datenverkehr anzieht. In Fällen, in denen sich mehrere NVAs in der gleichen Region befinden (der Route Server unterstützt bis zu acht BGP-Peers), kann AS PATH vorangestellt werden, um eine der NVAs zu bevorzugen und damit praktisch eine Aktiv/Standby-NVA-Topologie einzurichten.

Von Bedeutung

Um sicherzustellen, dass der lokale Routenserver die von der NVA angekündigten Routen aus der Remoteregion lernen kann, muss die NVA die ASN (Autonomous System Number) 65515 aus dem AS-Pfad der Routen entfernen. Diese Technik wird auf bestimmten BGP-Plattformen manchmal als "AS-Override" oder "AS-Path Rewrite" bezeichnet. Andernfalls verhindert der BGP-Schleifenverhinderungsmechanismus, dass der lokale Routenserver diese Routen lernt, da er das Erlernen von Routen verhindert, die bereits die lokale ASN enthalten.

ExpressRoute

Das Design mit mehreren Regionen kann mit ExpressRoute- oder VPN-Gateways kombiniert werden. Das folgende Diagramm zeigt eine Topologie mit einem ExpressRoute-Gateway, das mit einem lokalen Netzwerk in einer der Azure-Regionen verbunden ist. In diesem Fall hilft ein Überlagerungsnetzwerk über die ExpressRoute-Leitung bei der Vereinfachung des Netzwerks, sodass lokale Präfixe nur gemäß Ankündigung der NVA in Azure angezeigt werden (und nicht vom ExpressRoute-Gateway).

Diagramm, das den Entwurf mehrerer Regionen mit Route Server und ExpressRoute zeigt.

Design ohne Overlays

Die regionsübergreifenden Tunnel zwischen den NVAs sind erforderlich, da sonst eine Routingschleife gebildet wird. Betrachten Sie beispielsweise die NVA in Region 1:

  • Das NVA in Region 1 lernt die Präfixe aus Region 2 und kündigt sie dem Route-Server in Region 1 an.
  • Der Routenserver in der Region 1 fügt Routen für diese Präfixe in alle Subnetze in der Region 1 ein und verwendet die NVA in der Region 1 als den nächsten Hop.
  • Wenn die NVA in Region 1 Datenverkehr von Region 1 nach Region 2 an die andere NVA sendet, erbt das eigene Subnetz auch die vom Routenserver programmierten Routen, die auf sich selbst (die NVA) verweisen. Das Paket wird somit an die NVA zurückgegeben, und eine Routingschleife entsteht.

Wenn UDRs eine Option sind, können Sie die BGP-Routenweitergabe in den Subnetzen der NVAs deaktivieren und statische UDRs anstelle einer Überlagerung konfigurieren, damit Azure Datenverkehr an die Remote-Spoke-VNets weiterleiten kann.

Verwandte Inhalte