Dieser Artikel richtet sich an Netzwerkarchitekten, die softwaredefinierte Wide Area Networks (SD-WANs) entwerfen möchten, um lokale Einrichtungen miteinander und mit Azure zu verbinden. Er beschreibt eine Architektur, mit der Azure-Kunden ihre vorhandenen Investitionen in die Plattform nutzen können, indem sie effiziente, globale SD-WAN-Überlagerungen über das Microsoft-Backbone erstellen.
Zutreffende Szenarios
Die Empfehlungen in diesem Artikel sind anbieterunabhängig und gelten für alle nicht von Microsoft stammenden SD-WAN-Technologien, die zwei grundlegende Voraussetzungen erfüllen:
- Abhängigkeit von Tunnelprotokollen, die Transmission Control Protocol (TCP) oder User Datagram Protocol (UDP) als zugrunde liegender Transport verwenden, z. B. Tunnelmodus IPSec ESP mit NAT-Traversal.
- Border Gateway Protocol v4-Unterstützung (BGP) für den Routenaustausch mit externen Entitäten. Es werden keine Annahmen über das Routing-Protokoll getroffen, das von nicht von Microsoft stammenden SD-WAN-Geräten zum Austausch von Routing-Informationen untereinander verwendet wird.
Kunden, die sich an diese Empfehlungen halten, können mit der SD-WAN-Technologie ihrer Wahl die folgenden Ziele erreichen:
- Integrieren Sie SD-WAN-Produkte in ein bestehendes Azure-Hub-and-Spoke-Netzwerk, indem Sie den Routenaustausch zwischen Azure Virtual Network und SD-WAN-Geräten automatisieren.
- Optimieren Sie die Konnektivität (sowohl zu Azure als auch zu lokalen Rechenzentren) für Zweigstellen mit lokalen Internet-Breakouts. Die Reichweite des Microsoft-Backbones in Kombination mit seiner Kapazitäts-, Resilienz- und „Cold Potato“-Routingrichtlinie deutet darauf hin, dass es als leistungsstarkes Underlay für globale SD-WANs verwendet werden kann.
- Verwenden Sie das Microsoft-Backbone für den gesamten Azure-zu-Azure-Verkehr (regions- und geografieübergreifend).
- Nutzen Sie bestehende Multi-Protocol-Label-Switching (MPLS)-Netzwerke als leistungsstarke Underlays. Es kann auch verwendet werden, um ein bestehendes MPLS-Netzwerk in einem schrittweisen Ansatz zu ersetzen, der die Auswirkungen auf das Unternehmen minimiert.
In den folgenden Abschnitten wird davon ausgegangen, dass der Leser mit den Grundlagen des SD-WAN-Paradigmas und der Architektur des Microsoft-Backbones vertraut ist. Das Microsoft-Backbone verbindet Azure-Regionen untereinander und mit dem öffentlichen Internet.
Aufbau
Organisationen mit globaler Präsenz und einer Azure-Präsenz in mehreren Regionen nutzen typischerweise eine Kombination von Konnektivitätsdiensten, um ihre Unternehmensnetzwerke zu implementieren und eine Verbindung zum Microsoft-Backbone herzustellen:
- Dedizierte Konnektivitätsdienste wie MPLS Internet-Protocol-Virtual-Private-Networks (IPVPNs) können an den größten Standorten wie Rechenzentren oder Hauptsitzen genutzt werden.
- Große Standorte können dedizierte Konnektivität mit dem Microsoft-Backbone über ExpressRoute-Leitungen umfassen, wobei eines der unterstützten Konnektivitätsmodelle verwendet wird. Genauer gesagt kann ein Standort dedizierte Punkt-zu-Punkt-Leitungen verwenden, um eine Verbindung zum nächstgelegenen ExpressRoute-Peering-Standort herzustellen. Oder es kann sein MPLS-IPVPN verwenden, um auf ExpressRoute-Verbindungen zuzugreifen, die vom MPLS-Anbieter bereitgestellt werden.
- Zweigstellen, die nur über eine Internetverbindung verfügen, können IPSec-VPNs verwenden, um eine Verbindung zum nächstgelegenen lokalen Rechenzentrum herzustellen und die ExpressRoute-Verbindung dieses Rechenzentrums für den Zugriff auf Azure-Ressourcen zu verwenden. Oder sie nutzen IPSec-VPNs, um eine direkte Verbindung zu Azure-Hub-and-Spoke-Netzwerken herzustellen.
SD-WAN-Projekte können unterschiedliche Bereiche aufweisen, in denen herkömmliche Netzwerkdienste ersetzt werden sollen. Einige Organisationen möchten möglicherweise bei großen Einrichtungen an dedizierten Verbindungen oder MPLS festhalten und ein SD-WAN nur bereitstellen, um veraltete internetbasierte IPSec-VPNs an kleinen Standorten zu ersetzen. Andere Organisationen möchten möglicherweise ihr SD-WAN auf MPLS-verbundene Standorte ausweiten und das vorhandene MPLS-Netzwerk als leistungsstarkes Underlay nutzen. Schließlich möchten einige Organisationen möglicherweise ihre MPLS-IPVPNs ablehnen. Oder einen beliebigen dedizierten Konnektivitätsdienst, um das SD-WAN-Paradigma zu übernehmen. Auf diese Weise können sie ihr gesamtes Unternehmensnetzwerk als logisches Overlay auf öffentlichen oder gemeinsam genutzten Grundlagen (dem öffentlichen Internet und dem Microsoft-Backbone) aufbauen.
Die in diesem Artikel beschriebene Architektur unterstützt alle zuvor aufgeführten Bereiche und basiert auf den folgenden Prinzipien:
- SD-WAN-Geräte werden als Network Virtual Appliances (NVAs) im Hub-and-Spoke-Netzwerk jeder Azure-Region bereitgestellt und als SD-WAN-Hubs konfiguriert, die Tunnel von lokalen Standorten beenden.
- SD-WAN-Geräte in Azure sind so konfiguriert, dass Tunnel miteinander hergestellt werden, wodurch eine Hub-zu-Hub-Überlagerung mit vollständigem Mesh erstellt wird, die den Datenverkehr effizient zwischen Azure-Regionen transportieren und den Datenverkehr zwischen geografisch entfernten lokalen Standorten über dem Microsoft-Backbone weiterleiten kann.
- SD-WAN-Geräte werden an allen von der SD-WAN-Lösung abgedeckten lokalen Standorten bereitgestellt und so konfiguriert, dass sie Tunnel zu den SD-WAN-NVAs in den nächstgelegenen Azure-Regionen einrichten. Verschiedene Standorte können unterschiedliche Transportdienste als Grundlage für die Tunnel nutzen, z. B. öffentliches Internet, ExpressRoute-Konnektivität usw.
- Der Datenverkehr von einem Standort zu einem beliebigen Ziel, ob in Azure oder an einem anderen lokalen Standort, wird an die SD-WAN-NVAs in der nächstgelegenen Azure-Region weitergeleitet. Anschließend erfolgt die Weiterleitung über das Hub-zu-Hub-Overlay.
SD-WAN-Produkte können proprietäre Protokolle und Funktionen zur Erkennung verwenden. Sobald sie dynamisch eingerichtet sind, können direkte Tunnel zwischen zwei Standorten eine bessere Leistung bieten als die Weiterleitung des Datenverkehrs über SD-WAN-NVAs in Azure.
Die allgemeine Architektur eines globalen SD-WAN, das das Microsoft-Backbone, das öffentliche Internet und dedizierte ER-Verbindungen als Grundlagen nutzt, ist im folgenden Bild dargestellt.
Abbildung 1: Allgemeine Architektur eines globalen SD-WAN, das das Microsoft-Backbone, das öffentliche Internet und dedizierte ER-Verbindungen als Grundlagen nutzt. Die schwarze gestrichelte Linie zeigt, wie der Datenverkehr zwischen zwei lokalen Standorten über SD-WAN-NVAs weitergeleitet werden kann, die in Azure-Regionen in der Nähe der Standorte bereitgestellt werden. Das Microsoft-Backbone kann aufgrund seiner Reichweite, Kapazität und „Cold Potato“-Routing-Richtlinie zu einer wesentlich besseren/vorhersehbaren Leistung führen als das öffentliche Internet, insbesondere bei Langstreckenverbindungen.
SD-WAN-Produkte in Azure-Hub-and-Spoke-Netzwerken
Dieser Abschnitt enthält Empfehlungen für die Bereitstellung von nicht von Microsoft stammenden SD-WAN CPE-Geräten als NVAs in einem vorhandenen Hub-and-Spoke-Azure-Netzwerk.
SD-WAN NVAs im virtuellen Hubnetzwerk
Hub and Spoke ist die Topologie, die Microsoft zum Aufbau skalierbarer Netzwerke in einer Azure-Region mithilfe von Kunden verwalteter virtueller Netzwerke empfiehlt. Das virtuelle Hubnetzwerk hostet gemeinsam genutzte Komponenten wie nicht von Microsoft stammende NVAs und native Dienste, die Netzwerkfunktionen wie Firewall, Lastausgleich und Konnektivität zu lokalen Standorten über Site-2-Site-VPNs oder ExpressRoute bereitstellen. Das virtuelle Hubnetzwerk ist der natürliche Standort für SD-WAN-NVAs, bei denen es sich letztendlich um nicht von Microsoft stammende Gateways handelt, die den Zugriff auf Remote-Netzwerke ermöglichen.
SD-WAN-NVAs sollten wie folgt in virtuellen Hubnetzwerken bereitgestellt werden:
- Für den gesamten SD-WAN-Verkehr wird ein einziger Netzwerkschnittstellen-Controller (NIC) verwendet. Andere NICs, beispielsweise eine Verwaltungs-NIC, können hinzugefügt werden, um Sicherheits- und Compliance-Anforderungen zu erfüllen oder um die Richtlinien des Anbieters für Azure-Bereitstellungen einzuhalten.
- Die für den SD-WAN-Verkehr verwendete Netzwerkkarte muss an ein dediziertes Subnetz angeschlossen sein. Die Größe des Subnetzes muss basierend auf der Anzahl der bereitgestellten SD-WAN-NVAs definiert werden, um die Anforderungen an Hochverfügbarkeit (HA) und Skalierung oder Durchsatz zu erfüllen, die später in diesem Artikel erläutert werden.
- Netzwerksicherheitsgruppen (NSGs) müssen der SD-WAN-Verkehrs-NIC entweder direkt oder auf Subnetzebene zugeordnet sein. Diese Zuordnung ermöglicht Verbindungen von Remotestandorten vor Ort über die von der SD-WAN-Lösung verwendeten TCP/UDP-Ports.
- Die IP-Weiterleitung muss auf der Netzwerkkarte aktiviert sein, die für den SD-WAN-Verkehr verwendet wird.
Azure Route Server im virtuellen Hubnetzwerk
Azure Route Server automatisiert den Routenaustausch zwischen SD-WAN-NVAs und dem Azure Software Defined Networking (SDN)-Stack. Route Server unterstützt BGP als dynamisches Routingprotokoll. Durch die Einrichtung von BGP-Adjazenzen zwischen Route Server und den SD-WAN NVA(s):
- Routen für alle mit dem SD-WAN verbundenen lokalen Standorte werden in die Routingtabellen des virtuellen Netzwerks eingefügt und von allen Azure-VMs gelernt.
- Routen für alle IP-Präfixe, die im Adressraum virtueller Netzwerke enthalten sind, werden an alle mit SD-WAN verbundenen Standorte weitergegeben.
Route Server sollte wie folgt konfiguriert werden.
- Er muss in einem dedizierten Subnetz im virtuellen Hubnetzwerk gemäß Erstellen und Konfigurieren einer Route Server-Instanz mithilfe des Azure-Portals bereitgestellt werden.
- Um den automatisierten Routenaustausch für alle virtuellen Spoke-Netzwerke zu ermöglichen, muss das Peering virtueller Netzwerke so konfiguriert werden, dass die virtuellen Spoke-Netzwerke das Gateway und den Routenserver des virtuellen Hubnetzwerks verwenden können. Details, die in den Häufig gestellten Fragen zum Azure Route Server verfügbar sind.
- Da Route Server und die SD-WAN NVAs an unterschiedliche Subnetze angeschlossen sind, müssen BGP-Sitzungen zwischen Route Server und SD-WAN NVAs mit eBGP-Multihop-Unterstützung konfiguriert werden. Es kann eine beliebige Anzahl von Hops zwischen 2 und dem von der SD-WAN NVA unterstützten Maximum eingestellt werden. Details zum Konfigurieren von BGP-Adjazenzen für Route Server finden Sie unter Erstellen und Konfigurieren einer Route Server-Instanz mithilfe des Azure-Portals.
- Zwei
/32statische Routen müssen auf dem SD-WAN-NVA für die von Route Server verfügbar gemachten BGP-Endpunkte konfiguriert werden. Diese Konfiguration stellt sicher, dass die Routingtabelle des NVA immer Routen für seine Multihop-BGP-Peers (nicht direkt verbunden) enthält.
Der Route Server befindet sich nicht im Datenpfad. Es handelt sich um eine Steuerelementebenenenentität. Sie verbreitet Routen zwischen der SD-WAN NVA und dem SDN-Stack des virtuellen Netzwerks, aber die tatsächliche Weiterleitung des Datenverkehrs zwischen der SD-WAN NVA und den virtuellen Maschinen im virtuellen Netzwerk erfolgt durch den Azure SDN-Stack, wie in der folgenden Abbildung dargestellt. Um dieses Routing-Verhalten zu erhalten, fügt der Route Server alle Routen ein, die er von den SD-WAN-NVAs lernt, wobei der nächste Hop auf die eigene Adresse des NVA eingestellt ist.
Der Route Server unterstützt IPv6 derzeit nicht. Diese Architektur ist nur für IPv4 vorgesehen.
Abbildung 2. Route Server unterstützt die Routenweitergabe zwischen dem SD-WAN CPE und dem SDN-Stack des virtuellen Netzwerks, leitet jedoch keinen Datenverkehr zwischen dem SD-WAN CPE und den virtuellen Maschinen im virtuellen Netzwerk weiter.
Hohe Verfügbarkeit für SD-WAN NVAs mit Route Server
Route Server verfügt über integrierte Hochverfügbarkeit. Zwei Rechenknoten sichern eine einzelne Instanz von Route Server. Sie werden in verschiedenen Verfügbarkeitszonen bereitgestellt, für die Regionen, die Verfügbarkeitszonenunterstützung bieten, oder in derselben Verfügbarkeitsgruppe. Sie machen zwei BGP-Endpunkte verfügbar. Hochverfügbarkeit für die SD-WAN-NVAs wird durch die Bereitstellung mehrerer Instanzen in verschiedenen Verfügbarkeitszonen, für Regionen, die sie unterstützen, oder im selben Verfügbarkeitssatz erreicht. Jede SD-WAN NVA richtet zwei BGP-Sitzungen ein, wobei beide Endpunkte vom Route Server verfügbar gemacht werden.
Die in diesem Artikel beschriebene Architektur basiert nicht auf Azure Load Balancern. Dies gilt insbesondere in folgenden Fällen:
Keine öffentlichen Load Balancer machen SD-WAN-Tunnel-Endpunkte verfügbar. Jede SD-WAN NVA stellt ihren eigenen Tunnelendpunkt bereit. Remote-Peers richten mehrere Tunnel ein, einen für jede SD-WAN-NVA in Azure.
Keine internen Lastausgleichsfunktionen verteilen den von Azure-VMs erzeugten Datenverkehr an die SD-WAN-NVAs. Route Server und der Azure SDN-Stack unterstützen ECMP-Routing (Equal-Cost Multipath). Wenn mehrere NVAs BGP-Adjazenzen mit Route Server einrichten und Routen für dieselben Ziele ankündigen (z. B. Remote-Netzwerke und Standorte, die mit dem SD-WAN verbunden sind), indem sie denselben Präferenzgrad verwenden, führt Route Server Folgendes aus:
- Fügt mehrere Routen für diese Ziele in die Routingtabelle des virtuellen Netzwerks ein.
- Legt jede Route so fest, dass eine andere NVA als nächster Hop verwendet wird.
Der SDN-Stapel verteilt dann den Datenverkehr an diese Ziele über alle verfügbaren nächsten Hops.
Die resultierende Hochverfügbarkeitsarchitektur ist in der folgenden Abbildung dargestellt:
Abbildung 3. Route Server unterstützt ECMP-Routing (Equal-Cost Multipath). Azure Load Balancer werden nicht benötigt, wenn aus Gründen der Verfügbarkeit und/oder Skalierbarkeit mehrere SD-WAN-NVAs verwendet werden.
N-aktive versus aktive Standby-Hochverfügbarkeit
Wenn Sie mehrere SD-WAN-NVAs verwenden und diese mit Route Server verbinden, steuert BGP das Failover. Wenn ein SD-WAN NVA offline geht, stoppt es die Ankündigung von Routen zum Route Server. Die vom ausgefallenen Gerät gelernten Routen werden dann aus der Routingtabelle des virtuellen Netzwerks entfernt. Wenn also ein SD-WAN NVA aufgrund eines Fehlers im Gerät selbst oder im Underlay keine Konnektivität zu Remote-SD-WAN-Standorten mehr bereitstellt, wird es nicht mehr als möglicher nächster Hop zu den Remote-Standorten in der Routingtabelle des virtuellen Netzwerk angezeigt. Der gesamte Datenverkehr geht an die verbleibenden fehlerfreien Geräte. Weitere Informationen zur Routenverteilung zwischen SD-WAN NVAs und Route Server finden Sie unter Routen, die von einem BGP-Peer an Route Server angekündigt werden.
Abbildung 4. BGP-gesteuertes Failover. Wenn SD-WAN NVA #0 offline ist, werden die BGP-Sitzungen mit dem Route Server geschlossen. SD-WAN NVA #0 wird aus der Routingtabelle des virtuellen Netzwerks als möglicher nächster Hop für Datenverkehr von Azure zu einem lokalen Standort entfernt.
BGP-gesteuertes Failover und ECMP-Routing ermöglichen auf natürliche Weise N-aktive Hochleistungsarchitekturen mit N Geräten, die gleichzeitig Datenverkehr verarbeiten. Sie können BGP aber auch zur Implementierung aktiver und passiver Hochverfügbarkeitsarchitekturen verwenden: Konfigurieren Sie das passive Gerät so, dass es dem Route Server die Routen mit einem geringeren Präferenzgrad als sein aktiver Peer mitteilt. Der Route Server verwirft die vom passiven Gerät empfangenen Routen, wenn er vom aktiven Gerät Routen für dieselben Ziele mit einem höheren Präferenzgrad empfängt. Und es werden nur die letztgenannten Routen in der Routingtabelle des virtuellen Netzwerks ausgelotet.
Wenn das aktive Gerät ausfällt oder einige seiner Routen zurückzieht, führt Route Server Folgendes aus:
- Wählt die entsprechenden vom passiven Gerät angekündigten Routen aus.
- Lotet die Routen in der Routingtabelle des virtuellen Netzwerks aus.
Das einzige BGP-Attribut, das SD-WAN-NVAs verwenden können, um einen Grad der Präferenz für die Routen auszudrücken, die sie dem Route Server mitteilen, ist AS Path.
Wir empfehlen N-aktive Hochverfügbarkeitsarchitekturen, da sie eine optimale Ressourcennutzung (es gibt keine Standby-SD-WAN-NVAs) und horizontale Skalierbarkeit ermöglichen. Um den Durchsatz zu erhöhen, können mehrere NVAs parallel ausgeführt werden, bis zur maximalen Anzahl von BGP-Peers, die vom Route Server unterstützt werden. Weitere Informationen finden Sie unter BGP-Peers. Das N-aktive Hochverfügbarkeitsmodell erfordert jedoch, dass die SD-WAN-NVAs als zustandslose Layer-3-Router fungieren. Wenn mehrere Tunnel zu einer Site vorhanden sind, können TCP-Verbindungen asymmetrisch weitergeleitet werden. Das heißt, die ORIGINAL- und REPLY- Flows derselben TCP-Verbindung können über verschiedene Tunnel und unterschiedliche NVAs weitergeleitet werden. Die folgende Abbildung zeigt ein Beispiel für eine asymmetrisch weitergeleitete TCP-Verbindung. Solche Routing-Asymmetrien sind für TCP-Verbindungen möglich, die entweder im virtuellen Netzwerk oder am lokalen Standort initiiert werden.
Abbildung 5. Asymmetrisches Routing in aktiven/aktiven Hochverfügbarkeitsarchitekturen. SD-WAN NVA #0 und SD-WAN NVA #1 geben die gleiche Route für Ziel 192.168.1.0/24 (Remote-SD-WAN-Standort) mit der gleichen AS-Pfadlänge zum Route Server an. Der ORIGINAL-Flow (vom SD-WAN-Remotestandort zu Azure, roter Pfad) wird über den auf Azure beendeten Tunnel von SD-WAN NVA #1 weitergeleitet. Der lokale SD-WAN-CPE wählt diesen Tunnel aus. Der Azure SDN-Stapel leitet den REPLY-Flow (von Azure bis zum Remote-SD-WAN-Standort, grüner Pfad) an SD-WAN NVA #0 weiter, was einer der möglichen nächsten Hops für 192.168.1.0/24 ist, entsprechend der Routingtabelle des virtuellen Netzwerks. Es kann nicht garantiert werden, dass der nächste vom Azure SDN-Stack ausgewählte Hop immer dasselbe SD-WAN CPE ist, das den ORIGINAL-Flow empfangen hat.
Aktive und passive Hochverfügbarkeitsarchitekturen sollten nur dann in Betracht gezogen werden, wenn SD-WAN-NVAs in Azure andere Netzwerkfunktionen ausführen, die Routing-Symmetrie erfordern, wie beispielsweise Stateful Firewalling. Wir empfehlen diesen Ansatz aufgrund seiner Auswirkungen auf die Skalierbarkeit nicht. Die Ausführung weiterer Netzwerkfunktionen auf SD-WAN-NVAs erhöht den Ressourcenverbrauch. Gleichzeitig ermöglicht die aktive und passive Hochverfügbarkeitsarchitektur, dass zu jedem Zeitpunkt ein einziger NVA den Datenverkehr verarbeitet. Das heißt, die gesamte SD-WAN-Ebene kann nur auf die maximal unterstützte Azure-VM-Größe skaliert, aber nicht aufskaliert werden. Führen Sie zustandsbehaftete Netzwerkfunktionen aus, die Routing-Symmetrie auf separaten NVA-Clustern erfordern, die auf Standard Load Balancer für n-aktive Hochverfügbarkeit angewiesen sind.
Überlegungen zur ExpressRoute-Konnektivität
Die in diesem Artikel beschriebene Architektur ermöglicht es Kunden, das SD-WAN-Paradigma vollständig zu nutzen und ihr Unternehmensnetzwerk als logische Überlagerung über dem öffentlichen Internet und dem Microsoft-Backbone aufzubauen. Sie unterstützt auch die Verwendung dedizierter Expressroute-Leitungen, um bestimmte Szenarien zu bewältigen, die später beschrieben werden.
Szenario Nr. 1: ExpressRoute- und SD-WAN-Koexistenz
SD-WAN-Lösungen können mit ExpressRoute-Konnektivität koexistieren, wenn SD-WAN-Geräte nur in einer Teilmenge von Standorten bereitgestellt werden. Beispielsweise könnten einige Organisationen SD-WAN-Lösungen als Ersatz für herkömmliche IPSec-VPNs an Standorten bereitstellen, die nur über eine Internetverbindung verfügen. Anschließend nutzen sie MPLS-Dienste und ExpressRoute-Leitungen für große Standorte und Rechenzentren, wie in der folgenden Abbildung dargestellt.
Abbildung 6. SD-WAN-Lösungen können mit ExpressRoute-Konnektivität koexistieren, wenn SD-WAN-CPE-Geräte nur an einer Untergruppe von Standorten bereitgestellt werden.
Dieses Koexistenzszenario erfordert, dass in Azure bereitgestellte SD-WAN-NVAs in der Lage sind, Datenverkehr zwischen Standorten, die mit dem SD-WAN verbunden sind, und Standorten, die mit ExpressRoute-Leitungen verbunden sind, weiterzuleiten. Route Server kann so konfiguriert werden, dass Routen zwischen virtuellen ExpressRoute-Gateways und SD-WAN-NVAs in Azure verteilt werden, indem das AllowBranchToBranch Feature aktiviert wird, wie hier dokumentiert. Die Routenweitergabe zwischen dem ExpressRoute-Gateway für virtuelle Netzwerke und den SD-WAN-NVAs erfolgt über BGP. Route Server richtet BGP-Sitzungen mit beiden ein und gibt die vom anderen Peer gelernten Routen an jeden Peer weiter. Die Plattform verwaltet die BGP-Sitzungen zwischen Route Server und dem virtuellen Netzwerk-Gateway ExpressRoute. Benutzer müssen sie nicht explizit konfigurieren, sondern lediglich das AllowBranchToBranch Flag bei der Bereitstellung von Route Server aktivieren.
Abbildung 7. Die Routenweitergabe zwischen dem ExpressRoute-Gateway für virtuelle Netzwerke und den SD-WAN-NVAs erfolgt über BGP. Route Server richtet BGP-Sitzungen mit beiden ein und verbreitet Routen in beide Richtungen, wenn er mit „AllowBranchToBranch=TRUE“ konfiguriert ist. Der Route Server fungiert als Routenreflektor, das heißt, er ist nicht Teil des Datenpfads.
Dieses SD-WAN- und ExpressRoute-Koexistenzszenario ermöglicht Migrationen von MPLS-Netzwerken zu SD-WAN. Es bietet einen Pfad zwischen alten MPLS-Standorten und neu migrierten SD-WAN-Standorten und macht die Weiterleitung des Datenverkehrs über lokale Rechenzentren überflüssig. Dieses Muster kann nicht nur bei Migrationen verwendet werden, sondern auch in Szenarien, die sich aus Unternehmensfusionen und -übernahmen ergeben, und sorgt für eine nahtlose Verbindung unterschiedlicher Netzwerke.
Szenario Nr. 2: Expressroute als SD-WAN-Underlay
Wenn Ihre lokalen Standorte über ExpressRoute-Konnektivität verfügen, können Sie SD-WAN-Geräte so konfigurieren, dass sie Tunnel zu den SD-WAN-Hub-NVAs einrichten, die in Azure über der oder den ExpressRoute-Verbindungen ausgeführt werden. ExpressRoute-Konnektivität kann über Punkt-zu-Punkt-Verbindungen oder ein MPLS-Netzwerk erfolgen. Sie können sowohl das private ExpressRoute-Peering als auch das Microsoft-Peering verwenden.
Privates Peering
Wenn Sie das private ExpressRoute-Peering als Grundlage verwenden, richten alle lokalen SD-WAN-Standorte Tunnel zu den SD-WAN-Hub-NVAs in Azure ein. In diesem Szenario ist keine Routenverteilung zwischen den SD-WAN NVAs und dem virtuellen ExpressRoute-Netzwerkgateway erforderlich (d. h. Route Server muss mit dem Flag „AllowBranchToBranch“ auf „false“ konfiguriert werden).
Dieser Ansatz erfordert eine ordnungsgemäße BGP-Konfiguration auf den kunden- oder anbieterseitigen Routern, die die ExpressRoute-Verbindung beenden. Tatsächlich kündigen die Microsoft Enterprise Edge Routers (MSEEs) alle Routen für die virtuellen Netzwerke an, die mit der Leitung verbunden sind (entweder direkt oder über virtuelles Netzwerk-Peering). Um jedoch Datenverkehr, der für virtuelle Netzwerke bestimmt ist, über einen SD-WAN-Tunnel weiterzuleiten, sollte der lokale Standort diese Routen vom SD-WAN-Gerät lernen – und nicht von der ER-Verbindung.
Daher müssen die Router auf Kunden- oder Anbieterseite, die die ExpressRoute-Verbindung beenden, die von Azure empfangenen Routen herausfiltern. Die einzigen im Underlay konfigurierten Routen sollten solche sein, die es den lokalen SD-WAN-Geräten ermöglichen, die SD-WAN-Hub-NVAs in Azure zu erreichen. Kunden, die das private ExpressRoute-Peering als SD-WAN-Underlay verwenden möchten, sollten überprüfen, ob sie ihre Routing-Geräte entsprechend konfigurieren können. Dies ist insbesondere für Kunden relevant, die keine direkte Kontrolle über ihre Edge-Geräte für ExpressRoute haben. Ein Beispiel wäre, wenn die ExpressRoute-Verbindung von einem MPLS-Anbieter zusätzlich zu einem IPVPN-Dienst bereitgestellt wird.
Abbildung 8. Privates ExpressRoute-Peering als SD-WAN-Underlay. In diesem Szenario erhalten die Router auf Kunden- und Anbieterseite die Routen für das virtuelle Netzwerk, die die ExpressRoute-Verbindung beenden, in den privaten ER-Peering-BGP-Sitzungen und im SD-WAN CPE. Nur das SD-WAN CPE sollte die Azure-Routen in das LAN des Standorts weiterleiten.
Microsoft-Peering
Sie können das ExpressRoute-Microsoft-Peering auch als Grundlage für SD-WAN-Tunnel verwenden. In diesem Szenario stellen die SD-WAN-Hub-NVAs in Azure nur öffentliche Tunnelendpunkte bereit, die sowohl von SD-WAN-CPEs in mit dem Internet verbundenen Standorten (sofern vorhanden) als auch von SD-WAN-CPEs in über Expressroute verbundenen Standorten verwendet werden. Obwohl für das ExpressRoute-Microsoft-Peering komplexere Voraussetzungen gelten als für das private Peering, empfehlen wir aufgrund dieser beiden Vorteile die Verwendung dieser Option als Grundlage:
Es sind keine virtuellen Expressroute-Netzwerk-Gateways im virtuellen Hubnetzwerk erforderlich. Es entfernt Komplexität, reduziert Kosten und ermöglicht die Skalierung der SD-WAN-Lösung über die Bandbreitengrenzen des Gateways hinaus, wenn Sie ExpressRoute FastPath nicht verwenden.
Es sorgt für eine saubere Trennung zwischen Overlay- und Underlay-Routen. Die MSEEs geben lediglich die öffentlichen Präfixe des Microsoft-Netzwerks an den Edge des Kunden oder Anbieters bekannt. Sie können diese Routen in einem separaten VRF verwalten und nur an ein DMZ-Segment des LAN des Standorts weitergeben. SD-WAN-Geräte verbreiten im Overlay die Routen für das Unternehmensnetzwerk des Kunden, einschließlich Routen für virtuelle Netzwerke. Kunden, die diesen Ansatz in Betracht ziehen, sollten überprüfen, ob sie ihre Routing-Geräte entsprechend konfigurieren können, oder den richtigen Service bei ihrem MPLS-Anbieter anfordern.
Überlegungen zu MPLS
Die Migration von traditionellen MPLS-Unternehmensnetzwerken zu moderneren Netzwerkarchitekturen auf Basis des SD-WAN-Paradigmas erfordert einen erheblichen Aufwand und sehr viel Zeit. Die in diesem Artikel beschriebene Architektur ermöglicht schrittweise SD-WAN-Migrationen. Zwei typische Migrationsszenarien werden später besprochen.
Phasenweise MPLS-Außerbetriebnahme
Kunden, die ein SD-WAN auf dem öffentlichen Internet und dem Microsoft-Backbone aufbauen und MPLS IPVPNs oder andere dedizierte Konnektivitätsdienste vollständig außer Betrieb nehmen möchten, können das im vorherigen Abschnitt beschriebene Koexistenzszenario ExpressRoute und SD-WAN verwenden. Es ermöglicht SD-WAN-verbundenen Standorten, Standorte zu erreichen, die noch mit dem alten MPLS verbunden sind. Sobald ein Standort in das SD-WAN migriert wird und CPE-Geräte bereitgestellt werden, kann seine MPLS-Verbindung außer Betrieb genommen werden. Der Standort kann über seine SD-WAN-Tunnel auf das gesamte Unternehmensnetzwerk zu den nächstgelegenen Azure-Regionen zugreifen.
Abbildung 9. Das Szenario „ExpressRoute- und SD-WAN-Koexistenz“ ermöglicht die phasenweise Außerbetriebnahme von MPLS.
Wenn alle Standorte migriert sind, kann das MPLS-IPVPN zusammen mit den ExpressRoute-Leitungen, die es mit dem Microsoft-Backbone verbinden, außer Betrieb genommen werden. ExpressRoute-Gateways für virtuelle Netzwerke werden nicht mehr benötigt und können aufgehoben werden. Die SD-WAN-Hub-NVAs in jeder Region werden zum einzigen Einstiegspunkt in das Hub-and-Spoke-Netzwerk dieser Region.
MPLS-Integration
Organisationen, die nicht darauf vertrauen, dass öffentliche und gemeinsam genutzte Netzwerke die gewünschte Leistung und Zuverlässigkeit bieten, entscheiden sich möglicherweise für die Verwendung eines vorhandenen MPLS-Netzwerks als Grundlage für Unternehmen. Sie haben zwei Möglichkeiten:
- Eine Untergruppe von Standorten wie Rechenzentren oder große Zweigstellen.
- Eine Teilmenge von Verbindungen, typischerweise latenzempfindlicher oder geschäftskritischer Datenverkehr.
Das zuvor beschriebene Szenario Expressroute als SD-WAN-Underlay ermöglicht die SD-WAN- und MPLS-Integration. Aus den zuvor erläuterten Gründen sollte das ExpressRoute-Microsoft-Peering dem privaten Peering vorgezogen werden. Wenn das Microsoft-Peering verwendet wird, werden das MPLS-Netzwerk und das öffentliche Internet außerdem zu funktional gleichwertigen Grundlagen. Sie bieten Zugriff auf alle SD-WAN-Tunnelendpunkte, die von SD-WAN-Hub-NVAs in Azure bereitgestellt werden. Ein SD-WAN-CPE, das an einem Standort mit Internet- und MPLS-Konnektivität bereitgestellt wird, kann auf beiden Grundlagen mehrere Tunnel zu den SD-WAN-Hubs in Azure einrichten. Anschließend können sie verschiedene Verbindungen durch verschiedene Tunnel leiten, basierend auf Richtlinien auf Anwendungsebene, die von der SD-WAN-Steuerungsebene verwaltet werden.
Abbildung 10. Das Szenario „ExpressRoute als SD-WAN-Underlay“ ermöglicht die SD-WAN- und MPLS-Integration.
Routing-Einstellung für Route Server
In beiden MPLS-Szenarien, die in den beiden vorherigen Abschnitten behandelt wurden, können einige Zweigstellen sowohl mit dem MPLS IPVPN als auch mit dem SD-WAN verbunden werden. Dadurch können die in den virtuellen Hubnetzwerken bereitgestellten Route Server-Instanzen dieselben Routen von ExpressRoute-Gateways und SD-WAN-NVAs lernen. Mit der Routing-Präferenz von Route Server können Sie steuern, welcher Pfad bevorzugt und in die Routingtabellen der virtuellen Netzwerke aufgenommen werden soll. Die Routingeinstellung ist nützlich, wenn der AS-Pfad nicht verwendet werden kann. Ein Beispiel sind MPLS-IPVPN-Dienste, die keine benutzerdefinierten BGP-Konfigurationen auf den PEs unterstützen, die ExpressRoute-Verbindungen beenden.
Einschränkungen und Designüberlegungen für Route Server
Route Server ist der Eckpfeiler der in diesem Artikel beschriebenen Architektur. Er verbreitet Routen zwischen SD-WAN-NVAs, die in virtuellen Netzwerken bereitgestellt werden, und dem zugrunde liegenden Azure SDN-Stack. Er bietet einen BGP-basierten Ansatz zum Betrieb mehrerer SD-WAN-NVAs für hohe Verfügbarkeit und horizontale Skalierbarkeit. Wenn Sie große SD-WANs basierend auf dieser Architektur entwerfen, müssen die Skalierbarkeitsgrenzwerte von Route Server eingegrenzt werden.
Die folgenden Abschnitte enthalten Hinweise zur maximalen Skalierbarkeit und zum Umgang mit den einzelnen Grenzwerten.
Routen, die von einem BGP-Peer für Route Server angekündigt werden
Route Server definiert keinen expliziten Grenzwert für die Anzahl der Routen, die an ExpressRoute Virtual Network Gateways angekündigt werden können, wenn das AllowBranchToBranch Flag festgelegt ist. ExpressRoute-Gateways geben die Routen, die sie vom Route Server lernen, jedoch weiter an die ExpressRoute-Leitungen, mit denen sie verbunden sind.
Es gibt ein Limit für die Anzahl der Routen, die ExpressRoute-Gateways für ExpressRoute-Leitungen über das private Peering ankündigen können, die bei Azure-Abonnement- und Dienstgrenzwerten, Kontingenten und Einschränkungen dokumentiert sind. Beim Entwerfen von SD-WAN-Lösungen basierend auf den Anleitungen in diesem Artikel ist es wichtig sicherzustellen, dass SD-WAN-Routen nicht dazu führen, dass dieser Grenzwert erreicht wird. Beim Erreichen des Grenzwerts werden die BGP-Sitzungen zwischen ExpressRoute-Gateways und ExpressRoute-Leitungen unterbrochen und die Konnektivität zwischen virtuellen Netzwerken und über ExpressRoute verbundenen Remotenetzwerken geht verloren.
Die Gesamtzahl der von ExpressRoute-Gateways an Leitungen angekündigten Routen ist die Summe der Anzahl der vom Route Server gelernten Routen und der Anzahl der Präfixe, die den Adressraum des Azure-Hub-and-Spoke-Netzwerks bilden. Um Ausfälle aufgrund abgebrochener BGP-Sitzungen zu vermeiden, empfehlen wir Ihnen, die folgenden Abhilfemaßnahmen zu implementieren:
- Verwenden Sie die Funktionen nativer SD-WAN-Geräte, um die Anzahl der dem Route Server angekündigten Routen zu begrenzen, sofern die Funktion verfügbar ist.
- Verwenden Sie Azure Monitor-Benachrichtigungen, um Spitzen in der Anzahl der von ExpressRoute-Gateways angekündigten Routen proaktiv zu erkennen. Die zu überwachende Metrik heißt Anzahl der an den Peer angekündigten Routen, wie in der ExpressRoute-Überwachung dokumentiert.
BGP-Peers
Route Server kann BGP-Sitzungen mit bis zu einer maximalen Anzahl von BGP-Peers einrichten. Dieser Grenzwert bestimmt die maximale Anzahl von SD-WAN-NVAs, die BGP-Adjazenzen mit Route Server herstellen können, und damit den maximalen Gesamtdurchsatz, der über alle SD-WAN-Tunnel hinweg unterstützt werden kann. Es wird erwartet, dass nur große SD-WANs diese Grenze erreichen. Es gibt keine Problemumgehungen, um dieses Problem zu umgehen, außer der Schaffung mehrerer Hub-and-Spoke-Netzwerke, jedes mit eigenen Gateways und Routenservern.
Teilnehmende VMs
Virtual Network Gateways und Route Server konfigurieren die Routen, die sie von ihren Remote-Peers lernen, für alle VMs in ihrem eigenen virtuellen Netzwerk und in direkt verbundenen virtuellen Netzwerken. Um Route Server vor übermäßigem Ressourcenverbrauch aufgrund der Weiterleitung von Aktualisierungen an VMs zu schützen, definiert Azure einen Grenzwert für die Anzahl der VMs, die in einem einzelnen Hub-and-Spoke-Netzwerk vorhanden sein können. Es gibt keine Problemumgehungen, um diese Grenze zu überwinden, außer der Schaffung mehrerer Hub-and-Spoke-Netzwerke, jedes mit seinen eigenen Gateways und Routenservern, in derselben Region.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Federico Guerrini | Senior Cloud Solution Architect
- Khush Kaviraj | Cloud Solution Architect
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.