EVPN-LAGs in EVPN-VXLAN-Referenzarchitekturen
Dieser Abschnitt bietet einen Überblick über die EVPN-VXLAN-Referenzarchitekturen von Juniper und die Rolle von EVPN-LAGs in diesen Architekturen. Es soll den Lesern helfen, die EVPN LAG-Funktionen in verschiedenen Kontexten zu verstehen.
Die Standard-EVPN-VXLAN-Architektur besteht aus einer 3-stufigen Spine-Leaf-Architektur. Das physische Underlay ist IP-Weiterleitungsfähig – alle Leaf-to-Spine-Underlay-Verbindungen sind in der Regel IPv4-geroutet – und die logische Overlay-Schicht verwendet MP-BGP mit EVPN-Signalisierung für das auf Steuerungsebene basierende MAC-IP-Adresslernen und zum Einrichten von VXLAN-Tunneln zwischen Switches.
Juniper Networks verfügt über vier primäre Datencenter-Architekturen:
Zentral geroutetes Bridging (CRB): Das Routing zwischen VNI erfolgt auf den Spine-Switches.
Edge Routed Bridging (ERB): Das Routing zwischen VNI erfolgt auf den Leaf-Switches.
Bridged Overlay – Inter-VLAN- und Inter-VNI Routing findet außerhalb der EVPN-VXLAN-Fabric statt. Beispiel: Das Routing erfolgt auf dem Firewall-Cluster, der mit dem EVPN-VXLAN verbunden ist.
Centrally-Routed Bridging Mutual (CRB-M) – Architektur, bei der die Spine-Switches auch die vorhandene Datencenter-Infrastruktur mit der EVPN-LAG verbinden. CRB-M-Architekturen werden häufig bei Datencenter-Migrationen verwendet.
EVPN-LAGs in zentral gerouteten Bridging-Architekturen
In der CRB-Architektur empfehlen wir, die EVPN-LAGs auf der Leaf-Ebene bereitzustellen und zwei oder mehr Leaf-Geräte mit jedem Server oder BladeCenter zu verbinden.
Abbildung 1 veranschaulicht die Bereitstellung von EVPN LAG in einer CRB-Architektur.
Derselbe ESI-Wert und dieselbe LACP-System-ID sollten verwendet werden, wenn mehrere Leaf-Geräte mit demselben Server verbunden werden. Eindeutige ESI-Werte und LACP-System-IDs sollten pro EVPN-LAG verwendet werden.
EVPN-LAGs in Edge-Routing-Bridging-Architekturen
Abbildung 2 veranschaulicht die Verwendung von EVPN-LAGs innerhalb einer Edge Routed Bridging (ERB)-Architektur. Die empfohlene EVPN LAG-Bereitstellung in einer ERB-Architektur ähnelt der CRB-Architektur. Der Hauptunterschied zwischen den Architekturen besteht darin, dass die IP-First-Hop-Gateway-Funktion mithilfe von IRB-Schnittstellen mit Anycast-Adressierung auf die Leaf-Ebene verlagert wird.
Die ERB-Architektur bietet ARP-Unterdrückungsfunktionen, die durch die Ankündigung der spezifischsten Host-/32-Typ-5-EVPN-Routen von Leaf-Geräten zu den Spine-Geräten ergänzt werden. Diese Technologiekombination reduziert effizient die Datenverkehrsflut im Datencenter und schafft eine Topologie, die häufig zur Unterstützung von VMTO-Funktionen (Virtual Machine Traffic Optimization) verwendet wird.
EVPN-LAGs in Bridged-Overlay-Architekturen
In einer Bridged-Overlay-Architektur werden VLANs zwischen Leaf-Geräten über VXLAN-Tunnel erweitert. EVPN-LAGs werden in einem Bridged-Overlay verwendet, um Multihoming für Server bereitzustellen und eine Verbindung zu First-Hop-Gateways außerhalb der EVPN-VXLAN-Fabric herzustellen, bei denen es sich in der Regel um Services Gateways der SRX-Serie oder Router der MX-Serie handelt. Die Bridged-Overlay-Architektur hilft, Bandbreite auf den Gateway-Geräten zu sparen und erhöht die Bandbreite und Ausfallsicherheit von Servern und BladeCentern, indem sie Aktiv-Aktiv-Weiterleitung in derselben Broadcast-Domäne bereitstellt.
Abbildung 3 zeigt EVPN-LAGs in einem Beispiel für eine Bridged-Overlay-Architektur.
EVPN-LAGs in zentral gerouteten Bridging-Migrationsarchitekturen
EVPN-LAGs können während einer Migration zu einer der oben genannten EVPN-VXLAN-Referenzarchitekturen zwischen Spine- und Leaf-Geräten eingeführt werden. Diese EVPN-LAG wird in einigen Migrationsszenarien benötigt, um die vorhandene Legacy-ToR-basierte Infrastruktur in die EVPN-VXLAN-Architektur zu integrieren.
Abbildung 4 zeigt ein Virtual Chassis und eine MC-LAG-Architektur, die über eine EVPN-LAG mit Spine-Geräten verbunden sind. Die EVPN-LAG-Bereitstellung erfolgt von den Spine-Geräten während der Migration dieser Topologien in eine EVPN-VXLAN-Referenzarchitektur.
Die CRB-Migrationsarchitektur wird häufig verwendet, wenn ein MC-LAG- oder Virtual Chassis-basiertes Datencenter phasenweise migriert wird. In dieser Architektur wird die EVPN LAG-Funktion auf Spine-Ebene eingeführt, und es wird nur eine Overlay-iBGP-Sitzung zwischen den beiden Spine-Switches ausgeführt. Bei den Top-of-Rack-Switches, die mit den Spine-Geräten verbunden sind, handelt es sich um Legacy-Switches, die als Virtual Chassis- oder MC-LAG-Cluster konfiguriert sind und keine EVPN iBGP-Peerings zu den Spine-Switches aufweisen.
Diese Architektur hilft bei der schrittweisen Bereitstellung von EVPN-VXLAN-Technologien in einem bestehenden Datencenter. Der erste Schritt ist der Aufbau eines EVPN LAG-fähigen Spine-Layers und dann die sequenzielle Migration zu einem EVPN-Steuerungsplan, bei dem die MAC-Adressen für die neuen Leaf-Switches von den Spine-Layer-Switches gelernt werden. Die neuen Leaf-Switches können daher von den erweiterten EVPN-Funktionen wie ARP-Unterdrückung, IGMP-Unterdrückung und optimiertem Multicast profitieren, die von den neuen Switches unterstützt werden.
Das standardmäßige EVPN-Core-Isolationsverhalten sollte in CRB-Migrationsarchitekturen deaktiviert werden. Das standardmäßige EVPN-Core-Isolationsverhalten deaktiviert lokale EVPN-LAG-Mitglieder, wenn das Netzwerk den letzten iBGP-EVPN-signalisierten Peer verliert. Da dieses Peering zwischen den beiden Spine-Geräten während der Migration verloren geht, muss das Standardverhalten, das durch Eingabe der Option in der no-core-isolation edit protocols evpn Hierarchie geändert werden kann, geändert werden, um Coreisolationsereignisse zu verhindern.