Die explosionsartige Zunahme containerisierter Workloads, verteilter Kubernetes-Cluster und East-West-Microservice-Kommunikation hat traditionelle hierarchische Drei-Schichten-Rechenzentrumsnetzwerke (Core, Distribution, Access) völlig obsolet gemacht. Klassische Layer-2-Spanning-Tree-Protokoll-Architekturen (STP) blockieren bis zu 50 % der verfügbaren Bandbreite, um Switching-Loops zu verhindern, leiden unter quälend langsamer Konvergenz bei Topologieänderungen und brechen bei groß angelegter Virtual-Machine-Mobilität zusammen. Moderne Hyperscale- und Enterprise-Rechenzentren setzen auf non-blocking Clos-Leaf-Spine-Topologien entkoppelt in eine zugrunde liegende Hochgeschwindigkeits-IP-Routing-Schicht (Underlay) und eine agile virtualisierte Netzwerkschicht (Overlay), gesteuert durch BGP-EVPN und VXLAN (RFC 7348). In dieser technischen Monografie analysieren wir die mathematischen Grundlagen von Clos-Fabrics, VXLAN-Kapselung, BGP-EVPN-Routentypen (RFC 7432) und Distributed Anycast Default Gateways.
Referenz für Data Center Fabric Engineering
Entwickelt vom Enterprise Network & Cloud Infrastructure Editorial Board. Architektur-Baselines: RFC 7938 (Use of BGP for Routing in Large-Scale Data Centers), RFC 7348 (Virtual eXtensible Local Area Network), RFC 7432 (BGP MPLS-Based Ethernet VPN) und RFC 8365 (BGP EVPN for VXLAN). Ziel: Null Paketverlust über ECMP-Hash-Pfade mit deterministischer 1-Hop-Leaf-to-Spine-East-West-Latenz.
1. Clos-Leaf-Spine-Topologien: Beseitigung von Spanning-Tree-Engpässen
Moderne Data-Center-Fabrics basieren auf den mehrstufigen Switching-Netzwerkkonzepten, die 1953 von Charles Clos entwickelt wurden. In einer zweistufigen Clos-Fabric ist jeder Leaf-Switch (Top-of-Rack / ToR) in einem Full-Mesh mit jedem Spine-Switch verbunden. Leaf-Switches verbinden sich nicht mit anderen Leafs, und Spine-Switches verbinden sich nicht mit anderen Spines. Diese deterministische physische Geometrie garantiert, dass zwei beliebige Server, die an unterschiedliche Leaf-Switches angeschlossen sind, durch genau drei physische Hops getrennt sind (Leaf → Spine → Leaf), was eine vorhersagbare Latenz und eine gleichmäßige bisektionale Bandbreite über die gesamte Rechenfarm hinweg sicherstellt.
Im Gegensatz zu STP-Topologien, die redundante Uplinks in einen inaktiven blockierenden Zustand versetzen, nutzen Leaf-Switches Equal-Cost Multi-Pathing (ECMP) um ausgehende Datenströme gleichzeitig über alle verfügbaren Spine-Switches zu hashen. Wenn ein Unternehmen vier 400G-Spine-Switches einsetzt, nutzt ein 32-Port-100G-Leaf-Switch mit vier 100G-Uplinks 100 % seiner gesamten Uplink-Bandbreite von 400 Gbps über die aktive Spine-Ebene.
2. Underlay-Routing-Mechanismen: Single-AS- vs. eBGP-per-Leaf-Muster
Die einzige Aufgabe des physischen Underlay-Netzwerks besteht darin, einen schnellen, schleifenfreien Punkt-zu-Punkt-IP-Transport zwischen Leaf- und Spine-Loopback-Adressen (VTEPs) bereitzustellen. Während Interior-Link-State-Protokolle wie OSPF oder IS-IS als Underlay-IGP dienen können, setzen Hyperscale-Rechenzentrumsdesigns vorwiegend auf eBGP im Underlay (RFC 7938) aufgrund der überlegenen Skalierbarkeit, der vorhersehbaren Fehlerisolierung und der vereinfachten Präfix-Unterdrückung:
- eBGP-per-Rack (Empfohlen): Jedes Leaf-Paar teilt sich eine eindeutige private 2-Byte- oder 4-Byte-ASN, während alle Spine-Switches eine einzige gemeinsame ASN nutzen. Die BGP-AS-Path-Schleifenerkennung verhindert auf natürliche Weise Routing-Schleifen, während standardmäßiges ECMP die Datenströme über die Spines ausbalanciert, ohne dass eine komplizierte IGP-Optimierung erforderlich ist.
- Unnumbered BGP: Eliminiert die Notwendigkeit, Tausende von Punkt-zu-Punkt-/30- oder /31-Subnetzen über Leaf-Spine-Verbindungen zuzuweisen und zu dokumentieren, indem BGP direkt über IPv6-Link-Local-Adressen (RFC 5549) ausgeführt wird und eine erweiterte Next-Hop-Kodierung verwendet wird, um IPv4-Präfixe über IPv6-Peering-Sitzungen anzukündigen.
3. VXLAN-Kapselung (RFC 7348) & Der Virtual Tunnel Endpoint
VXLAN bietet Layer-2-Overlay-Netzwerkvirtualisierung über Layer-3-IP-Underlays. VXLAN kapselt einen vollständigen ursprünglichen Ethernet-Frame in ein Standard-UDP-Paket (Ziel-UDP-Port 4789). Zu den Schlüsselkomponenten von VXLAN gehören:
- VXLAN Network Identifier (VNI): Ein 24-Bit-Segment-Identifikator, der das herkömmliche 12-Bit-IEEE-802.1Q-VLAN-Tag ersetzt. VNIs erweitern die maximale Segment-Skalierung von 4,094 VLANs auf über 16.7 Millionen isolierte virtuelle Netzwerke.
- Virtual Tunnel Endpoint (VTEP): Die Hardware-Einheit (typischerweise der Leaf-Switch-ASIC), die für die Kapselung ausgehender Ethernet-Frames in IP/UDP-Pakete und die Entkapselung eingehender Pakete vor deren Zustellung an lokale Server-Ports verantwortlich ist.
- UDP-Entropie-Hashing: Der Quell-UDP-Port im äußeren Header wird dynamisch durch Hashing der Layer-2/3/4-Header des inneren Ethernet-Frames berechnet. Dies ermöglicht es Underlay-Spine-Switches, den VXLAN-Datenverkehr über ECMP-Pfade auszubalancieren, ohne die gekapselte Nutzlast zu untersuchen.
4. BGP-EVPN-Control-Plane (RFC 7432): Eliminierung von Flood-and-Learn
Frühe VXLAN-Implementierungen verließen sich auf IP-Multicast im Underlay, um die Flood-and-Learn-Erkennung von MAC-Adressen zu handhaben, was zu einem erheblichen betrieblichen Overhead und einer Aufblähung des Multicast-Zustands führte. Ethernet VPN (EVPN) in Verbindung mit MP-BGP bietet eine standardisierte, skalierbare Control Plane, die MAC- und IP-Erreichbarkeit direkt über BGP-Routing-Updates ankündigt:
| EVPN-Routentyp | Standardname | RFC-Referenz | Betriebsfunktion im VXLAN-Fabric |
|---|---|---|---|
| Typ-1 | Ethernet Auto-Discovery | RFC 7432 | Erkennt Multi-Homed-Leaf-Switches (ESI) und ermöglicht eine schnelle Failover-Konvergenz. |
| Typ-2 | MAC / IP-Ankündigung | RFC 7432 | Kündigt die MAC-Adresse des Endhosts und optional die ARP-IP-Adresse an, die an eine spezifische VTEP-IP gebunden ist. |
| Typ-3 | Inclusive Multicast Ethernet Tag | RFC 7432 | Richtet Head-End-Replikationstunnel für Broadcast, Unknown Unicast & Multicast (BUM) ein. |
| Typ-4 | Ethernet Segment Route | RFC 7432 | Wählt den Designated Forwarder (DF) auf Dual-Homed-Multi-Chassis-Leaf-Links (ESI-LAG) aus. |
| Typ-5 | IP-Präfix-Route | RFC 7432 / 9136 | Kündigt Inter-Subnetz- oder geroutete externe Präfixe an, ohne einzelne Host-MACs anzukündigen. |
5. Verteiltes Anycast-Standard-Gateway & Symmetrisches IRB
In Legacy-Netzwerken waren First-Hop-Standard-Gateways auf zentralisierten Distributions-Switches unter Verwendung von VRRP oder HSRP konzentriert, was den gesamten Inter-VLAN-Verkehr dazu zwang, über den Core zu laufen (Hairpinning). In einer modernen EVPN-VXLAN-Fabric fungiert jeder Leaf-Switch gleichzeitig als Standard-Gateway für alle Subnetze durch eine verteilte Anycast-Gateway- Architektur.
Jeder Leaf-Switch ist mit der identischen virtuellen IP-Adresse und virtuellen MAC-Adresse über jedes VNI hinweg konfiguriert. Wenn eine virtuelle Maschine oder ein Container eine ARP-Anfrage für sein Gateway sendet, antwortet das lokale ToR-Leaf sofort mit Leitungsgeschwindigkeit. Beim Routing zwischen verschiedenen VNIs führt die Fabric ein symmetrisches Integrated Routing and Bridging (IRB)aus: Der Ingress-Leaf-Switch routet das Paket vom Quell-VNI zu einem mandantenspezifischen Layer-3-VNI, kapselt es zum Ziel-Leaf-VTEP ein, und das Egress-Leaf routet das Paket vom L3-VNI in das Ziel-Subnetz, wodurch kein trianguläres Routing entsteht.
6. Technischer Vergleich: Legacy 3-Tier STP vs. EVPN-VXLAN Leaf-Spine
| Architektur-Vektor | Legacy 3-Tier STP-Netzwerk | BGP-EVPN VXLAN Leaf-Spine-Fabric |
|---|---|---|
| Link-Auslastung | Aktiv/Standby (50 % Bandbreite durch STP blockiert) | 100 % Aktiv/Aktiv ECMP über alle Spine-Uplinks |
| Fehlerdomäne | VLAN-weite Broadcast-Stürme betreffen das gesamte Rechenzentrum | Isoliert pro VNI; Broadcast durch BGP-Control-Plane eingedämmt |
| Segmentierungsskala | Max. 4,094 VLANs (802.1Q 12-Bit-Limit) | 16.7+ Millionen VNIs (VXLAN 24-Bit-Kennung) |
| Ost-West-Latenz | Variabel (2 bis 6 Hops abhängig vom STP-Root) | Deterministische 3 Hops (Leaf → Spine → Leaf) |
| Host-Erkennung | Data-Plane Broadcast Flood-and-Learn | Control-Plane MP-BGP Typ-2 Routen-Updates |
| Standard-Gateway | Zentralisierte HSRP/VRRP Aktiv-Standby-Paare | Verteiltes Anycast-Gateway, aktiv auf jedem ToR-Leaf |
7. Produktions-Switch-Konfiguration: Arista EOS EVPN-VXLAN Leaf
Nachfolgend finden Sie eine produktive Arista EOS-Konfiguration für einen ToR-Leaf-Switch, der ein VXLAN-Overlay mit EVPN-Control-Plane und verteiltem Anycast-Gateway aufbaut:
! ==============================================================================
! Arista EOS EVPN-VXLAN Leaf Switch Configuration
! ==============================================================================
service routing protocols model multi-agent
!
vlan 10
name Web_Tier
!
interface Vlan10
description Web_Tier_Distributed_Gateway
ip address virtual 10.1.10.1/24
!
interface Loopback0
description Underlay_Router_ID
ip address 10.255.1.11/32
!
interface Loopback1
description VTEP_Source_IP
ip address 10.254.1.11/32
!
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan vlan 10 vni 10010
!
router bgp 65011
router-id 10.255.1.11
neighbor SPINE_PEERS peer group
neighbor SPINE_PEERS remote-as 65000
neighbor SPINE_PEERS send-community extended
neighbor 10.255.0.1 peer group SPINE_PEERS
neighbor 10.255.0.2 peer group SPINE_PEERS
!
address-family evpn
neighbor SPINE_PEERS activate
!
vlan 10
rd 65011:10010
route-target both 10010:10010
redistribute learned
!Häufig gestellte Fragen (FAQ)
Warum ist für EVPN auf Arista EOS ein Multi-Agent-Routing-Modell erforderlich?
Arista EOS betrieb traditionell separate, diskrete Routing-Engines für Standard-IP-Protokolle. BGP-EVPN erfordert eine kontinuierliche bidirektionale Koordination zwischen dem BGP-Routing-Daemon, der Layer-2-Forwarding-Engine (MAC-Tabelle) und dem VXLAN-VTEP-Hardwaretreiber. Das Ausführen von service routing protocols model multi-agent aktiviert den Multi-Protokoll-EVPN-Daemon (bgp-evpn), der erforderlich ist, um den Layer-2- und Layer-3-Forwarding-Status mit der Hardware-Forwarding-Information-Base zu synchronisieren.
Was ist der Unterschied zwischen symmetrischem und asymmetrischem IRB in VXLAN?
Bei Asymmetric IRB routet und bridgt das Ingress-Leaf Pakete zur Ziel-VNI, bevor es sie über den VXLAN-Tunnel sendet, was erfordert, dass jedes Leaf Routing-Status und ARP-Einträge für alle VNIs im gesamten Rechenzentrum vorhält. Bei Symmetric IRB routet das Ingress-Leaf Pakete in eine intermediäre Tenant Layer-3-VNI (Transit-VNI), und das Egress-Leaf routet das Paket von der L3-VNI in die lokale Ziel-VNI. Symmetric IRB reduziert den Speicherbedarf für MAC- und ARP-Tabellen auf Leaf-Switches drastisch.
Wie handhabt EVPN Broadcast-, Unknown Unicast- und Multicast-Verkehr (BUM) ohne Multicast?
EVPN eliminiert die Anforderung für PIM-Multicast im Underlay durch Ingress Replication (Head-End Replication). Wenn ein Leaf einen BUM-Frame von einem lokalen Server empfängt, fragt es seine EVPN Type-3 Inclusive Multicast-Routing-Tabelle ab. Das Leaf erstellt dann individuelle Punkt-zu-Punkt-Unicast-Kopien des Frames und überträgt diese direkt an jedes entfernte VTEP, das an dieser VNI teilnimmt, wodurch die Komplexität von Underlay-Multicast entfällt.
Was ist ein Ethernet Segment Identifier (ESI) in EVPN?
Ein Ethernet Segment Identifier (ESI) ist eine eindeutige 10-Byte-Kennung, die einem Server zugewiesen wird, der über zwei separate Leaf-Switches dual-homed angebunden ist (Active-Active Multi-Homing). EVPN verwendet ESI-Routen (Type-1 und Type-4), um Split-Horizon-Schleifenvermeidung zu koordinieren, die Wahl des Designated Forwarder für BUM-Verkehr durchzuführen und beiden Leaf-Switches zu ermöglichen, Verkehr gleichzeitig weiterzuleiten, ohne proprietäre Legacy-Protokolle wie Cisco vPC oder Arista MLAG.