Sie sind auf Seite 1von 16

Referenzarchitektur

REFERENZARCHITEKTUR IP
FABRIC EVPN-VXLAN

©2019, Juniper Networks, Inc.


Referenzarchitektur IP Fabric EVPN-VXLAN

INHALTSVERZEICHNIS
Übersicht über die IP Fabric EVPN-VXLAN-Lösung............................................................. 3
Lösungskomponenten................................................................................................................. 3
IP-Fabric Underlay-Netzwerk.....................................................................................................................................3
Netzwerkvirtualisierungs-Overlay.............................................................................................................................4

Overlay-Services ......................................................................................................................... 4
Bridging-Overlay...........................................................................................................................................................4
Zentral geroutetes Overlay (alias Spine Routed).....................................................................................................5
Edge-Routing-Overlay (alias Leaf Routed)...............................................................................................................6

Overlay-Design und Bereitstellungsoptionen........................................................................ 6


Randgeräte.................................................................................................................................... 7
Multihoming................................................................................................................................. 8
Multihoming-Support für Ethernet-verbundene Systeme....................................................................................8

Service-Einfügung ...................................................................................................................... 8
Vernetzung von Datencentern.................................................................................................. 9
Layer 2 DCI....................................................................................................................................................................9
Layer 3 DCI................................................................................................................................................................. 10

Multicast-aktiviertes EVPN-basiertes Datencenter ..........................................................11


Multicast in Overlay – Multicast-Weiterleitung zwischen Subnetzen............................................................ 11
Multicast in Overlay – Multicast-Weiterleitung zwischen Subnetzen............................................................ 11
Multicast in einer zentral gerouteten Overlay-Architektur .............................................................................. 12

Automatisierung der Datencenter EVPN-VXLAN Fabrics.................................................13


Automatisierung der EVPN-VXLAN Fabric durch Ansible/Saltstack .............................................................. 13

Contrail Enterprise Multicloud ...............................................................................................13


Multicloud................................................................................................................................................................... 13

Telemetrie/Analysen ................................................................................................................14
Contrail Insights......................................................................................................................................................... 14

Fazit..............................................................................................................................................16
Über Juniper Networks.............................................................................................................16

©2019, Juniper Networks, Inc.


2
Referenzarchitektur IP Fabric EVPN-VXLAN

EINFÜHRUNG
Diese Referenzarchitektur beschreibt die Ethernet VPN (EVPN)-Virtual Extensible LAN
(VXLAN)-Lösungen von Juniper Networks, die viele der Aufgaben im Zusammenhang mit
der Verwaltung eines Datencenters und der Erweiterung seiner Konnektivität auf andere
Datencenter oder öffentliche Cloud-Angebote vereinfachen und automatisieren.
Das Dokument enthält eine Funktionsbeschreibung der Lösung selbst und umreißt die
Komponenten, aus denen die Lösung besteht.
Es wird vorausgesetzt, dass der Leser über IP-Netzwerkkenntnisse und ein grundlegendes
Verständnis von Datencenter-Technologien verfügt.

Übersicht über die IP Fabric EVPN-VXLAN-Lösung


Traditionell haben Datencenter Layer-2-Technologien wie das Spanning Tree Protocol (STP) und die Multichassis Link
Aggregation Group (MC-LAG) verwendet, um Rechen- und Speicherressourcen zu verbinden. Da sich diese Datencenter
weiterentwickeln, um Multitenant-Netzwerke zu skalieren, ist eine neue Datencenter-Architektur erforderlich, die das
(physische) Underlay-Netzwerk von einem Tenant-Overlay-Netzwerk entkoppelt.

Durch die Verwendung eines IP-basierten Layer 3-Underlay mit einem EVPN-VXLAN-Overlay können Datencenter,
Unternehmen und Cloud-Betreiber viel größere Netzwerke bereitstellen, als sonst bei herkömmlichen auf Ethernet
basierten Layer 2-Architekturen möglich. Mit Overlays können Endgeräte wie Server oder virtuelle Maschinen (VMs)
überall im Netzwerk platziert werden und mit demselben logischen L2-Netzwerk verbunden bleiben, wodurch die virtuelle
Topologie von der physischen Topologie entkoppelt wird.

Lösungskomponenten
IP-Fabric Underlay-Netzwerk
In Datencenter-Umgebungen besteht die Rolle des physischen Underlay-Netzwerks darin, eine IP-Fabric bereitzustellen. Es liegt
in der Verantwortung der IP-Fabric, die auch als Clos-Netzwerk bekannt ist, Unicast-IP-Konnektivität von jedem physischen
Gerät (Server, Speichergerät, Router oder Switch) zu jedem anderen physischen Gerät bereitzustellen. Ein ideales Underlay-
Netzwerk bietet eine latenzarme, nicht blockierende Konnektivität mit hoher Bandbreite von jedem Punkt im Netzwerk zu jedem
anderen Punkt im Netzwerk.

IP-Fabrics können in Größe und Umfang variieren. Eine typische Lösung verwendet zwei Layer, Spine und Leaf, um eine
so genannte dreistufige IP-Fabric zu bilden, bei der jedes Leaf-Gerät mit jedem Spine-Gerät verbunden ist, wie in
Abbildung 1 dargestellt.

Spine Spine Spine Spine

Leaf Leaf Leaf Leaf Leaf

Abbildung 1: Die dreistufige IP-Fabric

©2019, Juniper Networks, Inc.


3
Referenzarchitektur IP Fabric EVPN-VXLAN

Mit zunehmendem Umfang der Fabric wird es notwendig, zu einer fünfstufigen IP-Fabric zu expandieren, wie in
Abbildung 2 dargestellt. In diesem Szenario wird ein Fabric-Layer (oder "Super-Spine") hinzugefügt, um die Konnektivität
zwischen den einzelnen Modulen oder Datencentern zu gewährleisten.

Fabric Fabric Fabric Fabric

Spine Spine Spine Spine

Leaf Leaf Leaf Leaf Leaf Leaf

Abbildung 2: Die fünfstufige IP-Fabric

Ein Hauptvorteil einer IP-basierten Fabric ist ihre natürliche Elastizität. Hochverfügbarkeitsmechanismen wie MC-LAG oder
die Virtual Chassis-Technologie von Juniper sind nicht erforderlich, da die IP-Fabric mehrere Links auf jeder Schicht und jedem
Gerät verwendet. Ausfallsicherheit und Redundanz werden durch die physische Netzwerkinfrastruktur selbst gewährleistet.
Die in diesem Dokument beschriebene Referenzarchitektur verwendet aufgrund ihrer Zuverlässigkeit und Skalierbarkeit
EBGP als Routing-Protokoll im Underlay-Netzwerk. Jedem Spine- and Leaf-Gerät wird ein eigenes autonomes System mit
einer eindeutigen, autonomen 32-Bit-Systemnummer zur Unterstützung von EBGP zugewiesen. Andere Routing-Protokolle
wie OSPF/IS-IS können zwar im Underlay-Netzwerk des Datencenters verwendet werden, sie gehen jedoch über den
Rahmen dieses Dokuments hinaus.

Netzwerkvirtualisierungs-Overlay
Ein Netzwerkvirtualisierungs-Overlay ist ein virtuelles Netzwerk, das über ein IP-Underlay transportiert wird – ein
funktionaler Baustein, der die Mandantenfähigkeit innerhalb eines Netzwerks ermöglicht und Ihnen die Möglichkeit
bietet, ein einziges physisches Netzwerk über mehrere Mandanten hinweg gemeinsam zu nutzen und gleichzeitig den
Netzwerkverkehr jedes Mandanten von den anderen Mandanten zu isolieren.
Ein Tenant ist eine Benutzergemeinschaft (z. B. eine Geschäftseinheit, Abteilung, Arbeitsgruppe oder Anwendung), die
Gruppen von Endgeräten enthält. Diese Gruppen können mit anderen Gruppen im gleichen Tenant-Verhältnis kommunizieren,
und die Tenants können mit anderen Tenants kommunizieren, wenn die Netzwerkrichtlinien dies zulassen. Eine Gruppe wird
typischerweise als ein Subnetz (VLAN) ausgedrückt, das mit anderen Geräten im selben Subnetz kommunizieren und externe
Gruppen und Endgeräte über eine virtuelle Routing und Forwarding (VRF)-Instanz erreichen kann.

Overlay-Services
IBGP ist ein Routing-Protokoll, das Erreichbarkeitsinformationen über ein IP-Netzwerk austauscht. In Kombination mit
Multiprotokoll-IBGP (MP-IBGP) ermöglicht IBGP EVPN den Austausch von Erreichbarkeitsinformationen mit VXLAN Virtual
Tunnel Endpoint (VTEP)-Geräten. Dies ist erforderlich, um Inter-VTEP VXLAN-Tunnel einzurichten und diese für Overlay-
Konnektivitätsdienste zu nutzen.
In den folgenden Abschnitten werden verschiedene Overlay-Servicemodelle als Teil der EVPN-VXLAN-Referenzarchitektur diskutiert.

Bridging-Overlay
In einem Bridging-Overlay-Modell (siehe Abbildung 4) werden Ethernet-VLANs zwischen Leaf-Geräten über VXLAN-Tunnel
erweitert. Diese Leaf-to-Leaf-VXLAN-Tunnel unterstützen Datencenter-Netzwerke, die eine Ethernet-Verbindung zwischen
Leaf-Geräten, aber kein Routing zwischen den VLANs benötigen. Infolgedessen bieten Spine-Geräte nur grundlegende
Underlay- und Overlay-Konnektivität für die Leaf-Geräte und führen keine Routing- oder Gateway-Services aus, wie dies
bei anderen Overlay-Methoden der Fall ist. Universelle Routing-Plattformen der MX-Serie 5G oder Service-Gateways
der SRX-Serie von Juniper Networks®, die außerhalb der EVPN/VXLAN-Fabric liegen, können zur Durchführung des
erforderlichen Routings verwendet werden.

©2019, Juniper Networks, Inc.


4
Referenzarchitektur IP Fabric EVPN-VXLAN

Leaf-Geräte richten VTEPs ein, um eine Verbindung zu anderen Leaf-Geräten herzustellen. Die Tunnel ermöglichen es den
Leaf-Geräten, VLAN-Verkehr an andere Leaf-Geräte und Ethernet-verbundene Endsysteme im Datencenter zu senden.
Die Einfachheit dieses Overlay-Service macht ihn attraktiv für Betreiber, die eine einfache Möglichkeit zur Einführung von
EVPN/VXLAN in ihr bestehendes Ethernet-basiertes Datencenter-Netzwerk benötigen.

Blaues Grünes
VLAN VLAN

Über Ethernet
verbundenes
Endsystem
Blaues VLAN Grünes VLAN Blaues VLAN
Grünes VLAN

Abbildung 3: Bridging-Overlay

Zentral geroutetes Overlay (alias Spine Routed)


Das Prinzip eines zentral gerouteten Bridging-Overlays besteht darin, dass das Routing an einem zentralen Gateway innerhalb
des Datencenter-Netzwerks (in diesem Beispiel das Spine-Layer) und nicht am VTEP-Gerät erfolgt, an dem die Endsysteme
angeschlossen sind (in diesem Beispiel das Leaf-Layer). Sie können dieses Overlay-Modell verwenden, wenn der geroutete
Datenverkehr durch ein zentralisiertes Gateway geleitet werden muss oder wenn die VTEP-Edge-Geräte nicht über die
erforderlichen Routing-Funktionen verfügen. Wie in Abbildung 4 dargestellt, wird der Verkehr, der von den mit Ethernet
verbundenen Endsystemen ausgeht, über einen Trunk (mehrere VLANs) oder einen Access-Port (ein VLAN) an die VTEP-
Leaf-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 (IRB)-Schnittstelle an jedem Spine-Gerät routet den
Verkehr zwischen den virtuellen Ethernet-Netzwerken.

L3 VXLAN GW

Blaues Grünes
VLAN VLAN

L2 VXLAN

Über Ethernet
verbundenes Endsystem

Blaues VLAN Grünes VLAN

Abbildung 4: Zentral geroutetes Overlay

©2019, Juniper Networks, Inc.


5
Referenzarchitektur IP Fabric EVPN-VXLAN

Edge-Routing-Overlay (alias Leaf Routed)


In diesem Ethernet-Servicemodell werden die IRB-Schnittstellen zu Leaf-Geräte-VTEPs am Edge des Overlay-Netzwerks
verschoben, um das IP-Routing näher an die Endsysteme zu bringen. Aufgrund der speziellen ASIC-Fähigkeiten, die zur
Unterstützung von Bridging, Routing und EVPN/VXLAN in einem Gerät erforderlich sind, sind Edge-Routing-Bridging-
Overlays nur bei bestimmten Switches möglich, z. B. bei der leistungsstarken und vielseitigen QFX10000-Switch-Reihe von
Juniper Networks.
Diese Option ermöglicht einen schnelleren Server-zu-Server-, Intra-Datencenter-Verkehr (auch als Ost-West-Verkehr
bekannt), bei dem die kommunizierenden Endsysteme an dasselbe Leaf-Gerät-VTEP angeschlossen sind. Folglich
erfolgt das Routing viel näher an den Endsystemen als bei zentral gerouteten Bridging-Overlays. Es ermöglicht auch ein
einfacheres Gesamtnetzwerk.
Bei diesem Modell sind die Spine-Geräte so konfiguriert, dass sie nur IP-Verkehr verarbeiten, sodass die Notwendigkeit
entfällt, Bridging-Overlays auf die Spine-Geräte auszudehnen.

Lean Spine

Blaues Grünes
VLAN VLAN

L2 VXLAN

Über Ethernet
verbundenes Endsystem

Blaues VLAN Grünes VLAN

Abbildung 5: Edge-Routing-Overlay

Overlay-Design und Bereitstellungsoptionen


Betreiber haben mehrere Möglichkeiten, ihre Overlay-Services zu gestalten. Tabelle 1 zeigt Überlegungen zu Central- und
Edge-Bereitstellungen.

Tabelle 1: Central- und Edge-Routing-Bereitstellungen im Vergleich

Wann empfiehlt sich Central-Routing? Wann empfiehlt sich Edge-Routing?


Wenn der meiste Verkehr in Nord-Süd-Richtung verläuft Wenn der meiste Verkehr in Ost-West-Richtung verläuft und
(normalerweise auf dem Campus) innerhalb des Pod stark segmentiert ist
Wenn eine zentralisierte IP/VRF-Verwaltung des Tenant Wenn der Umfang hoch ist und der Status verteilt werden muss,
bevorzugt wird um die Konvergenzzeit bei Ausfällen zu verkürzen
Wenn Leaf-Geräte kein VXLAN-Routing unterstützen Wenn Konfigurationskomplexität durch Controller abstrahiert wird

©2019, Juniper Networks, Inc.


6
Referenzarchitektur IP Fabric EVPN-VXLAN

Randgeräte
Randgeräte stellen eine Verbindung zu externen Geräten (z. B. einem WAN oder außerhalb einer Fabric) oder zu Services her,
einschließlich (aber nicht beschränkt auf) Firewalls, Load Balancer, Domain Name System (DNS), Dynamic Host Configuration
Protocol (DHCP) und andere. Randgeräte können sich auf einem Leaf (Abbildung 6) oder Spine (Abbildung 7) befinden, völlig
unabhängig von der Positionierung des Gateways auf Leaf- oder Spine-Geräten.

Lean Spine

L2 VXLAN
Leaf-Randgeräte

Services (SRX/DNS/DHCP)
oder WAN

Blaues VLAN Grünes VLAN

Abbildung 6: Leaf-Randgerät

WAN oder Geräte außerhalb


der Fabric

Spine-Randgeräte

Blaues VLAN Grünes VLAN

Abbildung 7: Spine-Randgerät

©2019, Juniper Networks, Inc.


7
Referenzarchitektur IP Fabric EVPN-VXLAN

Multihoming
Multihoming-Support für Ethernet-verbundene Systeme
Die über Ethernet verbundene Multihoming-Technologie ermöglicht einen Lastausgleich des Ethernet-Datenverkehrs über die
Fabric zwischen VTEPs auf verschiedenen Leaf-Geräten, die an dasselbe Endsystem angeschlossen sind.

Zu
Spine-Geräten Leaf Leaf Leaf

ESi

Über Ethernet
verbundenes Endsystem

Abbildung 8: Über Ethernet verbundenes Endsystem-Multihoming

Service-Einfügung
Jedes Datencenter verfügt über zugehörige Services, einschließlich (aber nicht beschränkt auf) Firewalls, Load Balancer,
DNS, DHCP und andere. Es gibt zwei primäre Methoden, um Services in das Netzwerk einzufügen. Abbildung 9 zeigt eine
Serviceblock-Architektur mit einem Cluster der SRX-Serie, der direkt mit den Spine-Geräten verbunden ist.

Mandant 1
Blaues
VLAN

Mandant 2
Grünes
VLAN

Chassis-Cluster der SRX-Serie

Blaues VLAN Grünes VLAN

Abbildung 9: Serviceblock, der direkt mit Spine-Geräten verbunden ist

Obwohl dieser Ansatz, bei dem der Serviceblock direkt mit den Spine-Geräten verbunden ist, weniger zentralisiert ist, kann
er dennoch jeden Service bereitstellen, der vom Datencenter benötigt wird.

©2019, Juniper Networks, Inc.


8
Referenzarchitektur IP Fabric EVPN-VXLAN

Dieses Bereitstellungsmodell wird typischerweise in den folgenden Anwendungsfällen eingesetzt:


• Betreiber, denen es nichts ausmacht, wenn ihre Spine-Geräte mehrere Funktionen erfüllen
• Betreiber, die ein verteiltes Modell verwenden, bei dem Services an verschiedenen Punkten im Datencenter vorhanden
sein können
• Datencenter, in denen Spine-Geräte-Ports für die Verbindung mit Servicegeräten eingespart werden können
Eine zweite Methode zum Einfügen von Services in das Netzwerk unter Verwendung eines gemeinsamen „Services-Blocks”, der
über ein oder mehrere „Service-Leaf”-Geräte mit dem Netzwerk verbunden ist, ist in Abbildung 10 dargestellt.

Spine-Randgeräte

Mandant 1
RETH RETH Blaues
VLAN

Mandant 2
Grünes
Gehäuse-Cluster der SRX-Serie VLAN

Grünes VLAN
Servicebaustein
Blaues VLAN

Abbildung 10: Mit Service-Leaf-Geräten verbundener Services-Block

Eine Services-Block-Architektur, die mit Service-Leaf-Geräten verbunden ist, wird normalerweise verwendet, um Services
an einem gemeinsamen Standort im Datencenter zu zentralisieren. Der Services-Block kann zur Bereitstellung beliebiger
Services verwendet werden, z. B. Firewalls, Load Balancer, DNS-Server, DHCP-Server und jede andere Art von allgemeinen
Netzwerkservices, die für das Datencenter erforderlich sein können.
Ein Services-Block, der mit Service-Leaf-Geräten verbunden ist, wird typischerweise in den folgenden Anwendungsfällen
eingesetzt:
• Betreiber, die ihre Spine-Geräte nicht als Endpunkt für EVPN-VXLAN-Datenverkehr einsetzen wollen
• Betreiber, die einen zentralen Verwaltungspunkt für ihre Services wünschen
• Größere Datencenter, in denen die Spine-Geräte-Ports begrenzt sind und für die Konnektivität mit folgenden Geräten
reserviert werden müssen
• Umgebungen, in denen einfachere Routing-Richtlinien erwünscht sind

Vernetzung von Datencentern


Die meisten Unternehmen setzen heute mehrere Datencenter ein. Wenn mehrere Datencenter im Einsatz sind,
ist es eine häufige Anforderung, sie miteinander zu verbinden. EVPN-VXLAN vereinfacht die DCI-Funktionalität (Data Center
Interconnect) durch die Verwendung desselben Protokolls, das innerhalb des Datencenters zur Erstellung des DCI-Overlays
verwendet wird.

Es gibt zwei Optionen für die Bereitstellung von DCI: Layer 2 und Layer 3. Beachten Sie, dass diese Konzepte hier zwar in
einem DCI-Kontext dargestellt werden, dass dieselben Konzepte aber auch auf die Inter-Pod-Konnektivität innerhalb eines
Datencenters angewendet werden können.

Layer 2 DCI
In einem L2-DCI, auch als „L2-Strecke” bekannt, werden ein VLAN und das zugehörige IP-Subnetz über zwei oder mehr
Datencenter gespannt. Nur die VLANs, die dies erfordern, sollten gestreckt werden.

©2019, Juniper Networks, Inc.


9
Referenzarchitektur IP Fabric EVPN-VXLAN

Layer 3 DCI
L3 DCI wird in einer EVPN-VXLAN-Umgebung unter Verwendung der EVPN Typ 5-Route erreicht. Das Subnetz
darf nur innerhalb eines einzigen Datencenters existieren; andernfalls wird es zu einer L2-DCI-Verbindung und,
wie oben erläutert, sollten nur VLANs, die dies erfordern, gestreckt werden. EVPN Typ 5-Routen sind die empfohlene
Methode, um L3 DCI zu erreichen.

Abbildung 11 zeigt ein DCI-Referenzmodell mit Spine-Randgeräten und Abbildung 12 zeigt dasselbe, wobei der DCI-
Datenverkehr über Service-Leaf-Geräte austritt.

DCI-Optionen:
1. IP-Backbone
2. MPLS-Backbone

EVPN Typ 5

DC1 DC2
EVPN Typ 2/
L2 Stretch

RETH1 RETH2 RETH1 RETH2


/ESI /ESI /ESI /ESI

Gehäuse-Cluster der SRX-Serie Gehäuse-Cluster der SRX-Serie

Grünes VLAN
Servicebaustein Servicebaustein Blaues VLAN Rotes VLAN
Blaues VLAN

Abbildung 11: Eine DCI-Referenzarchitektur mit Spine-Randgeräten

EVPN Typ 5

DC1 DC2
EVPN Typ 2/
L2 Stretch

RETH1 RETH2 RETH1 RETH2


/ESI /ESI /ESI /ESI

Gehäuse-Cluster der SRX-Serie Gehäuse-Cluster der SRX-Serie

Grünes VLAN
Servicebaustein Servicebaustein Blaues VLAN Rotes VLAN
Blaues VLAN

DCI-Optionen:
1. IP-Backbone
2. MPLS-Backbone

Abbildung 12: Eine DCI-Referenzarchitektur mit Leaf-Randgeräten

©2019, Juniper Networks, Inc.


10
Referenzarchitektur IP Fabric EVPN-VXLAN

Multicast-aktiviertes EVPN-basiertes Datencenter


Multicast in einer EVPN-Umgebung ist relativ einfach, da der Broadcast-, unbekannte Unicast- und Multicast-Datenverkehr
(BUM) innerhalb der EVPN-VXLAN-Fabric zu allen anderen VTEPs repliziert wird, die zum selben Virtual Network Identifier (VNI)
gehören (auch bekannt als Ingressreplikation oder Headend-Replikation). Dies ist eine einfachere Lösung für kleinere Einsätze,
da keine Multicastprotokolle im unterlagerten Netzwerk erforderlich sind. Bei größeren Bereitstellungen mit Multicast-fähiger
Infrastruktur kann jedoch die Ingress-Replikation für sich allein genommen zu Skalierbarkeits- und Leistungsproblemen führen.
Die Multicast-Optimierung in einer Overlay-Umgebung ist von entscheidender Bedeutung, um diese Einschränkungen zu
beheben, die sich aus der Ingress-Replikation ergeben.

Multicast in Overlay – Multicast-Weiterleitung zwischen Subnetzen


Wie in Abbildung 13 zu sehen ist, wird in Netzwerken mit selektiver Multicast-Optimierung (SMET/EVPN Typ 6) die Replikation
nicht an Leaf 3 gesendet, wenn kein aktiver Empfänger vorhanden ist. Ohne SMET-Optimierung hätte dasselbe Eingangsgerät
die Last der Replikation mehrerer Kopien übernommen, und alle Geräte hätten den Multicast-Verkehr empfangen, wodurch
Fabric-Bandbreite verschwendet worden wäre. Da das Spine-Gerät als assistierter Replikator (AR) konfiguriert ist, delegiert das
eindringende Leaf 1 die Replikationsaufgabe an das VNI-fähige Spine-Gerät.

Mit AR
Mit SMET
R2
R2 R1
R1

Leaf 1 Leaf 2 Leaf 3

Datenverkehr wird NICHT auf dem


Server repliziert, wenn Leaf IGMP-Snooping
und IGMP Join Synce unterstützt
(EVPN Typ 7/8)

Abbildung 13: Overlay-Multicast-Weiterleitung zwischen Subnetzen

Multicast in Overlay – Multicast-Weiterleitung zwischen Subnetzen


Unabhängig davon, ob es zentral oder am Edge geroutet ist, erfolgt das Inter-VNI-Multicast-Routing auf dem
Spine-Gerät. In Abbildung 14 sind sowohl Leaf 1 als auch Leaf 2 mit Empfängern ausgestattet, und mehrere Exemplare
werden über das Spine-Gerät gesendet, was bei lokalen Empfängern (Empfänger 1) zu Hair-Pinning führt.

©2019, Juniper Networks, Inc.


11
Referenzarchitektur IP Fabric EVPN-VXLAN

Inter-VNI-
MCAST-Routing

Leaf 1 Leaf 2

Quelle 1 Receiver 1 Receiver 2

Abbildung 14: Multicast-Weiterleitung zwischen Subnetzen

Multicast in einer zentral gerouteten Overlay-Architektur


Wenn eine Multicast-fähige, zentral geroutete EVPN-VXLAN-Fabric über ein Leaf-Randgerät mit einem entfernten
Datencenter oder einem Legacy-Campus-Netzwerk verbunden ist, wird das Multicast-Gateway im Allgemeinen auf dem
Randgerät angeordnet, wenn sich Quellen und Empfänger außerhalb der Fabric befinden (siehe Abbildung 15).

S
Campus-
Netzwerk R

Vorhandenes
PIM oder R
MVPN (nicht
EVPN) S
basierend auf DC

Unicast-Gateway
RETH1 RETH2
/ESI /ESI
Multicast-Gateway

Randrolle

Unterstützter Replikator
Gehäuse-Cluster der SRX-Serie
S MCAST-Quelle
R R R
Servicebaustein
S MCAST-Receiver

Abbildung 15: Multicast-aktivierte, zentral geroutete Overlay-Architektur

©2019, Juniper Networks, Inc.


12
Referenzarchitektur IP Fabric EVPN-VXLAN

Automatisierung der Datencenter EVPN-VXLAN Fabrics


Die Konfiguration von EVPN-VXLAN ist von einer Befehlszeile aus oder mithilfe von Automatisierungstools wie Ansible
möglich. Die Einrichtung neuer Underlay- und Overlay-Netzwerke kann zudem über Multicloud-Plattformen wie die
Juniper Contrail® Enterprise Multicloud orchestriert werden, die mit Juniper Contrail Command eine eigene Schnittstelle
für das einheitliche Netzwerk-Management bietet. Abbildung 16 zeigt die Optionen, die den Kunden zur Automatisierung
ihrer EVPN-VXLAN-Fabric zur Verfügung stehen.

Automatisierung der EVPN-VXLAN Fabric durch Ansible/Saltstack


Die Kombination aus Ansible/Saltstack und den Automatisierungs- und Orchestrierungstools von Juniper vereint das Wissen
und die Erfahrung erfahrener Entwickler, Betreiber und Administratoren von IT-Lösungen in verschiedenen Organisationen.
Die gemeinsame Lösung befasst sich mit den häufigsten Anwendungen der Automatisierung und Orchestrierung bei der
Verwaltung und Bereitstellung von IT-Ressourcen, einschließlich Konfigurationsautomatisierung, testgetriebener Vernetzung
und kontinuierlicher Compliance.

Ansible/Saltstack CEM

• Sehr flexibel • Graphische Schnittstelle


• Unterstützt MX-Serie und • Underlay- und Overlay-
QFX-Serie Fabric-Management
• Support durch die Community • Konnektivität und Sicherheit
CEM in der Multicloud

Abbildung 16: Automatisierung der EVPN-VXLAN Fabric

Contrail Enterprise Multicloud


Die Rolle von Juniper Contrail Enterprise Multicloud besteht darin, alles zu vereinen und einen automatisierten Betrieb,
Transparenz und Systemintegration in der gesamten Multicloud-Umgebung zu ermöglichen.

Dazu müssen sämtliche Netzwerkgeräte in das Fabric integriert werden. Nur so können Datencenter und private Clouds
mit öffentlichen Clouds verknüpft und mehrere verteilte Domains in einer einzigen Netzwerkarchitektur vereint werden.
Das Ergebnis: eine homogene Netzwerkumgebung, in der Nutzer von überall aus auf dieselben Ressourcen zugreifen und
dabei dieselbe Leistung erwarten können.

Multicloud
Ziel der Multicloud ist es, die Ausführung von Workloads überall im Netzwerk zu ermöglichen, damit die Entscheidung
über die in einem konkreten Fall zu nutzenden Ressourcen von den Kosten oder anderen kommerziellen und betrieblichen
Gegebenheiten abhängig gemacht werden kann. Die Benutzer sollten bei der Ausführung einer Workload in einer privaten
oder öffentlichen Cloud keinen Unterschied bemerken.

Das ist nur möglich, wenn das Netzwerk bezüglich der Konnektivität, der Sicherheit und der Bereitstellung und Nutzung
neuer Anwendungen und Services in die Anwendungsebene integriert ist. Auf dieser obersten Ebene der Multicloud-
Architektur werden die Elemente der unteren Ebenen so abstrahiert, dass die Nutzer nur die Services sehen, die für jede
der verfügbaren Anwendungen erforderlich sind.

©2019, Juniper Networks, Inc.


13
Referenzarchitektur IP Fabric EVPN-VXLAN

Contrail Insights

1
Contrail Command Contrail Command Contrail Command Contrail Command
✓ Fabric aufbauen
Nutzername ✓ Hybrid-Konnektivität bereitstellen
✓ PODs einrichten
Nutzername ✓ NE/Sec. anwenden Richtlinien
✓ Monitor / Troubleshoot

Betreiber
Verlagerung der Komplexität mehrerer Standorte auf eine Schnittstelle

4
AWS VPC - 1

Multicloud-
Kubernetes Architektur
OpenShift GCP VPC - 2
2
OpenStack

VMware
vRouter
(+Sicherheit)
3

Abbildung 17: Referenzarchitektur Contrail Enterprise Multicloud

Telemetrie/Analysen
Herkömmliche Verwaltungsmethoden wie SNMP- und CLI-Abfragemodelle sind in Bezug auf Skalierbarkeit und Effizienz
begrenzt. Die Telemetry Interface (JTI)-Lösung von Juniper Junos® überwindet diese Probleme durch den Einsatz von
Mechanismen wie einem asynchronen Push-Modell zur Eliminierung des traditionellen Polling. JTI ist hoch skalierbar und
kann Tausende von Sensoren in den physischen und virtuellen Knoten von Juniper überwachen. Sie unterstützt auch das
Streaming von Betriebsdaten in Echtzeit, um den Betriebszustand mit externen Controllern und Analyseplattformen zu
synchronisieren, was zu einer schnelleren Entscheidungsfindung im Vergleich zu traditionelleren Ansätzen führt.

Contrail Insights
Juniper Contrail Insights bietet einen umfassenden Einblick in Multi-Cloud-Umgebungen (wie in den Abbildungen 18
und 19 dargestellt), wodurch potenzielle Netzwerkprobleme eliminiert werden und der Betrieb einfacher und effektiver
gestaltet wird. Es ermöglicht Ihnen die Visualisierung und Analyse sowohl physischer als auch virtueller Umgebungen,
wobei Überwachung und intentbasierte Analysen verwendet werden, um Rohdaten aus einer Vielzahl von Ressourcen in
ein Format zu transformieren, das sofort einsatzbereit ist.

Die Netzwerkgeräte-Überwachungsfunktion von Contrail Insights bietet eine Infrastruktur-Leistungsüberwachung (IPM) in


Echtzeit für Netzwerkgeräte in Datencentern und auf dem Campus, einschließlich Switches der QFX-Serie und der EX-Serie,
unter Verwendung von JTI und OpenConfig.

Die Cloud-Infrastruktur und Anwendungsüberwachung bietet Echtzeit-Überwachung und -Analyse von DevOps und
Cloud-nativen Umgebungen und unterstützt eine Kombination aus leistungsstarken Bare-Metal-Systemen in privater
Cloud, virtuellen Maschinen in OpenStack und Containern in Kubernetes-Umgebungen. Contrail Insights überwacht und
analysiert auch Anwendungen, die in öffentlichen Clouds laufen, wie z. B. Amazon Web Services (AWS), Microsoft Azure
und Google Cloud Platform (GCP).

©2019, Juniper Networks, Inc.


14
Referenzarchitektur IP Fabric EVPN-VXLAN

Contrail Insights

Anwendungen und Services Cloud-Infrastruktur Softwaredefinierte Infrastruktur Physische Infrastruktur

Abbildung 18: Transparenz und Analysen auf allen Ebenen

Analysen

Contrail Insights

Analysen
Contrail

Topologieerkennung Statusbasierte
Orchestrierung

Contrail Contrail

Private Clouds
mit beliebiger
Arbeitsauslastung

Abbildung 19: Analysen in einer Contrail Enterprise Multicloud-Umgebung

©2019, Juniper Networks, Inc.


15
Referenzarchitektur IP Fabric EVPN-VXLAN

Fazit
Die EVPN-VXLAN-Bereitstellung von Juniper stellt eine moderne, offene, standardbasierte und automatisierungsnative
Steuerungsebene dar, die mehrere Technologieprobleme löst und Unternehmen dabei unterstützt, Daten über Legacy-,
On-Premises- und Cloud-basierte Verarbeitung zu verschieben und zu verarbeiten. Die Beteiligung von Juniper an der
Entwicklung, Standardisierung und Implementierung der EVPN-Technologie demonstriert die Fähigkeiten zur Lösung der
weltweit komplexesten Probleme und bestätigt Junipers Leitprinzip, Simplizität in der Technik voranzutreiben.

Für weitere Informationen zum Entwurf und zur Bereitstellung von Overlay-Netzwerken lesen Sie bitte die Cloud Data
Center Blueprint-Architekturkomponenten in der Technischen Bibliothek.

Über Juniper Networks


Juniper Networks vereinfacht mit seinen Produkten, Lösungen und Services die Netzwerke, die unsere Welt umspannen.
Durch kontinuierliche Innovation überwinden wir die Einschränkungen und die Komplexität, mit der Netzwerkadministratoren
in der Cloud-Ära zu kämpfen haben, und unterstützen unsere Kunden und Partner bei der Bewältigung ihrer größten
Herausforderungen. Wir bei Juniper Networks sind überzeugt, dass Netzwerke ein Medium für den weltweiten
Wissensaustausch und den die Welt verändernden Fortschritt der Menschheit sind. Deshalb haben wir uns das Ziel gesetzt,
bahnbrechende Lösungen für automatisierte, skalierbare und sichere Netzwerke zu entwickeln, die mit dem Tempo unserer
schnelllebigen Geschäftswelt Schritt halten.

Hauptsitz Hauptniederlassung für die


Juniper Networks, Inc. Regionen APAC und EMEA

1133 Innovation Way Juniper Networks International B.V.

Sunnyvale, CA 94089 USA Boeing Avenue 240

Telefon: +1 888 586 4737 1119 PZ Schiphol-Rijk

oder +1 408 745 2000 Amsterdam, Niederlande

Fax: +1 408 745 2100 Telefon: +31 0207 125 700

www.juniper.net/de Fax: +31 0207 125 701

Copyright 2020 Juniper Networks, Inc. Alle Rechte vorbehalten. Juniper Networks, das Juniper Networks-Logo, Juniper und Junos sind eingetragene Marken von Juniper Networks,
Inc. in den USA und anderen Ländern. Alle anderen Marken, eingetragenen Marken, Servicemarken und eingetragenen Servicemarken sind Eigentum ihrer jeweiligen Inhaber.
Eine Haftung durch Juniper Networks für fehlerhafte Angaben in diesem Dokument wird ausgeschlossen. Juniper Networks behält sich das Recht vor, diese Veröffentlichung ohne
Ankündigung zu ändern, zu übertragen oder anderweitig zu überarbeiten.

8030015-002-DE Okt. 2019 16