Überblick über die Collapsed Spine-Architektur mit EVPN Multihoming
Informationen zu diesem Netzwerkkonfigurationsbeispiel
Dieses Netzwerkkonfigurationsbeispiel (NCE) zeigt, wie Sie eine Collapsed Spine-Datencenter-Fabric einrichten, die es Ihnen ermöglicht, Ihre vorhandenen Layer 2-Top-of-Rack-Switches anstelle von Leaf-Geräten zu verwenden. Außerdem wird gezeigt, wie EVPN Multihoming verwendet werden kann, um Multichassis-LAG-Funktionalität für Layer 2-Top-of-Rack-Switches bereitzustellen.
Darüber hinaus wird optional gezeigt, wie Sie die Vernetzung von Datencentern und erweiterte Sicherheitsservices für mandantenübergreifenden Datenverkehr über ein SRX-Chassis-Cluster einrichten.
Juniper Networks benötigt eine Lizenz für EVPN-VXLAN auf Switches der QFX-Serie. Weitere Informationen finden Sie im Lizenzierungshandbuch .
Siehe auch
Überblick über Anwendungsfälle
Die Datencenter großer Unternehmen migrieren auf Overlay-basierte Architekturen mit einer End-to-End-IP-Fabric mit einem VXLAN-Overlay und einer EVPN-Steuerungsebene. Mit einem IP-basierten Layer-3-Underlay im Core in Verbindung mit einem EVPN-VXLAN-Overlay auf den Top-of-Rack (ToR)-Switches können Datencenter- und Cloud-Betreiber viel größere Netzwerke bereitstellen, als dies mit herkömmlichen Ethernet-basierten Layer-2-Architekturen möglich ist.
Ältere ToR-Switches unterstützen EVPN-VXLAN jedoch möglicherweise nicht. In Datencentern mit diesen ToR-Switches, die nur Layer-2-Datenverkehr unterstützen, sind die Spine-Switches für das Routing zwischen den VLANs verantwortlich. Es wird eine Datencenter-Architektur benötigt, die mit Technologien wie VXLAN das Underlay-Netzwerk vom Tenant-Overlay-Netzwerk entkoppelt. Dies lässt sich mit einer Collapsed Spine-Architektur erreichen.
Eine Collapsed Spine-Architektur hat keine Blattschicht. Stattdessen werden das IP-basierte Layer-3-Underlay und die EVPN-VXLAN-Overlay-Funktionalität, die normalerweise auf Leaf-Switches ausgeführt werden, auf die Spine-Switches reduziert. Die Spine-Switches fungieren auch als Border Gateway.
Eine Collapsed Spine-Architektur mit EVPN Multihoming ist ideal für Unternehmen mit:
plant den Wechsel zu einer IP-Fabric-basierten Architektur mit EVPN-VXLAN-Overlay.
Kleine Datencenter mit überwiegend Nord-Süd-Datenverkehr.
Es besteht die Notwendigkeit, den Layer-2-Datenverkehr über Datencenter hinweg auszuweiten.
Ältere ToR-Switches mehrerer Hersteller, die EVPN-VXLAN nicht unterstützen
Aktuelle oder zukünftige Anforderungen an die Unterstützung von mehr als zwei Spine-Switches, um eine ausreichende Bandbreite während Wartungsarbeiten oder bei einem Spine-Ausfall zu gewährleisten.
Bedarf an einer Alternative zu einer MC-LAG-ARCHITEKTUR (ICCP-Protokoll).
Technische Übersicht
- Collapsed Spine mit EVPN Multihoming-Architektur – Übersicht
- Collapsed Spine-Architektur verstehen
- EVPN Multihoming verstehen
- VXLAN verstehen
- EVPN verstehen
- Overlay-Netzwerk
- Underlay-Netzwerk
- Top-of-Rack-Switches
- Diener
- SRX-Gehäuse-Cluster
Collapsed Spine mit EVPN Multihoming-Architektur – Übersicht
Diese NCE zeigt, wie eine Collapsed Spine-Architektur für zwei Datencenter bereitgestellt wird, in denen jeweils zwei QFX5120 Spine-Switches und zwei Layer 2 ToR-Switches als Virtual Chassis bereitgestellt werden. Die Datencenter sind über Spine-Geräte mit Layer 3 Data Center Interconnect (DCI) miteinander verbunden. Verwenden Sie EVPN-Multihoming, um die Inhaltsverzeichnis-Switches mit Multihome zu den Spine-Geräten zu verbinden. Die Server sind mit den ToR-Switches multivernetzt. Abbildung 1 zeigt die fertige Collapsed Spine-Architektur.
Für die Multicast-Unterstützung bieten wir:
-
Layer-3-Multicast in einem QFX5120 Collapsed-Spine-Design mit EVPN OISM mit symmetrischen Bridge-Domänen.
-
Layer-2-Multicast-IGMPv2-Snooping in EVPN-VXLAN mit:
-
EVPN-Routen mit selektivem Multicast Ethernet Tag (SMET) Typ 6
-
EVPN Join and Leave Sync (Typ 7 und Typ 8) leitet, wenn ein Multicast-Empfänger auf Layer 2 mit einer ESI-LAG multihomed zu den Collapsed Spine-Geräten verbunden ist.
-
Collapsed Spine-Architektur verstehen
In einer Collapsed Spine-Architektur fungieren die Spine-Geräte sowohl als Spine- als auch als Leaf-Geräte. Da die ToRs nur Layer 2 sind und VXLAN nicht unterstützen, fungieren sie nicht als Leaf-Geräte. Die normale Leaf-Geräteaktivität wird auf den Spine-Geräten verarbeitet oder reduziert, was bedeutet, dass VXLAN nur auf den Spine-Geräten erforderlich ist. Das Collapsed Spine fungiert als Layer-3-Gateway und verarbeitet den Datenverkehr zwischen den VXLANs über IRB-Schnittstellen.
EVPN Multihoming verstehen
In einem älteren Datencenter mit einer Collapsed-Spine-Architektur müssen die ToR-Switches mit den Spine-Switches mit Multichassis Link Aggregation Groups (MC-LAGs) verbunden werden, um die Ausfallsicherheit des Netzwerks zu verbessern. MC-LAG bietet Redundanz auf Knotenebene und Redundanz auf Link-Ebene. Traditionell verwenden Spine-Switches in diesen Datencentern das Inter-Chassis Control Protocol (ICCP), um MC-LAG-Funktionalität bereitzustellen. Allerdings MC-LAG mit ICCP:
Ist eine proprietäre Technologie.
Layer 2 kann nicht effizient zwischen Datencentern ausgebaut werden.
Unterstützt nicht mehr als zwei Spine-Switches.
EVPN bietet eine standardbasierte Multihoming-Lösung, die horizontal über zwei oder mehr Spine-Switches skaliert werden kann, um im Falle eines Spine-Ausfalls zusätzliche Ausfallsicherheit und Bandbreite zu gewährleisten. EVPN-Multihoming, auch bekannt als ESI-LAG, bietet MC-LAG-Funktionalität für die Layer 2-ToR-Switches und die Server in dieser Architektur ohne die Nachteile von ICCP-basierter MC-LAG.
Eine Collapsed Spine-Architektur, bei der die ToR-Switches mit den Spines multihomed sind, ist eine Datencenter-Architektur, die Legacy-ToR-Switches unterstützt, wenn diese EVPN-VXLAN nicht unterstützen. Abbildung 2 zeigt eine Collapsed Spine-Architektur mit zwei Spine-Schaltern der Einfachheit halber und einem als Virtual Chassis implementierten ToR-Gerät (siehe Grundlegendes zu Virtual Chassis).
Siehe auch
VXLAN verstehen
Netzwerk-Overlays erfolgen durch Kapselung des Datenverkehrs und Tunneling über ein physisches Netzwerk. Das VXLAN-Tunneling-Protokoll kapselt Layer-2-Ethernet-Frames in Layer-3-UDP-Pakete ein. VXLAN ermöglicht virtuelle Layer-2-Subnetze oder -Segmente, die sich über das zugrunde liegende physische Layer-3-Netzwerk erstrecken können.
In einem VXLAN-Overlay-Netzwerk wird jedes Layer-2-Subnetz oder -Segment eindeutig durch einen Virtual Network Identifier (VNI) identifiziert. Ein VNI segmentiert den Datenverkehr genauso wie eine VLAN-ID. Wie bei VLANs können Endgeräte im selben virtuellen Netzwerk direkt miteinander kommunizieren. Endgeräte in verschiedenen virtuellen Netzwerken erfordern ein Gerät, das VNI-übergreifendes Routing unterstützt.
Die Entität, die die VXLAN-Kapselung und -Entkapselung vornimmt, heißt VXLAN Tunnel Endpoint (VTEP). Jedem VTEP wird in der Regel eine eindeutige IP-Adresse zugewiesen.
EVPN verstehen
EVPN ist eine der Erweiterungen für BGP, die es dem Netzwerk ermöglicht, Network Layer Reachability Information (NLRI) wie Layer-2-MAC-Adressen und Layer-3-IP-Adressen zu übertragen. Diese Steuerungsebenentechnologie verwendet MP-BGP für die Verteilung von MAC- und IP-Adressendgeräten, wobei MAC-Adressen als Routen behandelt werden. EVPN lässt Geräte als VTEPs agieren, um die Erreichbarkeitsinformationen ihrer Endgeräte untereinander auszutauschen.
EVPN bietet Multipath-Forwarding und Redundanz durch ein aktiviertes Modell. Die Zugriffsschicht kann eine Verbindung zu zwei oder mehr Spine-Geräten herstellen und den Datenverkehr über alle Verbindungen weiterleiten. Wenn eine Zugriffsverbindung oder ein Spine-Gerät ausfällt, fließt der Datenverkehr von der Zugriffsebene über die verbleibenden aktiven Verbindungen zur Spine-Schicht. Für Datenverkehr in die andere Richtung aktualisieren Remote-Spine-Geräte ihre Weiterleitungstabellen, um Datenverkehr an die verbleibenden aktiven Spine-Geräte zu senden, die mit dem mehrfach vernetzten Ethernet-Segment verbunden sind.
Overlay-Netzwerk
Diese Architektur verwendet VXLAN als Kapselungsprotokoll für die Overlay-Datenebene und MP-BGP mit EVPN-Signalisierung als Protokoll der Overlay-Steuerungsebene.
Data Plane-Overlay
Diese Architektur verwendet VXLAN als Overlay-Data-Plane-Kapselungsprotokoll auf den Collapsed Spine-Switches. Ein Switch, der als Layer-2- oder Layer-3-VXLAN-Gateway fungiert, fungiert als VXLAN Tunnel Endpoint und kann Datenpakete einkapseln und entkapseln.
In einer einzelnen Datencenter-Bereitstellung mit zwei Spine-Switches wird das VXLAN-Overlay zwischen den Spine-Switches für den Datenverkehr zwischen den beiden Geräten verwendet. Wenn beispielsweise ein Single-Homed-Server mit einem der Spine-Geräte verbunden ist, überträgt das VXLAN-Overlay den Datenverkehr entweder absichtlich oder im Falle eines Verbindungsausfalls zum anderen Spine-Gerät.
Wie in der folgenden Abbildung dargestellt, ist der DHCP-Server mit Spine 1 verknüpft. Datenverkehr vom DHCP-Client wird aufgrund der Lastverteilung möglicherweise an Spine 2 gesendet. Spine 2 sendet den Datenverkehr über das VXLAN-Overlay mit Spine 1 an den DHCP-Server.
Control Plane-Overlay
MP-BGP mit EVPN-Signalisierung fungiert in diesem Beispiel als Overlay-Steuerungsebenenprotokoll. Die Spine-Switches richten IBGP-Sitzungen untereinander ein. Abbildung 4 zeigt die Topologie des Overlay-Netzwerks.
Siehe auch
Underlay-Netzwerk
In kleineren Datencentern gibt es keine Super-Spine-Schicht, sodass die Spine-Switches direkt miteinander verbunden sind. Die Spine-Switches können ein dynamisches Routing-Protokoll im Underlay verwenden. Die Hauptanforderung im Underlay-Netzwerk ist, dass alle Spine-Geräte über eine Loopback-Erreichbarkeit verfügen. Sie können jedes Layer-3-Routing-Protokoll verwenden, um Loopback-Adressen zwischen den Core- und Spine-Geräten auszutauschen.
In diesem Beispiel verwenden wir EBGP als Underlay-Routing-Protokoll zwischen den Spine-Switches. EBGP bietet Vorteile wie bessere Präfixfilterung, Traffic-Engineering und Traffic-Tagging. Abbildung 5 zeigt die Topologie des Spine-Underlay-Netzwerks.
Verwenden Sie mindestens zwei Verbindungen zwischen den Spine-Switches. Der Verlust der Konnektivität zwischen den Spine-Switches kann zu einem Split-Brain-Zustand führen. Weitere Informationen finden Sie unter Split-Brain-Zustand .
Top-of-Rack-Switches
Da die ToR-Switches nicht Teil der EVPN-VXLAN-Fabric sind und nur auf Layer 2 arbeiten, können Sie sie als Virtual Chassis implementieren. In diesem Beispiel werden die ToR-Switches als Virtual Chassis mit zwei Komponenten bereitgestellt.
Bei den Uplinks von den ToR-Switches zu den Spine-Switches handelt es sich um Layer-2-Trunk-LAG-Ports mit für den ToR-Switch relevanten VLANs. Jedes Virtual Chassis ist mithilfe von EVPN Multihoming mit zwei Spine-Switches multihomed. Abbildung 6 zeigt die Topologie eines Virtual Chassis als ToR-Gerät, das mit den beiden Spine-Geräten multivernetzt ist. Zur Redundanz und besseren Ausfallsicherheit zeigt diese Abbildung Spine-zu-ToR-Virtual Chassis-Verbindungen, die mit verschiedenen Virtual Chassis-Mitgliedern verknüpft sind, sodass das Virtual Chassis-ToR-Gerät auch dann noch erreichbar ist, wenn eines der Virtual Chassis-Mitglieder ausfällt.
Die Spine-zu-ToR-Virtual Chassis-Verbindungen in den aggregierten Multihoming-Ethernet-Verbindungen können auch Links zum selben Virtual Chassis-Mitglied enthalten, wodurch dieses Netzwerkkonfigurationsbeispiel konfiguriert ist. Abbildung 7 zeigt eine logische Ansicht der Multihoming-Topologie, die der Konfiguration in diesem Dokument entspricht.
Virtual Chassis verstehen
In diesem Beispiel implementieren wir die ToR-Switches in einem Virtual Chassis. Virtual Chassis kann mehrere eigenständige Switches in ein logisches Gerät integrieren und das logische Gerät als einzelnes Chassis verwalten. Verwenden Sie Virtual Chassis für die ToR-Switches für folgende Zwecke:
Verwalten Sie mehrere Geräte als ein einzelnes Gerät mit den gleichen oder ähnlichen Funktionen wie das eigenständige Gerät.
Erhöhen Sie die Fehlertoleranz und hohe Verfügbarkeit.
Vereinfachen Sie Ihr Netzwerk und reduzieren Sie den Netzwerkaufwand, indem Sie zulassen, dass Netzwerkgeräte mit einem ausfallsicheren logischen Gerät synchronisiert werden.
Ermöglichen Sie eine vereinfachte Layer-2-Netzwerktopologie, die Schleifenvermeidungsprotokolle wie das Spanning Tree Protocol (STP) minimiert oder eliminiert.
Stellen Sie Redundanz und Lastenverteilung für Server bereit, die über die Virtual Chassis-Mitglieder hinweg mehrfach vernetzt sind.
Virtual Chassis bietet eine zentrale Steuerungsebene und eine verteilte Datenebene für eine vereinfachte Verwaltung auf der ToR-Ebene. Die ToR-Switches verhalten sich wie Linecards auf einem einzelnen Gehäuse. Da sich das Virtual Chassis wie ein einzelnes Chassis verhält, kann es bei Servern, die mit dem Virtual Chassis verbunden sind, während Softwareupgrades der ToR-Switches zu Ausfallzeiten kommen.
Siehe auch
Diener
Die Datencenter-Server in diesem Beispiel sind mit den ToR-Switches multihomed, die als Virtual Chassis bereitgestellt werden. Die Serverkonnektivität kann über die beiden ToR-Switches mit LAG verteilt werden.
SRX-Gehäuse-Cluster
In diesem Beispiel stellen wir SRX-Sicherheitsgeräte in einem Gehäuse-Cluster bereit, der mit den Spine-Geräten verbunden ist, um erweiterte Sicherheit zu bieten. In einem Gehäuse-Cluster arbeiten zwei Firewalls der SRX-Serie als ein einziges Gerät zusammen, um Geräte-, Schnittstellen- und Servicelevel-Redundanz bereitzustellen. Konfigurationsdateien und die dynamischen Laufzeitsitzungszustände werden zwischen Firewalls der SRX-Serie in einem Chassis-Cluster synchronisiert. Verwenden Sie ein SRX-Chassis-Cluster für Folgendes:
Verhindern Sie den Ausfall einzelner Geräte, der zu einem Verlust der Konnektivität führt.
Sorgen Sie für hohe Verfügbarkeit zwischen Sicherheitsgeräten bei der Verbindung von Zweigstellen- und Remote-Standortverbindungen zu größeren Unternehmensniederlassungen.
Stellen Sie die Konnektivität im Falle eines Geräte- oder Verbindungsausfalls sicher.
des SRX-Chassis-Clusters