Ausfallsicherheit und hohe Verfügbarkeit
Die Contrail SD-WAN-Lösung ist ausfallsicher und auf allen Ebenen hochverfügbar. Dadurch kann das Netzwerk bei Ausfällen nahtlos und mit möglichst wenigen Ausfallzeiten zusammenarbeiten. In den folgenden Abschnitten wird die Hochverfügbarkeit auf den einzelnen Ebenen erläutert.
Netzwerksteuerungsebene
Die Steuerungsebene selbst ist in der Contrail SD-WAN-Lösung eine verteilte Entität. Die Steuerungsebene wird mithilfe von vRRs aktiviert, die ein Peering mit den lokalen Geräten herstellen und das Routing dynamisch basierend auf Informationen aus den Microservices des Routing-Managers und des Richtlinien-/SLA-Managers einrichten.
Route Reflectors werden in einer hierarchischen Struktur bereitgestellt. Die Geräte vor Ort verbinden sich mit ihrem nächstgelegenen regionalen Routenreflektor, der wiederum mit den anderen Routenreflektoren peert.
Headless-Weiterleitung
Wenn lokale Geräte die Verbindung zum Routenreflektor im SD-WAN-Controller verlieren, können die Geräte den Datenverkehr weiterhin weiterleiten. Dies wird als Headless-Betrieb bezeichnet. Diese Situation ist suboptimal, da der Controller nicht überwachen und neue Routen vorschlagen kann, die Pfade jedoch weiterhin bestehen und der Datenverkehr nach bestem Wissen und Gewissen weitergeleitet wird.
Im Headless-Modus werden keine neuen Konfigurations- oder Richtlinienänderungen am Gerät vorgenommen, und es werden keine neuen Daten vom Gerät gemeldet. Sobald die Konnektivität wiederhergestellt ist, meldet sich das Gerät beim Controller an, um sicherzustellen, dass es über die neuesten Routing- und Konfigurationsinformationen verfügt.
Data Plane
CSO-Version 3.3 und höher unterstützen lokale Geräteredundanz. Ein Standort kann einen Cluster aus zwei Knoten umfassen, die als primärer und sekundärer Knoten fungieren, um vor Geräte- und Verbindungsausfällen zu schützen. Wenn der primäre Knoten ausfällt oder die Verbindungen zu ihm ausgefallen sind, fließt der Datenverkehr über den sekundären Knoten.
Spoke-Redundanz
Spoke-Standorte können Redundanz bieten, indem zwei CPE-Geräte miteinander verbunden werden, um einen einzigen, logischen und sicheren Router zu schaffen. Es können Firewalls der NFX-Serie oder SRX-Serie verwendet werden.
Verwenden von Geräten der NFX-Serie
Abbildung 1 zeigt eine Spoke-Redundanz-Einrichtung mit Geräten der NFX-Serie, auf denen jeweils eine virtuelle Virtuelle Firewall vSRX installiert ist. Die beiden CPE-Geräte werden miteinander verbunden, indem ein SRX-Chassis-Cluster erstellt wird, um einen einzigen logischen Knoten zu bilden. Der Cluster verwendet eine redundante Ethernet-Schnittstelle (reth) für die Verbindung mit der Junos Control Plane (JCP)-Komponente, die als Switch für die Verbindung zu und aus den Geräten fungiert.
der NFX-Serie
Verwenden von Firewalls der SRX-Serie
Abbildung 2 zeigt eine Spoke-Redundanzeinrichtung mit Firewalls der SRX-Serie. Die beiden CPE-Geräte werden mittels Chassis-Clustering zu einem einzigen logischen Knoten verbunden.
der SRX-Serie
Auch hier sorgen mehrere Verbindungen auf beiden Seiten der Geräte für Linkredundanz. Auf der LAN-Seite werden Aktiv/Backup-Links verwendet, die als Reth-Schnittstelle im SRX-Cluster gebündelt sind. Die WAN-Seite nutzt alle vier aktiven WAN-Verbindungen, die auf die beiden Geräte verteilt sind.
Failover-Szenarien
In Tabelle x wird beschrieben, wie ein Spoke-Redundanz-Setup auf verschiedene Fehlerszenarien reagiert.
Szenario |
NFX-Verhalten |
SRX-Verhalten |
|---|---|---|
Geräteausfall |
Knoten-Failover des Virtuelle Firewall vSRX-Clusters |
Knoten-Failover des SRX-Chassis-Clusters |
GWR Virtuelle Firewall vSRX VM-Ausfall |
Knoten-Failover des Virtuelle Firewall vSRX-Clusters |
N/A |
Ausfall der LAN-seitigen Verbindung |
JCP – LAG-basierter Schutz für einzelne Verbindungsausfälle Virtuelle Firewall vSRX – Reth-Failover auf den anderen Cluster-Knoten, wenn alle LAN-Verbindungen zu einem Knoten ausfallen |
LAG-basierter Schutz für einzelne Verbindungsausfälle Erneutes Failover auf den anderen Clusterknoten, wenn alle LAN-Verbindungen zu einem Knoten ausfallen |
WAN-seitiger Verbindungsausfall |
Identisch mit Single-CPE – ECMP über die verbleibenden Verbindungen bis zur Durchsetzung des SLA durch den SD-WAN-Controller |
|
Fehler bei der physischen Verbindung der Verbindung |
JCP – LAG-basierter Schutz |
Keine eingebaut; kann LAG-basierten Schutz durch zwei miteinander verbundene Switches zwischen den Knoten hinzufügen |
Usage Notes
Sie müssen dasselbe Gerätemodell der Firewall der NFX-Serie oder SRX-Serie verwenden, und auf den Geräten (primär und sekundär) muss dieselbe Version von Junos OS installiert sein.
Die folgenden SD-WAN-Funktionen werden bei Verwendung von Spoke-Redundanz nicht unterstützt:
LTE-WAN-Backup-Verbindung
Unterstützung der Servicekette
Weitere Informationen zur Spoke-Redundanz finden Sie unter Übersicht über die Unterstützung von Geräteredundanz im CSO-Benutzerhandbuch.
Hub-Redundanz (CPE-Multihoming)
Bei Hub-and-Spoke-Topologien kann auch auf der Hub-Seite Redundanz geschaffen werden, indem zwei Hub-Geräte in einem Aktiv/Backup-Setup bereitgestellt werden. Wenn der primäre Hub ausfällt oder alle Overlay-Tunnel zum primären Hub ausfallen, wechselt der Datenverkehr zum sekundären Hub. Wenn der primäre Hub wieder hochgefahren wird und Tunnel eingerichtet werden, wird der Datenverkehr zurück zum primären Hub bewegt.
Der Dual-Hub-Modus kann auch im Primär-/Sekundärmodus verwendet werden. Ein Hub kann z. B. für die Hälfte der Speichen primär und für die andere Hälfte sekundär sein. Auf diese Weise wird die Last aktiv/aktiv auf alle Paare von Hub-Geräten verteilt. Beachten Sie, dass für diesen Modus die Hub-Geräte vernetzt werden müssen, um die Datenstromsymmetrie im gesamten Netzwerk aufrechtzuerhalten.
Designoptionen
Es gibt mehrere Möglichkeiten, Redundanz zwischen Hub-and-Spoke-Geräten zu implementieren, abhängig von den Entwurfsanforderungen:
Single Spoke Device Multihomed to Dual Hub Devices; Single Access
Abbildung 3 zeigt, wie ein Single-Spoke-Gerät mit Dual-Hub-Geräten mit einfachem Zugriff multihomed verbunden werden kann.
Abbildung 3: Ein Spoke-Gerät, ein Tunnel zu jedem Hub
In diesem Szenario befinden sich die Hub-Geräte in einer Aktiv/Backup-Konfiguration, und Spoke-Site-Präfixe werden an den aktiven Hub weitergeleitet.
Single Spoke Device Multihomed to Dual Hub Devices; Multiple Access
Abbildung 4 zeigt, wie ein Single-Spoke-Gerät mit Dual-Hub-Geräten mit mehrfachem Zugriff multihomed verbunden werden kann.
Abbildung 4: Ein Spoke-Gerät, zwei Tunnel zu jedem Hub
Wie im vorherigen Szenario befinden sich die Hub-Geräte in einer Aktiv/Backup-Konfiguration, und Spoke-Site-Präfixe werden an den aktiven Hub weitergeleitet. Darüber hinaus verfügt die Spoke-Site über Overlay-Links zu den einzelnen Hubs über jedes Zugriffsnetzwerk. APBR leitet den Datenverkehr vom CPE-Gerät zum aktiven Hub über alle möglichen Overlays.
Clustered Spoke Devices Multihomed to Dual Hub Devices; Multiple Access
Abbildung 5 zeigt, wie Dual-CPE-Geräte mit Dual-Hub-Geräten mit mehrfachem Zugriff von jedem CPE-Gerät multinetworked werden können.
Abbildung 5: Spoke-Cluster, ein Tunnel zu jedem Hub
Wie im vorherigen Szenario befinden sich die Hub-Geräte in einer Aktiv/Backup-Konfiguration, Spoke-Site-Präfixe werden an den aktiven Hub weitergeleitet, und APBR leitet den Datenverkehr vom aktiven CPE-Gerät zum aktiven Hub über alle möglichen Overlays. In diesem Szenario befinden sich die CPE-Geräte ebenfalls in einer Aktiv/Passiv-Konfiguration.
Der Spoke-Standort verfügt über acht Overlay-Tunnel:
Aktives CPE zu aktivem Hub – zwei aktive Verbindungen
Aktives CPE zum Backup-Hub – zwei Backup-Links
Backup von CPE auf aktivem Hub – zwei aktive Verbindungen
Backup-CPE zu Backup-Hub – zwei Backup-Links
Anmerkung:Bei beiden Hubs, mit denen ein CPE-Gerät multihomed ist, muss es sich um denselben Gerätetyp handeln.
Anmerkung:Bei Verwendung von NAT kann ein Hub-Switchover aufgrund eines Ausfalls eines primären Hubs dazu führen, dass Standort-zu-Internet- und Standort-zu-Cloud-Anwendungssitzungen unterbrochen werden, wenn sich das NAT-Verhalten an die Änderung anpasst.Site-to-Site-Sitzungen funktionieren auch während des Switchovers.