AUF DIESER SEITE
Contrail SD-WAN-Bereitstellungsarchitekturen
Eine SD-WAN-Implementierung bietet eine flexible und automatisierte Möglichkeit, den Datenverkehr von standort zu Standort zu leiten. Wie in Abbildung 1 zu sehen ist, umfasst eine einfache SD-WAN-Architektur nur einige Grundelemente.
Mehrere Standorte
Mehrere Verbindungen zwischen Standorten, die das Underlay-Netzwerk bilden
Mehrere Overlay-Tunnel
Ein Controller
Der in CSO integrierte SD-WAN-Controller fungiert als Orchestrierungsebene und bietet eine Schnittstelle, die es dem Betreiber ermöglicht, die Geräte an den Standorten einzurichten und zu verwalten.
Referenzarchitektur Contrail SD-WAN
Die Contrail SD-WAN-Lösungsarchitektur von Juniper Networks, siehe Abbildung 2 , verwendet eine Hub-and-Spoke-Topologie mit CPE-Geräten, die sich an den Zweigstellen des Kunden befinden. Auf der lokalen Seite des Standorts verbinden sich die CPE-Geräte mit LAN-Segmenten und nehmen an dynamischen Routing-Protokollen mit anderen LAN-Geräten teil. Auf der WAN-Seite verbinden sich die CPE-Geräte über zwei oder mehr Verbindungen zu einem Provider-Hub-Gerät. Da das SD-WAN-Modell eine Hub-and-Spoke-Topologie verwendet, wird der Datenverkehr von Standort zu Standort über den Provider Hub geleitet. Standardmäßig fließt der Datenverkehr über das Internet auch über das Hub-Gerät des Anbieters.
Contrail SD-WAN
Der SD-WAN-Orchestrator und die Controller-Funktionen werden über die Contrail Service Orchestration (CSO)-Software von Juniper Networks implementiert. Die CSO-Plattform nutzt Richtlinien und SLA-Parameter, um die Datenverkehrsströme nach Bedarf über die verfügbaren Pfade zu differenzieren und zu leiten.
In den folgenden Abschnitten werden diese Architekturelemente ausführlicher beschrieben.
Spoke-Geräte
Das CPE-Gerät in der Zweigstelle eines Unternehmenskunden fungiert im SD-WAN-Modell als Spoke-Gerät. Das Gerät fungiert auch als Gateway-Router und bietet Konnektivität von der Zweigstelle zu anderen Standorten im Mandantennetzwerk und zum Internet. Es gibt zwei Arten von Spoke-Geräten: On-Premises-Spoke und Cloud-Spoke.
Spoke-Geräte vor Ort
Vor-Ort-Spoke-Geräte können entweder Geräte der NFX-Serie oder bestimmte Geräte der SRX-Serie sein.
Network Services Platform der NFX-Serie
Eine Network Services Platform der NFX-Serie, die als On-Premises-Spoke-Gerät verwendet wird, kann eine Reihe von anbieterübergreifenden VNFs hosten, Serviceverkettung unterstützen und durch Orchestrierungssoftware in der Cloud verwaltet werden. Geräte der NFX-Serie beseitigen die betriebliche Komplexität der Bereitstellung mehrerer physischer Netzwerkgeräte an einem Kundenstandort und bieten eine erhebliche Verbesserung gegenüber herkömmlichen CPE-Geräten mit einer einzigen Funktion.
Eine wichtige VNF, die auf der Plattform der NFX-Serie unterstützt wird, ist die virtuelle Firewall vSRX. In der Contrail SD-WAN-Lösung führt die vSRX-Instanz mit Routing- und Switching-Funktionen die Gateway-Router-Funktion aus. Es bietet auch die gleichen funktionsreichen Sicherheitsservices, die auf Standardgeräten der SRX-Serie zu finden sind. Tabelle 1 zeigt die Hardware der NFX-Serie, die Sie als on-Premises-Spoke-Gerät implementieren können.
Die NFX150 verfügt anstelle der vSRX-Funktionalität auf anderen Geräten der NFX-Serie über eine integrierte SRX-Firewall.
Plattform |
Unterstützte Modelle |
|---|---|
Netzwerkserviceplattform NFX150 |
|
Netzwerkserviceplattform NFX250 |
|
Geräte der SRX-Serie und virtuelle vSRX-Firewalls
Anstelle der Plattform der NFX-Serie kann ein physisches Sicherheitsgerät der SRX-Serie verwendet werden, um die Gateway-Routerfunktion bereitzustellen, ebenso wie eine auf einem Server installierte vSRX-Instanz. Tabelle 2 zeigt die SRX-Hardware und die virtuellen vSRX-Firewalls, die Sie als On-Premises-Spoke-Geräte implementieren können.
Plattform |
Unterstützte Modelle |
|---|---|
SRX-Serie |
|
Virtuelle Firewalls vSRX |
vSRX vSRX 3.0 |
Aktuelle Informationen zur Hardware- und Softwareunterstützung für CSO finden Sie in den Versionshinweisen zu Contrail Service Orchestration.
Cloud-Spoke-Geräte
Ein Contrail SD-WAN-Cloud-Spoke-Gerät in Form einer vSRX kann in einer AWS VPC lokalisiert werden. Die vSRX dient als Spoke-Gerät in der Cloud; Sobald das Endgerät online ist, verhält es sich wie jedes andere Spoke-Gerät.
Spoke-Redundanz
An Spoke-Standorten können zwei redundante CPE-Geräte zum Schutz vor Geräte- und Verbindungsausfällen verwendet werden. Weitere Informationen finden Sie im Abschnitt Ausfallsicherheit und hohe Verfügbarkeit. des Design- und Architekturleitfadens für Contrail SD-WAN.
Provider-Hub-Geräte
Die Contrail SD-WAN-Lösung unterstützt zwei Bereitstellungstopologien (die weiter unten in diesem Leitfaden erläutert werden): Dynamisches Mesh und Hub-and-Spoke. In einer dynamischen Mesh-Bereitstellung verfügt jeder Standort über ein CPE-Gerät, das eine Verbindung zu den anderen Standorten und dem Enterprise Hub-Gerät herstellt. In einer Hub-and-Spoke-Bereitstellung gibt es mindestens ein Hub-Gerät für Anbieter und ein oder mehrere Spoke-Geräte.
Das Provider-Hub-Gerät beendet sowohl MPLS/GRE- als auch IPsec-Tunnel von Spoke-Geräten.
Provider-Hubs
In einer Service Provider (SP)-Umgebung hostt der Service Provider ein Provider-Hub-Gerät in ihrem Netzwerk. Das Provider-Hub-Gerät fungiert als Point of Presence (POP) oder Verbindungspunkt. Es handelt sich in der Regel um ein gemeinsam genutztes Gerät, das hub-Funktionen für mehrere Kunden (Mandanten) durch die Verwendung von virtuellen Routing- und Weiterleitungsinstanzen (VRF) bereitstellt. Der SP-Administrator und der OpCo-Administrator können beide das Provider-Hub-Gerät verwalten. Für CSOaaS wird die SP-Administratorrolle von Juniper Networks als cspadmin-Benutzer (oder gleichwertig) ausgeführt. Die OpCo-Administratorrolle kann einem Benutzer vom Sp-Administrator zugewiesen werden, der OpCo-Administrator verfügt jedoch nicht über Sp-Administratorrechte. Tabelle 3 listet die Provider-Hub-Geräte auf, die in einer CSO-SD-WAN-Umgebung unterstützt werden.
Rolle |
Unterstützte Gerätetypen |
|---|---|
Provider-Hub |
|
Aktuelle Informationen zur Hardware- und Softwareunterstützung für CSO finden Sie in den Versionshinweisen zu Contrail Service Orchestration.
Provider-Hub-Redundanz
Zwei redundante Provider-Hub-Geräte können an einem POP zum Schutz vor Geräte- und Verbindungsausfällen und zur Bereitstellung von Upstream-Multihoming für Spoke-Standorte verwendet werden. Weitere Informationen finden Sie im Thema Ausfallsicherheit und hohe Verfügbarkeit in diesem Leitfaden.
Enterprise Hub-Standorte und -Geräte
Ein spezielles Spoke-Gerät, ein Enterprise Hub-Gerät, kann als CPE an einem lokalen Spoke-Standort bereitgestellt werden. SrX1500-, SRX4100- und SRX4200-Geräte können diese Funktion erfüllen. Der Spoke-Standort, der auf diese Weise funktioniert, muss während der Standorterstellung als Enterprise-Hub-Standort konfiguriert werden. Durch das Erstellen eines Enterprise Hub-Standorts werden zusätzliche Funktionen für den Standort geöffnet:
Kann als Ankerpunkt für standort-zu-Standort-Kommunikation im Netzwerk des Kunden fungieren.
Kann als zentraler Breakout-Knoten für das Netzwerk des Kunden fungieren.
Bietet eine spezialisierte Abteilung namens Datencenter-Abteilung.
Unterstützt dynamische LAN-Segmente im Datencenter mit BGP- und OSPF-Routenimporten, einschließlich Standardrouten, vom LAN-seitigen Layer 3-Gerät.
Ermöglicht absichtsbasierte Breakout-Profile zur Erstellung granularer Breakout-Verhaltensweisen basierend auf Abteilung, Anwendung, Standort und so weiter.
In einer Unternehmensumgebung ist der Enterprise Hub eigentum des Kunden (Mandant) und befindet sich in der Regel in einem Unternehmens-Datencenter. Nur die Spoke-Standorte des Kunden können sich mit dem Enterprise Hub-Gerät verbinden. OpCo- und Mandantenadministratoren können den Enterprise Hub verwalten. Tabelle 4 listet die Hub-Geräte auf, die in einer CSO-SD-WAN-Umgebung unterstützt werden.
Rolle |
Unterstützte Gerätetypen |
|---|---|
Enterprise Hub |
|
Aktuelle Informationen zur Hardware- und Softwareunterstützung für CSO finden Sie in den Versionshinweisen zu Contrail Service Orchestration.
Underlay (physisches) Netzwerk
Das Underlay-Netzwerk umfasst die physische Konnektivität zwischen Geräten in der SD-WAN-Umgebung. Diese Netzwerkebene hat keine Aufmerksamkeit für die LAN-Segmente der Kunden, sie bietet einfach die Erreichbarkeit zwischen vor Ort-Geräten.
Abbildung 3 zeigt ein Beispiel für ein Underlay-Netzwerk für eine Hub-and-Spoke-SD-WAN-Bereitstellung (die Details gelten auch für eine dynamische Mesh-Einrichtung). Jeder Spoke-Standort hat in der Regel mehrere Pfade zum Hub-Standort. in diesem Fall eine über die private MPLS-Cloud und eine über das Internet.
Jedes gerät (oder standort) vor Ort kann bis zu vier WAN-Verbindungen haben, einschließlich einer Satellitenverbindung, die für OAM verwendet werden kann. Während der Konfiguration identifiziert CSO die WAN-orientierten Schnittstellen der Geräte als WAN_0 durch WAN_3.
Beachten Sie folgendes:
Die WAN-Schnittstellen können je nach Designanforderungen per VLAN getaggt oder nicht getaggt werden.
Die Internetschnittstellen der on-Premises-Geräte können an verschiedene Netzwerke von Service Providern angeschlossen werden.
WAN-Zugriffsoptionen
Jeder unten aufgeführte WAN-Zugriffstyp kann für ZTP-, Daten- oder OAM-Datenverkehr verwendet werden. Alle Verbindungen können gleichzeitig für den Datenverkehr genutzt werden.
MPLS
Ethernet
LTE
Hinweis:LTE-WAN-Zugriff wird mithilfe eines Dongles auf Geräten der NFX250-Serie unterstützt.
LTE-WAN-Zugriff wird über eine integrierte Schnittstelle auf Geräten der NFX150-Serie unterstützt.
LTE-WAN-Zugriff wird mit einem Mini-PIM im Steckplatz 1 der Geräte der SRX300-Serie unterstützt.
Alle zuvor erwähnten LTE-Schnittstellen werden für ZTP unterstützt.
Wird nur für Hub-and-Spoke-SD-WAN-Bereitstellungen mit einem einzigen CPE unterstützt.
Vollständige und restriktive NAT-Bereitstellungen werden unterstützt.
Dual-CPE-Konfigurationen werden nicht unterstützt.
LTE-APN-Einstellungen können während des ZTP-Prozesses für die Installationsregion lokalisiert werden.
ADSL/VDSL (ADSL/VDSL-Unterstützung für WAN-Links und ZTP auf Geräten der NFX-Serie ab CSO-Version 4.0.0 und ADSL-Unterstützung für die Services Gateways der SRX300-Reihe ab CSO-Version 5.2.0.)
Breitband
MPLS und Breitband
Satellitenverbindung
WAN-Schnittstellentypen – Daten und OAM
Die WAN-Schnittstellen werden hauptsächlich zum Senden und Empfangen von Benutzerdatenverkehr (Daten) verwendet. Mindestens eine der WAN-Schnittstellen muss auch für Management -Datenverkehr (OAM) verwendet werden. Die OAM-Schnittstelle wird für die Kommunikation mit CSO verwendet und ermöglicht CSO die Verwaltung des lokalen Geräts.
Abbildung 4 zeigt diese beiden Schnittstellentypen.
Beachten Sie folgendes:
Die OAM-Schnittstelle des lokalen Geräts muss CSO erreichen können. Die Konnektivität kann ausschließlich über CSO-orchestrierte Overlay-Netzwerke bereitgestellt werden. Dazu benötigen Sie keine bereits vorhandene Underlay-Netzwerkkonnektivität. Ab CSO-Version 5.0.1 wählt CSO automatisch eine IP-Adresse für die OAM-Schnittstelle des lokalen Geräts aus. So wird sichergestellt, dass die Adresse innerhalb der gesamten CSO-Bereitstellung eindeutig ist und menschliche Fehler verhindert.
Um eine sichere Kommunikation über das WAN zu gewährleisten, initiiert das lokale Gerät die Verbindung zu CSO.
Geräteinitiierte Verbindungen können über zwischengeschaltete NAT-Geräte funktionieren.
Die Benutzer- und OAM-Datenschnittstelle kann für beide Funktionen eine einzige IP-Adresse verwenden.
Overlay-Netzwerk (Tunnel)
Das Overlay-Netzwerk umfasst die logische Tunnelkonnektivität zwischen Geräten in der SD-WAN-Umgebung. Diese Netzwerkebene hat ein Bewusstsein für die LAN-Segmente der Kunden und ist für den Transport des Kundendatenverkehrs zwischen Standorten verantwortlich.
Abbildung 5 zeigt ein Overlay-Netzwerk für eine Hub-and-Spoke-Umgebung. Jeder Spoke-Standort verfügt über zwei Tunnel, um den Datenverkehr zum Hub-Standort zu leiten: einen über die private MPLS-Cloud und einen über das Internet.
Die Tunnel haben zwei Kapselungsoptionen: MPLSoGRE oder MPLSoGREoIPsec. CSO stellt diese Tunnel als Teil des Bereitstellungsprozesses automatisch vor und richtet sie ein.
Overlay-Bereitstellungstopologien
Die SD-WAN-Lösung unterstützt Hub-and-Spoke- oder dynamische Mesh-Bereitstellungstopologien. Eine dynamische Mesh-Topologie ähnelt einer Full-Mesh-Topologie, bei der jeder Standort eine direkte Verbindung zu jedem anderen Standort herstellen kann. Aber mit dynamischem Mesh werden die Verbindungen (Tunnel) bei Bedarf eingerichtet, wodurch die kontinuierliche Belastung an jedem Standort reduziert wird. Ein einzelner Mandant kann sowohl Hub-and-Spoke- als auch dynamische Mesh-Topologien unterstützen.
Hub and Spoke
Mit der Hub-and-Spoke-Topologie sind alle Spoke-Standorte mit mindestens einem Hub-Standort verbunden, wie in Abbildung 6 dargestellt. Spoke-Standorte können nicht direkt mit anderen Spoke-Standorten kommunizieren.
Die verwendeten Hub-Standorte können entweder Provider-Hub- oder Enterprise-Hub-Standorte sein. Wenn ein Enterprise Hub-Standort verwendet wird, wird der Provider-Hub (falls vorhanden) nur als Backup verwendet. Diese Topologie wird bevorzugt, wenn Anwendungen und Services am Hub-Standort zentralisiert werden.
Dynamic Mesh
Mit der dynamischen Mesh-Topologie ermöglichen Overlay-Tunnel zwischen beteiligten Standorten die direkte Kommunikation untereinander, wie in Abbildung 7 dargestellt. Obwohl die Abbildung die DATA_AND_OAM Verbindung auf dem MPLS-Link zeigt, WAN_0, kann diese Funktion entweder für die MPLS- oder Internetlinks ausgeführt werden.
SD-WAN
Diese Topologie eignet sich gut für Bereitstellungen, bei denen Anwendungen und Services nicht zentralisiert sind.
Sowohl Hub-and-Spoke- als auch Full-Mesh-Topologien erfordern das Hinzufügen eines sicheren OAM-Netzwerk-Overlays und damit eines OAM-Hubs.
Wenn Spoke-Geräte zu einer dynamischen Mesh-Topologie hinzugefügt werden, muss der Administrator, der die Standorte konfiguriert, jeder WAN-Schnittstelle ein Mesh-Tag zuweisen. Nur zwei Geräte mit passenden Mesh-Tags können die VPN-Verbindung bilden, um die Kommunikation zu ermöglichen. Schnittstellen mit nicht übereinstimmende Mesh-Tags können niemals direkt kommunizieren.
Orchestrierung und Steuerung
Orchestrierungs- und Controllerfunktionen werden über die Contrail Service Orchestration (CSO)-Software von Juniper implementiert. Wie in Abbildung 8 dargestellt, bietet die CSO-Software eine webbasierte Benutzeroberfläche zur Verwaltung der SD-WAN-Umgebung. Abbildung 8 ist ein Beispielbild und die CSO-Versionsnummer darauf dient nur zur Referenz.
Die Service Orchestration-Ebene enthält den Network Service Orchestrator (NSO). Die Orchestrierungssoftware bietet einen globalen Überblick über alle Ressourcen und ermöglicht das Mandantenmanagement und bietet end-to-End-Datenverkehrsorchestrierung, Visibilität und Überwachung. Die Domain Orchestration Layer enthält den Network Service Controller (NSC). Die Orchestrierungssoftware arbeitet mit dem Controller zusammen, um vor Ort (CPE)-Geräte zu verwalten und Topologie- und CPE-Lebenszyklusverwaltungsfunktionen bereitzustellen.
Auf Benutzerebene stellt CSO die Schnittstelle zur Bereitstellung, Verwaltung und Überwachung der Geräte im SD-WAN-Netzwerk über das NSC bereit. Auf Netzwerkebene umfasst NSC eine vRR, die es jedem Standort ermöglicht, seine lokalen Routen zu Remote-Standorten bekannt zu machen.
Sicheres OAM-Netzwerk
SD-WAN-Bereitstellungen umfassen ein sicheres OAM-Overlay-Netzwerk, um end-to-End-sichere Kommunikation zwischen lokalen Geräten und CSO bereitzustellen. Für CSOaaS wird dies automatisch als Teil des Service bereitgestellt.
Wie in Abbildung 9 dargestellt, ermöglichen dedizierte, IPsec-verschlüsselte OAM-Tunnel vor Ort die sichere Weiterleitung von Management-, Routing- und Protokollierungs-Datenverkehrs an einen Provider-Hub. Der Provider Hub leitet den Datenverkehr dann an CSO weiter.
- Integration mit Bereitstellungstopologien
- OAM Hub-Designoptionen
- Nutzungshinweise zu Designoptionen für Provider-Hubs
Integration mit Bereitstellungstopologien
Sowohl die Hub-and-Spoke- als auch die dynamische Mesh-Bereitstellungstopologien müssen sichere OAM-Tunnel verwenden.
Hub-and-Spoke
Mit der Hub-and-Spoke-Topologie verfügt jeder Spoke-Standort jetzt über zwei Verbindungen zum Provider-Hub-Standort: einen Overlay-Tunnel, der Daten enthält, und einen separaten, dedizierten IPsec-Overlay-Tunnel, der OAM-Datenverkehr trägt, wie in Abbildung 10 dargestellt.
Dynamisches Mesh
Da eine normale Full-Mesh-Topologie kein Hub-Gerät für den Datenverkehr enthalten würde, muss eines hinzugefügt werden. Wie in Abbildung 11 dargestellt, verfügt jeder Spoke-Standort über eine neue Verbindung: einen separaten, dedizierten IPsec-Overlay-Tunnel, der OAM-Datenverkehr zum Provider-Hub führt.
OAM Hub-Designoptionen
Je nach Designanforderungen gibt es zwei Möglichkeiten, den OAM-Hub in einer lokalen CSO-Bereitstellung zu implementieren. Wie in Abbildung 12 dargestellt, gibt es folgende Optionen:
Daten- und OAM-Tunnel enden auf einem Hub-Gerät desselben Anbieters– Dies ist eine gute Option für kleine Bereitstellungen, bei denen das einzelne Hub-Gerät sowohl den Daten- als auch den OAM-Datenverkehr bewältigen kann.
Daten- und OAM-Tunnel enden auf separaten Provider-Hub-Geräten– Diese Option kann für größere Bereitstellungen nützlich sein, bei denen die Ressourcen des Haupt-Hub-Geräts benötigt werden, um die Overlay-Tunnel, die den Datenverkehr übertragen, zu warten. ein zweites Hub-Gerät kann verwendet werden, um die OAM-Tunnel zu beenden.
Abbildung 12: OAM-Tunnel – Designoptionen für
Provider-Hubs
Für CSOaaS wird der OAM-Hub als Teil des Service bereitgestellt.
Ein OpCo-Administrator kann jedoch einen DATA_ONLY oder einen OAM_AND_DATA Hub bereitstellen. Im Fall eines DATA_ONLY Hubs verfügt der DATA-Hub über einen IPsec-gesicherten Tunnel zum OAM_HUB. Im Fall eines OAM_AND_DATA Hubs muss der OpCo-Administrator die IPsec-gesicherte Verbindung zwischen dem OAM_AND_DATA HUB und CSO einrichten.
Nutzungshinweise zu Designoptionen für Provider-Hubs
Ein OAM-Hub kann mehrere Mandanten unterstützen oder einem einzelnen Mandanten zugeordnet werden.
Die Konnektivität von den Provider-Hubs zu CSO sollte privat und gesichert sein, da sie nicht von den OAM-Tunneln abgedeckt wird.
Wir empfehlen, mehrere OAM-Hubs zu implementieren, um Redundanz zu gewährleisten und sicherzustellen, dass die Verwaltung oder Überwachung der lokalen Geräte nicht verloren geht.
Für CSOaaS ist die OAM-Hub-Redundanz Teil des Service.
Wenn ein Spoke-Standort auf mehrere Hub-Geräte verteilt ist, sollte auf jedem Hub ein OAM-Tunnel enden.
Lokale Geräte, die NAT verwenden, werden für Hub-and-Spoke-Bereitstellungen unterstützt.
Vollständig automatisierte Bereitstellung
Eine der wichtigsten Merkmale der Contrail SD-WAN-Lösung ist die Möglichkeit, neue Spoke-Geräte mithilfe von ZTP (Autoinstallation) "plug-and-play" zu nutzen. Im Folgenden ist eine Allgemeine Liste der Schritte, die während der ZTP durchgeführt werden:
Wenn Sie die lokale Version von CSO implementieren, müssen Sie das entsprechende CSO-SSL-Zertifikat zum Umleitungsserver hinzufügen, bevor Sie ZTP durchführen.
Hinweis:Wenn Sie die Cloud-basierte Version von CSO bereitstellen, konfiguriert Juniper Networks den Umleitungsserver für Sie.
Wenn ein Spoke-Gerät zum ersten Mal online ist, verwendet es einen lokalen DHCP-Server, um eine IP-Adresse und Namensserverinformationen zu erhalten.
Das Spoke-Gerät kontaktiert dann den Umleitungsserver, der den DNS-Namen und das Zertifikat für die CSO-Installation bereitstellt.
Das Spoke-Gerät kontaktiert dann den CSO-Server, um seine Erstkonfiguration und (falls erforderlich) Junos OS-Softwareupdate zu erhalten.
CSO Version 4.1 und höher enthält Verbesserungen, die die für ZTP erforderliche Bandbreite auf 2 Mbit/s reduzieren.
Nutzungshinweise für ZTP
Mindestens einer der WAN-Schnittstellen des Geräts muss seine IP-Adresse von einem DHCP-Server abrufen, um auch einem DNS-Namenserver und einer Standardroute zugewiesen zu werden.
Sowohl CSO als auch der Weiterleitungsserver müssen über dieselbe WAN-Schnittstelle erreichbar sein.
Der ZTP-Prozess kann von jeder WAN-Schnittstelle auf dem Spoke-Gerät ausgeführt werden, einschließlich einer Satellitenverbindung.
Der Download der Erstkonfiguration kann aufgrund der Größe der Konfiguration und der Junos OS-Software erhebliche Zeit in Anspruch bringen, insbesondere bei langsamen Verbindungen.
Umleitungsserver
Der Umleitungsserver ist ein im Internet ansässiger, im Besitz von Juniper befindlicher und verwalteter Server, der für den ZTP-Prozess unerlässlich ist. Der Server ermöglicht jedem Spoke-Gerät die Ortung und Authentifizierung mit seiner designierten CSO-Instanz. Mit Hilfe des Umleitungsservers kann das Spoke-Gerät CSO kontaktieren und seine ursprüngliche Konfiguration erhalten, einschließlich eines Junos OS-Softwareupdates (falls erforderlich).
Für on-Premises-Bereitstellungen von CSO konfiguriert der Administrator WAN-Ports auf den Spoke-Geräten für eine Verbindung mit dem Internet und dem Umleitungsserver. Für Cloud-basierte CSO übernimmt Juniper Networks diese Konfiguration für Sie.
In Abbildung 13 befinden sich sowohl der Umleitungsserver als auch CSO im Internet. Das Spoke-Gerät erhält und verwendet IP-Adressierung und andere Informationen, die über seine Internetschnittstelle bereitgestellt werden, und kann sowohl den Umleitungsserver als auch den CSO über dieselbe WAN-Schnittstelle erreichen.
Serviceverkettung in Contrail SD-WAN
Ab CSO-Version 4.0 ist Serviceverkettung für SD-WAN-Umgebungen verfügbar. Serviceverkettung ist ein Konzept, bei dem mehrere Netzwerkservices, die in Software instanziiert und auf x86-Hardware ausgeführt werden, durchgängig miteinander verknüpft oder verkettet werden. Auf diese Weise kann ein physisches Gerät die Services bereitstellen, die normalerweise von mehreren Geräten bereitgestellt werden. Serviceverkettung kann auf Geräten der NFX-Serie durchgeführt werden, wie in Abbildung 14 dargestellt.
Ab CSO-Version 4.0 werden die folgenden virtuellen Netzwerkfunktionen (VNFs) von Drittanbietern unterstützt: Fortigate-VM und Single-Legged Ubuntu VM.
Derzeit wird in SD-WAN-Serviceketten nur der Layer-2-VNF-Modus unterstützt.
Drei Ebenen, vier Ebenen
Um alle oben genannten Elemente zusammenzuführen, kann die Contrail SD-WAN-Architektur in drei Ebenen betrachtet werden, die aus vier Funktionsschichten bestehen:
Data Plane:
Umfasst das Underlay-Netzwerk; bietet physische Konnektivität
Umfasst das Overlay-Netzwerk; bietet Tunnel für Mandantendatenverkehr
Steuerungsebene – Umfasst die Routing-Protokolle, die durch die OAM-Tunnel fließen
Management Plane – Umfasst die Overlay-Tunnel für das sichere OAM-Netzwerk
Abbildung 15 veranschaulicht dieses Konzept.
