BGP EVPN/VXLAN im Rechenzentrum: Praxisleitfaden

Wer heute ein modernes Rechenzentrum betritt, findet unter den Racks fast überall dasselbe architektonische Muster: eine Leaf-Spine-Fabric, zusammengehalten von VXLAN-Tunneln und gesteuert von einer EVPN-Kontrollebene. Es ist leise zum Standard geworden, um Netze zu bauen, die gewaltige Mengen an Ost-West-Verkehr tragen, Dutzende oder Hunderte Mandanten isolieren und wachsen können, ohne dass man die halbe Infrastruktur austauschen muss. Für viele Netzwerker bleibt die Begriffswelt trotzdem ein Buchstabensalat — Overlay, Underlay, VTEP, Route-Type 2, symmetrisches IRB.

Dieser Leitfaden zeigt, wie BGP EVPN und VXLAN tatsächlich zusammenspielen, warum die Branche ältere Layer-2-Designs hinter sich gelassen hat und was die Kombination in der Praxis bedeutet, wenn sie unter einer Private Cloud liegt. Es geht nicht darum, Sie in Protokolldetails zu ertränken, sondern Ihnen ein belastbares Denkmodell an die Hand zu geben, das Sie auch in einem Design-Review vertreten können.

Das Problem, das EVPN/VXLAN löst

Klassische Rechenzentrumsnetze spannten VLANs über viele Switches und verließen sich auf das Spanning Tree Protocol, um Schleifen zu verhindern. Solange der Verkehr überwiegend Nord-Süd floss — Clients zu Servern — funktionierte das. Doch es alterte schlecht. Spanning Tree deaktiviert Verbindungen, um Schleifen aufzubrechen; man bezahlt also für Ports, die man nicht nutzen kann. Der VLAN-Adressraum endet bei 4096 Segmenten, viel zu wenig für eine mandantenfähige Plattform. Und jeder Switch in einer Layer-2-Domäne muss jede MAC-Adresse lernen, die er je sehen könnte, sodass Fehlerdomäne und Hardware-Tabellen mit der Größe aus dem Ruder laufen.

Virtualisierung und verteilte Anwendungen verschärften das. Plötzlich war der Großteil des Verkehrs Ost-West: Microservices, Storage-Replikation, Live-Migration und Datenbank-Cluster, die ununterbrochen zwischen Racks kommunizieren. Eine Topologie, die für Nord-Süd-Flüsse gebaut und auf ein paar Tausend Segmente begrenzt war, kam da nicht mehr mit. EVPN/VXLAN ist die Antwort, auf die sich die Branche geeinigt hat, und sie ruht auf einer eleganten Idee: das Netz, das Pakete bewegt, von dem Netz zu trennen, das entscheidet, wohin sie gehen.

Underlay und Overlay: zwei Netze in einem

Das Fundament ist das Underlay — ein schlichtes, geroutetes IP-Netz, das jeden Leaf und jeden Spine verbindet. Spanning Tree gibt es hier nicht. Stattdessen sind die Verbindungen geroutet, jeder Leaf erreicht jeden Spine, und Equal-Cost Multipath (ECMP) verteilt den Verkehr gleichzeitig über alle verfügbaren Uplinks. Fällt eine Verbindung oder ein Spine aus, konvergiert das Routing in deutlich unter einer Sekunde, und die übrigen Pfade fangen die Last auf. Das Underlay hat genau eine Aufgabe: Pakete zwischen den Loopback-Adressen der Switches schnell und zuverlässig zuzustellen.

Darüber liegt das Overlay — ein Geflecht virtueller Tunnel, das den eigentlichen Mandantenverkehr trägt. Die Geräte, die diese Tunnel aufbauen und beenden, heißen VTEPs (VXLAN Tunnel Endpoints), und in einer Leaf-Spine-Fabric übernehmen das die Leaf-Switches. Für eine virtuelle Maschine oder einen Container sieht das Overlay aus wie ein flaches Layer-2-Segment, obwohl die Pakete in Wahrheit über eine IP-Fabric geroutet werden. Genau diese Trennung erlaubt es, das physische Netz und die logischen Netze unabhängig voneinander zu skalieren.

Was VXLAN macht: die Datenebene

VXLAN ist die Kapselung, die das Overlay aufbaut. Sendet ein Server einen Frame, verpackt ihn der eingehende VTEP in ein UDP-Paket und ergänzt einen VXLAN-Header, bevor er ihn über das Underlay zum ausgehenden VTEP schickt, der die Hülle entfernt und den ursprünglichen Frame zustellt. Da das äußere Paket gewöhnliches IP ist, muss das Underlay nicht wissen, was darin steckt — es leitet schlicht UDP weiter.

Das entscheidende Feld im Header ist der 24-Bit VXLAN Network Identifier, kurz VNI. Wo VLANs rund 4.000 Segmente boten, liefert der VNI etwa 16 Millionen. Genau diesen Spielraum braucht eine mandantenfähige Plattform: Jedes Mandantennetz, jede isolierte Umgebung, jedes Projekt erhält eine eigene Kennung, ganz ohne Kollisionen. Der Preis ist Overhead — die Kapselung fügt 50 Byte pro Paket hinzu —, weshalb die MTU-Planung wichtig ist, ein Punkt, auf den wir zurückkommen.

Was EVPN macht: die Kontrollebene

VXLAN allein hat eine Schwäche. Frühe Implementierungen nutzten Flood-and-Learn: Um eine unbekannte MAC zu finden, flutete ein VTEP den Frame an alle anderen VTEPs und lernte die Orte aus den Antworten. Das ist laut, langsam und skaliert schlecht. EVPN behebt das, indem es dem Overlay eine echte Kontrollebene auf Basis von Multiprotocol BGP (MP-BGP) gibt — mit einer eigenen Adressfamilie für Layer-2-VPN-EVPN-Routen.

Statt zur Endpunktsuche zu fluten, kündigt jeder VTEP per BGP an, was er weiß: die MAC-Adressen, die IP-zu-MAC-Bindungen und die Segmente, die er bedient. Andere VTEPs übernehmen diese Information direkt in ihre Weiterleitungstabellen. Das Ergebnis ist ein Netz, das sich vorhersehbar verhält, schnell konvergiert und den Großteil des Broadcast-Lärms unterdrückt, der ältere Designs plagte.

EVPN-Route-Typen verständlich erklärt

Den vollständigen Katalog muss niemand auswendig kennen, doch drei Route-Typen tragen die Hauptlast. Type-2-Routen kündigen einzelne MAC- und IP-Adressen an, sodass ein VTEP genau weiß, wo ein Host lebt, und ARP-Anfragen lokal beantworten kann, statt sie zu fluten. Type-3-Routen regeln Multicast- und Broadcast-Zugehörigkeit und teilen jedem VTEP mit, welche Nachbarn zu einem Segment gehören, damit wirklich unbekannter Verkehr nur die richtigen Stellen erreicht. Type-5-Routen kündigen IP-Präfixe an — so routet die Fabric zwischen Subnetzen und bindet externe Netze ein. Zusammen ermöglichen sie der Fabric intelligentes Bridging und Routing, ganz ohne brachiales Fluten.

Wie ein Paket wirklich fließt

Stellen Sie sich eine VM an einem Server hinter Leaf 1 vor, die Verkehr an eine VM hinter Leaf 9 sendet. Ziel-MAC und -IP wurden Leaf 1 bereits per EVPN-Type-2-Route bekannt gegeben, also weiß Leaf 1, dass das Ziel hinter dem VTEP auf Leaf 9 liegt. Er kapselt den Frame in VXLAN, versieht ihn mit dem korrekten VNI und schickt ihn ins Underlay, adressiert an Leaf 9. Das ECMP-Hashing wählt einen der Spine-Uplinks; der Spine, der nur den äußeren IP-Header sieht, routet weiter. Leaf 9 empfängt das Paket, entfernt die VXLAN-Hülle und übergibt den ursprünglichen Frame an die Ziel-VM. Kein Fluten, kein Spanning Tree, kein Raten — nur ein gerouteter Lookup und eine saubere Entkapselung.

Mandantenfähigkeit und der Private-Cloud-Bezug

Hier zahlt sich die Architektur in einer Cloud-Plattform aus. Indem Mandantennetze auf eigene VNIs abgebildet und Routing-Domänen an VRFs gebunden werden, kann die Fabric viele Kunden oder Projekte auf gemeinsamer Hardware betreiben und ihren Verkehr dennoch echt isolieren. Verteiltes Routing — bei dem jeder Leaf als Standard-Gateway für seine lokal angeschlossenen Segmente dient — bedeutet, dass Verkehr zwischen Subnetzen am ersten Hop geroutet wird, statt zu einem zentralen Router zurückzulaufen. Die Ost-West-Latenz sinkt, und es gibt keinen einzelnen Engpass, der überlastet werden könnte.

Für eine Private Cloud passt das nahezu eins zu eins zu der Art, wie die Virtualisierungsschicht über Netzwerk denkt. Mandanten-Overlays, die die Cloud-Plattform anlegt, nutzen dieselbe Kapselung, die die physische Fabric ohnehin spricht, sodass die logischen Netze der Mandanten und die physischen Pfade ihrer Pakete sauber entkoppelt bleiben. Genau dieses Fundament liefert eine Leaf-Spine-Fabric, und deshalb ist EVPN/VXLAN zum Bindegewebe von On-Premise-Private-Clouds geworden.

Worauf man im Betrieb achten sollte

Die Architektur ist robust, doch ein paar Details entscheiden über einen reibungslosen oder einen zähen Rollout. Die MTU ist die klassische Falle: Weil VXLAN 50 Byte Overhead hinzufügt, muss das Underlay Jumbo Frames tragen (typischerweise 9216 Byte), damit gekapselter Verkehr nie fragmentiert wird. Macht man das falsch, jagt man tagelang rätselhaften Performance-Problemen hinterher. Auch das ECMP-Hashing verdient Aufmerksamkeit — Flows sollen gleichmäßig über die Uplinks verteilt werden, und die Entropie im äußeren UDP-Quellport ist es, die das ermöglicht. Die durch EVPN-Type-2-Routen aktivierte ARP-Unterdrückung senkt den Broadcast-Verkehr drastisch, bedeutet aber, dass das Monitoring die Kontrollebene beobachten sollte, statt auf sichtbare Floods zu warten. Und behandeln Sie das Underlay-Routing als heilig: halten Sie es einfach, halten Sie es schnell, und lassen Sie es nichts anderes tun, als Pakete zwischen VTEPs zu bewegen.

Alles zusammengeführt

BGP EVPN und VXLAN haben Erfolg, weil sie ein schweres Problem in zwei beherrschbare zerlegen. VXLAN liefert eine skalierbare Datenebene mit Millionen Segmenten und sauberer Kapselung; EVPN liefert eine intelligente Kontrollebene, die Erreichbarkeit ohne Fluten verteilt. Das Ergebnis ist eine Fabric, die horizontal skaliert, Mandanten sauber isoliert und sich in deutlich unter einer Sekunde von Ausfällen erholt — genau die Eigenschaften, die eine ernsthafte Private Cloud verlangt.

Eine solche Fabric zu planen, auszurollen und zu betreiben bleibt echte Ingenieursarbeit, von der Leaf-Spine-Verkabelung und Switch-Auswahl bis zur BGP-Policy und MTU-Hygiene. Bei clouditiv bauen wir souveräne, OpenStack-basierte Private Clouds auf Arista-Leaf-Spine-Fabrics, in denen dieses Overlay-Modell die Mandantenisolation und die vorhersehbare Ost-West-Leistung trägt, die moderne Workloads erwarten. Wenn das Netz unter der Cloud so entworfen ist, hat die Plattform darüber Raum zu wachsen — und genau das ist am Ende der Gewinn von EVPN/VXLAN.