Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Komponenten der Datencenter-Fabric-Blueprint-Architektur

Dieser Abschnitt gibt einen Überblick über die Bausteine, die in dieser Blaupausenarchitektur verwendet werden. Die Implementierung der einzelnen Bausteintechnologien wird in späteren Abschnitten ausführlicher behandelt.

Informationen zu der Hardware und Software, die als Grundlage für Ihre Bausteine dienen, finden Sie in der Zusammenfassung der Datencenter-EVPN-VXLAN-Fabric-Referenzdesigns – Unterstützte Hardware.

Zu den Bausteinen gehören:

IP-Fabric-Underlay-Netzwerk

Der moderne IP-Fabric-Underlay-Netzwerkbaustein bietet IP-Konnektivität über eine Clos-basierte Topologie. Juniper Networks unterstützt die folgenden IP-Fabric-Underlay-Modelle:

  • Eine 3-stufige IP-Struktur, die aus einer Reihe von Spine-Geräten und einer Reihe von Leaf-Geräten besteht. Siehe Abbildung 1.

  • Eine 5-stufige IP-Fabric, die in der Regel als eine einzelne 3-stufige IP-Fabric beginnt, die zu zwei 3-stufigen IP-Fabrics heranwächst. Diese Fabrics sind in separate Points of Delivery (PODs) innerhalb eines Datencenters segmentiert. Für diesen Anwendungsfall unterstützen wir das Hinzufügen einer Reihe von Super-Spine-Geräten, die die Kommunikation zwischen den Spine- und Leaf-Geräten in den beiden PODs ermöglichen. Siehe Abbildung 2.

  • Ein Collapsed-Spine-IP-Fabric-Modell, bei dem Leaf-Layer-Funktionen auf die Spine-Geräte reduziert werden. Diese Art von Fabric kann ähnlich wie eine 3-stufige oder eine 5-stufige IP-Fabric eingerichtet werden und betrieben werden, jedoch ohne eine separate Ebene von Leaf-Geräten. Sie können eine Collapsed Spine-Fabric verwenden, wenn Sie schrittweise zu einem EVPN-Spine-and-Leaf-Modell wechseln oder wenn Sie Zugriffsgeräte oder Top-of-Rack (TOR)-Geräte haben, die nicht in einem Leaf-Layer verwendet werden können, da sie EVPN-VXLAN nicht unterstützen.

Abbildung 1: Dreistufiges IP-Fabric-Underlay Three-Stage IP Fabric Underlay
Abbildung 2: Fünfstufiges IP-Fabric-Underlay Five-Stage IP Fabric Underlay

In diesen Abbildungen sind die Geräte über Hochgeschwindigkeitsschnittstellen miteinander verbunden, bei denen es sich entweder um einzelne Links oder um aggregierte Ethernet-Schnittstellen handelt. Die aggregierten Ethernet-Schnittstellen sind optional – in der Regel wird eine einzige Verbindung zwischen Geräten verwendet –, können aber zur Erhöhung der Bandbreite und zur Bereitstellung von Redundanz auf Verbindungsebene eingesetzt werden. Wir decken beide Optionen ab.

Wir haben uns aufgrund seiner Zuverlässigkeit und Skalierbarkeit für EBGP als Routing-Protokoll im Underlay-Netzwerk entschieden. Jedem Gerät wird ein eigenes autonomes System mit einer eindeutigen autonomen Systemnummer zur Unterstützung von EBGP zugewiesen. Sie können andere Routing-Protokolle im Underlay-Netzwerk verwenden. Die Verwendung dieser Protokolle würde den Rahmen dieses Dokuments sprengen.

Die in diesem Handbuch beschriebenen Referenzarchitekturdesigns basieren auf einer IP-Fabric, die EBGP für die Underlay-Konnektivität und IBGP für Overlay-Peering verwendet (siehe IBGP für Overlays). Alternativ können Sie das Overlay-Peering mithilfe von EBGP konfigurieren.

Ab den Junos OS-Versionen 21.2R2 und 21.4R1 unterstützen wir auch die Konfiguration einer IPv6-Fabric. Das IPv6-Fabric-Design in diesem Leitfaden verwendet EBGP sowohl für Underlay-Konnektivität als auch für Overlay-Peering (siehe EBGP für Overlays mit IPv6-Underlays).

Anmerkung:

Die IP-Fabric kann IPv4 oder IPv6 wie folgt verwenden:

  • Eine IPv4-Fabric verwendet IPv4-Schnittstellenadressierung sowie IPv4-Underlay- und Overlay-BGP-Sitzungen für eine durchgängige Workload-Kommunikation.

  • Eine IPv6-Fabric verwendet IPv6-Schnittstellenadressierung sowie IPv6-Underlay- und Overlay-BGP-Sitzungen für eine durchgängige Workload-Kommunikation.

  • Wir unterstützen keine IP-Fabric, die IPv4 und IPv6 mischt.

    Sowohl IPv4-Fabrics als auch IPv6-Fabrics unterstützen Dual-Stack-Workloads – die Workloads können entweder IPv4 oder IPv6 oder sowohl IPv4 als auch IPv6 sein.

Micro Bidirectional Forwarding Detection (BFD) – die Möglichkeit, BFD auf einzelnen Verbindungen in einer aggregierten Ethernet-Schnittstelle auszuführen – kann in diesem Baustein ebenfalls aktiviert werden, um Verbindungsfehler auf allen Mitgliedslinks in aggregierten Ethernet-Paketen, die Geräte verbinden, schnell zu erkennen.

Weitere Informationen finden Sie in den folgenden anderen Abschnitten dieses Handbuchs:

IPv4- und IPv6-Workload-Support

Da viele Netzwerke eine Dual-Stack-Umgebung für Workloads implementieren, die IPv4- und IPv6-Protokolle umfasst, bietet dieser Blueprint Unterstützung für beide Protokolle. Schritte zum Konfigurieren der Fabric für die Unterstützung von IPv4- und IPv6-Workloads sind in diesem Leitfaden miteinander verwoben, damit Sie eines oder beide dieser Protokolle auswählen können.

Anmerkung:

Das IP-Protokoll, das Sie für den Workloaddatenverkehr verwenden, ist unabhängig von der IP-Protokollversion (IPv4 oder IPv6), die Sie für das IP-Fabric-Underlay und -Overlay konfigurieren. (Siehe IP-Fabric-Underlay-Netzwerk.) Eine IPv4-Fabric oder eine IPv6-Fabric-Infrastruktur kann sowohl IPv4- als auch IPv6-Workloads unterstützen.

Overlays der Netzwerkvirtualisierung

Ein Netzwerkvirtualisierungs-Overlay ist ein virtuelles Netzwerk, das über ein IP-Underlay-Netzwerk übertragen wird. Dieser Baustein ermöglicht die Mehrfachmandantenfähigkeit in einem Netzwerk, sodass Sie ein einzelnes physisches Netzwerk über mehrere Mandanten hinweg gemeinsam nutzen können, während der Netzwerkverkehr jedes Mandanten von den anderen Mandanten isoliert bleibt.

Ein Mandant ist eine Benutzergemeinschaft (z. B. eine Geschäftseinheit, Abteilung, Arbeitsgruppe oder Anwendung), die Gruppen von Endpunkten enthält. Gruppen können mit anderen Gruppen im selben Mandanten kommunizieren, und Mandanten können mit anderen Mandanten kommunizieren, wenn dies durch Netzwerkrichtlinien zulässig ist. Eine Gruppe wird in der Regel als ein Subnetz (VLAN) ausgedrückt, das mit anderen Geräten im selben Subnetz kommunizieren und externe Gruppen und Endpunkte über eine VRF-Instanz (Virtual Routing and Forwarding) erreichen kann.

Wie im Overlay-Beispiel in Abbildung 3 zu sehen ist, verarbeiten Ethernet-Bridging-Tabellen (dargestellt durch Dreiecke) Mandanten-Bridged-Frames und IP-Routing-Tabellen (dargestellt durch Quadrate) geroutete Pakete. Das Routing zwischen VLANs erfolgt an den IRB-Schnittstellen (Integrated Routing and Bridging) (dargestellt durch Kreise). Ethernet- und IP-Tabellen werden in virtuelle Netzwerke geleitet (dargestellt durch farbige Linien). Um Endsysteme zu erreichen, die an andere VXLAN Tunnel Endpoint (VTEP)-Geräte angeschlossen sind, werden Mandantenpakete gekapselt und über einen EVPN-signalisierten VXLAN-Tunnel (dargestellt durch grüne Tunnelsymbole) an die zugehörigen Remote-VTEP-Geräte gesendet. Getunnelte Pakete werden an den entfernten VTEP-Geräten entkapselt und über die jeweiligen Bridging- oder Routing-Tabellen des ausgehenden VTEP-Geräts an die entfernten Endsysteme weitergeleitet.

Abbildung 3: VXLAN-Tunnel – Ethernet-Bridging, IP-Routing und IRB VXLAN Tunnels—Ethernet Bridging, IP Routing, and IRB

In den nächsten Abschnitten finden Sie weitere Details zu Overlay-Netzwerken.

IBGP für Overlays

Intern BGP (IBGP) ist ein Routing-Protokoll, das Erreichbarkeitsinformationen über ein IP-Netzwerk austauscht. Wenn IBGP mit Multiprotocol BGP (MP-IBGP) kombiniert wird, bietet es die Grundlage für EVPN für den Austausch von Erreichbarkeitsinformationen zwischen VTEP-Geräten. Diese Funktion ist erforderlich, um VXLAN-Tunnel zwischen VTEP einzurichten und sie für Overlay-Konnektivitätsservices zu verwenden.

Abbildung 4 zeigt, dass die Spine- und Leaf-Geräte ihre Loopback-Adressen für das Peering in einem einzigen autonomen System verwenden. Bei diesem Design fungieren die Spine-Geräte als Routenreflektor-Cluster und die Leaf-Geräte als Routenreflektor-Clients. Ein Routenreflektor erfüllt die IBGP-Anforderungen an ein vollständiges Mesh, ohne dass alle VTEP-Geräte direkt miteinander verbunden werden müssen. Infolgedessen peeren die Leaf-Geräte nur mit den Spine-Geräten und die Spine-Geräte Peering sowohl mit Spine-Geräten als auch mit Leaf-Geräten. Da die Spine-Geräte mit allen Leaf-Geräten verbunden sind, können die Spine-Geräte IBGP-Informationen zwischen den indirekt durch Peering verknüpften Leaf-Gerätenachbarn weiterleiten.

Abbildung 4: IBGP für Overlays IBGP for Overlays

Sie können Routenreflektoren fast überall im Netzwerk platzieren. Sie müssen jedoch Folgendes beachten:

  • Verfügt das ausgewählte Gerät über genügend Arbeitsspeicher und Rechenleistung, um die zusätzliche Arbeitslast zu bewältigen, die für einen Routenreflektor erforderlich ist?

  • Ist das ausgewählte Gerät von allen EVPN-Lautsprechern gleich weit entfernt und erreichbar?

  • Verfügt das ausgewählte Gerät über die richtigen Softwarefunktionen?

Bei diesem Design wird der Routenreflektorcluster auf der Spine-Schicht platziert. Die QFX-Switches, die Sie in diesem Referenzdesign als Spine verwenden können, verfügen über eine ausreichende Verarbeitungsgeschwindigkeit, um den Routenreflektor-Client-Datenverkehr im Netzwerkvirtualisierungs-Overlay zu verarbeiten.

Weitere Informationen zum Implementieren von IBGP in einem Overlay finden Sie unter Konfigurieren von IBGP für das Overlay.

EBGP für Overlays mit IPv6-Underlays

Die ursprünglichen Anwendungsszenarien für die Referenzarchitektur in diesem Leitfaden veranschaulichen ein IPv4-EBGP-Underlay-Design mit IPv4-IBGP-Overlay-Gerätekonnektivität. Weitere Informationen finden Sie unter IP-Fabric-Underlay-Netzwerk und IBGP für Overlays. Da jedoch NVE-Geräte (Network Virtualization Edge) IPv6-VTEPs einsetzen, um den erweiterten Adressierungsbereich und die erweiterten Funktionen von IPv6 zu nutzen, haben wir die IP-Fabric-Unterstützung auf IPv6 erweitert.

Ab Junos OS Version 21.2R2-S1 können Sie auf unterstützenden Plattformen alternativ eine IPv6-Fabric-Infrastruktur mit einigen Referenzarchitektur-Overlay-Designs verwenden. Das IPv6-Fabric-Design umfasst IPv6-Schnittstellenadressierung, ein IPv6-EBGP-Underlay und ein IPv6-EBGP-Overlay für die Workload-Konnektivität. Bei einer IPv6-Fabric kapseln die NVE-Geräte den VXLAN-Header in einen äußeren IPv6-Header ein und tunneln die Pakete mithilfe von IPv6-Next-Hops durch die gesamte Fabric. Die Arbeitsauslastung kann IPv4 oder IPv6 sein.

Die meisten Elemente, die Sie in den unterstützten Referenzarchitektur-Overlay-Designs konfigurieren, sind unabhängig davon, ob die Underlay- und Overlay-Infrastruktur IPv4 oder IPv6 verwendet. In den entsprechenden Konfigurationsverfahren für jedes der unterstützten Overlay-Designs werden alle Konfigurationsunterschiede angezeigt, wenn für das Underlay und Overlay das IPv6-Fabric-Design verwendet wird.

Weitere Informationen finden Sie in den folgenden Referenzen in diesem Handbuch und in anderen Ressourcen:

Überbrücktes Overlay

Der erste in diesem Handbuch beschriebene Overlay-Servicetyp ist ein Bridged-Overlay, wie in Abbildung 5 dargestellt.

Abbildung 5: Bridged Overlay Bridged Overlay

Bei diesem Overlay-Modell werden Ethernet-VLANs zwischen Leaf-Geräten über VXLAN-Tunnel erweitert. Diese Leaf-to-Leaf-VXLAN-Tunnel unterstützen Datencenter-Netzwerke, die eine Ethernet-Konnektivität zwischen Leaf-Geräten, aber kein Routing zwischen den VLANs erfordern. Infolgedessen stellen die Spine-Geräte nur grundlegende Underlay- und Overlay-Konnektivität für die Leaf-Geräte bereit und führen keine Routing- oder Gateway-Services aus, die bei anderen Overlay-Methoden üblich sind.

Leaf-Geräte erstellen VTEPs, um eine Verbindung zu den anderen Leaf-Geräten herzustellen. Die Tunnel ermöglichen es den Leaf-Geräten, VLAN-Datenverkehr an andere Leaf-Geräte und Ethernet-verbundene Endsysteme im Datencenter zu senden. Die Simplizität dieses Overlay-Services macht ihn attraktiv für Betreiber, die eine einfache Möglichkeit suchen, EVPN/VXLAN in ihr bestehendes Ethernet-basiertes Datencenter einzuführen.

Anmerkung:

Sie können einem Bridged-Overlay Routing hinzufügen, indem Sie einen Router der MX-Serie oder ein Sicherheitsgerät der SRX-Serie außerhalb der EVPN/VXLAN-Fabric implementieren. Andernfalls können Sie einen der anderen Overlay-Typen auswählen, die Routing beinhalten (z. B. ein Edge-Routing-Bridging-Overlay, ein zentral geroutetes Bridging-Overlay oder ein geroutetes Overlay).

Informationen zum Implementieren eines Bridged-Overlays finden Sie unter Bridged-Overlay-Entwurf und -Implementierung.

Zentral geroutetes Bridging Overlay

Der zweite Overlay-Servicetyp ist das CRB-Overlay (Centrally Routed Bridging), wie in Abbildung 6 dargestellt.

Abbildung 6: Zentral geroutetes Bridging-Overlay Centrally Routed Bridging Overlay

Bei einem CRB-Overlay erfolgt das Routing an einem zentralen Gateway des Datencenter-Netzwerks (in diesem Beispiel der Spine-Schicht) und nicht am VTEP-Gerät, mit dem die Endsysteme verbunden sind (in diesem Beispiel die Leaf-Schicht).

Sie können dieses Overlay-Modell verwenden, wenn gerouteter Datenverkehr über ein zentralisiertes Gateway geleitet werden soll oder wenn Ihre Edge-VTEP-Geräte nicht über die erforderlichen Routing-Funktionen verfügen.

Wie oben dargestellt, wird der Datenverkehr, der von den mit dem Ethernet verbundenen Endsystemen ausgeht, über einen Trunk (mehrere VLANs) oder einen Zugriffsport (einzelnes VLAN) an die Leaf-VTEP-Geräte weitergeleitet. Das VTEP-Gerät leitet den Datenverkehr an lokale Endsysteme oder an ein Endsystem auf einem entfernten VTEP-Gerät weiter. Eine integrierte Routing- und Bridging-Schnittstelle (IRB) an jedem Spine-Gerät hilft bei der Weiterleitung des Datenverkehrs zwischen den virtuellen Ethernet-Netzwerken.

Mit dem VLAN-fähigen Bridging-Overlay-Service-Modell können Sie auf einfache Weise eine Sammlung von VLANs in demselben virtuellen Overlay-Netzwerk aggregieren. Das EVPN-Design von Juniper Networks unterstützt drei VLAN-fähige Konfigurationen von Ethernet-Servicemodellen im Datencenter:

Edge-Routed Bridging Overlay

Die dritte Overlay-Service-Option ist das ERB-Overlay (Edge-Routed Bridging), wie in Abbildung 7 dargestellt.

Abbildung 7: Edge-Routed Bridging Overlay Edge-Routed Bridging Overlay

Bei diesem Ethernet-Service-Modell werden die IRB-Schnittstellen zu Leaf-Geräte-VTEPs am Rand des Overlay-Netzwerks verlagert, um das IP-Routing näher an die Endsysteme zu bringen. Aufgrund der speziellen ASIC-Funktionen, die zur Unterstützung von Bridging, Routing und EVPN/VXLAN in einem Gerät erforderlich sind, sind ERB-Overlays nur auf bestimmten Switches möglich. Eine Liste der Switches, die wir als Leaf-Geräte in einem ERB-Overlay unterstützen, finden Sie unter Data Center EVPN-VXLAN Fabric-Referenzdesigns – Zusammenfassung unterstützter Hardware.

Dieses Modell ermöglicht ein einfacheres Gesamtnetzwerk. Die Spine-Geräte sind so konfiguriert, dass sie nur IP-Datenverkehr verarbeiten, wodurch die Bridging-Overlays auf die Spine-Geräte nicht mehr ausgeweitet werden müssen.

Diese Option ermöglicht auch einen schnelleren Server-zu-Server-Datenverkehr innerhalb des Datencenters (auch bekannt als Ost-West-Datenverkehr), bei dem die Endsysteme mit demselben Leaf-Gerät VTEP verbunden sind. Dadurch erfolgt das Routing viel näher an den Endsystemen als bei CRB-Overlays.

Anmerkung:

Wenn Sie IRB-Schnittstellen konfigurieren, die in EVPN Typ-5-Routing-Instances auf QFX5110- oder QFX5120-Switches enthalten sind, die als Leaf-Geräte fungieren, aktiviert das Gerät automatisch symmetrisches Inter-IRB-Unicast-Routing für EVPN-Routen vom Typ 5.

Informationen zum Implementieren des ERB-Overlays finden Sie unter Entwurf und Implementierung von Edge-Routed Bridging Overlay.

Collapsed Spine Overlay

Das Overlay-Netzwerk in einer Collapsed Spine-Architektur ähnelt einem ERB-Overlay. In einer Collapsed Spine-Architektur werden die Leaf-Gerätefunktionen auf die Spine-Geräte reduziert. Da es keine Leaf-Schicht gibt, konfigurieren Sie die VTEPS- und IRB-Schnittstellen auf den Spine-Geräten, die sich wie die Leaf-Geräte in einem ERB-Modell am Edge des Overlay-Netzwerks befinden. Die Spine-Geräte können auch Border-Gateway-Funktionen ausführen, um Nord-Süd-Datenverkehr weiterzuleiten oder Layer-2-Datenverkehr über Datencenter-Standorte hinweg zu erweitern.

Eine Liste der Switches, die wir mit einer Collapsed-Spine-Architektur unterstützen, finden Sie unter Data Center EVPN-VXLAN Fabric-Referenzdesigns – Zusammenfassung unterstützter Hardware.

Vergleich von Bridged-, CRB- und ERB-Overlays

Um Ihnen bei der Entscheidung zu helfen, welcher Overlay-Typ für Ihre EVPN-Umgebung am besten geeignet ist, lesen Sie Tabelle 1.

Anmerkung:

Wir unterstützen das gleichzeitige Mischen von Bridged-Overlay-, CRB-Overlay- und ERB-Overlay-Konfigurationen auf demselben Gerät auf Geräten, die diese Overlay-Typen unterstützen. Sie müssen das Gerät nicht mit separaten logischen Systemen konfigurieren, damit das Gerät in verschiedenen Arten von Overlays parallel betrieben werden kann.

Tabelle 1: Vergleich von Bridged-, CRB- und ERB-Overlays

Vergleichspunkte

ERB-Overlay

CRB-Overlay

Überbrücktes Overlay

Vollständig verteiltes Routing zwischen Subnetzen für Mandanten

✓

Minimale Auswirkungen eines Ausfalls des IP-Gateways

✓

Dynamisches Routing zu Drittanbieterknoten auf Leaf-Ebene

✓

Optimiert für hohes Ost-West-Verkehrsaufkommen

✓

Bessere Integration mit IP-Roh-Fabrics

✓

IP-VRF-Virtualisierung näher am Server

✓

Contrail vRouter Multihoming erforderlich

✓

Einfachere Interoperabilität von EVPN mit verschiedenen Anbietern

✓

Symmetrisches Routing zwischen Subnetzen

✓

✓

VLAN-ID überlappend pro Rack

✓

✓

✓

Einfachere manuelle Konfiguration und Fehlerbehebung

✓

✓

Schnittstellen im Stil von Service Providern und Unternehmen

✓

✓

Support für Legacy-Leaf-Switches (QFX5100)

✓

✓

Zentrale Steuerung der Verkehrsoptimierung virtueller Maschinen (VMTO)

✓

IP-Mandanten-Subnetzgateway im Firewallcluster

✓

IRB-Adressierungsmodelle in Bridging-Overlays

Die Konfiguration von IRB-Schnittstellen in CRB- und ERB-Overlays erfordert ein Verständnis der Modelle für die Standard-Gateway-IP- und MAC-Adresse-Konfiguration von IRB-Schnittstellen wie folgt:

  • Unique IRB IP Address– Bei diesem Modell wird auf jeder IRB-Schnittstelle in einem Overlay-Subnetz eine eindeutige IP-Adresse konfiguriert.

    Der Vorteil einer eindeutigen IP- und MAC-Adresse auf jeder IRB-Schnittstelle besteht in der Möglichkeit, jede der IRB-Schnittstellen innerhalb des Overlays mit ihrer eindeutigen IP-Adresse zu überwachen und zu erreichen. Mit diesem Modell können Sie auch ein Routing-Protokoll auf der IRB-Schnittstelle konfigurieren.

    Der Nachteil dieses Modells besteht darin, dass die Zuweisung einer eindeutigen IP-Adresse zu jeder IRB-Schnittstelle viele IP-Adressen eines Subnetzes verbrauchen kann.

  • Unique IRB IP Address with Virtual Gateway IP Address—Dieses Modell fügt dem vorherigen Modell eine virtuelle Gateway-IP-Adresse hinzu und wird für zentral geroutete Bridged-Overlays empfohlen. Sie ähnelt VRRP, jedoch ohne die In-Band-Data-Plane-Signalübertragung zwischen den IRB-Schnittstellen des Gateways. Das virtuelle Gateway sollte für alle Standardgateway-IRB-Schnittstellen im Overlay-Subnetz identisch sein und auf allen Gateway-IRB-Schnittstellen, in denen es konfiguriert ist, aktiv sein. Sie sollten außerdem eine gemeinsame IPv4-MAC-Adresse für das virtuelle Gateway konfigurieren, die zur Quell-MAC-Adresse für Datenpakete wird, die über die IRB-Schnittstelle weitergeleitet werden.

    Zusätzlich zu den Vorteilen des Vorgängermodells vereinfacht das virtuelle Gateway die Standardkonfiguration des Gateways auf Endsystemen. Der Nachteil dieses Modells ist derselbe wie beim Vorgängermodell.

  • IRB with Anycast IP Address and MAC AddressBei diesem Modell werden alle Standard-Gateway-IRB-Schnittstellen in einem Overlay-Subnetz mit derselben IP- und MAC-Adresse konfiguriert. Wir empfehlen dieses Modell für ERB-Overlays.

    Ein Vorteil dieses Modells besteht darin, dass nur eine einzige IP-Adresse pro Subnetz für die IRB-Schnittstellenadressierung des Standardgateways erforderlich ist, wodurch die Konfiguration des Standardgateways auf Endsystemen vereinfacht wird.

Geroutetes Overlay mit EVPN-Routen Typ 5

Die letzte Overlay-Option ist ein geroutetes Overlay, wie in Abbildung 8 dargestellt.

Abbildung 8: Geroutetes Overlay Routed Overlay

Bei dieser Option handelt es sich um einen IP-gerouteten virtuellen Netzwerkdienst. Im Gegensatz zu einem MPLS-basierten IP-VPN basiert das virtuelle Netzwerk in diesem Modell auf EVPN/VXLAN.

Cloud-Anbieter bevorzugen diese Option für virtuelle Netzwerke, da die meisten modernen Anwendungen für IP optimiert sind. Da die gesamte Kommunikation zwischen Geräten auf der IP-Schicht erfolgt, müssen bei diesem gerouteten Overlay-Modell keine Ethernet-Bridging-Komponenten wie VLANs und ESIs verwendet werden.

Informationen zum Implementieren eines gerouteten Overlays finden Sie unter Entwurf und Implementierung eines gerouteten Overlays.

MAC-VRF-Instanzen für Mehrfachmandantenfähigkeit in Netzwerkvirtualisierungs-Overlays

MAC-VRF-Routing-Instanzen ermöglichen es Ihnen, mehrere EVPN-Instanzen mit unterschiedlichen Ethernet-Servicetypen auf einem Gerät zu konfigurieren, das als VTEP in einer EVPN-VXLAN-Fabric fungiert. Mithilfe von MAC-VRF-Instanzen können Sie mehrere Mandanten im Datencenter mit kundenspezifischen VRF-Tabellen verwalten, um Mandanten-Workloads zu isolieren oder zu gruppieren.

MAC-VRF-Instanzen führen zusätzlich zur vorherigen Unterstützung für den VLAN-fähigen Servicetyp auch Unterstützung für den VLAN-basierten Servicetyp ein. Siehe Abbildung 9.

Abbildung 9: MAC-VRF-Diensttypen MAC-VRF Service Types

  • VLAN-basierter Service: Sie können ein VLAN und den entsprechenden VXLAN Network Identifier (VNI) in der MAC-VRF-Instanz konfigurieren. Um ein neues VLAN und VNI bereitzustellen, müssen Sie eine neue MAC-VRF-Instanz mit dem neuen VLAN und VNI konfigurieren.

  • VLAN-fähiger Service: Sie können ein oder mehrere VLANs und die entsprechenden VNIs in derselben MAC-VRF-Instanz konfigurieren. Um ein neues VLAN und VNI bereitzustellen, können Sie die neue VLAN- und VNI-Konfiguration zur vorhandenen MAC-VRF-Instanz hinzufügen, wodurch einige Konfigurationsschritte gegenüber der Verwendung eines VLAN-basierten Services eingespart werden.

MAC-VRF-Instanzen ermöglichen flexiblere Konfigurationsoptionen sowohl auf Layer 2 als auch auf Layer 3. Zum Beispiel:

Abbildung 10: Flexible Konfigurationsoptionen auf Layer 2 und Layer 3 mit MAC-VRF-Instanzen Flexible Configuration Options at both Layer 2 and Layer 3 with MAC-VRF Instances

Abbildung 10 zeigt bei MAC-VRF-Instanzen:

  • Sie können verschiedene Diensttypen in verschiedenen MAC-VRF-Instanzen auf demselben Gerät konfigurieren.

  • Sie haben flexible Optionen für die Mandantenisolierung sowohl auf Layer 2 (MAC-VRF-Instanzen) als auch auf Layer 3 (VRF-Instanzen). Sie können eine VRF-Instanz konfigurieren, die dem VLAN oder den VLANs in einer einzelnen MAC-VRF-Instanz entspricht. Alternativ können Sie eine VRF-Instanz konfigurieren, die die VLANs in mehreren MAC-VRF-Instanzen umfasst.

Abbildung 11 zeigt eine ERB-Overlay-Fabric mit einer Beispiel-MAC-VRF-Konfiguration für die Mandantentrennung.

Abbildung 11: ERB-Overlay-Fabric mit MAC-VRF-Instanzen für Mandantentrennung ERB Overlay Fabric with MAC-VRF Instances for Tenant Separation

In Abbildung 11 richten die Leaf-Geräte VXLAN-Tunnel ein, die die Isolation auf Layer 2 zwischen Mandant 12 (VLAN 1 und VLAN 2) und Mandant 3 (VLAN 3) mithilfe der MAC-VRF-Instanzen MAC-VRF 12 und MAC-VRF 3 aufrechterhalten. Die Leaf-Geräte isolieren außerdem die Mandanten auf Layer 3 mithilfe der VRF-Instanzen VRF 12 und VRF 3.

Sie können andere Optionen für die gemeinsame Nutzung von VLAN-Datenverkehr zwischen Mandanten verwenden, die auf Layer 2 und Layer 3 durch die MAC-VRF- und VRF-Konfigurationen isoliert sind, z. B.:

  • Stellen Sie über eine Firewall eine sichere externe Verbindung zwischen Mandanten-VRFs her.

  • Konfigurieren Sie lokale Routenlecks zwischen Layer 3-VRFs.

Weitere Informationen zu MAC-VRF-Instanzen und deren Verwendung in einem Beispielanwendungsfall für Kunden finden Sie unter EVPN-VXLAN DC IP Fabric MAC-VRF L2 Services.

MAC-VRF-Instanzen entsprechen Weiterleitungsinstanzen wie folgt:

  • MAC-VRF-Instanzen auf Switches in der QFX5000-Reihe (einschließlich solcher, auf denen Junos OS oder Junos OS Evolved ausgeführt wird) sind alle Teil der Standardweiterleitungsinstanz. Auf diesen Geräten können Sie keine überlappenden VLANs in einer MAC-VRF-Instanz oder über mehrere MAC-VRF-Instanzen hinweg konfigurieren.

  • Auf den Switches der QFX10000-Reihe können Sie mehrere Weiterleitungsinstanzen konfigurieren und eine MAC-VRF-Instanz einer bestimmten Weiterleitungsinstanz zuordnen. Sie können auch mehrere MAC-VRF-Instanzen derselben Weiterleitungsinstanz zuordnen. Wenn Sie jede MAC-VRF-Instanz für die Verwendung einer anderen Weiterleitungsinstanz konfigurieren, können Sie überlappende VLANs über die verschiedenen MAC-VRF-Instanzen hinweg konfigurieren. Es ist nicht möglich, überlappende VLANs in einer einzelnen MAC-VRF-Instanz oder über MAC-VRF-Instanzen hinweg zu konfigurieren, die derselben Weiterleitungsinstanz zugeordnet sind.

  • In der Standardkonfiguration enthalten Switches ein Standard-VLAN mit VLAN-ID=1, das der Standard-Weiterleitungsinstanz zugeordnet ist. Da VLAN-IDs in einer Weiterleitungsinstanz eindeutig sein müssen, müssen Sie die VLAN-ID des Standard-VLANs einem anderen Wert als 1 zuweisen, wenn Sie ein VLAN mit VLAN-ID=1 in einer MAC-VRF-Instanz konfigurieren möchten, die die Standardweiterleitungsinstanz verwendet. Zum Beispiel:

Die Beispiele für die Overlay-Konfiguration der Referenznetzwerkvirtualisierung in diesem Handbuch enthalten Schritte zum Konfigurieren des Overlays mithilfe von MAC-VRF-Instanzen. Sie konfigurieren eine EVPN-Routing-Instanz vom Typ mac-vrfund legen einen Routenunterscheidungsmerkmal und ein Routenziel in der Instanz fest. Außerdem schließen Sie die gewünschten Schnittstellen (einschließlich einer VTEP-Quellschnittstelle), VLANs und VLAN-zu-VNI-Zuordnungen in die Instanz ein. Weitere Informationen finden Sie in den Referenzkonfigurationen in den folgenden Themen:

Anmerkung:

Bei einem Gerät kann es zu Problemen mit der VTEP-Skalierung kommen, wenn die Konfiguration mehrere MAC-VRF-Instanzen verwendet. Um dieses Problem zu vermeiden, müssen Sie daher die Funktion "Gemeinsam genutzte Tunnel" auf der QFX5000 Reihe von Switches aktivieren, die Junos OS mit einer MAC-VRF-Instanzkonfiguration ausgeführt werden. Wenn Sie gemeinsam genutzte Tunnel konfigurieren, minimiert das Gerät die Anzahl der Next-Hop-Einträge, um Remote-VTEPs zu erreichen. Sie aktivieren gemeinsam genutzte VXLAN-Tunnel auf dem Gerät global mithilfe der shared-tunnels Anweisung auf Hierarchieebene [edit forwarding-options evpn-vxlan] . Für diese Einstellung müssen Sie das Gerät neu starten.

Diese Anweisung ist optional für die QFX10000-Reihe von Switches, auf denen Junos OS ausgeführt wird und die eine höhere VTEP-Skalierung als QFX5000 Switches bewältigen können.

Auf Geräten, auf denen Junos OS Evolved in EVPN-VXLAN-Fabrics ausgeführt wird, sind gemeinsam genutzte Tunnel standardmäßig aktiviert. Junos OS Evolved unterstützt EVPN-VXLAN nur mit MAC-VRF-Konfigurationen.

Multihoming-Unterstützung für Ethernet-verbundene Endsysteme

Abbildung 12: Multihoming des Ethernet-Connected End System Multihoming mit Ethernet verbundenen Endsystems

Mit Ethernet verbundenes Multihoming ermöglicht es mit Ethernet verbundenen Endsystemen, sich über eine einzelne Homed-Verbindung mit einem VTEP-Gerät oder über mehrere Multihomed-Links mit verschiedenen VTEP-Geräten mit dem Ethernet-Overlay-Netzwerk zu verbinden. Der Lastenausgleich des Ethernet-Datenverkehrs erfolgt über die Fabric zwischen VTEPs auf Leaf-Geräten, die mit demselben Endsystem verbunden sind.

Wir haben Setups getestet, bei denen ein mit Ethernet verbundenes Endsystem mit einem Single-Leaf-Gerät verbunden oder mit 2 oder 3 Leaf-Geräten multihomediert wurde, um nachzuweisen, dass der Datenverkehr in Multihomed-Setups mit mehr als zwei Leaf-VTEP-Geräten ordnungsgemäß gehandhabt wird. In der Praxis kann ein mit Ethernet verbundenes Endsystem mit einer großen Anzahl von Leaf-VTEP-Geräten multihomed verbunden werden. Alle Verbindungen sind aktiv, und der Netzwerkdatenverkehr kann über alle mehrfach vernetzten Verbindungen ausgeglichen werden.

In dieser Architektur wird EVPN für Multihoming mit Ethernet-Verbindung verwendet. Multihomed EVPN-LAGs werden durch einen Ethernet Segment Identifier (ESI) im EVPN-Bridging-Overlay identifiziert, während LACP zur Verbesserung der LAG-Verfügbarkeit verwendet wird.

VLAN-Trunking ermöglicht es einer Schnittstelle, mehrere VLANs zu unterstützen. VLAN-Trunking stellt sicher, dass virtuelle Maschinen (VMs) auf Nicht-Overlay-Hypervisoren in jedem Overlay-Netzwerkkontext betrieben werden können.

Weitere Informationen zur Unterstützung von Ethernet-verbundenem Multihoming finden Sie unter Entwurf und Implementierung von Multihoming an Ethernet-Connected End-System.

Multihoming-Unterstützung für IP-verbundene Endsysteme

Abbildung 13: Multihoming IP-Connected End System Multihoming des IP-verbundenen Endsystems

IP-verbundene Multihoming-Endgeräte zur Verbindung mit dem IP-Netzwerk über mehrere IP-basierte Zugriffsschnittstellen auf verschiedenen Leaf-Geräten.

Wir haben Setups getestet, bei denen ein IP-verbundenes Endsystem mit einem Single-Leaf verbunden oder mit 2- oder 3-Leaf-Geräten multihomed betrieben wurde. Das Setup hat überprüft, ob der Datenverkehr ordnungsgemäß verarbeitet wird, wenn er auf mehrere Leaf-Geräte multihomed ist. In der Praxis kann ein IP-verbundenes Endsystem mit einer großen Anzahl von Leaf-Geräten multihomed betrieben werden.

In Multihomed-Setups sind alle Verbindungen aktiv und der Netzwerkdatenverkehr wird über alle Multihomed-Verbindungen weitergeleitet und empfangen. Der Lastenausgleich des IP-Datenverkehrs über die mehrfach vernetzten Verbindungen erfolgt mithilfe eines einfachen Hashing-Algorithmus.

EBGP wird verwendet, um Routing-Informationen zwischen dem IP-verbundenen Endsystem und den verbundenen Leaf-Geräten auszutauschen, um sicherzustellen, dass die Route oder Routen zu den Endpunktsystemen für alle Spine- und Leaf-Geräte gemeinsam genutzt werden.

Weitere Informationen zum Baustein für IP-verbundenes Multihoming finden Sie unter Entwurf und Implementierung von Multihoming an IP-Connected End-System.

Border-Geräte

Einige unserer Referenzdesigns umfassen Border-Geräte, die Verbindungen zu den folgenden Geräten bereitstellen, die sich außerhalb der lokalen IP-Fabric befinden:

  • Ein Multicast-Gateway.

  • Ein Datencenter-Gateway für Data Center Interconnect (DCI).

  • Ein Gerät, z. B. ein SRX-Router, auf dem mehrere Services wie Firewalls, Network Address Translation (NAT), Intrusion Detection and Prevention (IDP), Multicast usw. konsolidiert sind. Die Konsolidierung mehrerer Services auf einem physischen Gerät wird als Serviceverkettung bezeichnet.

  • Appliances oder Server, die als Firewalls, DHCP-Server, sFlow-Collectors usw. fungieren.

    Anmerkung:

    Wenn Ihr Netzwerk ältere Geräte oder Server umfasst, die eine 1-Gbit/s-Ethernet-Verbindung zu einem Border-Gerät benötigen, empfehlen wir die Verwendung eines QFX10008- oder QFX5120-Switches als Border-Gerät.

Um die oben beschriebenen zusätzlichen Funktionen bereitzustellen, unterstützt Juniper Networks die Bereitstellung eines Border-Geräts auf folgende Weise:

  • Als ein Gerät, das nur als Rahmengerät dient. In dieser dedizierten Rolle können Sie das Gerät so konfigurieren, dass es eine oder mehrere der oben beschriebenen Aufgaben ausführt. In dieser Situation wird das Gerät in der Regel als Border Leaf bereitgestellt, das mit einem Spine-Gerät verbunden ist.

    In dem in Abbildung 14 dargestellten ERB-Overlay bieten die Border Leafs L5 und L6 beispielsweise Konnektivität zu Datencenter-Gateways für DCI, einen sFlow-Kollektor und einen DHCP-Server.

  • Als ein Gerät, das zwei Rollen hat: ein Netzwerk-Underlay-Gerät und ein Border-Gerät, das eine oder mehrere der oben beschriebenen Aufgaben ausführen kann. In dieser Situation übernimmt in der Regel ein Spine-Gerät die beiden Rollen. Daher wird die Funktionalität des Rahmengeräts als Border Spine bezeichnet.

    In der in Abbildung 15 gezeigten ERB-Überlagerung fungieren beispielsweise die Border Spines S1 und S2 als Lean-Spine-Geräte. Außerdem bieten sie Konnektivität zu Datencenter-Gateways für DCI, einen sFlow-Kollektor und einen DHCP-Server.

Abbildung 14: Beispiel für eine ERB-Topologie mit Border Leafs Sample ERB Topology with Border Leafs
Abbildung 15: Beispiel für eine ERB-Topologie mit Border Spines Sample ERB Topology with Border Spines

Data Center Interconnect (DCI)

Der Baustein Data Center Interconnect (DCI) stellt die Technologie bereit, die für das Senden von Datenverkehr zwischen Datencentern erforderlich ist. Das validierte Design unterstützt DCI unter Verwendung von EVPN-Routen vom Typ 5, IPVPN-Routen und Layer-2-DCI mit VXLAN-Stitching.

EVPN Typ 5 oder IPVPN-Routen werden in einem DCI-Kontext verwendet, um sicherzustellen, dass der Datenverkehr zwischen Datencentern zwischen Datencentern mit unterschiedlichen IP-Adress-Subnetzschemata ausgetauscht werden kann. Routen werden zwischen Spine-Geräten in verschiedenen Datencentern ausgetauscht, um die Übertragung von Datenverkehr zwischen Datencentern zu ermöglichen.

Abbildung 16: DCI mit EVPN Typ 5 Routentopologie – Übersicht DCI Using EVPN Type 5 Routes Topology Overview

Eine physische Verbindung zwischen den Datencentern ist erforderlich, bevor Sie DCI konfigurieren können. Die physische Konnektivität wird durch Backbone-Geräte in einer WAN-Cloud bereitgestellt. Ein Backbone-Gerät ist mit allen Spine-Geräten in einem einzigen Datencenter (POD) sowie mit den anderen Backbone-Geräten, die mit den anderen Datencentern verbunden sind, verbunden.

Weitere Informationen zum Konfigurieren von DCI finden Sie unter:

Dienstverkettung

In vielen Netzwerken ist es üblich, dass der Datenverkehr über separate Hardwaregeräte fließt, die jeweils einen Service bereitstellen, z. B. Firewalls, NAT, IDP, Multicast usw. Jedes Gerät erfordert eine separate Bedienung und Verwaltung. Diese Methode der Verknüpfung mehrerer Netzwerkfunktionen kann als physische Dienstverkettung betrachtet werden.

Ein effizienteres Modell für die Dienstverkettung ist die Virtualisierung und Konsolidierung von Netzwerkfunktionen auf einem einzigen Gerät. In unserer Blueprint-Architektur verwenden wir die Router der SRX-Serie als das Gerät, das Netzwerkfunktionen konsolidiert, Prozesse verarbeitet und Services anwendet. Dieses Gerät wird als physische Netzwerkfunktion (PNF) bezeichnet.

Bei dieser Lösung wird die Dienstverkettung sowohl für ein CRB- als auch für ein ERB-Overlay unterstützt. Sie funktioniert nur für Datenverkehr zwischen Mandanten.

Logische Sicht der Dienstverkettung

Abbildung 17 zeigt eine logische Ansicht der Dienstverkettung. Es zeigt eine Spine mit einer Konfiguration auf der rechten Seite und einer Konfiguration auf der linken Seite. Auf jeder Seite befinden sich eine VRF-Routing-Instanz und eine IRB-Schnittstelle. Der Router der SRX-Serie in der Mitte ist die PNF und führt die Dienstverkettung durch.

Abbildung 17: Logische Ansicht Service Chaining Logical View der Dienstverkettung

Der Datenverkehrsfluss in dieser logischen Ansicht sieht wie folgt aus:

  1. Der Spine empfängt ein Paket auf dem VTEP, das sich im VRF auf der linken Seite befindet.

  2. Das Paket wird entkapselt und an die IRB-Schnittstelle auf der linken Seite gesendet.

  3. Die IRB-Schnittstelle leitet das Paket an den Router der SRX-Serie weiter, der als PNF fungiert.

  4. Der Router der SRX-Serie führt eine Dienstverkettung für das Paket durch und leitet das Paket zurück an das Spine, wo es über die IRB-Schnittstelle auf der rechten Seite des Spine empfangen wird.

  5. Die IRB-Schnittstelle leitet das Paket an den VTEP im VRF auf der rechten Seite weiter.

Weitere Informationen zum Konfigurieren der Dienstverkettung finden Sie unter Entwurf und Implementierung der Dienstverkettung.

Multicast-Optimierungen

Multicast-Optimierungen tragen dazu bei, Bandbreite zu erhalten und den Datenverkehr in einem Multicast-Szenario in EVPN-VXLAN-Umgebungen effizienter zu routen. Ohne konfigurierte Multicast-Optimierungen erfolgt die gesamte Multicast-Replikation am Eingang des Leafs, das mit der Multicast-Quelle verbunden ist, wie in Abbildung 18 dargestellt. Multicast-Datenverkehr wird an alle Leaf-Geräte gesendet, die mit dem Spine verbunden sind. Jedes Leaf-Gerät sendet Datenverkehr an verbundene Hosts.

Abbildung 18: Multicast ohne Optimierungen Multicast without Optimizations

Es gibt einige Arten von Multicast-Optimierungen, die in EVPN VXLAN-Umgebungen unterstützt werden und zusammenarbeiten können:

Weitere Informationen zum Konfigurieren von Multicastfunktionen finden Sie unter:

IGMP-Snooping

IGMP-Snooping in einer EVPN-VXLAN-Fabric ist nützlich, um die Verteilung von Multicast-Datenverkehr zu optimieren. IGMP-Snooping spart Bandbreite, da Multicast-Datenverkehr nur an Schnittstellen weitergeleitet wird, an die IGMP-Listener vorhanden sind. Nicht alle Schnittstellen auf einem Leaf-Gerät müssen Multicast-Datenverkehr empfangen.

Ohne IGMP-Snooping erhalten Endsysteme IP-Multicast-Datenverkehr, an dem sie kein Interesse haben, wodurch ihre Verbindungen unnötig mit unerwünschtem Datenverkehr überflutet werden. In einigen Fällen, wenn die IP-Multicast-Datenströme groß sind, führt die Flut von unerwünschtem Datenverkehr zu Denial-of-Service-Problemen.

Abbildung 19 zeigt, wie IGMP-Snooping in einer EVPN-VXLAN-Fabric funktioniert. In dieser EVPN-VXLAN-Beispielfabric ist IGMP-Snooping auf allen Leaf-Geräten konfiguriert, und Multicast-Empfänger 2 hat zuvor eine IGMPv2-Beitrittsanforderung gesendet.

  1. Multicastempfänger 2 sendet einen IGMPv2-Abwesenheitsantrag.

  2. Die Multicastempfänger 3 und 4 senden eine IGMPv2-Join-Anforderung.

  3. Wenn Leaf 1 eingehenden Multicast-Datenverkehr empfängt, repliziert es diesen für alle Leaf-Geräte und leitet ihn an das Spine weiter.

  4. Das Spine leitet den Datenverkehr an alle Leaf-Geräte weiter.

  5. Leaf 2 empfängt den Multicastdatenverkehr, leitet ihn aber nicht an den Empfänger weiter, da der Empfänger eine IGMP-Abbruchnachricht gesendet hat.

Abbildung 19: Multicast mit IGMP-Snooping Multicast with IGMP Snooping

In EVPN-VXLAN-Netzwerken wird nur IGMP Version 2 unterstützt.

Weitere Informationen zu IGMP-Snooping finden Sie unter Überblick über die Multicast-Weiterleitung mit IGMP-Snooping oder MLD-Snooping in einer EVPN-VXLAN-Umgebung.

Selektive Multicast-Weiterleitung

Selektive Multicast Ethernet (SMET)-Weiterleitung sorgt für eine höhere End-to-End-Netzwerkeffizienz und reduziert den Datenverkehr im EVPN-Netzwerk. Dies spart Bandbreitennutzung im Kern der Fabric und reduziert die Last auf ausgehenden Geräten, die keine Listener haben.

Geräte mit aktiviertem IGMP-Snooping verwenden die selektive Multicast-Weiterleitung, um Multicast-Datenverkehr effizient weiterzuleiten. Wenn IGMP-Snooping aktiviert ist, sendet ein Leaf-Gerät Multicast-Datenverkehr nur an die Zugriffsschnittstelle mit einem interessierten Empfänger. Wenn SMET hinzugefügt wird, sendet das Leaf-Gerät Multicast-Datenverkehr selektiv nur an die Leaf-Geräte im Core, die Interesse an dieser Multicast-Gruppe bekundet haben.

Abbildung 20 zeigt den SMET-Datenverkehrsfluss zusammen mit IGMP-Snooping.

  1. Multicastempfänger 2 sendet einen IGMPv2-Abwesenheitsantrag.

  2. Die Multicastempfänger 3 und 4 senden eine IGMPv2-Join-Anforderung.

  3. Wenn Leaf 1 eingehenden Multicast-Datenverkehr empfängt, repliziert es den Datenverkehr nur an Leaf-Geräte mit interessierten Empfängern (Leaf-Geräte 3 und 4) und leitet ihn an das Spine weiter.

  4. Das Spine leitet den Datenverkehr an die Leaf-Geräte 3 und 4 weiter.

Abbildung 20: Selektive Multicast-Weiterleitung mit IGMP-Snooping Selective Multicast Forwarding with IGMP Snooping

Sie müssen SMET nicht aktivieren. Sie ist standardmäßig aktiviert, wenn IGMP-Snooping auf dem Gerät konfiguriert ist.

Weitere Informationen zu SMET finden Sie unter Übersicht über die selektive Multicastweiterleitung.

Unterstützte Replikation von Multicast-Datenverkehr

Die Funktion "Assistierte Replikation" (AR) entlastet EVPN-VXLAN-Fabric-Leaf-Geräte von eingehenden Replikationsaufgaben. Das Eingangs-Leaf repliziert keinen Multicast-Datenverkehr. Er sendet eine Kopie des Multicast-Datenverkehrs an ein Spine, das als AR-Replikatorgerät konfiguriert ist. Das AR-Replikator-Gerät verteilt und kontrolliert den Multicast-Datenverkehr. Diese Methode reduziert nicht nur die Replikationslast auf den Eingangs-Leaf-Geräten, sondern spart auch Bandbreite in der Fabric zwischen dem Leaf und dem Spine.

Abbildung 21 zeigt, wie AR zusammen mit IGMP-Snooping und SMET funktioniert.

  1. Leaf 1, das als AR-Leaf-Gerät eingerichtet ist, empfängt Multicast-Datenverkehr und sendet eine Kopie an das Spine, das als AR-Replikator-Gerät eingerichtet ist.

  2. Das Spine repliziert den Multicast-Datenverkehr. Es repliziert den Datenverkehr für Leaf-Geräte, die mit dem VLAN-VNI bereitgestellt werden, in dem der Multicast-Datenverkehr von Leaf 1 stammt.

    Da wir IGMP-Snooping und SMET im Netzwerk konfiguriert haben, sendet das Spine den Multicast-Datenverkehr nur an Leaf-Geräte mit interessierten Empfängern.

Abbildung 21: Multicast mit AR, IGMP-Snooping und SMET Multicast with AR, IGMP Snooping, and SMET

In diesem Dokument zeigen wir Multicast-Optimierungen in kleinem Maßstab. In einem vollwertigen Netzwerk mit vielen Spines und Leafs sind die Vorteile der Optimierungen viel offensichtlicher.

Optimiertes Intersubnet-Multicast für ERB-Overlay-Netzwerke

Wenn Sie über Multicast-Quellen und -Empfänger innerhalb und außerhalb einer ERB-Overlay-Fabric verfügen, können Sie optimiertes Intersubnet-Multicast (OISM) konfigurieren, um einen effizienten Multicast-Datenverkehrsfluss in großem Umfang zu ermöglichen.

OISM verwendet ein lokales Routing-Modell für Multicast-Datenverkehr, das Hairpinning des Datenverkehrs vermeidet und die Datenverkehrslast innerhalb des EVPN-Cores minimiert. OISM leitet Multicast-Datenverkehr nur im Multicast-Quell-VLAN weiter. Bei Intersubnetz-Empfängern verwenden die Leaf-Geräte IRB-Schnittstellen, um den über das Quell-VLAN empfangenen Datenverkehr lokal an andere Empfänger-VLANs auf demselben Gerät weiterzuleiten. Um den Multicast-Datenverkehrsfluss in der EVPN-VXLAN-Fabric weiter zu optimieren, verwendet OISM IGMP-Snooping und SMET, um den Datenverkehr in der Fabric nur an Leaf-Geräte mit interessierten Empfängern weiterzuleiten.

OISM ermöglicht es der Fabric auch, Datenverkehr effektiv von externen Multicastquellen zu internen Empfängern und von internen Multicastquellen zu externen Empfängern weiterzuleiten. OISM verwendet eine zusätzliche Bridge-Domäne (SBD) innerhalb der Fabric, um Multicast-Datenverkehr weiterzuleiten, der von externen Quellen auf den Border-Leaf-Geräten empfangen wird. Beim SBD-Design wird das lokale Routingmodell für Datenverkehr aus externen Quellen beibehalten.

Sie können OISM mit AR verwenden, um die Replikationslast auf OISM-Leaf-Geräten mit geringerer Kapazität zu reduzieren. (Siehe Unterstützte Replikation von Multicastdatenverkehr.)

Siehe Abbildung 22 für eine einfache Fabric mit OISM und AR.

Abbildung 22: OISM mit AR OISM with AR

Abbildung 22 zeigt OISM-Server-Leaf- und Border-Leaf-Geräte, Spine 1 in der AR-Replikatorrolle und Server-Leaf 1 als Multicastquelle in der AR-Leaf-Rolle. Eine externe Quelle und Empfänger können auch in der externen PIM-Domäne vorhanden sein. OISM und AR arbeiten in diesem Szenario wie folgt zusammen:

  1. Multicast-Empfänger hinter Server-Leaf 3 auf VLAN 1 und hinter Server-Leaf 4 auf VLAN 2 senden IGMP-Joins, die Interesse an der Multicast-Gruppe zeigen. Externe Empfänger können ebenfalls der Multicastgruppe beitreten.

  2. Die Multicastquelle hinter Server Leaf 1 sendet Multicast-Datenverkehr für die Gruppe in die Fabric auf VLAN 1. Server-Leaf 1 sendet nur eine Kopie des Datenverkehrs an den AR-Replikator auf Spine 1.

  3. Außerdem kommt der externe Quelldatenverkehr für die Multicastgruppe bei Border Leaf 1 an. Border Leaf 1 leitet den Datenverkehr auf dem SBD an Spine 1, den AR-Replikator, weiter.

  4. Der AR-Replikator sendet Kopien von der internen Quelle im Quell-VLAN und von der externen Quelle auf dem SBD an die OISM-Leaf-Geräte mit interessierten Empfängern.

  5. Die Server-Leaf-Geräte leiten den Datenverkehr an die Empfänger im Quell-VLAN weiter und leiten den Datenverkehr lokal an die Empfänger in den anderen VLANs weiter.

Optimierung des eingehenden Datenverkehrs virtueller Maschinen für EVPN

Wenn virtuelle Maschinen und Hosts innerhalb eines Datencenters oder von einem Datencenter in ein anderes verschoben werden, kann der Netzwerkdatenverkehr ineffizient werden, wenn der Datenverkehr nicht an das optimale Gateway weitergeleitet wird. Dies kann passieren, wenn ein Host verlagert wird. Die ARP-Tabelle wird nicht immer geleert, und der Datenfluss zum Host wird an das konfigurierte Gateway gesendet, selbst wenn ein optimaleres Gateway vorhanden ist. Der Datenverkehr wird "tausgelassen" und unnötigerweise an das konfigurierte Gateway weitergeleitet.

Ingress Virtual Machine Traffic Optimization (VMTO) sorgt für mehr Netzwerkeffizienz, optimiert eingehenden Datenverkehr und kann den Posauneneffekt zwischen VLANs eliminieren. Wenn Sie Ingress VMTO aktivieren, werden Routen in einer virtuellen Routing- und Weiterleitungstabelle (VRF) auf Layer 3 gespeichert und das Gerät leitet den eingehenden Datenverkehr direkt zurück zum Host, der verlagert wurde.

Abbildung 23 zeigt Datenverkehr ohne eingehende VMTO und optimierten Datenverkehr mit aktivierter Eingangs-VMTO.

  • Ohne Eingangs-VMTO kündigen Spine 1 und 2 von DC1 und DC2 die Remote-IP-Hostroute 10.0.0.1 an, wenn die Ursprungsroute von DC2 stammt. Der eingehende Datenverkehr kann entweder an Spine 1 und 2 in DC1 weitergeleitet werden. Sie wird dann an Spine 1 und 2 in DC2 weitergeleitet, wohin Route 10.0.0.1 verschoben wurde. Dadurch entsteht der Trombone-Effekt.

  • Mit Eingangs-VMTO können wir einen optimalen Weiterleitungspfad erreichen, indem wir eine Richtlinie für die IP-Hostroute (10.0.01) so konfigurieren, dass sie nur von Spine 1 und 2 von DC2 und nicht von DC1 angekündigt wird, wenn der IP-Host auf DC2 verschoben wird.

Abbildung 23: Datenverkehr mit und ohne Ingress-VMTO Traffic with and without Ingress VMTO

Weitere Informationen zum Konfigurieren von VMTO finden Sie unter Konfigurieren von VMTO.

DHCP-Relay

Abbildung 24: DHCP-Relay in einem CRB-Overlay DHCP Relay in a CRB Overlay

Der DHCP-Relaybaustein (Dynamic Host Configuration Protocol) ermöglicht dem Netzwerk die Übertragung von DHCP-Nachrichten zwischen einem DHCP-Client und einem DHCP-Server. Die DHCP-Relay-Implementierung in diesem Baustein bewegt DHCP-Pakete durch ein CRB-Overlay, bei dem sich das Gateway auf der Spine-Schicht befindet.

Der DHCP-Server und die DHCP-Clients stellen über Zugriffsschnittstellen auf Leaf-Geräten eine Verbindung mit dem Netzwerk her. DHCP-Server und -Clients können ohne weitere Konfiguration über das vorhandene Netzwerk miteinander kommunizieren, wenn sich DHCP-Client und -Server im selben VLAN befinden. Wenn sich ein DHCP-Client und -Server in unterschiedlichen VLANs befinden, wird der DHCP-Datenverkehr zwischen Client und Server über die IRB-Schnittstellen auf Spine-Geräten zwischen den VLANs weitergeleitet. Sie müssen die IRB-Schnittstellen auf den Spine-Geräten so konfigurieren, dass sie DHCP-Relay zwischen VLANs unterstützen.

Weitere Informationen zum Implementieren des DHCP-Relays finden Sie unter Entwurf und Implementierung von DHCP-Relays.

Reduzierung des ARP-Datenverkehrs mit ARP-Synchronisierung und -Unterdrückung (Proxy-ARP)

Das Ziel der ARP-Synchronisierung besteht darin, ARP-Tabellen in allen VRFs zu synchronisieren, die ein Overlay-Subnetz bedienen, um die Menge des Datenverkehrs zu reduzieren und die Verarbeitung sowohl für Netzwerkgeräte als auch für Endsysteme zu optimieren. Wenn ein IP-Gateway für ein Subnetz von einer ARP-Bindung erfährt, gibt es diese für andere Gateways frei, sodass diese dieselbe ARP-Bindung nicht separat ermitteln müssen.

Wenn ein Leaf-Gerät bei der ARP-Unterdrückung eine ARP-Anforderung erhält, prüft es seine eigene ARP-Tabelle, die mit den anderen VTEP-Geräten synchronisiert ist, und antwortet lokal auf die Anforderung, anstatt die ARP-Anforderung zu überfluten.

Proxy-ARP und ARP-Unterdrückung sind standardmäßig auf allen Switches der QFX-Serie aktiviert, die als Leaf-Geräte in einem ERB-Overlay fungieren können. Eine Liste dieser Switches finden Sie unter Data Center EVPN-VXLAN Fabric-Referenzdesigns – Übersicht über unterstützte Hardware.

IRB-Schnittstellen auf dem Leaf-Gerät liefern ARP-Anforderungen und NDP-Anfragen sowohl von lokalen als auch von Remote-Leaf-Geräten. Wenn ein Leaf-Gerät eine ARP- oder NDP-Anforderung von einem anderen Leaf-Gerät empfängt, durchsucht das empfangende Gerät seine MAC+IP-Adressbindungsdatenbank nach der angeforderten IP-Adresse.

  • Wenn das Gerät die MAC+IP-Adressbindung in seiner Datenbank findet, antwortet es auf die Anforderung.

  • Wenn das Gerät die MAC+IP-Adressbindung nicht findet, überflutet es die ARP-Anfrage an alle Ethernet-Verbindungen im VLAN und die zugehörigen VTEPs.

Da alle beteiligten Leaf-Geräte die ARP-Einträge hinzufügen und ihre Routing- und Bridging-Tabellen synchronisieren, reagieren lokale Leaf-Geräte direkt auf Anfragen von lokal verbundenen Hosts, ohne dass Remote-Geräte auf diese ARP-Anforderungen reagieren müssen.

Informationen zum Implementieren der ARP-Synchronisierung, des Proxy-ARP und der ARP-Unterdrückung finden Sie unter Aktivieren von Proxy-ARP und ARP-Unterdrückung für das Edge-Routed Bridging Overlay.

Layer-2-Port-Sicherheitsfunktionen auf Ethernet-verbundenen Endsystemen

CRB- und ERB-Overlays unterstützen die Sicherheitsfunktionen auf Layer-2-Ethernet-verbundenen Endsystemen, die in den nächsten Abschnitten beschrieben werden.

Weitere Informationen zu diesen Funktionen finden Sie unter Unterstützung für MAC-Filterung, Sturmsteuerung und Portspiegelung in einer EVPN-VXLAN-Umgebung.

Weitere Informationen zum Konfigurieren dieser Funktionen finden Sie unter Konfigurieren von Layer-2-Port-Sicherheitsfunktionen auf Ethernet-verbundenen Endsystemen.

Verhindern von BUM-Verkehrsstürmen mit Storm Control

Die Sturmkontrolle kann verhindern, dass übermäßiger Datenverkehr das Netzwerk beeinträchtigt. Es verringert die Auswirkungen von BUM-Datenverkehrsstürmen, indem es das Datenverkehrsvolumen auf EVPN-VXLAN-Schnittstellen überwacht und BUM-Datenverkehr verwirft, wenn ein bestimmtes Datenverkehrsniveau überschritten wird.

In einer EVPN-VXLAN-Umgebung überwacht die Sturmkontrolle:

  • Layer 2 BUM-Datenverkehr, der von einem VXLAN stammt und an Schnittstellen innerhalb desselben VXLAN weitergeleitet wird.

  • Layer-3-Multicast-Datenverkehr, der von einer IRB-Schnittstelle in einem VXLAN empfangen und an Schnittstellen in einem anderen VXLAN weitergeleitet wird.

Verwenden von MAC-Filterung zur Verbesserung der Portsicherheit

MAC-Filterung verbessert die Portsicherheit, indem sie die Anzahl der MAC-Adressen begrenzt, die in einem VLAN gelernt werden können, und damit den Datenverkehr in einem VXLAN begrenzt. Durch die Begrenzung der Anzahl der MAC-Adressen wird der Switch vor einer Überflutung der Ethernet-Switching-Tabelle geschützt. Eine Überflutung der Ethernet-Switching-Tabelle tritt auf, wenn die Anzahl der neu gelernten MAC-Adressen dazu führt, dass die Tabelle überläuft und zuvor gelernte MAC-Adressen aus der Tabelle geleert werden. Der Switch lernt die MAC-Adressen neu, was sich auf die Leistung auswirken und Sicherheitslücken einleiten kann.

In diesem Konzept begrenzt die MAC-Filterung die Anzahl der akzeptierten Pakete, die an eingehende Zugriffsschnittstellen gesendet werden, basierend auf MAC-Adressen. Weitere Informationen zur Funktionsweise der MAC-Filterung finden Sie in den Informationen zur MAC-Begrenzung unter Grundlegendes zur MAC-Begrenzung und MAC-Verschiebungsbegrenzung.

Analysieren des Datenverkehrs mithilfe der Portspiegelung

Mit einer auf Analysatoren basierenden Portspiegelung können Sie den Datenverkehr in einer EVPN-VXLAN-Umgebung bis auf Paketebene analysieren. Sie können diese Funktion verwenden, um Richtlinien in Bezug auf die Netzwerknutzung und die Dateifreigabe durchzusetzen und Problemquellen zu identifizieren, indem Sie eine ungewöhnliche oder starke Bandbreitennutzung durch bestimmte Stationen oder Anwendungen lokalisieren.

Die Portspiegelung kopiert Pakete, die einen Port betreten oder verlassen oder in ein VLAN eintreten, und sendet die Kopien an eine lokale Schnittstelle zur lokalen Überwachung oder an ein VLAN zur Remoteüberwachung. Verwenden Sie die Portspiegelung, um Datenverkehr an Anwendungen zu senden, die den Datenverkehr zu Zwecken wie der Überwachung der Compliance, der Durchsetzung von Richtlinien, der Erkennung von Eindringlingen, der Überwachung und Vorhersage von Datenverkehrsmustern, der Korrelation von Ereignissen usw. analysieren.

Zugehörige Dokumentation