Hinweis: Dies ist ein Demo-Beitrag als Platzhalter für den Blog-Aufbau. Er kann jederzeit gelöscht werden.
Wer heute ein Rechenzentrumsnetz plant, kommt an zwei Buchstabenkombinationen kaum vorbei: EVPN und VXLAN. Was in Hyperscaler-Umgebungen längst Standard ist, setzt sich zunehmend auch in mittelständischen und Colocation-Rechenzentren durch – getrieben von virtualisierten Workloads, wachsendem Ost-West-Traffic zwischen Servern und dem Wunsch nach Mandantentrennung ohne architektonische Kompromisse. Dieser Beitrag ordnet die Technik ein: warum klassische Designs an ihre Grenzen stoßen, wie Leaf-Spine, VXLAN und EVPN zusammenspielen – und wann sich der Umstieg für ein Rechenzentrum tatsächlich lohnt.
Warum klassische 3-Tier- und STP-Netze an ihre Grenzen stoßen
Die klassische Core-Distribution-Access-Architektur wurde für Nord-Süd-Verkehr entworfen: Anfragen kommen von außen, laufen zum Server und zurück. Moderne Anwendungen erzeugen jedoch überwiegend Ost-West-Verkehr zwischen Servern, Microservices und Storage-Systemen. In einem 3-Tier-Design mit Spanning Tree Protocol (STP) wird dieser Verkehr über wenige aktive Uplinks geführt, während redundante Links blockiert bleiben – Bandbreite, für die der Betreiber bezahlt hat, liegt brach.
Hinzu kommt die Fragilität von STP selbst: Topologieänderungen führen zu Reconvergenzzeiten, in denen Teile des Netzes kurzzeitig ausfallen, und große Layer-2-Domänen vergrößern die Broadcast- und Fehlerdomäne über das gesamte Rechenzentrum hinweg. Wächst die Anzahl der Racks, wird die Skalierung klassischer VLANs mit maximal 4094 Segmenten zusätzlich zum limitierenden Faktor für Multi-Tenant-Umgebungen.
Leaf-Spine: Die Clos-Fabric als neues Fundament
Als Antwort hat sich die Leaf-Spine-Topologie durchgesetzt, ein aus der Telefonvermittlungstechnik abgeleitetes Clos-Design. Jeder Leaf-Switch, an dem Server angeschlossen sind, verbindet sich mit jedem Spine-Switch – es entsteht ein nichtblockierendes Fabric mit konstanter Latenz, unabhängig davon, welche zwei Server miteinander kommunizieren. Da alle Uplinks aktiv genutzt werden (typischerweise über ECMP-Routing statt STP-Blocking), skaliert die Bandbreite linear mit der Anzahl der Spines.
Wachstum erfolgt horizontal: Reicht die Kapazität nicht mehr aus, werden weitere Spines oder Leafs ergänzt, ohne die bestehende Verkabelung oder Konfiguration grundlegend zu verändern. Die Fabric selbst wird meist rein Layer-3-geroutet betrieben – und genau hier setzt VXLAN an, um trotzdem Layer-2-Dienste bereitzustellen.
VXLAN: Layer-2-Overlay über eine Layer-3-Fabric
VXLAN (Virtual Extensible LAN) löst das Skalierungs- und Isolationsproblem, indem es Layer-2-Frames in UDP-Pakete kapselt und über das geroutete Underlay transportiert – ein Konzept, das als MAC-in-UDP bezeichnet wird. Damit können virtuelle Maschinen im selben logischen Segment liegen, obwohl sie physisch an unterschiedlichen Leaf-Switches im gesamten Rechenzentrum hängen.
VNI: virtuelle Segmentierung im großen Stil
Statt der 12-Bit-VLAN-ID nutzt VXLAN die 24-Bit-VNI (VXLAN Network Identifier) und erlaubt damit theoretisch über 16 Millionen isolierte Segmente – ein entscheidender Faktor für Multi-Tenant-Rechenzentren mit vielen Kunden oder Abteilungen.
VTEP: MAC-in-UDP-Kapselung an der Netzwerkkante
Die Kapselung übernimmt der VTEP (VXLAN Tunnel Endpoint), meist auf dem Leaf-Switch implementiert. Verlässt ein Frame den Server, kapselt der lokale VTEP ihn mit VXLAN-Header, IP- und UDP-Header und schickt ihn über das Underlay zum VTEP am Ziel-Leaf, der ihn entkapselt und als normales Ethernet-Frame an den Zielserver weiterreicht. Für die virtuellen Maschinen bleibt dieser Vorgang vollständig transparent.
EVPN: BGP als intelligente Control-Plane
VXLAN allein definiert nur die Datenebene – wie Pakete gekapselt werden. Ursprünglich wurde die Frage, welcher VTEP welche MAC-Adresse und welchen Host kennt, per Flood-and-Learn und Multicast gelöst, was in großen Fabrics schlecht skaliert und unnötigen Broadcast-Verkehr erzeugt. EVPN (Ethernet VPN) schließt diese Lücke als Control-Plane auf Basis von MP-BGP und verteilt Erreichbarkeitsinformationen proaktiv, statt sie erst durch Datenverkehr zu erlernen.
Route Types 2, 3 und 5 im Überblick
EVPN kennt dafür klar definierte BGP-Route-Types: Route Type 2 (MAC/IP Advertisement) verteilt MAC- und optional IP-Adressen einzelner Hosts zwischen den VTEPs, Route Type 3 (Inclusive Multicast Ethernet Tag) baut die Tunnel für BUM-Verkehr (Broadcast, Unknown-Unicast, Multicast) automatisch auf, und Route Type 5 (IP Prefix Advertisement) ermöglicht das Routing ganzer IP-Präfixe zwischen VXLAN-Segmenten – etwa für externe Konnektivität oder Inter-Tenant-Routing. Damit wird das gesamte Fabric-Wissen konsistent über Standard-BGP verteilt, inklusive bewährter Mechanismen wie Route-Reflectoren und Route-Targets.
Praktische Vorteile: Multi-Tenancy, ARP-Suppression und Anycast Gateway
Der eigentliche Mehrwert von EVPN-VXLAN zeigt sich im Betrieb: Layer-2-Konnektivität ist überall im Fabric verfügbar, ohne dass physisch durchgängige VLANs oder blockierte STP-Links nötig wären – VM-Mobilität über Racks und Reihen hinweg wird dadurch erst praktikabel. Da jeder Leaf-Switch über EVPN weiß, welche MAC-Adressen wo liegen, kann er ARP-Anfragen lokal beantworten (ARP-Suppression), statt sie im gesamten Fabric zu fluten.
Weitere zentrale Vorteile im Überblick:
- L2 über L3: Layer-2-Segmente lassen sich über ein rein geroutetes Underlay verteilen, ohne dessen Robustheit und Skalierbarkeit zu opfern.
- Multi-Tenancy: VRFs und VNIs erlauben eine saubere, hochskalierbare Mandantentrennung auf Layer 2 und Layer 3.
- ARP-Suppression: Lokale Beantwortung von ARP-Anfragen reduziert Broadcast-Last im gesamten Fabric erheblich.
- Anycast Gateway: Jeder Leaf-Switch stellt dasselbe Default-Gateway mit identischer IP und MAC bereit, wodurch VM-Umzüge ohne Neukonfiguration möglich sind.
- Active-Active-Multihoming: Server können über EVPN-Multihoming redundant an mehrere Leafs angebunden werden, ganz ohne STP.
Wann sich EVPN-VXLAN lohnt – und wann nicht
EVPN-VXLAN entfaltet seinen Nutzen vor allem dort, wo mehrere Racks über eine Leaf-Spine-Fabric verbunden werden müssen, VM-Mobilität über Standortgrenzen hinweg gefordert ist oder mehrere Mandanten strikt getrennte, aber flexibel skalierbare Netzsegmente benötigen – etwa in Colocation-Umgebungen, Cloud-Infrastrukturen oder größeren Unternehmensrechenzentren mit mehreren Hallen.
In einem kleinen Rechenzentrum mit wenigen Racks, überschaubarer VLAN-Anzahl und einem einzigen Betreiber ohne Mandantentrennung steht der zusätzliche Betriebsaufwand oft in keinem Verhältnis zum Nutzen. Hier reichen klassische, gut dokumentierte VLAN- und Routing-Designs meist völlig aus – die zusätzliche Komplexität von BGP-EVPN sollte nicht ohne konkreten Skalierungs- oder Mandantenbedarf eingeführt werden.
Betrieb und Troubleshooting in der Praxis
Im laufenden Betrieb verschiebt sich der Debugging-Fokus: Statt Spanning-Tree-Zustände zu prüfen, analysiert man BGP-EVPN-Sessions, die verteilten Route-Type-2/3/5-Einträge und den Zustand der VTEPs. Werkzeuge wie „show bgp l2vpn evpn“, VXLAN-Interface-Counter und Underlay-Reachability-Checks (meist BGP oder OSPF im Underlay) bilden das neue Standard-Toolset. Wichtig ist zudem ein durchgängiges Monitoring von MTU-Werten entlang des Pfades, da die VXLAN-Kapselung zusätzlichen Overhead erzeugt und fragmentierte Pakete Performance-Probleme verursachen können.
Automatisierung zahlt sich hier besonders aus: Da EVPN-VXLAN-Konfigurationen auf allen Leafs strukturell ähnlich sind, lassen sie sich hervorragend über Templating und Infrastructure-as-Code ausrollen – manuelle CLI-Eingriffe sind fehleranfällig und sollten die Ausnahme bleiben.
Fazit
EVPN-VXLAN ersetzt die fragile Kombination aus großen Layer-2-Domänen und Spanning Tree durch eine robuste, horizontal skalierbare Leaf-Spine-Fabric mit BGP als bewährter, standardisierter Control-Plane. Für Rechenzentren mit Wachstumsambitionen, Multi-Tenant-Anforderungen oder verteilten Workloads ist die Technik heute Best Practice. Kleinere, einfach strukturierte Umgebungen fahren dagegen oft besser mit klassischen, schlankeren Designs – die richtige Wahl hängt immer von Skalierung, Mandantenmodell und vorhandenem Betriebs-Know-how ab.