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 dargestellt, umfasst eine grundlegende SD-WAN-Architektur nur einige grundlegende Elemente
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 Orchestrierungsschicht und stellt eine Schnittstelle bereit, über die der Betreiber die Geräte an den Standorten einrichten und verwalten kann.
Contrail SD-WAN Referenzarchitektur
Die Contrail SD-WAN-Lösungsarchitektur von Juniper Networks (siehe Abbildung 2 ) verwendet eine Hub-and-Spoke-Topologie mit CPE-Geräten, die sich in den Zweigstellen des Kunden befinden. Auf der lokalen Seite des Standorts stellen die CPE-Geräte eine Verbindung zu LAN-Segmenten her und nehmen an dynamischen Routing-Protokollen mit anderen LAN-Geräten teil. Auf der WAN-Seite stellen die CPE-Geräte über zwei oder mehr Links eine Verbindung zu einem Provider-Hub-Gerät her. Da das SD-WAN-Modell eine Hub-and-Spoke-Topologie verwendet, fließt der Datenverkehr über den Provider-Hub von Standort zu Standort. Standardmäßig fließt der Datenverkehr, der an das Internet geht, auch über das Provider-Hub-Gerät.
Der SD-WAN-Orchestrator und die Controller-Funktionen werden über die Contrail Service Orchestration (CSO)-Software von Juniper Networks implementiert. Die CSO-Plattform verwendet Richtlinien und SLA-Parameter, um den Datenverkehr zu differenzieren und wie gewünscht über die verfügbaren Pfade 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 stellt die Konnektivität von der Zweigstelle zu anderen Standorten im Mandantennetzwerk und zum Internet bereit. Es gibt zwei Arten von Spoke-Geräten: lokale Spoke-Geräte und Cloud-Spoke-Geräte.
Lokale Spoke-Geräte
Bei lokalen Spoke-Geräten kann es sich entweder um Geräte der NFX-Serie oder um bestimmte Firewalls der SRX-Serie handeln.
Netzwerkserviceplattform der NFX-Serie
Eine Netzwerkserviceplattform der NFX-Serie, die als lokales Spoke-Gerät verwendet wird, kann eine Reihe von VNFs verschiedener Hersteller hosten, Serviceverkettungen unterstützen und von einer Orchestrierungssoftware in der Cloud verwaltet werden. Die Geräte der NFX-Serie machen die Bereitstellung mehrerer physischer Netzwerkgeräte am Kundenstandort überflüssig und bieten eine wesentliche Verbesserung gegenüber herkömmlichen CPE-Geräten mit nur einer Funktion.
Eine wichtige VNF, die auf der Plattform der NFX-Serie unterstützt wird, ist die virtuelle Firewall virtuelle Firewall vSRX. In der Contrail SD-WAN-Lösung übernimmt die virtuelle Firewall vSRX-Instanz mit Routing- und Switching-Funktionen die Gateway-Router-Funktion. Sie bietet auch die gleichen funktionsreichen Sicherheitsservices wie Standard-Firewalls der SRX-Serie. Tabelle 1 zeigt die Hardware der NFX-Serie, die Sie als lokales Spoke-Gerät implementieren können.
Die NFX150 verfügt über eine integrierte SRX-Firewall anstelle der Virtuelle Firewall vSRX Funktionen anderer NFX-Serie Geräte.
Bahnsteig |
Unterstützte Modelle |
|---|---|
Netzwerkserviceplattform NFX150 |
|
Netzwerkserviceplattform NFX250 |
|
Geräte der SRX-Serie und virtuelle Firewall virtuelle Firewall vSRX
Anstelle der Plattform der NFX-Serie kann ein physisches Sicherheitsgerät der SRX-Serie verwendet werden, um die Gateway-Router-Funktion bereitzustellen, ebenso wie eine auf einem Server installierte virtuelle Firewall vSRX-Instanz. Tabelle 2 zeigt die SRX-Hardware und die virtuellen Firewalls der Virtuelle Firewall vSRX, die Sie als lokale Spoke-Geräte implementieren können.
Bahnsteig |
Unterstützte Modelle |
|---|---|
SRX-Serie |
|
Virtuelle Firewall vSRX Virtuelle Firewalls |
Virtuelle Firewall vSRX Virtuelle Firewall 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 virtuellen Firewall vSRX kann sich in einer AWS-VPC befinden. Die Virtuelle Firewall vSRX dient als Spoke-Gerät in der Cloud. Sobald der Endpunkt online geschaltet wird, verhält er 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 Resilienz und hohe Verfügbarkeit. des Contrail SD-WAN Design and Architecture Guide.
Provider-Hub-Geräte
Die Contrail SD-WAN-Lösung unterstützt zwei Bereitstellungstopologien (weiter unten in diesem Leitfaden beschrieben): dynamisches Mesh und Hub-and-Spoke. In einer dynamischen Mesh-Bereitstellung verfügt jeder Standort über ein CPE-Gerät, das eine Verbindung mit den anderen Standorten und dem Enterprise Hub-Gerät herstellt. In einer Hub-and-Spoke-Bereitstellung gibt es mindestens ein Provider-Hub-Gerät 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-Umgebung (Service Provider, SP) hostet der Service Provider ein Provider-Hub-Gerät in seinem Netzwerk. Das Provider-Hub-Gerät fungiert als Point of Presence (POP) oder Verbindungspunkt. In der Regel handelt es sich um ein gemeinsam genutztes Gerät, das mehreren Kunden (Mandanten) mithilfe von virtuellen Routing- und Weiterleitungsinstanzen (VRF) Hub-Funktionen bietet. Sowohl der SP-Administrator als auch der OpCo-Administrator können das Provider-Hub-Gerät verwalten.Bei CSOaaS wird die Rolle des SP-Administrators von Juniper Networks als Benutzer cspadmin (oder einem gleichwertigen Benutzer) 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 |
|---|---|
Anbieter-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 verwendet werden, um vor Geräte- und Verbindungsausfällen zu schützen und vorgeschaltetes Multihoming für Spoke-Standorte bereitzustellen. Weitere Informationen finden Sie im Thema Resilienz und hohe Verfügbarkeit in diesem Handbuch.
Enterprise Hub-Standorte und -Geräte
Ein spezieller Typ von Spoke-Gerät, der als Enterprise Hub-Gerät bezeichnet wird, kann als CPE an einem lokalen Spoke-Standort bereitgestellt werden. SRX1500, SRX4100 und SRX4200 Geräte können diese Funktion erfüllen. Die Spoke-Site, die auf diese Weise funktioniert, muss während der Site-Erstellung als Enterprise Hub-Site konfiguriert werden. Durch das Erstellen einer Enterprise Hub-Website werden zusätzliche Funktionen für die Website geöffnet:
Kann als Ankerpunkt für die Kommunikation zwischen Standorten im Netzwerk des Kunden dienen.
Kann als zentraler Breakout-Knoten für das Netzwerk des Kunden dienen.
Bietet eine spezialisierte Abteilung, die Datencenter-Abteilung.
Unterstützt dynamische LAN-Segmente in Datencentern mit BGP- und OSPF-Routenimporten, einschließlich Standardrouten, vom LAN-seitigen Layer-3-Gerät.
Ermöglicht absichtsbasierte Breakout-Profile zur Erstellung eines granularen Breakout-Verhaltens basierend auf Abteilung, Anwendung, Standort usw.
In einer Unternehmensumgebung ist der Unternehmens-Hub im Besitz des Kunden (Mandanten) und befindet sich in der Regel in einem Unternehmens-Datencenter. Nur die Spoke-Standorte des Kunden können eine Verbindung mit dem Enterprise Hub-Gerät herstellen. OpCo-Administratoren und Mandantenadministratoren können den Enterprise Hub verwalten. Tabelle 4 listet die Enterprise-Hub-Geräte auf, die in einer CSO SD-WAN-Umgebung unterstützt werden.
Rolle |
Unterstützte Gerätetypen |
|---|---|
Unternehmens-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 Netzwerkschicht kennt die LAN-Segmente des Kunden nicht, sondern sorgt lediglich für die Erreichbarkeit zwischen lokalen Geräten.
Abbildung 3 zeigt ein Beispiel für ein Underlay-Netzwerk für eine Hub-and-Spoke-SD-WAN-Bereitstellung (die Details gelten gleichermaßen für ein dynamisches Mesh-Setup). Jeder Spoke-Standort verfügt in der Regel über mehrere Pfade zum Hub-Standort. in diesem Fall eine über die private MPLS-Cloud und eine über das Internet.
Jedes lokale Gerät (oder jeder Standort) kann über bis zu vier WAN-Verbindungen verfügen, einschließlich einer Satellitenverbindung, die für OAM verwendet werden kann. Während der Konfiguration identifiziert CSO die WAN-seitigen Schnittstellen der Geräte als WAN_0 über WAN_3.
Beachten Sie, dass:
Die WAN-Schnittstellen können je nach Designanforderungen mit VLAN-Tags versehen oder nicht getaggt werden.
Die mit dem Internet verbundenen Schnittstellen der lokalen Geräte können an verschiedene Service Provider-Netzwerke 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
Anmerkung:LTE-WAN-Zugang, der mit einem Dongle auf Geräten der NFX250-Serie unterstützt wird.
LTE-WAN-Zugang, der über eine integrierte Schnittstelle auf Geräten der NFX150-Serie unterstützt wird.
LTE-WAN-Zugang, der über ein Mini-PIM in Steckplatz 1 von Geräten der SRX300-Serie unterstützt wird.
Alle der zuvor genannten LTE-Schnittstellen werden für ZTP unterstützt.
Wird nur für Hub-and-Spoke-SD-WAN-Bereitstellungen mit einem CPE unterstützt.
Full-Cone- und restriktive NAT-Bereitstellungen werden unterstützt.
Duale 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-Verbindungen und ZTP auf Geräten der NFX-Serie ab CSO-Version 4.0.0 und ADSL-Unterstützung für 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 in erster Linie zum Senden und Empfangen von Benutzerverkehr (Daten) verwendet. Mindestens eine der WAN-Schnittstellen muss auch für den Management-Datenverkehr (OAM) verwendet werden. Die OAM-Schnittstelle wird für die Kommunikation mit CSO verwendet und ermöglicht es CSO, das lokale Gerät zu verwalten.
Abbildung 4 veranschaulicht diese beiden Schnittstellentypen.
Beachten Sie, dass:
Die OAM-Schnittstelle des lokalen Geräts muss in der Lage sein, CSO zu erreichen. Die Konnektivität kann ausschließlich über CSO-orchestrierte Overlay-Netzwerke bereitgestellt werden. Hierfür 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. Dies stellt sicher, dass die Adresse innerhalb der gesamten CSO-Bereitstellung eindeutig ist, und verhindert menschliche Fehler.
Um eine sichere Kommunikation über das WAN zu gewährleisten, initiiert das lokale Gerät die Verbindung zum CSO.
Geräteinitiierte Verbindungen können über zwischengeschaltete NAT-Geräte hinweg 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 Netzwerkschicht kennt die LAN-Segmente des Kunden und ist für den Transport des Kundendatenverkehrs zwischen den Standorten verantwortlich.
Abbildung 5 zeigt ein Overlay-Netzwerk für eine Hub-and-Spoke-Umgebung. Jeder Spoke-Standort verfügt über zwei Tunnel für den Datenverkehr zum Hub-Standort: einen über die private MPLS-Cloud und einen über das Internet.
Die Tunnel verfügen über zwei Kapselungsoptionen: MPLSoGRE oder MPLSoGREoIPsec. CSO stellt diese Tunnel automatisch bereit und richtet sie als Teil des Bereitstellungsprozesses ein.
Overlay-Bereitstellungstopologien
Die SD-WAN-Lösung unterstützt Hub-and-Spoke- oder dynamische Mesh-Bereitstellungstopologien. Eine dynamische Mesh-Topologie ähnelt einer vollständigen Mesh-Topologie, bei der jeder Standort in der Lage ist, eine direkte Verbindung zu jedem anderen Standort herzustellen. Mit dynamischem Mesh werden die Verbindungen (Tunnel) jedoch bei Bedarf hergestellt, wodurch die kontinuierliche Belastung eines Standorts reduziert wird. Ein einzelner Mandant kann sowohl Hub-and-Spoke- als auch dynamische Mesh-Topologien unterstützen.
Hub and Spoke
Bei der Hub-and-Spoke-Topologie sind alle Spoke-Standorte mit mindestens einem Hub-Standort verbunden, wie in Abbildung 6 dargestellt. Spoke-Sites können nicht direkt mit anderen Spoke-Sites kommunizieren.
Bei den verwendeten Hub-Websites kann es sich entweder um Provider-Hub- oder Enterprise-Hub-Standorte handeln. Wenn ein Unternehmenshubstandort verwendet wird, wird der Anbieterhub (sofern vorhanden) nur als Sicherung verwendet. Diese Topologie wird bevorzugt, wenn Anwendungen und Dienste am Hub-Standort zentralisiert sind.
Dynamic Mesh
Bei der dynamischen Mesh-Topologie ermöglichen Overlay-Tunnel zwischen den teilnehmenden Standorten die direkte Kommunikation miteinander, wie in Abbildung 7 dargestellt. Obwohl die Abbildung die DATA_AND_OAM Verbindung auf der MPLS-Verbindung zeigt, kann diese Funktion WAN_0 entweder auf der MPLS- oder auf der Internetverbindung ausgeführt werden.
von SD-WAN
Diese Topologie eignet sich gut für Bereitstellungen, in denen Anwendungen und Dienste 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 zur Bereitstellung.
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 übereinstimmenden Mesh-Tags können die VPN-Verbindung bilden, um die Kommunikation zu ermöglichen. Schnittstellen mit nicht übereinstimmenden Mesh-Tags können niemals direkt kommunizieren.
Orchestrierung und Steuerung
Orchestrierungs- und Controller-Funktionen werden über die Software Contrail Service Orchestration (CSO) von Juniper implementiert. Wie in Abbildung 8 dargestellt, bietet CSO-Software eine webbasierte Benutzeroberfläche für die Verwaltung der SD-WAN-Umgebung. Abbildung 8 ist ein Beispielbild, und die CSO-Versionsnummer dient nur als Referenz.
Die Serviceorchestrierungsschicht enthält den Network Service Orchestrator (NSO). Die Orchestrierungssoftware verfügt über eine globale Ansicht aller Ressourcen und ermöglicht Mandantenverwaltung, indem sie End-to-End-Datenverkehrsorchestrierung, Visibilität und Überwachung bietet. Die Domänenorchestrierungsschicht enthält den Network Service Controller (NSC). Die Orchestrierungssoftware arbeitet mit dem Controller zusammen, um lokale Geräte (CPE) zu verwalten und Topologie- und CPE-Lebenszyklusmanagementfunktionen bereitzustellen.
Auf Benutzerebene stellt CSO die Schnittstelle zur Bereitstellung, Verwaltung und Überwachung der Geräte im SD-WAN-Netzwerk über den NSC bereit. Auf Netzwerkebene umfasst NSC einen vRR, mit dem jeder Standort seine lokalen Routen zu Remote-Standorten ankündigen kann.
Sicheres OAM-Netzwerk
SD-WAN-Bereitstellungen umfassen ein sicheres OAM-Overlay-Netzwerk zur Bereitstellung einer durchgängigen sicheren Kommunikation zwischen lokalen Geräten und CSO. Bei CSOaaS wird dies automatisch als Teil des Service bereitgestellt.
Wie in Abbildung 9 dargestellt, ermöglichen dedizierte, IPsec-verschlüsselte OAM-Tunnel es lokalen Geräten, Verwaltungs-, Routing- und Protokollierungsdatenverkehr sicher über das Netzwerk an einen Provider-Hub zu senden. Der Provider-Hub leitet den Datenverkehr dann an CSO weiter.
- Integration mit Bereitstellungstopologien
- OAM-Hub-Designoptionen
- Nutzungshinweise zu den Entwurfsoptionen für Provider Hub
Integration mit Bereitstellungstopologien
Sowohl die Hub-and-Spoke- als auch die Dynamic Mesh-Bereitstellungstopologien müssen sichere OAM-Tunnel verwenden.
Hub-and-Spoke
Mit der Hub-and-Spoke-Topologie verfügt jeder Spoke-Standort nun über zwei Arten von Verbindungen zum Provider-Hub-Standort: einen Overlay-Tunnel, der Daten überträgt, und einen separaten, dedizierten IPsec-Overlay-Tunnel, der OAM-Datenverkehr transportiert (siehe Abbildung 10).
Dynamisches Netz
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 überträgt.
OAM-Hub-Designoptionen
Es gibt zwei Möglichkeiten, den OAM-Hub in einer lokalen CSO-Bereitstellung zu implementieren, abhängig von den Entwurfsanforderungen. Wie in Abbildung 12 dargestellt, stehen die Optionen wie folgt zur Verfügung:
Daten- und OAM-Tunnel enden auf demselben Provider-Hub-Gerät—Dies ist eine gute Option für kleine Bereitstellungen, bei denen ein einzelnes 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 zu bedienen, die den Datenverkehr übertragen. Ein zweites Hub-Gerät kann zum Beenden der OAM-Tunnel verwendet werden.
Abbildung 12: OAM-Tunnel – Entwurfsoptionen
für Provider Hub
Bei 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 Falle eines DATA_ONLY-Hubs verfügt der DATA-Hub über einen IPsec-gesicherten Tunnel zum OAM_HUB. Im Falle eines OAM_AND_DATA-Hubs muss der OpCo-Administrator die IPsec-gesicherte Verbindung zwischen dem OAM_AND_DATA HUB und CSO einrichten.
Nutzungshinweise zu den Entwurfsoptionen für Provider Hub
Ein OAM-Hub kann mehrere Mandanten unterstützen oder für einen einzelnen Mandanten dediziert sein.
Die Konnektivität von dem/den Provider-Hub(s) zu CSO sollte privat und sicher sein, da sie nicht von den OAM-Tunneln abgedeckt wird.
Es wird empfohlen, mehrere OAM-Hubs zu implementieren, um Redundanz zu gewährleisten und sicherzustellen, dass die Verwaltung oder Überwachung der lokalen Geräte nicht beeinträchtigt wird.
Bei CSOaaS ist die OAM-Hub-Redundanz Teil des Services.
Wenn eine Spoke-Site mit mehreren Hub-Geräten vernetzt ist, sollte ein OAM-Tunnel auf jedem Hub beendet werden.
Lokale Geräte, die NAT verwenden, werden für Hub-and-Spoke-Bereitstellungen unterstützt.
Vollständig automatisierte Bereitstellung
Eines der Hauptmerkmale der Contrail SD-WAN-Lösung ist die Möglichkeit, neue Spoke-Geräte mithilfe von ZTP (Autoinstallation) "plug-and-play" zu installieren. Im Folgenden finden Sie eine allgemeine Liste der Schritte, die während des ZTP ausgeführt werden:
Wenn Sie die lokale Version von CSO implementieren, müssen Sie dem Umleitungsserver das entsprechende CSO-SSL-Zertifikat hinzufügen, bevor Sie ZTP ausführen.
Anmerkung:Wenn Sie die in der Cloud bereitgestellte Version von CSO bereitstellen, konfiguriert Juniper Networks den Umleitungsserver für Sie.
Wenn ein Spoke-Gerät zum ersten Mal online geschaltet wird, verwendet es einen lokalen DHCP-Server, um eine IP-Adresse und Nameserverinformationen abzurufen.
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 die Erstkonfiguration und (falls erforderlich) ein Softwareupdate für Junos OS zu erhalten.
CSO Version 4.1 und höher enthält Verbesserungen, die die für ZTP erforderliche Bandbreite auf 2 Mbit/s reduzieren.
Hinweise zur Verwendung von ZTP
Mindestens eine der WAN-Schnittstellen des Gerätes muss ihre IP-Adresse von einem DHCP-Server beziehen, um auch einen DNS-Nameserver und eine Standardroute zugewiesen zu bekommen.
Sowohl CSO als auch der Umleitungsserver müssen über dieselbe WAN-Schnittstelle erreichbar sein.
Der ZTP-Prozess kann von jeder WAN-Schnittstelle auf dem Spoke-Gerät aus ausgeführt werden, einschließlich einer Satellitenverbindung.
Das Herunterladen der Erstkonfiguration kann aufgrund des Umfangs der Konfiguration und der Junos OS-Software viel Zeit in Anspruch nehmen, insbesondere bei langsamen Verbindungen.
Redirect-Server
Der Umleitungsserver ist ein im Internet befindlicher, im Besitz von Juniper verwalteter Server, der integraler Bestandteil des ZTP-Prozesses ist. Der Server ermöglicht es jedem Spoke-Gerät, die ihm zugewiesene CSO-Instanz zu finden und sich bei ihr zu authentifizieren. Mit Hilfe des Redirect-Servers kann das Spoke-Gerät Kontakt mit CSO aufnehmen und seine Erstkonfiguration erhalten, einschließlich eines Junos OS-Software-Updates (falls erforderlich).
Bei lokalen Bereitstellungen von CSO konfiguriert der Administrator WAN-Ports auf den Spoke-Geräten, um eine Verbindung sowohl mit dem Internet als auch mit dem Umleitungsserver herzustellen. Bei über die Cloud bereitgestellten CSO übernimmt Juniper Networks diese Konfiguration für Sie.
In Abbildung 13 befinden sich sowohl der Umleitungsserver als auch das CSO im Internet. Das Spoke-Gerät erfasst und verwendet IP-Adressen 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 die Dienstverkettung für SD-WAN-Umgebungen verfügbar. Dienstverkettung ist ein Konzept, bei dem mehrere Netzwerkservices, die in Software instanziiert sind und auf x86-Hardware ausgeführt werden, in einer End-to-End-Weise miteinander verbunden oder verkettet sind. Auf diese Weise kann das eine physische Gerät die Dienste bereitstellen, die normalerweise von mehreren Geräten bereitgestellt werden. Eine Dienstverkettung 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 Schichten
Um alle oben genannten Elemente zusammenzuführen, kann die Contrail SD-WAN-Architektur in drei Ebenen unterteilt werden, die aus vier Funktionsebenen bestehen:
Data Plane:
Umfasst das Underlay-Netzwerk; Bietet physische Konnektivität
Umfasst das Overlay-Netzwerk; Bietet Tunnel für den Datenverkehr der Mandanten
Control Plane: 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.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.