Von VLAN zu VXLAN – Segmentierung im Cisco-Netzwerk im Wandel der Zeit

10. September 2025

Hinweis zur Aktualisierung

Dieser Beitrag wurde ursprünglich am 10. September 2025 veröffentlicht und am 14. Juni 2026 grundlegend überarbeitet. Im Rahmen des Reloads wurden Inhalte fachlich erweitert, technisch aktualisiert und didaktisch neu strukturiert. Neu hinzugekommen sind unter anderem vertiefende Abschnitte zu VXLAN, EVPN, Cisco SD-Access (SDA), identitätsbasierter Segmentierung, VLAN-Sicherheit sowie modernen Datacenter- und Spine-Leaf-Architekturen. Zudem wurde der Beitrag umfassend aktualisiert, um aktuelle Enterprise- und Datacenter-Designs präziser einzuordnen.

Von physischen Kabeln zu logischen Strukturen

Netzwerke waren nie statisch. Sie haben sich über Jahrzehnte hinweg parallel zu den Anforderungen von Unternehmen, Anwendungen und Benutzer:innen entwickelt. Während frühe Netzwerke oft überschaubar waren und sich Kommunikation noch vergleichsweise direkt organisieren ließ, sind moderne Infrastrukturen hochgradig dynamische Systeme geworden. Cloud-Anwendungen, Virtualisierung, mobile Endgeräte, IoT-Komponenten und verteilte Workloads stellen heute Anforderungen, die sich mit klassischen Netzwerkprinzipien allein kaum noch effizient umsetzen lassen.

Damit rückt ein Konzept in den Mittelpunkt, das moderne Netzwerke maßgeblich prägt: Segmentierung.

Warum Segmentierung unverzichtbar wurde

Die grundlegende Aufgabe eines Netzwerks besteht darin, Systeme miteinander kommunizieren zu lassen. Doch je größer eine Infrastruktur wird, desto wichtiger wird eine zweite Frage: Welche Systeme sollen eigentlich miteinander kommunizieren dürfen – und welche besser nicht?

Genau hier setzt Segmentierung an. Sie unterteilt Netzwerke in logisch getrennte Bereiche und schafft damit Ordnung, Sicherheit und Skalierbarkeit.

Ohne Segmentierung würden sich Broadcasts unkontrolliert über gesamte Layer-2-Netze ausbreiten. Sicherheitsvorfälle könnten sich leichter auf andere Systeme auswirken, und selbst kleinere Änderungen an der Infrastruktur würden schnell komplex werden. Mit zunehmender Größe eines Netzwerks steigt daher die Notwendigkeit, Kommunikation gezielt zu strukturieren.

Segmentierung erfüllt dabei mehrere zentrale Aufgaben gleichzeitig:

  • Sicherheit erhöhen: Kritische Systeme, Gäste, Benutzer:innen oder IoT-Komponenten lassen sich logisch voneinander trennen
  • Skalierbarkeit verbessern: Broadcast-Domänen bleiben begrenzt, wodurch unnötiger Datenverkehr reduziert wird
  • Performance optimieren: Switches und Endgeräte müssen weniger irrelevanten Traffic verarbeiten
  • Komplexität beherrschbar machen: Netzwerke lassen sich organisatorisch und technisch sauber strukturieren

In der Praxis bedeutet das einen grundlegenden Perspektivwechsel: Wer heute Netzwerke plant, denkt längst nicht mehr primär in Kabelwegen oder Switchports. Entscheidend sind vielmehr logische Kommunikationsbeziehungen – Broadcast-Domänen, VLANs, virtuelle Netze oder identitätsbasierte Policies.

Einordnung: Von VLAN bis VXLAN

Die Entwicklung moderner Netzwerke lässt sich auch als Geschichte zunehmender Abstraktion verstehen. Während Segmentierung früher unmittelbar an physische Infrastruktur gebunden war, löst sie sich heute immer stärker von konkreten Standorten, Ports oder Verkabelungen.

Cisco-Technologien wie VLAN, VTP, Inter-VLAN-Routing, Software Defined Access (SDA) oder VXLAN stehen exemplarisch für diese Entwicklung. Wichtig ist dabei: Diese Technologien ersetzen sich nicht einfach gegenseitig, sondern bauen konzeptionell aufeinander auf.

Die Entwicklung folgt dabei grob vier Evolutionsstufen:

  • VLANs bilden den Grundbaustein moderner Segmentierung und schaffen logische Broadcast-Domänen innerhalb eines Layer-2-Netzes
  • VTP und zentrale Verwaltungsmechanismen vereinfachen die Administration wachsender VLAN-Strukturen – allerdings nicht ohne Risiken
  • Layer-3-Switching verbindet getrennte Segmente miteinander und macht Kommunikation zwischen VLANs performant und skalierbar
  • VXLAN und EVPN entkoppeln Segmentierung schließlich weitgehend von der physischen Infrastruktur und ermöglichen Millionen logischer Segmente über verteilte Datacenter- und Cloud-Umgebungen hinweg

Damit verschiebt sich auch die Rolle des Netzwerks selbst: Weg von einer rein transportorientierten Infrastruktur hin zu einer flexiblen Fabric, in der Kommunikation zunehmend logisch, identitätsbasiert und softwaredefiniert organisiert wird.

Exkurs: Von ‘Design follows Function’ zu ‘Function follows Design’

Wer heute mit VLANs, VXLAN oder identitätsbasierter Segmentierung arbeitet, vergisst leicht, wie grundlegend anders Netzwerke ursprünglich aufgebaut waren. Lange Zeit orientierte sich Infrastruktur unmittelbar an Kommunikationsanforderungen. Netzwerke wurden nicht logisch abstrahiert, sondern physisch organisiert.

Als Netzwerke noch physisch gedacht wurden

In frühen Ethernet-Netzen galt implizit das Prinzip: Design follows Function.

Sollten Systeme miteinander kommunizieren, mussten sie sich zwangsläufig im selben physischen Netzwerksegment befinden. In klassischen Shared-Ethernet-Umgebungen mit Hubs bedeutete dies: Alle Geräte teilten sich dasselbe Übertragungsmedium. Broadcasts, Kollisionen und Performanceprobleme nahmen mit wachsender Infrastruktur schnell zu. Selbst nach der Einführung von Switches blieb die grundlegende Logik zunächst erhalten: Kommunikation orientierte sich weiterhin stark an physischer Nähe und Verkabelung.

Das Netzwerkdesign folgte direkt organisatorischen Anforderungen. Mussten beispielsweise Mitarbeitende einer Abteilung gemeinsam auf Ressourcen zugreifen, wurden ihre Systeme physisch in dasselbe Segment integriert – unabhängig davon, ob dies architektonisch sinnvoll oder langfristig skalierbar war. Ein organisatorischer Umzug konnte dadurch erhebliche technische Konsequenzen haben.

Zog etwa eine Marketing-Abteilung in ein anderes Stockwerk oder Gebäude, mussten häufig:

  • Kabel neu verlegt werden
  • Patchfelder angepasst werden
  • Switchports neu organisiert werden
  • teilweise sogar ganze Netzsegmente neu entstehen

Kommunikationsanforderungen bestimmten somit unmittelbar die physische Infrastruktur.

Der Paradigmenwechsel durch VLANs

Mit der Einführung von VLANs begann ein grundlegender Wandel in der Netzwerkarchitektur.

Durch IEEE 802.1Q wurde es erstmals möglich, Broadcast-Domänen logisch statt physisch zu organisieren. Über sogenannte Trunk-Links konnten mehrere VLANs gleichzeitig zwischen Switches transportiert werden. Geräte mussten dadurch nicht länger am selben Switch oder im selben Gebäudebereich angeschlossen sein, um Teil derselben logischen Kommunikationsdomäne zu bleiben.

Entscheidend war dabei eine neue Idee: Kommunikation wird von der Verkabelung entkoppelt.

Mitarbeitende konnten nun den Standort wechseln, ohne dass die Zugehörigkeit zum Netzwerksegment verloren ging. Statt Kabel neu zu ziehen, genügte häufig eine logische Portzuweisung auf dem Switch.

Damit drehte sich das bisherige Architekturprinzip um: Function follows Design.

Netzwerke werden heute zunächst standardisiert, modular und skalierbar aufgebaut. Erst danach erfolgt die logische Segmentierung nach organisatorischen, technischen oder sicherheitsrelevanten Kriterien. Das physische Netzwerk wird dadurch zum stabilen Fundament, während die eigentliche Kommunikationslogik flexibel darübergelegt wird.

Von der logischen Segmentierung zur logischen Fabric

Mit VLANs begann die Abstraktion – sie endete dort jedoch nicht. Während VLANs logische Segmentierung innerhalb klassischer Layer-2-Domänen ermöglichen, verschieben moderne Architekturen diese Idee konsequent weiter. Technologien wie VXLAN und EVPN entkoppeln Netzsegmente zunehmend von geografischen Standorten oder physischen Grenzen. Ein logisches Segment kann sich heute über mehrere Racks, Rechenzentren oder Cloud-Standorte hinweg erstrecken.

Gleichzeitig verändert sich die Frage, worauf Segmentierung basiert. Früher lautete die zentrale Überlegung: Wo befindet sich ein Gerät? Heute lautet sie zunehmend: Wer oder was ist ein Gerät – und welche Kommunikation ist erlaubt?

Identitätsbasierte Ansätze wie Cisco Software Defined Access (SDA) oder TrustSec ergänzen klassische Netzwerksegmente um rollen- und policybasierte Steuerung. Zwei Systeme im selben VLAN müssen dadurch längst nicht mehr dieselben Zugriffsrechte besitzen.

Die Entwicklungslinie moderner Netzwerke lässt sich daher vereinfacht so beschreiben: Physische Segmente → VLANs → Overlay-Netze → identitätsbasierte Segmentierung

Dieses Verständnis bildet die Grundlage für die folgenden Kapitel – und erklärt, warum VLANs, Routing, VXLAN, EVPN oder Zero-Trust-Segmentierung keine isolierten Technologien sind, sondern aufeinander aufbauende Evolutionsstufen moderner Netzwerkarchitekturen.

VLAN – das Fundament der Segmentierung

Nachdem Netzwerke begonnen hatten, sich von physischen Grenzen zu lösen, entstand die Notwendigkeit einer neuen Form logischer Organisation. Genau hier setzen Virtual Local Area Networks (VLANs) an. Seit den 1990er-Jahren bilden sie das Fundament moderner Netzwerksegmentierung und gehören bis heute zu den wichtigsten Technologien in Campus-Netzen, Unternehmensumgebungen und Rechenzentren.

VLANs ermöglichen es, ein physisches Netzwerk in mehrere logisch getrennte Bereiche aufzuteilen. Dadurch lassen sich Sicherheit, Skalierbarkeit und Flexibilität deutlich verbessern – ohne dass dafür zusätzliche physische Infrastruktur notwendig wäre. Viele spätere Technologien wie VTP, Inter-VLAN-Routing, Cisco Software Defined Access (SDA) oder VXLAN bauen konzeptionell auf dieser Idee auf.

Broadcast-Domänen verstehen

Um die Bedeutung von VLANs zu verstehen, lohnt sich zunächst ein Blick auf ein zentrales Konzept von Ethernet-Netzwerken: die Broadcast-Domäne. Eine Broadcast-Domäne beschreibt den Bereich eines Netzwerks, in dem Broadcast-Frames von allen Geräten empfangen werden. Ein klassisches Beispiel ist ein ARP-Request. Möchte ein System die MAC-Adresse zu einer bekannten IPv4-Adresse ermitteln, sendet es eine Broadcast-Anfrage an alle Geräte innerhalb seines Layer-2-Netzes.

Ohne Segmentierung breiten sich solche Broadcasts über das gesamte lokale Netzwerk aus. In kleinen Umgebungen fällt dies kaum ins Gewicht. Wachsen Netzwerke jedoch, steigt auch die Zahl der Broadcasts – und damit die Belastung für Switches und Endgeräte. Jedes Gerät muss prüfen, ob ein empfangenes Broadcast-Frame relevant ist, selbst wenn es die Nachricht anschließend verwirft.

VLANs begrenzen diese Reichweite gezielt. Jedes VLAN bildet eine eigene logische Broadcast-Domäne. Broadcasts verbleiben dadurch innerhalb ihres Segments und erreichen ausschließlich Systeme, die demselben VLAN angehören. Dies reduziert unnötigen Datenverkehr und schafft zugleich eine klarere organisatorische und sicherheitstechnische Trennung.

Was ist ein VLAN?

Ein Virtual Local Area Network (VLAN) unterteilt ein physisches Layer-2-Netz in mehrere logisch getrennte Netzsegmente, die durch eine eindeutige VLAN-ID identifiziert werden. Obwohl Geräte weiterhin dieselbe physische Infrastruktur nutzen können, behandelt der Switch jedes VLAN wie ein eigenständiges Netzwerk.

In der Praxis lassen sich unterschiedliche Kommunikationsbereiche über VLAN-IDs gezielt voneinander trennen. Beispielsweise könnten Mitarbeitende dem VLAN 10, Gäste dem VLAN 20 und Server dem VLAN 30 zugeordnet werden. Die jeweilige VLAN-ID dient dabei als logischer Identifikator des Segments innerhalb der Switching-Infrastruktur.

Ein Broadcast-Frame aus VLAN 10 bleibt ausschließlich innerhalb dieser Broadcast-Domäne sichtbar und erreicht weder das Gäste- noch das Servernetz. Auf diese Weise lassen sich Netzwerke sicherer, skalierbarer und organisatorisch klarer strukturieren.

Entscheidend ist dabei: Die Zugehörigkeit zu einem VLAN hängt nicht vom physischen Standort eines Geräts ab, sondern von seiner logischen Zuordnung auf dem Switch. Zwei Geräte können sich in unterschiedlichen Gebäudeteilen befinden und dennoch demselben VLAN angehören – oder direkt nebeneinander stehen und vollständig getrennte Broadcast-Domänen nutzen.

VLANs lösen Kommunikation damit erstmals sichtbar von der physischen Verkabelung. Netzwerke werden nicht länger ausschließlich über Kabelwege und räumliche Nähe organisiert, sondern zunehmend logisch strukturiert und flexibel segmentiert.

Untagged Frames und Access-Ports

Im ersten Schritt ist VLAN-Segmentierung ein lokaler Prozess innerhalb eines Switches. VLANs werden in der Switch-Konfiguration definiert und erhalten eine numerische Kennung – die VLAN-ID – sowie optional eine sprechende Bezeichnung. Endgeräte selbst wissen dabei zunächst nichts über VLANs. Ein normaler Client, Drucker oder Server sendet in der Regel ganz gewöhnliche, untagged Ethernet-Frames.

Trifft ein solcher Frame auf einem Switchport ein, ordnet der Switch ihn automatisch dem VLAN zu, das diesem Port fest zugewiesen wurde. In Cisco-Netzwerken spricht man dabei von einem Access-Port.

Ein Access-Port gehört immer genau zu einem VLAN und erwartet standardmäßig untagged Frames. Die VLAN-Zuordnung entsteht also nicht im Endgerät selbst, sondern durch die Konfiguration des Switchports. Aus Sicht eines angeschlossenen Clients bleibt das VLAN vollständig transparent.

Diese Logik funktioniert zunächst vollständig lokal: Ein einzelner Switch kann Endgeräte sauber segmentieren, ohne dass weitere Infrastruktur beteiligt sein muss.

Kommunikation zwischen Switches

Sobald mehrere Switches beteiligt sind, stößt diese rein lokale VLAN-Zuordnung jedoch an Grenzen. Theoretisch könnte für jedes VLAN eine separate physische Verbindung zwischen den Switches aufgebaut werden. Für VLAN 10 würde beispielsweise ein eigener Port verwendet, für VLAN 20 ein weiterer und für VLAN 30 ein dritter. Technisch wäre dies durchaus möglich – selbst dann, wenn die VLAN-IDs auf beiden Seiten unterschiedlich wären. Ein Switch könnte intern VLAN 20 verwenden, der andere VLAN 80, solange die jeweilige physische Verbindung konsistent zugeordnet bleibt.

In der Praxis wäre dieses Modell jedoch kaum beherrschbar. Bereits bei wenigen VLANs würde die benötigte Zahl an Switchports stark steigen. Verkabelung, Dokumentation und Fehlersuche würden schnell unnötig komplex.

Damit stellt sich eine entscheidende Frage: Wie lassen sich mehrere VLANs gleichzeitig über eine einzige Verbindung transportieren? Die Antwort darauf liefern standardisierte Tagging-Verfahren, allen voran IEEE 802.1Q.

Exkurs: Trunks, EtherChannel und Link Aggregation richtig einordnen

Sobald mehrere Switches miteinander kommunizieren, stellt sich eine praktische Herausforderung: Wie lassen sich mehrere VLANs effizient zwischen Geräten transportieren, ohne für jedes VLAN eine eigene physische Verbindung aufzubauen?

Im Cisco-Umfeld fällt in diesem Zusammenhang schnell der Begriff Trunk. Gemeint ist damit eine Verbindung, die Frames mehrerer VLANs gleichzeitig über eine einzige physische Leitung transportieren kann. Cisco spricht hierbei von einem Trunk-Port.

Wichtig ist jedoch eine klare begriffliche Trennung: Ein Trunk beschreibt keine Bündelung mehrerer Leitungen, sondern ausschließlich die Fähigkeit, mehrere VLANs parallel zu transportieren. Ein Trunk-Port verarbeitet dazu VLAN-Tags – typischerweise nach IEEE 802.1Q – und kann so den jeweiligen Netzwerkverkehr logisch voneinander unterscheiden. Statt einer Leitung pro VLAN genügt damit eine einzige Verbindung zwischen den Switches.

Warum der Begriff Trunk häufig missverstanden wird

Verwirrend wird der Begriff vor allem dadurch, dass Hersteller ihn teilweise unterschiedlich verwenden. Im Cisco-Kontext bezeichnet ein Trunk-Port ausschließlich die Übertragung mehrerer VLANs über eine Verbindung. In anderen Netzwerkumgebungen wird Trunk dagegen teilweise synonym für gebündelte Leitungen verwendet. Technisch handelt es sich jedoch um unterschiedliche Konzepte.

Ein Cisco-Trunk beantwortet die Frage: Welche VLANs dürfen transportiert werden? Link Aggregation beantwortet dagegen: Wie werden mehrere physische Verbindungen zu einem logischen Link zusammengefasst?

Beides wird in der Praxis häufig kombiniert, sollte jedoch gedanklich sauber getrennt bleiben.

EtherChannel und Link Aggregation

Sollen mehrere physische Leitungen parallel genutzt werden, um Bandbreite zu erhöhen oder Redundanz zu schaffen, kommt bei Cisco EtherChannel zum Einsatz. Mehrere physische Switchports werden dabei zu einem einzigen logischen Kanal zusammengefasst.

Der Vorteil: Aus Sicht des Netzwerks entsteht eine einzige Verbindung, obwohl physisch mehrere Kabel beteiligt sind. Dadurch erhöht sich nicht nur die verfügbare Bandbreite – auch die Ausfallsicherheit steigt. Fällt eine Leitung aus, bleibt der logische Kanal weiterhin funktionsfähig, solange mindestens ein aktiver Link verfügbar ist.

Für die Steuerung existieren unterschiedliche Verfahren:

  • PAgP (Port Aggregation Protocol) ist ein proprietäres Cisco-Verfahren und findet sich heute überwiegend in Legacy-Umgebungen
  • LACP (Link Aggregation Control Protocol) ist der herstellerübergreifende Standard. Ursprünglich wurde dieser mit IEEE 802.3ad eingeführt und später in IEEE 802.1AX überführt. In modernen Netzwerken gilt LACP als Best Practice

Begriffe sauber voneinander abgrenzen

Gerade in Schulungen oder Projektumgebungen werden Access-Port, Trunk und EtherChannel häufig vermischt. Eine klare Trennung hilft dabei, spätere Missverständnisse zu vermeiden:

  • Access-Port: gehört genau zu einem VLAN und verarbeitet typischerweise untagged Frames
  • Trunk-Port: transportiert mehrere VLANs gleichzeitig über eine Verbindung und nutzt dafür VLAN-Tagging
  • EtherChannel: bündelt mehrere physische Verbindungen zu einem logischen Link und kann sowohl als Access-Port als auch als Trunk konfiguriert werden

In der Praxis treten beide Konzepte häufig gemeinsam auf: Mehrere physische Leitungen werden zunächst per EtherChannel gebündelt und anschließend als Trunk betrieben. Dadurch lassen sich viele VLANs gleichzeitig performant und redundant zwischen Switches transportieren.

Mit dieser Grundlage stellt sich nun die entscheidende technische Frage: Wie erkennt ein Switch eigentlich, zu welchem VLAN ein Frame gehört? Die Antwort liefert der heute dominierende Standard IEEE 802.1Q.

Standardisierte Lösung: 802.1Q und ISL

Damit mehrere VLANs gleichzeitig über eine einzige Verbindung zwischen Switches transportiert werden können, müssen Ethernet-Frames Informationen über ihre logische Zugehörigkeit enthalten. Die zentrale Herausforderung lautet also: Woher weiß ein empfangender Switch, zu welchem VLAN ein Frame gehört?

Die Antwort liefern standardisierte Tagging-Verfahren, die VLAN-Informationen direkt in Ethernet-Frames integrieren. Im Cisco-Umfeld spielten dabei historisch vor allem zwei Verfahren eine Rolle:

  • IEEE 802.1Q als heute dominierender Standard
  • Inter-Switch Link (ISL) als früherer Cisco-spezifischer Ansatz

IEEE 802.1Q – der Standard

Der heute nahezu universell eingesetzte Standard für VLAN-Tagging ist IEEE 802.1Q. Statt für jedes VLAN eigene physische Leitungen zu benötigen, erlaubt 802.1Q die parallele Übertragung vieler VLANs über dieselbe Verbindung. Dazu werden VLAN-Informationen direkt im Ethernet-Frame transportiert.

Technische Infografik zum VLAN-Tagging nach IEEE 802.1Q. Die Darstellung vergleicht einen klassischen Ethernet-Frame (IEEE 802.3) mit einem VLAN-Frame und zeigt die Einfügung des zusätzlichen 802.1Q-Tags zwischen Source Address und Type/Length-Feld. Eine Detailansicht erklärt die Bestandteile des VLAN-Tags: TPID, PCP, CFI und VLAN Identifier (VID).

Technisch geschieht dies durch ein zusätzliches 4-Byte-Tag, das zwischen Quell-MAC-Adresse und EtherType-Feld eingefügt wird.

Dieses VLAN-Tag besteht aus mehreren Informationen:

  • Tag Protocol Identifier (TPID): Kennzeichnet den Frame als 802.1Q-Frame. Standardmäßig wird hierfür der Wert 0x8100
  • Priority Code Point (PCP): Drei Bits dienen der Priorisierung von Datenverkehr und unterstützen Quality of Service (QoS).
  • Drop Eligible Indicator (DEI): Historisch als Canonical Format Indicator (CFI) bekannt; dient heute vor allem zur Kennzeichnung verwerfbarer Frames bei Überlast.
  • VLAN Identifier (VID): Enthält die eigentliche VLAN-ID und ermöglicht bis zu 4096 logische Segmente (12 Bit).

Durch das zusätzliche Tag wächst ein Ethernet-Frame um vier Byte. Damit solche Frames nicht als fehlerhaft gelten, wurde der Ethernet-Standard um IEEE 802.3ac erweitert. Dieser erlaubt Ethernet-Frames mit einer Größe von bis zu 1522 Byte, sofern VLAN-Tagging verwendet wird.

Ein wichtiges technisches Detail bleibt dabei meist unsichtbar: Wird ein VLAN-Tag eingefügt oder entfernt, verändert sich der Ethernet-Frame. Dadurch verliert die ursprüngliche Frame Check Sequence (FCS) am Ende des Frames ihre Gültigkeit. Switches berechnen die Prüfsumme daher transparent neu, bevor der Frame weitergeleitet wird. Für angeschlossene Endgeräte bleibt dieser Vorgang vollständig unsichtbar.

Native VLAN und untagged Frames

Nicht jeder Frame auf einem Trunk muss zwangsläufig getaggt sein. Trifft ein untagged Frame auf einem 802.1Q-Trunk ein, ordnet der Switch diesen standardmäßig dem sogenannten Native VLAN zu. In vielen Cisco-Umgebungen ist dies traditionell VLAN 1.

Aus Sicherheitsgründen empfiehlt sich jedoch ein anderes Vorgehen: Moderne Best Practices empfehlen, ein separates, möglichst ungenutztes Native VLAN zu definieren und produktiven Datenverkehr nicht über VLAN 1 zu führen. Dadurch lassen sich Risiken wie VLAN Hopping deutlich reduzieren.

Cisco ISL – der historische Vorläufer

Bevor sich IEEE 802.1Q als offener Standard etablierte, entwickelte Cisco mit Inter-Switch Link (ISL) eine proprietäre Lösung für den VLAN-Transport zwischen Switches.

Technische Infografik zum Cisco Inter-Switch Link (ISL) VLAN-Tagging. Die Darstellung vergleicht einen klassischen Ethernet-Frame (IEEE 802.3) mit einem VLAN-Frame unter Cisco ISL. Visualisiert wird die vollständige Kapselung des Ethernet-Frames durch einen 26-Byte-ISL-Header und eine zusätzliche CRC-Prüfsumme sowie die internen Felder des ISL-Headers, einschließlich VLAN-ID und Steuerinformationen.

Im Gegensatz zu 802.1Q wird bei ISL kein zusätzliches Feld in den bestehenden Ethernet-Frame eingefügt. Stattdessen kapselt Cisco den gesamten Ethernet-Frame vollständig in einen neuen Header und Trailer ein.

Dadurch wächst der Frame deutlich stärker:

  • 26 Byte Header
  • 4 Byte Trailer
  • insgesamt 30 Byte Overhead

Die VLAN-Zuordnung erfolgt über eine 10-Bit VLAN-ID, wodurch maximal 1024 VLANs möglich waren.

ISL bot damals Vorteile in reinen Cisco-Umgebungen, insbesondere durch die enge Integration in proprietäre Switching-Plattformen. Gleichzeitig brachte der Ansatz jedoch einen entscheidenden Nachteil mit sich: ISL funktionierte ausschließlich innerhalb der Cisco-Welt.

Mit der zunehmenden Bedeutung herstellerübergreifender Netzwerke setzte sich daher 802.1Q als offener IEEE-Standard durch. Moderne Cisco-Switches unterstützen ISL heute nicht mehr – die Technologie bleibt jedoch ein wichtiger historischer Zwischenschritt und taucht in älteren Dokumentationen oder Zertifizierungskontexten weiterhin auf.

Praxisvergleich: 802.1Q vs. ISL

Aus heutiger Perspektive ist die technische Entwicklung klar erkennbar. Während Inter-Switch Link (ISL) lange Zeit eine leistungsfähige Lösung innerhalb reiner Cisco-Umgebungen darstellte, setzte sich IEEE 802.1Q letztlich als offener und herstellerübergreifender Standard durch. Der entscheidende Vorteil lag in der Interoperabilität: Netzwerke mussten nicht länger ausschließlich aus Cisco-Komponenten bestehen, um VLAN-Tagging zuverlässig nutzen zu können.

ISL bleibt damit vor allem eine historisch relevante Technologie und findet sich heute überwiegend noch in Legacy-Umgebungen, älteren Dokumentationen oder Zertifizierungskontexten. Im produktiven Enterprise- und Datacenter-Betrieb spielt dagegen nahezu ausschließlich 802.1Q in Kombination mit IEEE 802.3ac eine Rolle und bildet den de-facto-Standard für moderne VLAN-Kommunikation zwischen Switches.

Vorteile von VLANs

VLANs gehören bis heute zu den wichtigsten Werkzeugen moderner Netzsegmentierung. Ihr Erfolg liegt vor allem darin, dass sie organisatorische, technische und sicherheitsrelevante Anforderungen miteinander verbinden.

Durch die Trennung in eigenständige Broadcast-Domänen reduzieren VLANs unnötigen Netzwerkverkehr und verbessern die Skalierbarkeit. Broadcasts bleiben lokal begrenzt, wodurch Switches und Endgeräte weniger irrelevante Frames verarbeiten müssen.

Gleichzeitig steigt die Flexibilität deutlich: Geräte können unabhängig von ihrem physischen Standort logisch gruppiert werden. Zieht eine Abteilung in einen anderen Gebäudebereich um, genügt häufig eine Anpassung der VLAN-Zuordnung – zusätzliche Verkabelung wird oft überflüssig.

Ebenso wichtig ist die organisatorische Trennung. Mitarbeitende, Gäste, Server oder IoT-Geräte lassen sich sauber voneinander isolieren und strukturiert verwalten. VLANs schaffen dadurch eine erste logische Sicherheitsgrenze und bilden die Grundlage für viele moderne Netzwerk- und Sicherheitskonzepte.

Trotz dieser Vorteile stoßen klassische VLANs jedoch irgendwann an Grenzen – insbesondere dann, wenn Infrastrukturen wachsen, virtualisierte Workloads mobil werden oder Netzwerke sich über mehrere Standorte erstrecken.

Grenzen klassischer VLANs

So erfolgreich VLANs seit Jahrzehnten in Unternehmensnetzwerken eingesetzt werden, stoßen sie in größeren und dynamischeren Infrastrukturen irgendwann an natürliche Grenzen. Gerade in modernen Rechenzentren, virtualisierten Umgebungen oder Multi-Site-Architekturen zeigen sich Einschränkungen, die mit klassischen Layer-2-Konzepten allein nur schwer beherrschbar sind.

Eine erste Begrenzung betrifft die Skalierbarkeit. VLANs basieren auf einer 12-Bit VLAN-ID, die im IEEE-802.1Q-Tag gespeichert wird. Dadurch stehen theoretisch maximal 4096 VLANs zur Verfügung. In klassischen Campus-Netzen reicht dies meist problemlos aus. In großen Datacenter-Umgebungen, Cloud-Infrastrukturen oder mandantenfähigen Netzwerken kann dieser Adressraum jedoch schnell an seine Grenzen stoßen.

Hinzu kommt, dass VLANs ausschließlich auf Layer 2 arbeiten. Sie schaffen zwar logisch getrennte Broadcast-Domänen, stellen jedoch keine vollständige Sicherheitsgrenze dar. Systeme innerhalb desselben VLANs können grundsätzlich direkt miteinander kommunizieren. Für weitergehende Sicherheitsanforderungen – etwa in Zero-Trust-Architekturen, mandantenfähigen Umgebungen oder stark segmentierten Netzwerken – sind zusätzliche Mechanismen wie VRFs, Firewalls, Security Group Tags (SGT) oder Mikrosegmentierung erforderlich.

Auch die Kontrolle von Broadcast- und Multicast-Verkehr bleibt begrenzt. VLANs verkleinern Broadcast-Domänen zwar erheblich, eliminieren sie jedoch nicht vollständig. Mit steigender Zahl von Endgeräten wächst weiterhin die Menge an ARP-Requests, Discovery-Protokollen oder anderen Broadcasts. Besonders in großen Layer-2-Umgebungen kann dies zu zusätzlicher Last führen.

Eine weitere Herausforderung entsteht, sobald Netzwerke über mehrere Standorte oder Rechenzentren hinweg wachsen. VLANs sind ursprünglich für lokale Layer-2-Domänen konzipiert worden. Sollen Netzsegmente über größere Distanzen gestreckt werden – etwa um virtuelle Maschinen zwischen Hosts oder Standorten zu verschieben –, steigt die Komplexität schnell an. Technologien wie Spanning Tree oder klassische Trunk-Konzepte geraten hier zunehmend an praktische Grenzen.

Gerade moderne virtualisierte Workloads verändern zudem die Kommunikationsmuster grundlegend. Während Netzwerke lange Zeit überwiegend Nord-Süd-Verkehr – also Kommunikation zwischen Client und Server – transportierten, dominiert in Rechenzentren heute häufig Ost-West-Traffic zwischen virtuellen Maschinen, Containern oder verteilten Diensten. Diese Dynamik stellt neue Anforderungen an Skalierbarkeit, Mobilität und Segmentierung.

Hinzu kommt der administrative Aufwand: Mit wachsender Zahl von VLANs steigt auch die Komplexität der Konfiguration. Fehlerhafte Trunk-Definitionen, inkonsistente VLAN-Zuweisungen oder falsch konfigurierte Native VLANs gehören bis heute zu den häufigsten Ursachen für Störungen in Switching-Umgebungen.

Damit zeichnet sich ein neues Bild: VLANs bilden zwar bis heute das unverzichtbare Fundament moderner Netzwerksegmentierung und definieren die Reichweite logischer Broadcast-Domänen. Für hochskalierende, flexible und standortübergreifende Infrastrukturen reichen ihre Möglichkeiten allein jedoch zunehmend nicht mehr aus.

Genau an dieser Stelle beginnen moderne Overlay- und Fabric-Technologien – und damit auch die Entwicklung hin zu VXLAN.

Dynamische Segmentierung – Von statischen VLANs zur identitätsbasierten Zuweisung

VLANs bilden die Grundlage moderner Netzwerksegmentierung. In ihrer klassischen Form werden sie jedoch meist statisch betrieben: Ein Switchport wird fest einem VLAN zugewiesen und behält diese Zuordnung unabhängig davon, welches Gerät angeschlossen wird.

In kleinen oder stabilen Netzwerken funktioniert dieses Prinzip zuverlässig und mit geringem administrativem Aufwand. Wachsen Infrastrukturen jedoch, verändern sich auch die Anforderungen. Mitarbeitende wechseln Arbeitsplätze, Geräte werden ausgetauscht, Gäste benötigen temporären Zugang, und IoT-Systeme sollen getrennt von produktiven Netzen betrieben werden.

Spätestens dann stellt sich eine zentrale Frage: Muss wirklich jeder Switchport manuell konfiguriert werden? Genau hier beginnt die Entwicklung hin zur dynamischen Segmentierung.

Klassische statische VLAN-Zuweisung

In der einfachsten Form wird ein Switchport dauerhaft einem bestimmten VLAN zugeordnet. In Cisco-Netzwerken erfolgt dies typischerweise über einen Access-Port:

Switch(config)# interface fastEthernet 0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10

Der Port gehört damit fest zu VLAN 10. Unabhängig davon, welches Gerät angeschlossen wird, landet sämtlicher Datenverkehr automatisch in diesem Segment.

Das Prinzip ist bewusst einfach gehalten: Die Netzwerkinfrastruktur trifft keine Entscheidung darüber, wer oder was sich verbindet. Entscheidend ist allein, an welchem physischen Port ein Gerät angeschlossen wird.

Diese Vorgehensweise bietet mehrere Vorteile. Sie ist transparent, leicht nachvollziehbar und verursacht nur wenig Komplexität. Gerade in kleineren Umgebungen oder klar abgegrenzten Bereichen – etwa Serverräumen oder Druckernetzen – bleibt die statische Portzuweisung bis heute ein praktikabler Ansatz.

Mit wachsender Infrastruktur zeigen sich jedoch Grenzen. Müssen Geräte flexibel zwischen Arbeitsplätzen wechseln oder unterschiedliche Benutzer:innen dynamisch passende Netzwerkrechte erhalten, wird die manuelle VLAN-Zuweisung schnell unpraktisch. Jede Änderung erfordert Eingriffe an der Switch-Konfiguration – ein Aufwand, der in größeren Netzwerken kaum dauerhaft skalierbar ist.

VMPS – Der frühe Cisco-Ansatz für dynamische VLANs

Noch bevor sich identitätsbasierte Netzwerkkonzepte etablierten, versuchte Cisco bereits, die starre Bindung zwischen Switchport und VLAN aufzubrechen. Ein früher Ansatz hierfür war der VLAN Membership Policy Server (VMPS).

Die Idee dahinter war für ihre Zeit durchaus innovativ: Nicht mehr der Port allein sollte über die Zugehörigkeit zu einem VLAN entscheiden, sondern das angeschlossene Gerät selbst. Als Identifikator diente dabei die MAC-Adresse.

Dynamische VLAN-Zuweisung per MAC-Adresse

In klassischen VMPS-Umgebungen wurden Switchports dynamisch konfiguriert. Sobald ein neues Gerät verbunden wurde und der erste Ethernet-Frame am Port eintraf, überprüfte der Switch zunächst, ob die MAC-Adresse bekannt war.

War dies nicht der Fall, initiierte der Switch eine Anfrage an den zentralen VMPS-Server. Die Kommunikation erfolgte über das VLAN Query Protocol (VQP) – ein proprietäres Cisco-Protokoll.

Der Ablauf war dabei vergleichsweise einfach:

  1. Ein Gerät verbindet sich mit dem Netzwerk
  2. Der Switch erkennt die MAC-Adresse des Endgeräts
  3. Über VQP fragt der Switch beim VMPS nach der passenden VLAN-Zuordnung an
  4. Der Server prüft seine Datenbank und weist dem Port dynamisch das entsprechende VLAN zu

Damit konnte ein Gerät unabhängig vom physischen Standort automatisch im richtigen Netzwerksegment landen – ein Konzept, das für damalige Verhältnisse einen erheblichen Fortschritt darstellte.

In restriktiveren Szenarien unterstützte VMPS zusätzlich einen Secure Mode. Tauchte eine unbekannte oder nicht autorisierte MAC-Adresse auf, konnte der Switch den betroffenen Port blockieren und den Zugriff vollständig verweigern.

Warum sich VMPS langfristig nicht durchgesetzt hat

Trotz des innovativen Ansatzes erwies sich VMPS langfristig als Sackgasse. Das Grundproblem lag in der Wahl der Identität: MAC-Adressen eignen sich nur bedingt als vertrauenswürdiges Merkmal. Sie lassen sich relativ leicht manipulieren und liefern kaum Kontext darüber, wer oder was sich tatsächlich verbindet.

Hinzu kamen praktische Einschränkungen im Betrieb:

  • Trunk-Ports konnten nicht dynamisch per VMPS betrieben werden
  • IEEE 802.1X und VMPS schlossen sich gegenseitig aus
  • Bei mehr als 20 aktiven Hosts pro Port konnte ein Port automatisch deaktiviert werden
  • Der administrative Aufwand für die Pflege großer MAC-Datenbanken stieg schnell an

Mit zunehmender Bedeutung von Benutzeridentitäten, Zertifikaten und rollenbasierten Sicherheitsmodellen verlor VMPS daher an Relevanz.

Aus heutiger Sicht spielt die Technologie fast nur noch in historischen Kontexten, Legacy-Umgebungen oder Zertifizierungsfragen eine Rolle. Dennoch markiert VMPS einen wichtigen Zwischenschritt in der Entwicklung: Weg vom rein portbasierten Denken – hin zu einer ersten Form dynamischer Netzwerkzuweisung.

Die eigentliche Evolution begann jedoch erst mit IEEE 802.1X und RADIUS, wo nicht mehr die MAC-Adresse, sondern die Identität von Benutzer:innen oder Geräten in den Mittelpunkt rückte.

Moderne Ansätze: 802.1X und RADIUS

Mit zunehmender Größe und Dynamik moderner Netzwerke reichte die reine Zuordnung über MAC-Adressen mit der Zeit nicht mehr aus. Unternehmen wollten nicht länger nur erkennen, welches Gerät verbunden ist, sondern vor allem verstehen: Wer verbindet sich – und welche Berechtigungen soll diese Person oder dieses System erhalten?

Genau an dieser Stelle etablierten sich IEEE 802.1X und RADIUS als moderner Standard für dynamische Netzwerksegmentierung.

Authentifizierung statt fester Portzuweisung

Im Gegensatz zu statischen VLANs oder VMPS entscheidet hier nicht mehr der physische Switchport oder eine hinterlegte MAC-Adresse über die Netzwerkzugehörigkeit. Stattdessen wird zunächst die Identität des Endgeräts oder der Benutzer:innen überprüft.

Der Ablauf folgt dabei einem klaren Prinzip:

  1. Ein Gerät verbindet sich mit einem Switchport oder WLAN
  2. Der Netzwerkzugang bleibt zunächst eingeschränkt
  3. Der Switch oder Access Point fordert eine Authentifizierung über IEEE 802.1X an
  4. Die Anfrage wird an einen RADIUS-Server weitergeleitet
  5. Nach erfolgreicher Prüfung erhält das Gerät passende Netzwerkrechte

Als RADIUS-Systeme kommen in der Praxis häufig Lösungen wie Cisco Identity Services Engine (ISE) oder Microsoft Network Policy Server (NPS) zum Einsatz.

Die Rollen von 802.1X verstehen

Damit die Authentifizierung funktioniert, arbeiten mehrere Komponenten zusammen:

  • Supplicant: Das Endgerät oder der Benutzerclient, der sich authentifiziert
  • Authenticator: Der Switch oder Access Point, der den Netzwerkzugang kontrolliert
  • Authentication Server: Der RADIUS-Server, der Identität und Berechtigungen überprüft

Der Switch selbst trifft dabei keine Sicherheitsentscheidung. Er fungiert vielmehr als Vermittler zwischen Endgerät und Authentifizierungsinstanz und setzt die vom RADIUS-Server zurückgelieferten Richtlinien technisch um.

Dieses Prinzip markiert einen fundamentalen Unterschied zu VMPS: Nicht mehr eine technische Gerätekennung entscheidet über den Netzwerkzugang, sondern eine überprüfbare Identität.

Wer tiefer in die Funktionsweise von IEEE 802.1X, RADIUS, Cisco ISE, Zertifikatsauthentifizierung und Zero-Trust-Konzepte im Netzwerk einsteigen möchte, findet im Beitrag: 802.1X und Zero Trust im Netzwerk – Identität statt Portnummer: Cisco ISE Best Practices eine ausführliche technische Einordnung inklusive Praxisbeispielen und Architekturüberblick.

Dynamische VLAN-Zuweisung in der Praxis

Nach erfolgreicher Authentifizierung kann der RADIUS-Server dynamisch entscheiden, welches Netzwerksegment zugewiesen wird. Dabei spielen Rolle, Gerätetyp, Standort oder Sicherheitskontext eine wichtige Rolle.

Typische Szenarien sind beispielsweise:

  • Mitarbeitende erhalten Zugriff auf produktive Unternehmensnetze
  • Gäste werden automatisch in isolierte Internet-VLANs verschoben
  • IoT-Geräte landen in restriktiven Segmenten mit begrenzten Kommunikationsrechten
  • Administrationssysteme erhalten privilegierte Zugriffsrechte auf Managementnetze

Der große Vorteil: Der physische Anschlussport bleibt unverändert. Unterschiedliche Benutzer:innen oder Geräte können denselben Netzwerkanschluss nutzen und dennoch automatisch in unterschiedliche VLANs gelangen. Die Segmentierung wird dadurch deutlich flexibler und folgt erstmals stärker der Identität als dem physischen Standort.

Mehr als nur VLAN-Zuweisung

In modernen Netzwerken endet der Prozess häufig nicht bei der VLAN-Auswahl. 802.1X bildet heute die Grundlage vieler Network Access Control (NAC)-Konzepte. Neben VLANs lassen sich beispielsweise auch Sicherheitsrichtlinien, Zugriffsprofile, Quarantäne-Netze oder rollenbasierte Kommunikationsrechte dynamisch anwenden.

Damit verschiebt sich die zentrale Frage im Netzwerkbetrieb zunehmend: Nicht mehr an welchem Port sich ein Gerät befindet, sondern wer oder was sich verbindet wird entscheidend.

Genau aus dieser Entwicklung entstand schließlich der nächste Evolutionsschritt: identitäts- und policybasierte Netzwerkarchitekturen wie Cisco Software Defined Access (SDA).

Praxisbeispiele dynamischer Segmentierung

Die Vorteile dynamischer VLAN-Zuweisung werden besonders deutlich, wenn unterschiedliche Benutzer:innen oder Gerätetypen dieselbe physische Infrastruktur nutzen. In modernen Unternehmensnetzen entscheidet daher zunehmend nicht mehr der Standort eines Geräts über den Netzwerkzugang, sondern dessen Identität, Rolle oder Sicherheitskontext.

Ein typisches Beispiel ist der Arbeitsplatz im Unternehmen. Mitarbeitende authentifizieren sich per IEEE 802.1X am Netzwerk und erhalten automatisch Zugriff auf das passende produktive VLAN. Wechselt eine Person den Arbeitsplatz oder verbindet sich in einem anderen Gebäudebereich, bleibt die logische Netzwerkzuordnung dennoch konsistent – ohne manuelle Anpassung am Switchport.

Auch Gästezugänge profitieren von dynamischer Segmentierung. Externe Besucher:innen können nach erfolgreicher Anmeldung automatisch in ein isoliertes Gäste-VLAN verschoben werden, das ausschließlich den Internetzugang erlaubt. Ein Zugriff auf interne Unternehmensressourcen bleibt dabei ausgeschlossen.

Besonders relevant wird dieses Prinzip im Umgang mit IoT- und OT-Geräten. Drucker, Kameras, Smart-Building-Komponenten oder industrielle Steuerungssysteme unterstützen häufig keine klassische Benutzeranmeldung. Über Mechanismen wie MAC Authentication Bypass (MAB), Geräteprofiling oder Zertifikate können solche Systeme dennoch automatisch erkannt und in restriktive Netzwerksegmente eingeordnet werden. Dadurch lassen sich Kommunikationswege gezielt begrenzen und Sicherheitsrisiken reduzieren.

Auch im Bereich Administrations- und Privileged Access zeigt sich der Mehrwert identitätsbasierter Zuweisung. Ein Standard-Notebook kann abhängig von Benutzerrolle oder Authentifizierungsstatus unterschiedliche Netzwerkrechte erhalten. Während normale Benutzer:innen Zugriff auf produktive Dienste erhalten, können Administrator:innen automatisch in stärker privilegierte Managementsegmente eingeordnet werden.

Gemeinsam ist all diesen Szenarien ein grundlegender Wandel: Nicht mehr der physische Anschlussport entscheidet über die Netzwerkzugehörigkeit, sondern der Kontext der Verbindung. Genau diese Entwicklung bildet die Grundlage moderner Network Access Control (NAC)-Konzepte – und führt letztlich zu Architekturen, in denen Segmentierung vollständig identitäts- und policybasiert funktioniert.

Exkurs: Cisco SDA – Segmentierung neu gedacht

Die Entwicklung von statischen VLANs über 802.1X bis hin zur dynamischen VLAN-Zuweisung zeigt eine klare Richtung: Netzwerke lösen sich zunehmend von physischen Ports und festen Konfigurationen. Doch selbst dynamische VLANs stoßen irgendwann an Grenzen. Auch wenn VLAN-Zuweisungen automatisiert erfolgen, bleibt die zugrunde liegende Segmentierung weiterhin stark an klassische Layer-2-Konzepte gebunden.

Cisco Software Defined Access (SDA) geht daher einen entscheidenden Schritt weiter. Im Mittelpunkt steht nicht länger die Frage, an welchem Port ein Gerät angeschlossen ist oder welches VLAN verwendet wird, sondern: Wer oder was verbindet sich – und welche Kommunikation soll erlaubt sein?

SDA versteht Segmentierung damit nicht mehr primär als Netzwerkfunktion, sondern als identitäts- und policygesteuerte Architektur. Die zentrale Steuerung erfolgt über Cisco Catalyst Center (früher DNA Center) in Kombination mit Cisco Identity Services Engine (ISE). Während Catalyst Center die Netzwerkarchitektur modelliert und automatisiert bereitstellt, liefert Cisco ISE die Identitäts- und Policy-Informationen.

Underlay und Overlay – Zwei Ebenen eines Netzwerks

Ein zentrales Architekturprinzip von SDA besteht in der konsequenten Trennung zwischen physischer Transportinfrastruktur und logischer Segmentierung.

Das Underlay bildet dabei die physische Netzwerkschicht. Es stellt die reine IP-Konnektivität zwischen allen Netzwerkkomponenten sicher und wird typischerweise auf Basis von IS-IS oder OSPF aufgebaut. Seine Aufgabe ist bewusst einfach gehalten: Das Underlay transportiert Pakete – mehr nicht.

Die eigentliche Segmentierung erfolgt dagegen im Overlay. Hier nutzt SDA VXLAN, um logische Netzsegmente unabhängig von physischer Infrastruktur abzubilden. Endgeräte können dadurch flexibel in logische Kontexte eingeordnet werden, ohne dass VLANs über die gesamte Infrastruktur hinweg manuell konsistent gehalten werden müssen.

Diese Trennung erzeugt einen wichtigen Vorteil: Das physische Netzwerk bleibt stabil und standardisiert, während sich logische Kommunikationsbeziehungen flexibel verändern lassen.

Die Rollen in der Fabric verstehen

Eine SDA-Fabric besteht aus mehreren Knotenrollen, die jeweils klar definierte Aufgaben übernehmen.

Edge Nodes bilden die Zugangsschicht. Hier werden Endgeräte, Drucker, Kameras oder Access Points angeschlossen. Die Edge Nodes übernehmen das Onboarding der Endgeräte und setzen die vom Policy-System gelieferten Regeln um.

Control Plane Nodes verwalten die Zuordnung zwischen Endpunktidentitäten und deren aktuellem Netzwerkstandort. Technisch geschieht dies über das Locator / ID Separation Protocol (LISP).

Vereinfacht lässt sich LISP wie ein Telefonbuch der Fabric verstehen:

  • Endpoint Identifier (EID): beschreibt die Identität eines Endgeräts
  • Routing Locator (RLOC): beschreibt dessen aktuellen Aufenthaltsort im Netzwerk

Dadurch kann ein Gerät seinen Standort wechseln, ohne dass dessen logische Netzwerkidentität verloren geht.

Border Nodes verbinden die Fabric mit anderen Netzwerken – etwa WAN, Datacenter oder Internet. Gleichzeitig übernehmen sie die Übergabe zwischen verschiedenen Routing-Kontexten.

Intermediate Nodes bilden schließlich die reine Transportebene innerhalb des Underlays und übernehmen ausschließlich Routing-Funktionen.

Virtual Networks und Security Group Tags

SDA unterscheidet bewusst zwischen Makrosegmentierung und Mikrosegmentierung. Auf der Ebene der Makrosegmentierung kommen sogenannte Virtual Networks (VN) zum Einsatz. Ein Virtual Network entspricht technisch einer eigenen VRF (Virtual Routing and Forwarding Instance) und trennt größere organisatorische Bereiche voneinander.

So könnten beispielsweise folgende Virtual Networks existieren:

  • Unternehmensnetz
  • Gastnetz
  • IoT-Netz
  • Produktionsumgebung

Selbst wenn identische IP-Adressbereiche verwendet würden, blieben diese logisch vollständig voneinander getrennt.

Innerhalb eines Virtual Networks erfolgt zusätzlich die Mikrosegmentierung über Security Group Tags (SGT) aus Cisco TrustSec. Statt Kommunikation ausschließlich über IP-Adressen oder VLANs zu steuern, erhalten Benutzer:innen oder Geräte eine Rolle – beispielsweise:

  • Administration
  • Gäste
  • IoT
  • Management
  • Mitarbeitende

Auf Basis dieser Rollen definieren Security Group Access Control Lists (SGACLs), welche Kommunikationsbeziehungen erlaubt oder verboten sind. Die eigentliche Policy lautet dadurch nicht mehr: IP-Adresse A darf mit IP-Adresse B sprechen, sondern vielmehr: Geräte der Rolle Mitarbeitende dürfen auf Druckdienste zugreifen – Gäste nicht.

Policy-basierte Segmentierung

Damit verändert sich auch die Denkweise moderner Netzwerke grundlegend. In klassischen VLAN-Umgebungen orientierte sich Segmentierung vor allem an Netzbereichen, Subnetzen oder Standorten. SDA verschiebt diese Logik hin zu einer Policy-basierten Architektur. Zugriffsrechte werden zentral definiert und automatisch auf Benutzer:innen oder Geräte angewendet – unabhängig davon, wo sich diese physisch befinden.

Dadurch entstehen mehrere Vorteile:

  • weniger komplexe ACL-Strukturen
  • konsistente Sicherheitsrichtlinien
  • geringerer administrativer Aufwand
  • stärkere Unterstützung von Zero-Trust-Prinzipien

Die Segmentierung folgt damit nicht länger primär der Topologie, sondern dem gewünschten Kommunikationsmodell.

Wireless und Anycast Gateway

Ein besonderer Vorteil von SDA zeigt sich in WLAN-Umgebungen. Traditionell bedeutete Roaming zwischen verschiedenen Access Points oder Netzwerksegmenten häufig Änderungen am Default Gateway oder komplexe Mobility-Konstrukte.

SDA verfolgt hier einen anderen Ansatz. Endgeräte erhalten über ein Anycast Gateway unabhängig vom Standort stets dasselbe logische Gateway. Für Benutzer:innen bleibt die Netzwerkidentität dadurch konsistent – auch dann, wenn sie sich physisch zwischen Gebäuden oder Stockwerken bewegen.

Gleichzeitig gelten dieselben Policies für kabelgebundene und drahtlose Endgeräte. Ein:e Benutzer:in erhält somit unabhängig vom Zugangsmedium dieselben Berechtigungen und Sicherheitsregeln.

Multi-Site und Transit

SDA beschränkt sich nicht auf einzelne Standorte. Über SD-Access Transit oder klassische IP-Transit-Konstrukte lassen sich mehrere Fabric-Standorte miteinander verbinden. Border Nodes übernehmen dabei die Kommunikation zwischen den Fabrics sowie den Übergang zu externen Netzen.

Mandanten- oder Sicherheitsrichtlinien können dadurch standortübergreifend konsistent umgesetzt werden – ein entscheidender Vorteil gegenüber klassischen VLAN-Konstrukten, die über größere Distanzen schnell komplex und fehleranfällig werden.

Betrieb und Best Practices

Im laufenden Betrieb unterstützt Catalyst Center Assurance die Transparenz über Datenpfade, Endgeräte und Richtlinien. Kommunikationsprobleme lassen sich dadurch deutlich gezielter analysieren als in klassischen Campus-Netzen.

Für stabile Umgebungen empfiehlt Cisco redundante Control Plane Nodes und Border Nodes, um Ausfallsicherheit zu gewährleisten.

Aus architektonischer Sicht hat sich zudem ein klarer Planungsansatz bewährt:

  1. Zunächst die Makrosegmentierung über Virtual Networks definieren
  2. Anschließend gezielt Mikrosegmentierung über Security Group Tags einführen
  3. Policies möglichst einfach und nachvollziehbar halten

Denn auch in hochautomatisierten Netzwerken gilt weiterhin: Gute Segmentierung entsteht nicht durch maximale Komplexität, sondern durch ein klares Kommunikationsmodell. SDA zeigt damit, wohin sich Netzwerksegmentierung langfristig entwickelt: Weg von port- und VLAN-basierten Strukturen – hin zu identitäts-, rollen- und policygesteuerten Fabrics.

VTP – Vereinfachung und Risiken

Mit zunehmender Zahl an VLANs entstand früh ein praktisches Problem: Wie lassen sich VLAN-Konfigurationen konsistent über viele Switches hinweg verwalten, ohne jede Änderung manuell auf jedem einzelnen Gerät durchführen zu müssen?

Cisco entwickelte hierfür das VLAN Trunking Protocol (VTP). Ziel war es, VLAN-Informationen zentral innerhalb einer Switch-Domäne zu verteilen und dadurch Administrationsaufwand zu reduzieren.

Die Idee klingt zunächst überzeugend: VLANs werden einmal definiert – und automatisch an alle relevanten Switches verteilt. Gerade in größeren Campus-Netzen versprach dies erhebliche Vereinfachungen. Gleichzeitig entwickelte sich VTP jedoch zu einer Technologie, die im produktiven Betrieb mit Vorsicht betrachtet werden muss.

Funktionsweise und Betriebsmodi

VTP ermöglicht den Austausch von VLAN-Informationen zwischen Cisco-Switches innerhalb einer gemeinsamen VTP-Domäne. Damit Geräte miteinander synchronisieren können, müssen sie denselben VTP-Domain-Namen verwenden und – sofern konfiguriert – ein gemeinsames Passwort teilen.

Die Kommunikation erfolgt über sogenannte VTP Advertisements, die über Trunk-Verbindungen übertragen werden. Änderungen an der VLAN-Datenbank – etwa neue VLANs, Umbenennungen oder Löschungen – werden dadurch automatisch an andere Switches verteilt.

Infografik zur Funktionsweise des Cisco VLAN Trunking Protocol (VTP). Die Darstellung zeigt die Betriebsmodi Server, Client und Transparent Mode sowie die Verteilung von VLAN-Informationen zwischen mehreren Switches über Trunk-Links. Ergänzend werden VTP-Domäne, Konfigurationsversionsnummern, VLAN-Datenbank und typische Risiken bei fehlerhafter Synchronisation visualisiert.

Ein zentrales Element von VTP ist die Konfigurationsversionsnummer. Jede Änderung erhöht diese Nummer. Switches vergleichen die empfangenen Versionsstände und übernehmen grundsätzlich die Datenbank mit der höchsten Versionsnummer. Genau dieses Verhalten macht VTP zugleich leistungsfähig – und potenziell gefährlich.

Cisco unterscheidet mehrere Betriebsmodi:

  • Server Mode: VLANs können erstellt, geändert oder gelöscht werden. Änderungen werden automatisch innerhalb der VTP-Domäne verteilt
  • Client Mode: Der Switch empfängt VLAN-Informationen, darf selbst jedoch keine Änderungen vornehmen
  • Transparent Mode: VLANs werden lokal verwaltet. VTP-Informationen werden zwar weitergeleitet, jedoch nicht übernommen

In modernen Netzwerken spielt insbesondere der Transparent Mode eine wichtige Rolle.

Vorteile zentraler VLAN-Verwaltung

Der größte Vorteil von VTP liegt in der Vereinfachung administrativer Prozesse. Ohne VTP müsste jedes VLAN auf allen beteiligten Switches manuell erstellt werden – insbesondere in großen Campus-Netzen mit vielen Access-Switches ein nicht zu unterschätzender Aufwand. Durch die automatische Verteilung bleiben VLAN-Konfigurationen konsistent und Änderungen lassen sich deutlich schneller umsetzen.

Gerade in frühen Campus-Designs mit vielen Layer-2-Segmenten war dies ein relevanter Effizienzgewinn. Konfigurationsfehler konnten reduziert und neue VLANs innerhalb kurzer Zeit standortweit bereitgestellt werden. Unter idealen Bedingungen funktioniert VTP daher äußerst komfortabel.

VTP Pruning – Optimierung oder Stolperfalle?

Eine ergänzende Funktion von VTP ist das sogenannte VTP Pruning. Ziel dieser Funktion ist es, unnötigen VLAN-Verkehr auf Trunk-Verbindungen zu reduzieren. Ohne Pruning werden Broadcast-, Multicast- und unbekannte Unicast-Frames grundsätzlich über alle Trunk-Links transportiert, auf denen das jeweilige VLAN erlaubt ist – unabhängig davon, ob am Ziel-Switch überhaupt aktive Endgeräte dieses VLANs existieren.

Gerade in größeren Layer-2-Umgebungen kann dies zu unnötigem Datenverkehr führen. Die Grundidee von VTP Pruning lautet daher: Nur VLANs, die auf einem Ziel-Switch tatsächlich benötigt werden, sollen Traffic über den Trunk transportieren.

Dazu analysieren Switches innerhalb der VTP-Domäne, welche VLANs auf nachgelagerten Geräten tatsächlich aktiv genutzt werden. Erkennt ein Switch, dass auf einem entfernten Switch keine Ports eines bestimmten VLANs existieren, werden entsprechende Broadcast-, Multicast- oder Unknown-Unicast-Frames auf diesem Trunk nicht mehr weitergeleitet.

Ein vereinfachtes Beispiel verdeutlicht das Prinzip:

Angenommen, Switch A transportiert die VLANs 10, 20 und 30, während Switch B lediglich Endgeräte in VLAN 10 besitzt. Ohne Pruning würden Broadcasts aus VLAN 20 und 30 trotzdem über den Trunk übertragen – obwohl es dort keine Empfänger gibt. Mit aktiviertem VTP Pruning erkennt Switch A diese Situation und unterdrückt unnötigen Verkehr für VLAN 20 und 30.

Infografik zur Funktionsweise von VTP Pruning in Cisco-Switching-Umgebungen. Die Darstellung vergleicht Trunk-Verkehr ohne und mit VTP Pruning zwischen zwei Switches. Visualisiert wird, wie unnötiger Broadcast-, Multicast- und Unknown-Unicast-Verkehr ohne Pruning übertragen wird und wie nur benötigte VLANs bei aktiviertem Pruning den Trunk-Link nutzen. Ergänzend werden Trunk-Auslastung und empfohlene manuelle VLAN-Freigaben gezeigt.

Gerade in großen Campus-Netzen mit vielen VLANs kann dies Bandbreite sparen und Broadcast-Domänen effizienter gestalten.

In der Praxis wird VTP Pruning jedoch differenziert betrachtet. Da die Mechanismen automatisiert arbeiten, kann unerwartetes Verhalten auftreten – insbesondere in komplexeren Topologien oder bei Sonderfällen, in denen VLAN-Nutzung nicht eindeutig erkannt wird. Dies erschwert mitunter Fehlersuche und Transparenz.

Viele Administrator:innen bevorzugen deshalb einen stärker kontrollierten Ansatz und definieren erlaubte VLANs auf Trunk-Links explizit:

Switch(config-if)# switchport trunk allowed vlan 10,20

Dieses Verfahren erfordert zwar mehr manuellen Aufwand, bietet jedoch vollständige Kontrolle darüber, welche VLANs tatsächlich über einen Trunk transportiert werden. VTP Pruning zeigt damit exemplarisch die Ambivalenz vieler Automatisierungsmechanismen im Netzwerkbetrieb: Weniger Administrationsaufwand bedeutet nicht zwangsläufig mehr Betriebssicherheit.

Gerade in produktiven Enterprise-Umgebungen wird daher häufig bewusst auf automatisches Pruning verzichtet und stattdessen auf nachvollziehbare, explizite Trunk-Konfigurationen gesetzt.

Risiken im produktiven Betrieb

Die größte Schwäche von VTP liegt paradoxerweise in seiner größten Stärke: der automatischen Synchronisation. Da Switches grundsätzlich der höchsten Konfigurationsversionsnummer vertrauen, kann bereits ein einzelnes falsch vorbereitetes Gerät erhebliche Auswirkungen auf das gesamte Netzwerk haben.

Ein klassisches Szenario aus der Praxis:

Ein älterer Switch wird in eine produktive Umgebung eingebunden. Die VLAN-Datenbank auf diesem Gerät ist leer, die Konfigurationsversionsnummer jedoch höher als im laufenden Netzwerk.

Innerhalb weniger Sekunden kann sich diese leere Datenbank auf alle Switches replizieren – produktive VLANs verschwinden, Trunk-Verbindungen verlieren ihre Segmentzuordnung und ganze Netzbereiche fallen aus.

Dieses Verhalten führte in vielen Unternehmen zu einer klaren Neubewertung von VTP.

Hinzu kommt ein grundsätzlicher Aspekt moderner Netzwerke: Infrastruktur wird heute zunehmend automatisiert, versioniert und zentral dokumentiert. Viele Administrator:innen bevorzugen daher bewusst kontrollierte und nachvollziehbare Konfigurationsprozesse gegenüber automatischer Layer-2-Synchronisation.

Warum viele Administrator:innen heute auf Transparent Mode setzen

Aus diesen Gründen wird VTP in vielen Enterprise-Umgebungen heute bewusst nur eingeschränkt oder gar nicht mehr genutzt. Besonders verbreitet ist der Transparent Mode. Switches leiten VTP-Informationen dabei zwar weiterhin durch die Infrastruktur weiter, übernehmen jedoch keine automatischen Änderungen an ihrer eigenen VLAN-Datenbank.

Der administrative Aufwand steigt dadurch leicht an, da VLANs weiterhin manuell gepflegt werden müssen. Gleichzeitig gewinnen Administrator:innen jedoch ein hohes Maß an Kontrolle und reduzieren das Risiko unbeabsichtigter Änderungen erheblich. Gerade in produktiven Umgebungen gilt daher häufig ein pragmatischer Grundsatz: Lieber bewusst etwas mehr Verwaltungsaufwand – als ein unkontrollierter VLAN-Ausfall im gesamten Netzwerk.

VTP bleibt damit eine technologisch interessante, historisch wichtige und in bestimmten Szenarien weiterhin nützliche Lösung. In modernen Enterprise-Netzen wird ihr Einsatz jedoch meist sehr bewusst abgewogen.

L3-Switching – Wenn VLANs miteinander sprechen müssen

VLANs schaffen Ordnung im Netzwerk. Sie begrenzen Broadcast-Domänen, trennen organisatorische Bereiche voneinander und erhöhen Sicherheit sowie Skalierbarkeit. Gleichzeitig erzeugen sie jedoch eine neue Herausforderung: Wie kommunizieren Systeme unterschiedlicher VLANs miteinander?

Denn VLANs isolieren Netzsegmente bewusst auf Layer 2. Ein Gerät in VLAN 10 kann nicht ohne Weiteres direkt mit einem System in VLAN 20 kommunizieren – selbst dann nicht, wenn beide am selben Switch angeschlossen sind.

Damit stößt klassisches Switching an eine natürliche Grenze: Layer 2 segmentiert – Layer 3 verbindet. Sobald unterschiedliche Broadcast-Domänen miteinander kommunizieren müssen, wird Routing erforderlich.

Warum Layer 2 an Grenzen stößt

Die Isolation von VLANs ist technisch gewollt. Broadcasts bleiben lokal begrenzt, und Netzbereiche lassen sich sauber voneinander trennen. Für viele Szenarien reicht dies vollkommen aus. In der Praxis müssen jedoch unterschiedliche Systeme regelmäßig miteinander kommunizieren.

Einige typische Beispiele:

  • Mitarbeitende benötigen Zugriff auf zentrale Serverdienste
  • Drucker befinden sich in separaten Infrastruktur-VLANs
  • WLAN-Clients kommunizieren mit produktiven Anwendungen
  • IoT- oder Management-Netze benötigen kontrollierten Zugriff auf zentrale Systeme

Ein reines Layer-2-Netz kann solche Kommunikation nicht eigenständig ermöglichen. Da jedes VLAN einer eigenen Broadcast-Domäne entspricht, benötigt jedes Segment auch ein eigenes IP-Subnetz – und damit ein Gateway, das den Verkehr zwischen diesen Netzen vermittelt. Genau hier beginnt die Rolle von Layer 3.

Router-on-a-Stick – Die historische Zwischenstufe

Bevor leistungsfähige Layer-3-Switches zum Standard wurden, erfolgte Inter-VLAN-Kommunikation häufig über ein Design, das heute als Router-on-a-Stick bekannt ist. Die Idee war vergleichsweise einfach: Ein klassischer Router wurde über eine einzelne physische Verbindung mit einem Switch verbunden. Über einen 802.1Q-Trunk transportierte diese Leitung mehrere VLANs gleichzeitig. Auf dem Router wurden anschließend sogenannte Subinterfaces eingerichtet – jeweils eines pro VLAN.

Ein vereinfachtes Beispiel:

interface GigabitEthernet0/0.10
  encapsulation dot1Q 10
  ip address 192.168.10.1 255.255.255.0

interface GigabitEthernet0/0.20
  encapsulation dot1Q 20
  ip address 192.168.20.1 255.255.255.0

Jedes Subinterface fungierte dabei als Default Gateway für das jeweilige VLAN.

Musste ein Endgerät aus VLAN 10 mit einem System in VLAN 20 kommunizieren, lief der Datenverkehr zunächst zum Router, wurde dort geroutet und anschließend über dieselbe physische Verbindung zurück zum Switch transportiert.

Für kleinere Netzwerke funktionierte dieses Modell gut. Mit wachsender Infrastruktur zeigte sich jedoch ein grundlegendes Problem: Der Router entwickelte sich schnell zum Flaschenhals.

Sämtlicher Inter-VLAN-Verkehr musste denselben Uplink passieren und vollständig über die CPU des Routers verarbeitet werden. Mit steigender Zahl an VLANs, Endgeräten und Anwendungen nahmen Latenz und Auslastung entsprechend zu.

Die Antwort auf dieses Skalierungsproblem waren schließlich Layer-3-Switches, die Routing direkt in der Switching-Hardware integrierten.

Layer-3-Switching im Campus

Mit steigender Zahl an VLANs und wachsendem Netzwerkverkehr wurde schnell deutlich, dass klassische Router-on-a-Stick-Konstrukte langfristig nur begrenzt skalierbar sind. Unternehmen benötigten eine Lösung, die Routing-Funktionalität direkt in die Switching-Infrastruktur integriert – ohne zusätzliche Router-Hops oder zentrale Flaschenhälse. Genau hier entstand der Layer-3-Switch.

Ein Layer-3-Switch kombiniert klassische Layer-2-Funktionen wie VLAN-Switching mit Routing-Funktionalität auf Layer 3. Im Unterschied zu traditionellen Routern erfolgen Routingentscheidungen dabei nicht primär über die CPU, sondern direkt in spezialisierter Hardware – bei Cisco beispielsweise mithilfe von Cisco Express Forwarding (CEF). Dadurch lassen sich hohe Datenmengen mit geringer Latenz verarbeiten – ein entscheidender Vorteil in modernen Campus-Netzen.

Gerade in Enterprise-Architekturen übernehmen Layer-3-Switches heute häufig die Rolle des Distribution- oder Core-Layers, wo unterschiedliche Netzwerksegmente zusammengeführt und miteinander verbunden werden.

Inter-VLAN-Routing mit SVIs

Das am weitesten verbreitete Verfahren für Kommunikation zwischen VLANs ist das Inter-VLAN-Routing über Switched Virtual Interfaces (SVIs). Ein SVI stellt dabei ein logisches Layer-3-Interface für ein VLAN dar und übernimmt typischerweise die Funktion des Default Gateways.

Für jedes VLAN wird dabei ein eigenes virtuelles Interface erstellt:

Switch(config)# interface vlan 10
Switch(config-if)# ip address 192.168.10.1 255.255.255.0
Switch(config-if)# no shutdown

Das Interface VLAN 10 fungiert anschließend als Gateway für alle Endgeräte dieses Segments. Für weitere VLANs werden entsprechende zusätzliche SVIs angelegt.

Ein Beispiel:

  • VLAN 10 → Gateway 192.168.10.1
  • VLAN 20 → Gateway 192.168.20.1
  • VLAN 30 → Gateway 192.168.30.1

Möchte nun ein Gerät aus VLAN 10 mit einem Server in VLAN 20 kommunizieren, erfolgt die Weiterleitung direkt innerhalb des Layer-3-Switches. Der Traffic muss keinen externen Router mehr passieren und verlässt nicht unnötig die lokale Infrastruktur. Das verbessert Performance und Skalierbarkeit erheblich.

So funktioniert das Routing zwischen VLANs

Technisch betrachtet arbeitet der Layer-3-Switch dabei wie ein Router – allerdings deutlich effizienter. Sobald ein Endgerät erkennt, dass sich ein Ziel außerhalb des eigenen Subnetzes befindet, sendet es den Datenverkehr an sein Default Gateway, also das jeweilige SVI. Der Switch prüft anschließend seine Routing-Tabelle und entscheidet, über welches Zielinterface das Paket weitergeleitet werden muss. Die Weiterleitung erfolgt dabei hardwarebeschleunigt und bleibt vollständig innerhalb der Switching-Plattform.

Damit verschiebt sich die Rolle des Switches grundlegend: Er transportiert nicht mehr nur Ethernet-Frames – sondern trifft eigenständig Routingentscheidungen.

Routed Ports vs. SVIs

Neben SVIs unterstützen Layer-3-Switches auch sogenannte Routed Ports. Dabei wird ein physischer Switchport aus der klassischen Switching-Domäne herausgelöst und wie ein Routerinterface behandelt:

Switch(config)# interface gigabitEthernet1/0/1
Switch(config-if)# no switchport
Switch(config-if)# ip address 192.168.100.1 255.255.255.0

Im Unterschied zu einem SVI gehört ein Routed Port keinem VLAN an und verarbeitet keine Ethernet-Switching-Funktionen. Stattdessen erhält der Port direkt eine IP-Adresse und verhält sich wie ein klassisches Layer-3-Interface eines Routers.

Beide Konzepte erfüllen unterschiedliche Aufgaben:

  • SVIs eignen sich besonders für Inter-VLAN-Routing innerhalb von Campus-Netzen
  • Routed Ports werden häufig für Punkt-zu-Punkt-Verbindungen zwischen Core-, Distribution- oder Datacenter-Komponenten eingesetzt

In der Praxis treten beide Ansätze oft gemeinsam auf: Endgeräte kommunizieren über VLANs und SVIs, während die eigentliche Campus-Backbone-Kommunikation über Routed Links erfolgt.

Vorteile moderner L3-Switches

Layer-3-Switches gehören heute zum Standard moderner Enterprise-Netzwerke, weil sie Segmentierung und Routing effizient miteinander verbinden. Der größte Vorteil liegt in der Performance. Routing erfolgt direkt in spezialisierten Hardwarepfaden und nicht über einen separaten Router-Hop. Dadurch sinken Latenzen, und selbst große Mengen an Inter-VLAN-Verkehr lassen sich effizient verarbeiten.

Gleichzeitig ermöglichen Layer-3-Switches deutlich flexiblere Designs. Unternehmen können VLAN-Segmentierung, Routing und Sicherheitszonen sauber kombinieren, ohne zusätzliche Geräte in den Datenpfad integrieren zu müssen.

Zu den wichtigsten Vorteilen zählen insbesondere:

  • Hohe Performance: Hardwarebasiertes Routing über Technologien wie Cisco Express Forwarding (CEF)
  • Geringere Latenz: Kein externer Router-Hop erforderlich
  • Flexibles Design: Kombination aus VLANs, SVIs und Routed Ports
  • Skalierbarkeit: Viele VLANs lassen sich zentral und performant verbinden
  • Campus-Integration: Ideale Grundlage für Distribution- und Core-Schichten

Damit wurde Layer-3-Switching über viele Jahre zum Standardmodell moderner Campus-Netze. Gleichzeitig zeigt sich jedoch erneut ein wiederkehrendes Muster in der Netzwerkevolution: Mit wachsender Größe und Dynamik steigen auch die Anforderungen an Flexibilität und Skalierbarkeit.

Gerade in virtualisierten Rechenzentren, Multi-Tenant-Umgebungen oder hochmobilen Workload-Szenarien reichen klassische VLAN- und Routing-Konzepte irgendwann nicht mehr aus – und genau dort beginnt die nächste Evolutionsstufe.

VLAN-Sicherheit – Segmentierung ist nicht automatisch Sicherheit

VLANs gehören zu den wichtigsten Werkzeugen moderner Netzwerksegmentierung. Sie trennen Broadcast-Domänen, reduzieren unnötigen Netzwerkverkehr und ermöglichen die logische Trennung organisatorischer oder technischer Bereiche.

Gleichzeitig entsteht in der Praxis häufig ein Missverständnis: Segmentierung bedeutet nicht automatisch Sicherheit.

Zwar verhindern VLANs, dass Broadcast-Traffic unkontrolliert das gesamte Layer-2-Netz erreicht, sie stellen jedoch keine vollständige Sicherheitsgrenze dar. Geräte innerhalb eines VLANs können grundsätzlich direkt miteinander kommunizieren, und Fehlkonfigurationen oder Standardverhalten lassen sich unter Umständen gezielt ausnutzen.

Für belastbare Sicherheitsarchitekturen reichen VLANs allein daher nicht aus. Erst in Kombination mit Mechanismen wie Access Control Lists (ACLs), Firewalls, Network Access Control (NAC) oder Zero-Trust-Konzepten entsteht ein umfassender Schutz.

VLAN Hopping verstehen

Unter VLAN Hopping versteht man Angriffe, bei denen versucht wird, Netzwerkverkehr in ein VLAN einzuschleusen, zu dem eigentlich kein Zugriff bestehen sollte. Das Grundprinzip besteht darin, die logische Trennung von VLANs gezielt zu umgehen.

Zwei Verfahren spielen dabei historisch und technisch eine besondere Rolle:

  • Switch Spoofing
  • Double Tagging

Auch wenn beide Methoden heute durch Best Practices deutlich erschwert werden, verdeutlichen sie eine wichtige Erkenntnis: VLANs allein sind keine absolute Sicherheitsgrenze.

Switch Spoofing

Beim Switch Spoofing versucht ein Angreifer, einen Switchport dazu zu bringen, sich wie eine Trunk-Verbindung zu verhalten. Der Hintergrund: Cisco-Switches können Trunk-Links automatisch aushandeln. Befindet sich ein Port in Modi wie dynamic auto oder dynamic desirable, kann ein manipuliertes Endgerät den Switch unter Umständen dazu bewegen, eine Trunk-Verbindung aufzubauen.

Gelingt dies, erhält der Angreifer potenziell Zugriff auf mehrere VLANs gleichzeitig und kann Frames gezielt in unterschiedliche Segmente einschleusen. Das Risiko entsteht dabei weniger durch VLANs selbst, sondern vielmehr durch unsichere Standardkonfigurationen.

Aus diesem Grund gilt heute als Best Practice:

Switch(config-if)# switchport mode access

Access-Ports sollten konsequent statisch konfiguriert und automatische Trunk-Aushandlungen deaktiviert werden.

Double Tagging

Ein zweites bekanntes Verfahren ist das sogenannte Double Tagging. Hier versieht ein Angreifer einen Ethernet-Frame bewusst mit zwei VLAN-Tags.

Der erste Switch entfernt beim Weiterleiten zunächst das äußere VLAN-Tag – genau so, wie es beim Native VLAN vorgesehen ist. Dadurch bleibt das zweite Tag erhalten und kann auf einem nachgelagerten Switch dazu führen, dass der Frame einem anderen VLAN zugeordnet wird. In der Theorie lässt sich auf diese Weise eine VLAN-Grenze überwinden.

In der Praxis ist der Angriff jedoch an mehrere Bedingungen geknüpft:

  • Der Angreifer muss sich im Native VLAN befinden
  • Es muss ein 1Q-Trunk beteiligt sein
  • Ziel-VLAN und Trunk-Verhalten müssen passend konfiguriert sein

Dadurch gilt Double Tagging heute eher als Spezialfall denn als alltägliches Bedrohungsszenario.

Native VLAN Exploits

Eine besondere Rolle spielt dabei das Native VLAN. Auf 802.1Q-Trunks werden Frames ohne VLAN-Tag automatisch diesem VLAN zugeordnet. Standardmäßig ist dies häufig weiterhin VLAN 1 – eine Konfiguration, die in produktiven Netzwerken als ungünstig gilt. Da untagged Traffic besondere Behandlung erfährt, kann das Native VLAN unbeabsichtigt Angriffsflächen schaffen oder Fehlkonfigurationen begünstigen.

Viele Unternehmen verfolgen deshalb einen einfachen Grundsatz: Das produktive Netzwerk sollte niemals auf VLAN 1 basieren. Stattdessen empfiehlt sich ein dediziertes, möglichst ungenutztes Native VLAN, das ausschließlich für diesen Zweck reserviert bleibt.

Risiken durch DTP

Ein eng verwandtes Risiko entsteht durch das Dynamic Trunking Protocol (DTP). Cisco entwickelte DTP, um Trunk-Verbindungen automatisch auszuhandeln und den Administrationsaufwand zu reduzieren. In modernen Netzwerken wird diese Automatisierung jedoch zunehmend kritisch betrachtet.

Gerade unbeabsichtigt aktive DTP-Konfigurationen können Angriffsflächen eröffnen, wenn Ports nicht explizit als Access- oder Trunk-Port definiert wurden. Deshalb gilt heute in Enterprise-Netzen meist ein klarer Grundsatz: Trunks werden bewusst konfiguriert – nicht automatisch ausgehandelt. Neben einer festen Portkonfiguration wird DTP auf nicht benötigten Interfaces daher häufig vollständig deaktiviert.

Private VLANs als Schutzmechanismus

Eine interessante Erweiterung klassischer VLAN-Konzepte stellen Private VLANs (PVLANs) dar, die in RFC 5517 beschrieben werden. Ihr Ziel besteht darin, Systeme innerhalb desselben VLANs zusätzlich voneinander zu isolieren.

Dies erscheint zunächst widersprüchlich, ist jedoch in bestimmten Szenarien äußerst sinnvoll. Gerade in Serverfarmen, Hosting-Umgebungen, DMZ-Strukturen oder gemeinsam genutzten Infrastrukturen besteht häufig die Anforderung, dass Systeme zwar denselben Layer-2-Bereich nutzen, jedoch nicht uneingeschränkt direkt miteinander kommunizieren dürfen.

Private VLANs unterscheiden typischerweise zwischen:

  • Isolated Ports: Keine direkte Kommunikation zwischen Hosts
  • Community Ports: Kommunikation nur innerhalb definierter Gruppen
  • Promiscuous Ports: Kommunikation mit zentralen Diensten wie Firewalls oder Gateways

Dadurch lassen sich Ost-West-Bewegungen innerhalb eines Segments gezielt einschränken und potenzielle Angriffsflächen reduzieren.

Best Practices für sichere VLAN-Designs

Die beschriebenen Angriffsszenarien zeigen deutlich:

VLANs verbessern Sicherheit – ersetzen sie aber nicht.

Für belastbare Netzdesigns haben sich daher mehrere Schutzmaßnahmen etabliert:

  • DTP deaktivieren: Access-Ports konsequent statisch konfigurieren
  • Native VLAN ändern: VLAN 1 vermeiden und dedizierte Native VLANs nutzen
  • Trunks einschränken: Nur tatsächlich benötigte VLANs zulassen (switchport trunk allowed vlan)
  • Ungenutzte Ports deaktivieren: Nicht verwendete Interfaces abschalten oder isolieren
  • Port Security einsetzen: MAC-Adressen begrenzen und Verstöße überwachen
  • 1X und NAC ergänzen: Netzwerkzugriff identitätsbasiert steuern
  • Management-Netze trennen: Infrastrukturzugriffe konsequent separieren

Gerade die Kombination aus VLAN-Segmentierung und IEEE 802.1X stellt heute eine wichtige Grundlage moderner Enterprise-Netze dar. Auf die technische Umsetzung mit Cisco ISE, RADIUS und Zero-Trust-Prinzipien gehe ich im Beitrag Cisco ISE, VLAN und 802.1X – Zero Trust in der Praxis ausführlich ein.

VLAN-Sicherheit im Zero-Trust-Kontext

Moderne Sicherheitsarchitekturen betrachten VLANs zunehmend nur noch als eine Ebene der Segmentierung. Im Sinne von Zero Trust gilt: Kein Netzwerksegment ist automatisch vertrauenswürdig. Ein Gerät innerhalb desselben VLANs erhält daher nicht automatisch uneingeschränkten Zugriff auf andere Systeme. Stattdessen werden Kommunikationsbeziehungen zunehmend über Identitäten, Rollen und Policies gesteuert.

Technologien wie Cisco TrustSec, Security Group Tags (SGT), Mikrosegmentierung oder Software Defined Access (SDA) entwickeln den ursprünglichen VLAN-Gedanken konsequent weiter. Die zentrale Frage verändert sich dadurch grundlegend: Nicht mehr in welchem VLAN sich ein Gerät befindet, sondern welche Kommunikation erlaubt sein soll wird entscheidend.

VLANs bleiben damit ein unverzichtbares Fundament moderner Netzwerke – ihre Sicherheitswirkung entfalten sie jedoch erst im Zusammenspiel mit einer übergeordneten Sicherheitsarchitektur.

Warum VLANs irgendwann nicht mehr reichen

Über viele Jahre waren VLANs die zentrale Antwort auf die Herausforderung wachsender Netzwerke. Sie ermöglichten eine saubere logische Segmentierung, reduzierten Broadcast-Domänen und schufen eine flexible Trennung zwischen organisatorischen oder technischen Bereichen. Für klassische Campus-Netze funktionierte dieses Modell hervorragend.

Mit zunehmender Größe moderner Infrastrukturen änderten sich jedoch die Anforderungen grundlegend. Virtualisierung, Cloud-Plattformen und hochdynamische Rechenzentren führten dazu, dass traditionelle Layer-2-Konzepte zunehmend an ihre natürlichen Grenzen stießen.

Die Frage lautete plötzlich nicht mehr nur: Wie lassen sich Netzwerke segmentieren?, sondern vielmehr: Wie lassen sich hochdynamische, verteilte und skalierende Systeme flexibel miteinander verbinden?

Die Grenzen klassischer Segmentierung

VLANs basieren auf einem vergleichsweise einfachen Grundprinzip: Geräte werden in logisch getrennte Broadcast-Domänen eingeordnet. Diese Segmentierung funktioniert zuverlässig, solange Netzwerke überschaubar bleiben und sich Kommunikationsmuster nur langsam verändern.

Mit wachsender Komplexität steigen jedoch auch die Anforderungen. In modernen Unternehmensnetzen müssen Workloads häufig zwischen Standorten verschoben werden, virtuelle Systeme dynamisch bereitgestellt werden und unterschiedliche organisatorische Bereiche parallel auf derselben Infrastruktur betrieben werden.

Klassische VLAN-Strukturen geraten dabei zunehmend unter Druck. Denn VLANs bleiben eng mit Layer-2-Domänen, physischen Switches und festen Topologien verbunden. Was im Campus-Netz noch praktikabel erscheint, wird im hochdynamischen Datacenter schnell zur administrativen Herausforderung.

Das Problem der 4096 VLANs

Eine technische Grenze von VLANs ergibt sich direkt aus dem Aufbau des IEEE-802.1Q-Headers. Da die VLAN-ID lediglich 12 Bit umfasst, lassen sich maximal 4096 VLANs adressieren. Tatsächlich stehen in produktiven Umgebungen sogar etwas weniger Segmente zur Verfügung, da bestimmte IDs reserviert sind. Für klassische Unternehmensnetze ist diese Größenordnung häufig ausreichend.

In modernen Rechenzentren, Hosting-Umgebungen oder Cloud-Szenarien verändert sich die Perspektive jedoch erheblich. Dort müssen oft Tausende voneinander isolierte Kunden-, Applikations- oder Sicherheitssegmente parallel betrieben werden. Gerade Multi-Tenant-Umgebungen stoßen hier schnell an Grenzen.

Die Frage verschiebt sich dadurch von: Wie viele VLANs werden heute benötigt? zu: Wie viele logisch getrennte Netzsegmente könnten künftig erforderlich werden?

Virtualisierung verändert den Datenverkehr

Ein weiterer Wendepunkt entstand durch die zunehmende Virtualisierung von Workloads. In traditionellen Rechenzentren war ein Server fest mit seinem Standort verbunden. Anwendungen liefen auf dedizierter Hardware, und Netzwerkpfade blieben über lange Zeit stabil.

Mit der Verbreitung von Hypervisoren wie VMware ESXi, Hyper-V oder KVM änderte sich dieses Modell grundlegend. Virtuelle Maschinen lassen sich dynamisch verschieben, replizieren oder neu bereitstellen – oft ohne Unterbrechung des laufenden Betriebs. Technologien wie vMotion oder Live Migration ermöglichen es beispielsweise, Workloads zwischen Hosts zu verschieben, während ihre Netzwerkidentität erhalten bleibt.

Damit entsteht jedoch ein neues Problem: Das Netzwerk muss beweglich werden. Virtuelle Systeme erwarten konsistente Erreichbarkeit – unabhängig davon, auf welchem physischen Host sie aktuell betrieben werden. Klassische VLAN-Strukturen geraten dabei zunehmend an organisatorische und technische Grenzen.

Ost-West-Traffic statt Nord-Süd-Kommunikation

Gleichzeitig veränderten sich die Kommunikationsmuster im Rechenzentrum grundlegend. Traditionell dominierte der sogenannte Nord-Süd-Traffic: Endgeräte kommunizierten primär mit zentralen Servern oder externen Diensten. Datenströme verliefen überwiegend vertikal – vom Access Layer zum Core und zurück.

Mit der Virtualisierung entstand jedoch ein anderes Bild. Applikationen bestehen zunehmend aus vielen verteilten Komponenten, die intensiv miteinander kommunizieren. Datenbanken, Frontend-Systeme, APIs, Storage-Services oder Sicherheitsmechanismen tauschen permanent Informationen aus. Dadurch wächst der Anteil des Ost-West-Traffics, also der horizontalen Kommunikation zwischen Systemen innerhalb desselben Rechenzentrums.

Klassische Layer-2- und VLAN-Designs wurden ursprünglich jedoch nicht für massive horizontale Kommunikationsmuster entwickelt. Broadcast-Domänen wachsen, Routingpfade werden ineffizienter und die Abhängigkeit von stabilen Layer-2-Strukturen steigt.

Multi-Tenant- und Cloud-Anforderungen

Zusätzlichen Druck erzeugen moderne Cloud- und Hosting-Modelle. Unternehmen möchten heute häufig unterschiedliche Kund:innen, Geschäftsbereiche oder Workloads strikt voneinander isolieren – obwohl sie dieselbe physische Infrastruktur gemeinsam nutzen.

In solchen Szenarien reicht klassische VLAN-Segmentierung oft nicht mehr aus.

Jede Umgebung benötigt:

  • eigene Sicherheitsgrenzen
  • konsistente Netzwerkidentitäten
  • flexible Skalierung
  • möglichst standortunabhängige Bereitstellung

Gerade in hybriden Cloud-Umgebungen oder Service-Provider-Netzen steigt dadurch die Komplexität erheblich. Netzwerke müssen nicht nur isolieren – sie müssen zugleich hochdynamisch bleiben.

Warum Datacenter neue Konzepte benötigen

Diese Entwicklungen führten zu einer grundlegenden Erkenntnis: Klassische Layer-2-Segmentierung allein reicht für moderne Datacenter nicht mehr aus. Die Kombination aus begrenztem VLAN-Adressraum, steigender Virtualisierung, wachsendem Ost-West-Traffic und Multi-Tenant-Anforderungen machte neue Ansätze erforderlich.

Gesucht wurde eine Architektur, die:

  • deutlich stärker skaliert,
  • logische Segmente unabhängig von der physischen Infrastruktur abbildet,
  • virtuelle Workloads flexibel unterstützt,
  • und Layer-2-Kommunikation über beliebige Layer-3-Netze hinweg ermöglicht.

Genau aus dieser Anforderung heraus entstand die nächste Evolutionsstufe moderner Netzwerke: Overlay-Netzwerke – und insbesondere VXLAN.

Netzwerkarchitekturen im Vergleich – Campus, Datacenter und Fabric

Netzwerke unterscheiden sich nicht nur durch Protokolle oder Segmentierungstechniken – auch ihre grundlegende Architektur folgt unterschiedlichen Anforderungen. Über viele Jahre dominierten klassische hierarchische Modelle, die sich hervorragend für Campus-Netze eigneten. Mit der zunehmenden Virtualisierung und dem Wandel moderner Rechenzentren entstanden jedoch neue Kommunikationsmuster, die andere Designprinzipien erforderlich machten.

Die entscheidende Frage lautet dabei: Welche Architektur passt zu welchem Kommunikationsverhalten?

Das klassische Core-Distribution-Access-Modell

In klassischen Enterprise-Campus-Netzen hat sich über viele Jahre das sogenannte Core-Distribution-Access-Modell etabliert. Es folgt einer klaren hierarchischen Struktur und trennt unterschiedliche Aufgabenbereiche voneinander.

Der Access Layer bildet die Einstiegsebene für Endgeräte. Hier werden Clients, Drucker, Access Points oder IP-Telefone an das Netzwerk angebunden. VLAN-Zuweisungen, Port-Security oder IEEE 802.1X finden typischerweise auf dieser Ebene statt.

Darüber liegt der Distribution Layer. Er bündelt mehrere Access-Switches, übernimmt häufig das Inter-VLAN-Routing und dient als Policy-Grenze für Sicherheitsregeln, ACLs oder Quality-of-Service-Konfigurationen.

Im oberen Bereich befindet sich schließlich der Core Layer, der als hochperformantes Backbone dient und unterschiedliche Netzwerkbereiche miteinander verbindet.

Die folgende Abbildung verdeutlicht den hierarchischen Aufbau des klassischen Campus-Modells. Gut erkennbar ist die funktionale Trennung zwischen Access-, Distribution- und Core-Layer: Während der Access Layer Endgeräte anbindet, bündelt die Distribution mehrere Segmente und übernimmt zentrale Steuerungsfunktionen wie Inter-VLAN-Routing oder Richtlinienumsetzung. Der Core Layer bildet schließlich das performante Backbone und verbindet unterschiedliche Netzwerkbereiche mit hoher Verfügbarkeit.

Technische Infografik einer klassischen hierarchischen Three-Tier-Netzwerkarchitektur mit Core-, Distribution- und Access-Layer. Die Darstellung zeigt redundante Core- und Distribution-Switches, Access-Switches für Endgeräte sowie die Anbindung von Clients, VoIP-Telefonen, Access Points, Kameras und Druckern. Visualisiert werden Nord-Süd-Datenverkehr sowie unterschiedliche Uplink-Geschwindigkeiten zwischen den Netzwerkebenen.

Dieses Modell folgt einem zentralen Prinzip: Netzwerkfunktionen werden logisch hierarchisch organisiert. Gerade in Campus-Umgebungen funktioniert dies sehr gut, da Kommunikationspfade meist vorhersehbar bleiben und Endgeräte überwiegend auf zentrale Dienste zugreifen. Der Datenverkehr verläuft dabei typischerweise vertikal: vom Client in Richtung Datacenter, Server oder Internet – und wieder zurück. Man spricht in diesem Zusammenhang von Nord-Süd-Traffic.

Nord-Süd- vs. Ost-West-Traffic

Die Art des Netzwerkverkehrs beeinflusst unmittelbar, welche Architektur sinnvoll ist. Im klassischen Campus dominiert meist Nord-Süd-Kommunikation. Clients greifen auf zentrale Ressourcen zu – beispielsweise Fileserver, ERP-Systeme, Internetdienste oder Cloud-Anwendungen. Der Datenverkehr verläuft überwiegend zwischen unterschiedlichen Ebenen der Infrastruktur.

Moderne Rechenzentren funktionieren dagegen anders. Dort kommunizieren Anwendungen häufig intensiv miteinander: Datenbanken, Container-Plattformen, Storage-Systeme, APIs oder Sicherheitsdienste tauschen permanent Informationen aus. Datenströme verlaufen nicht mehr primär vertikal, sondern zunehmend horizontal zwischen Workloads.

Dieser Verkehr wird als Ost-West-Traffic bezeichnet. Mit zunehmender Virtualisierung wurde genau dieses Kommunikationsmuster dominant – und stellte klassische Campus-Architekturen zunehmend vor Herausforderungen.

Spine-Leaf-Architekturen im Datacenter

Moderne Rechenzentren setzen deshalb häufig auf sogenannte Spine-Leaf-Architekturen. Im Gegensatz zum hierarchischen Campus-Modell verfolgt dieser Ansatz ein anderes Ziel: möglichst kurze, gleichwertige und hochskalierende Kommunikationspfade.

Die Architektur besteht im Wesentlichen aus zwei Ebenen:

  • Leaf-Switches: Anbindung von Servern, Storage-Systemen oder Hypervisoren
  • Spine-Switches: Hochperformante Vermittlungsebene zwischen allen Leafs

Ein wesentliches Merkmal besteht darin, dass jeder Leaf-Switch mit jedem Spine-Switch verbunden ist. Dadurch entstehen zahlreiche parallele Kommunikationspfade.

Ein Leaf-Switch fungiert dabei häufig als Top-of-Rack-Switch (ToR). Dieser befindet sich direkt im Serverrack und verbindet die dort installierten Systeme mit dem Datacenter-Netzwerk. Kurze Kabelwege, standardisierte Rack-Designs und einfache Skalierbarkeit machen dieses Modell besonders effizient.

Die folgende Abbildung zeigt eine typische Spine-Leaf-Architektur, wie sie heute in vielen Rechenzentren eingesetzt wird. Leafs verbinden die lokalen Serverracks, während die Spine-Ebene als hochperformante Vermittlungsschicht fungiert.

Technische Infografik einer Spine-Leaf-Netzwerkarchitektur in einem modernen Rechenzentrum. Dargestellt sind redundante Spine-Switches im Backbone, mehrere Leaf-Switches als Top-of-Rack-Switches sowie direkt angeschlossene Server-Racks. Die Grafik visualisiert gleichwertige Kommunikationspfade zwischen Spine und Leaf, optimierten Ost-West-Traffic und Vorteile wie ECMP, hohe Bandbreite und Skalierbarkeit.

Im Unterschied zum klassischen Campus existieren hier keine langen hierarchischen Kommunikationspfade. Jeder Server erreicht andere Systeme mit einer nahezu konstanten Zahl an Netzwerk-Hops. Das reduziert Latenzen und verbessert Skalierbarkeit erheblich.

ECMP und gleichwertige Pfade

Damit eine Spine-Leaf-Architektur effizient arbeitet, kommt meist Equal Cost Multipath Routing (ECMP) zum Einsatz. ECMP erlaubt es, mehrere gleichwertige Pfade parallel zu nutzen. Statt Verkehr nur über einen bevorzugten Link zu senden, verteilt das Netzwerk Datenströme intelligent über mehrere Verbindungen.

Der Vorteil: Redundanz und Lastverteilung entstehen gleichzeitig. Fällt ein Pfad aus, stehen automatisch alternative Wege bereit. Gleichzeitig erhöht sich die verfügbare Bandbreite, da mehrere Links aktiv genutzt werden können.

Im Unterschied zu klassischen Campus-Netzen, in denen redundante Pfade häufig blockiert werden – beispielsweise durch Spanning Tree Protocol (STP) –, verfolgt Spine-Leaf einen anderen Ansatz: Alle Verbindungen sollen aktiv nutzbar sein. Gerade bei starkem Ost-West-Traffic ist dies ein entscheidender Vorteil.

Warum VXLAN perfekt zu Spine-Leaf passt

Mit steigender Zahl virtueller Workloads reicht eine performante Topologie allein jedoch nicht aus. Virtuelle Maschinen oder Container bewegen sich dynamisch zwischen Hosts, Sicherheitszonen müssen flexibel bleiben und logische Netzsegmente sollen unabhängig vom physischen Standort funktionieren. Genau hier ergänzt VXLAN die Spine-Leaf-Architektur ideal.

Während Spine-Leaf für performante und skalierbare Transportpfade sorgt, ermöglicht VXLAN die logische Segmentierung über diese Infrastruktur hinweg. Das Netzwerk löst sich dadurch zunehmend von festen Layer-2-Grenzen. Virtuelle Workloads behalten ihre Netzwerkidentität unabhängig vom Rack oder Standort, während die physische Infrastruktur ausschließlich als performantes IP-Underlay fungiert. Die Kombination aus Spine-Leaf und VXLAN entwickelte sich deshalb zum dominierenden Design moderner Datacenter-Fabrics.

Wann welches Modell sinnvoll ist

Die Wahl der Netzwerkarchitektur hängt letztlich stark vom Einsatzszenario ab. Für klassische Campus- und Unternehmensnetze bleibt das hierarchische Core-Distribution-Access-Modell meist die beste Wahl. Hier dominieren Nord-Süd-Kommunikation, überschaubare Segmentierung und klar strukturierte Verkehrsflüsse.

In Rechenzentren, Cloud-Plattformen oder Multi-Tenant-Umgebungen spielen dagegen Skalierbarkeit, Ost-West-Traffic und dynamische Workload-Mobilität eine deutlich größere Rolle. Hier entfalten Spine-Leaf-Architekturen ihre Stärken.

Damit zeigt sich ein grundlegender Zusammenhang: Nicht jede Architektur löst jedes Problem – sie muss zum Kommunikationsmuster des Netzwerks passen. Und genau aus dieser neuen Datacenter-Logik entstand schließlich die nächste Evolutionsstufe der Segmentierung: VXLAN als Overlay-Technologie für moderne Fabrics.

VXLAN Grundlagen und Funktionsweise

Mit klassischen VLANs lassen sich Netzwerke logisch segmentieren – allerdings nur innerhalb klar definierter Layer-2-Grenzen. Moderne Rechenzentren stellen jedoch deutlich höhere Anforderungen: Workloads bewegen sich dynamisch zwischen Hosts, Mandanten müssen sauber voneinander isoliert werden und Netzwerke sollen über physische Standorte hinweg konsistent funktionieren. Genau für diese Anforderungen wurde Virtual Extensible LAN (VXLAN) entwickelt.

VXLAN verfolgt dabei einen grundlegenden Architekturwechsel: Statt Layer 2 physisch auszudehnen, wird Ethernet-Verkehr über ein Layer-3-Netz transportiert. Damit löst sich die logische Segmentierung erstmals weitgehend von der zugrunde liegenden physischen Infrastruktur.

Was VXLAN ist und warum es entwickelt wurde

VXLAN ist ein Overlay-Protokoll, das Ethernet-Frames über ein bestehendes IP-Netzwerk transportiert. Das Grundprinzip ist vergleichsweise einfach: Ein Layer-2-Netz wird logisch über ein Layer-3-Netz gelegt. Anstatt VLANs direkt zwischen Switches zu erweitern, kapselt VXLAN Ethernet-Frames in UDP/IP-Pakete ein. Der eigentliche Datenverkehr wird dadurch unabhängig von der physischen Topologie.

Diese Entkopplung löst mehrere Probleme klassischer VLAN-Designs gleichzeitig:

  • Begrenzung auf maximal 4096 VLANs
  • eingeschränkte Layer-2-Skalierung
  • aufwendiges VLAN-Stretching
  • geringe Flexibilität bei Host-Mobilität
  • Herausforderungen in Multi-Tenant-Umgebungen

Der zugrunde liegende Transport erfolgt standardmäßig über UDP-Port 4789, der heute als De-facto-Standard für VXLAN gilt. Die physische Netzwerkinfrastruktur übernimmt dabei nur noch eine Aufgabe: Sie transportiert IP-Pakete effizient von A nach B. Die eigentliche logische Segmentierung erfolgt im Overlay.

Overlay statt Layer-2-Abhängigkeit

Um VXLAN zu verstehen, hilft ein Blick auf die Trennung zwischen Underlay und Overlay. Das Underlay-Netzwerk beschreibt die physische Infrastruktur – also Router, Switches und Routingprotokolle wie OSPF, IS-IS oder BGP. Seine Aufgabe besteht ausschließlich darin, zuverlässige IP-Konnektivität bereitzustellen.

Darüber liegt das Overlay-Netzwerk. Hier existieren die eigentlichen logischen Netzsegmente. Virtuelle Maschinen, Container oder physische Server kommunizieren weiterhin scheinbar innerhalb desselben Layer-2-Netzes – selbst dann, wenn sie sich physisch in unterschiedlichen Racks oder Standorten befinden. Die Konsequenz ist tiefgreifend: Logische Netzwerkgrenzen werden unabhängig von physischen Topologien.

Damit verändert sich auch die Rolle des Netzwerks selbst. Die physische Infrastruktur wird zunehmend zu einer leistungsfähigen Transportplattform, während Segmentierung und Workload-Zuordnung auf einer darüberliegenden logischen Ebene stattfinden.

VXLAN Network Identifier (VNI)

Das Herzstück von VXLAN bildet der sogenannte VXLAN Network Identifier (VNI). Während VLANs auf eine 12-Bit-ID und damit maximal 4096 Segmente beschränkt sind, verwendet VXLAN ein 24-Bit-Feld. Dadurch entstehen theoretisch rund: 16 Millionen logische Netzwerksegmente.

Jeder VNI repräsentiert dabei eine eigene logische Broadcast-Domäne – funktional vergleichbar mit einem VLAN, jedoch erheblich skalierbarer. Ein klassisches Unternehmensnetz könnte beispielsweise Mitarbeitende in VLAN 10, Gäste in VLAN 20 und Server in VLAN 30 betreiben. In einer VXLAN-Umgebung ließen sich diese Segmente etwa durch die VNIs 10010, 10020 und 10030 abbilden. Die konkrete Nummerierung ist dabei frei wählbar und orientiert sich häufig an organisatorischen, mandantenbezogenen oder architektonischen Designprinzipien.

Entscheidend ist jedoch weniger die konkrete Nummer selbst als das zugrunde liegende Konzept: Die Segmentierung bleibt logisch – nicht physisch.

Ein Workload kann sich dadurch an einem völlig anderen Standort befinden und dennoch Teil desselben logischen Netzsegments bleiben, ohne dass physische Layer-2-Grenzen erweitert oder VLANs standortübergreifend transportiert werden müssen.

VXLAN Tunnel Endpoints (VTEPs)

Damit VXLAN funktioniert, benötigt das Netzwerk sogenannte VXLAN Tunnel Endpoints (VTEPs). VTEPs bilden die Übergangspunkte zwischen klassischem Ethernet und dem VXLAN-Overlay.

Sie übernehmen zwei zentrale Aufgaben:

  1. Encapsulation: Ein Ethernet-Frame wird in VXLAN verpackt.
  2. Decapsulation: Am Ziel wird der ursprüngliche Frame wieder entpackt.

In modernen Datacentern befinden sich VTEPs häufig auf Leaf-Switches beziehungsweise Top-of-Rack-Switches (ToR), direkt in Hypervisoren wie VMware ESXi oder KVM sowie in virtuellen Switch-Instanzen. Dadurch kann VXLAN sowohl physische als auch virtuelle Workloads konsistent in dieselbe Overlay-Architektur integrieren.

Ein VTEP verhält sich dabei gewissermaßen wie ein Tunnelportal: Er übersetzt lokalen Layer-2-Verkehr in routbaren Layer-3-Verkehr. Für Endgeräte bleibt dieser Vorgang vollständig transparent. Ein Server glaubt weiterhin, sich im lokalen Ethernet-Segment zu befinden – selbst dann, wenn das Zielsystem physisch in einem anderen Rack, Rechenzentrum oder sogar an einem anderen Standort betrieben wird.

Vom Ethernet-Frame zum VXLAN-Paket

Die eigentliche Stärke von VXLAN entsteht durch seine Kapselungstechnik (Encapsulation). Ein vorhandener Ethernet-Frame wird dabei weder verändert noch ersetzt. Stattdessen bleibt er vollständig erhalten und wird in ein neues transportfähiges Paket eingebettet. Genau dieses Prinzip macht VXLAN so leistungsfähig: Layer-2-Kommunikation kann über ein beliebiges Layer-3-IP-Netz transportiert werden.

Technisch betrachtet entsteht dabei eine verschachtelte Struktur aus mehreren Headern. Der ursprüngliche Ethernet-Frame bildet gewissermaßen den Kern des Pakets und wird schrittweise um zusätzliche Informationen erweitert, damit das Netzwerk ihn über IP-Routing transportieren kann.

Die folgende Abbildung verdeutlicht diese Kapselung vereinfacht. Gut erkennbar ist, wie der ursprüngliche Ethernet-Frame vollständig erhalten bleibt und nacheinander von einem VXLAN-Header, einem UDP-Header sowie einem äußeren IP- und Ethernet-Header umschlossen wird.

Technische Visualisierung der VXLAN-Kapselung in einem Rechenzentrum. Ein bestehender Ethernet-Frame wird schrittweise in mehrere Protokollschichten eingebettet: Outer Ethernet Header, Outer IP Header, UDP Header (Port 4789), VXLAN Header mit VNI und der unveränderte innere Ethernet-Frame. Im Hintergrund ist eine Spine-Leaf-Netzwerkarchitektur dargestellt.

Die Kommunikation beginnt weiterhin mit einem gewöhnlichen Ethernet-Frame, wie ihn Server, virtuelle Maschinen oder Anwendungen ganz selbstverständlich erzeugen. Der lokale VXLAN Tunnel Endpoint (VTEP) übernimmt anschließend die Encapsulation und ergänzt mehrere zusätzliche Header:

  • einen VXLAN Header, der den logischen Kontext über den VXLAN Network Identifier (VNI) definiert
  • einen UDP Header, der standardmäßig Port 4789 verwendet
  • einen äußeren IP Header, damit das Paket über Layer 3 geroutet werden kann
  • einen äußeren Ethernet Header für den Transport über das physische Netzwerk

Für Endgeräte bleibt dieser Prozess vollständig transparent. Ein Server oder eine virtuelle Maschine glaubt weiterhin, sich in einem klassischen lokalen Ethernet-Segment zu befinden – selbst dann, wenn die eigentliche Kommunikation intern bereits über ein IP-basiertes Datacenter-Netz transportiert wird.

Genau diese Entkopplung von logischer Layer-2-Kommunikation und physischer Transportinfrasruktur macht VXLAN zu einer zentralen Technologie moderner Rechenzentren.

Encapsulation und Decapsulation

Damit VXLAN funktioniert, muss der ursprüngliche Layer-2-Verkehr in eine Form gebracht werden, die über ein gewöhnliches Layer-3-IP-Netz transportiert werden kann. Genau an dieser Stelle greifen die Mechanismen der Encapsulation und Decapsulation.

Die zentrale Idee dabei lautet: Der ursprüngliche Ethernet-Frame bleibt vollständig erhalten, wird jedoch um zusätzliche Informationen ergänzt, damit er unabhängig von seiner physischen Position durch das Netzwerk transportiert werden kann. Verantwortlich dafür sind die bereits erwähnten VXLAN Tunnel Endpoints (VTEPs), die den Übergang zwischen lokalem Layer 2 und transportfähigem Layer 3 übernehmen.

Sobald ein Endgerät Daten sendet, verarbeitet der lokale VTEP den Verkehr automatisch. Der Ablauf lässt sich vereinfacht in mehreren Schritten darstellen:

  1. Das Endgerät erzeugt einen normalen Ethernet-Frame
  2. Der lokale VTEP analysiert den Verkehr und ordnet ihn dem passenden VXLAN Network Identifier (VNI) zu
  3. Der ursprüngliche Ethernet-Frame wird vollständig in einen VXLAN-Header eingebettet und zusätzlich um UDP- sowie IP-Header ergänzt
  4. Das entstandene Paket wird nun über das Underlay-Netzwerk, also die physische IP-Infrastruktur, transportiert
  5. Am Ziel entfernt der empfangende VTEP die zusätzlichen Header wieder (Decapsulation)
  6. Anschließend wird der ursprüngliche Ethernet-Frame lokal innerhalb des Zielsegments zugestellt

Der gesamte Prozess läuft für Anwendungen und Endgeräte vollkommen transparent ab und erfolgt in modernen Datacenter-Umgebungen meist direkt in spezialisierter Hardware der Switches. Dadurch lassen sich Layer-2-Segmente über beliebige Layer-3-Grenzen hinweg erweitern, ohne auf klassische und oft schwer skalierbare VLAN-Stretching-Mechanismen angewiesen zu sein.

Anders formuliert: Für Endgeräte fühlt sich die Kommunikation weiterhin wie ein lokales Ethernet-Netz an – intern arbeitet das Netzwerk jedoch längst als hochskalierbare IP-Fabric.

Head-End Replication und Multicast

Eine besondere Herausforderung entsteht bei Broadcast-, Unknown-Unicast- und Multicast-Traffic (BUM-Traffic). Da VXLAN auf einem Layer-3-Netz basiert, müssen auch solche Datenströme gezielt verteilt werden.

Frühe VXLAN-Implementierungen nutzten dafür häufig IP-Multicast im Underlay. Broadcast-Traffic wurde an definierte Multicast-Gruppen gesendet, die den Verkehr an relevante Ziele weiterverteilten. Dieses Verfahren funktioniert technisch zuverlässig, erhöht jedoch Komplexität und Anforderungen an das Underlay.

Viele moderne Implementierungen – insbesondere im Enterprise-Umfeld – setzen daher auf Head-End Replication (HER). Dabei repliziert der sendende VTEP den Verkehr gezielt an alle relevanten Ziel-VTEPs. Der Vorteil: Hier ist kein Multicast im Underlay erforderlich. Gerade in kleineren oder mittleren VXLAN-Umgebungen vereinfacht dies den Betrieb erheblich.

Einsatzszenarien und Vorteile

VXLAN wurde ursprünglich für hochskalierende Datacenter-Umgebungen entwickelt, in denen klassische VLAN-Architekturen zunehmend an ihre Grenzen stießen. Besonders Virtualisierung, Cloud-Konzepte und dynamische Workloads veränderten die Anforderungen grundlegend: Netzwerke mussten plötzlich deutlich flexibler, skalierbarer und standortunabhängiger funktionieren.

Während in klassischen Campus-Netzen Geräte oft langfristig an einem festen Ort betrieben werden, bewegen sich moderne Workloads deutlich dynamischer. Virtuelle Maschinen werden zwischen Hosts verschoben, Container entstehen automatisiert und hybride Cloud-Umgebungen verteilen Anwendungen über mehrere Standorte hinweg. Genau in diesen Szenarien spielt VXLAN seine Stärken aus.

Typische Einsatzbereiche sind:

  • Multi-Tenant-Umgebungen: Sichere Trennung vieler Mandant:innen, Kund:innen oder organisatorischer Bereiche innerhalb derselben Infrastruktur
  • Cloud-Architekturen: Hochskalierbare Segmentierung für dynamische Dienste und elastische Ressourcen
  • Virtualisierte Rechenzentren: Flexible Platzierung und Migration virtueller Maschinen ohne aufwendige Netzwerkneukonfiguration
  • Hybrid- und Multi-Site-Szenarien: Erweiterung logischer Layer-2-Segmente über mehrere Standorte oder Rechenzentren hinweg

Der eigentliche Paradigmenwechsel liegt jedoch tiefer: VXLAN entkoppelt erstmals konsequent die logische Netzwerksegmentierung von der physischen Infrastruktur. Ein Workload bleibt damit logisch in demselben Segment, auch wenn sich sein physischer Standort verändert.

Für Administrator:innen bedeutet dies erheblich mehr Flexibilität. Virtuelle Maschinen oder Container können verschoben werden, ohne Netzsegmente neu aufbauen oder VLANs über das gesamte Netzwerk ausdehnen zu müssen. Gleichzeitig entsteht eine Skalierbarkeit, die klassische VLAN-Konzepte aufgrund ihrer technischen Begrenzungen kaum noch leisten können.

Vereinfacht formuliert: VLANs segmentieren innerhalb der vorhandenen Infrastruktur – VXLAN abstrahiert Segmentierung von der Infrastruktur selbst.

Grenzen und Herausforderungen

Trotz aller Vorteile ist VXLAN keine universelle Lösung. Die Technologie bringt zusätzliche Komplexität mit sich und setzt eine saubere Underlay-Infrastruktur voraus. Routing, IP-Adressierung und Designentscheidungen werden wichtiger als in klassischen Layer-2-Netzen.

Hinzu kommt ein weiteres Problem: Woher weiß ein VTEP eigentlich, welcher Ziel-VTEP für ein bestimmtes System zuständig ist? Frühe VXLAN-Implementierungen arbeiteten hier mit sogenannten Flood-and-Learn-Mechanismen – einem Ansatz, der in größeren Umgebungen schnell ineffizient wurde.

Moderne Datacenter setzen deshalb zunehmend auf eine skalierbare Control Plane, die Endpunktinformationen gezielt verteilt. Genau an dieser Stelle kommt EVPN (Ethernet VPN) ins Spiel – und macht VXLAN erst wirklich enterprise-tauglich.

Exkurs: VXLAN und MPLS – Konkurrenz oder unterschiedliche Werkzeuge?

Wer sich intensiver mit VXLAN beschäftigt, stößt früher oder später fast zwangsläufig auf einen anderen Begriff: MPLS (Multiprotocol Label Switching). Gerade im Enterprise- und Service-Provider-Umfeld entsteht häufig die Frage, ob VXLAN gewissermaßen der Nachfolger von MPLS sei – oder ob beide Technologien sogar miteinander konkurrieren.

Die kurze Antwort lautet: Nein – VXLAN ersetzt MPLS nicht. Beide Technologien lösen unterschiedliche Probleme auf unterschiedlichen Ebenen der Infrastruktur.

Der Vergleich lohnt sich dennoch, weil beide Ansätze auf den ersten Blick erstaunlich ähnliche Ziele verfolgen: Netzwerke skalierbar segmentieren, Mandant:innen voneinander trennen und logische Kommunikationsräume unabhängig von der physischen Infrastruktur bereitstellen.

MPLS – Das klassische Modell für WAN und Service Provider

MPLS entstand ursprünglich, um Routing effizienter und skalierbarer zu machen. Anders als klassische IP-Netze entscheidet MPLS nicht primär anhand von Routingtabellen über den nächsten Pfad, sondern nutzt sogenannte Labels.

Ein Paket erhält dabei einen zusätzlichen MPLS-Header. Router innerhalb des MPLS-Netzes – sogenannte Label Switch Router (LSR) – analysieren anschließend nicht mehr die vollständige Zieladresse, sondern lediglich das Label und leiten den Traffic entsprechend weiter.

Das bringt mehrere Vorteile:

  • deterministische und performante Weiterleitung
  • klar definierte Verkehrswege
  • Traffic Engineering
  • Quality of Service (QoS)
  • Mandantenfähigkeit über Layer-2- und Layer-3-VPNs

Gerade Service Provider, Carrier-Netze oder große WAN-Infrastrukturen setzen deshalb seit vielen Jahren auf MPLS.

Ein typisches Beispiel:

Ein Unternehmen betreibt mehrere Standorte weltweit. Über MPLS lassen sich diese logisch in voneinander getrennte Unternehmensnetze integrieren – selbst dann, wenn sie dieselbe Provider-Infrastruktur nutzen.

VXLAN – Overlay für moderne Datacenter

VXLAN verfolgt einen anderen Ansatz. Statt Labels innerhalb eines Provider-Netzes zu verwenden, kapselt VXLAN Ethernet-Verkehr vollständig in UDP/IP-Pakete und transportiert ihn über eine gewöhnliche IP-Infrastruktur.

Im Mittelpunkt steht dabei weniger der WAN-Transport als vielmehr die Frage, wie sich virtuelle Workloads flexibel, hochskalierbar und unabhängig von ihrer physischen Position vernetzen lassen. Genau deshalb entwickelte sich VXLAN insbesondere in Rechenzentren, Cloud-Umgebungen, Multi-Tenant-Fabrics und stark virtualisierten Serverlandschaften zum dominierenden Modell.

Während MPLS primär die Standortvernetzung und Segmentierung von WAN-Infrastrukturen adressiert, konzentriert sich VXLAN auf die hochdynamische Kommunikation innerhalb moderner Datacenter. Dort müssen virtuelle Maschinen, Container oder Anwendungen häufig ihren Standort wechseln können, ohne dass Netzsegmente neu aufgebaut oder physische Netzgrenzen angepasst werden müssen.

Besonders Virtualisierung veränderte hier die Anforderungen grundlegend: Virtuelle Maschinen wechseln Hosts, Container entstehen dynamisch und Anwendungen kommunizieren zunehmend horizontal innerhalb des Rechenzentrums. VXLAN löst genau dieses Problem.

VXLAN vs. MPLS – Die wichtigsten Unterschiede

Obwohl beide Technologien Segmentierung ermöglichen, unterscheiden sie sich architektonisch deutlich. MPLS basiert auf einem spezialisierten Provider- oder WAN-Core und nutzt Labels zur Weiterleitung. VXLAN arbeitet dagegen als Overlay-Technologie über einem gewöhnlichen Layer-3-IP-Netz und verwendet VXLAN Network Identifier (VNI) zur Segmentierung.

Vereinfacht lässt sich der Unterschied so zusammenfassen:

  • MPLS: optimiert für WAN, Provider-Netze und kontrollierte Verkehrswege
  • VXLAN: optimiert für Datacenter, Cloud und dynamische Workload-Kommunikation

Auch die Zielsetzung unterscheidet sich deutlich. MPLS fokussiert sich primär auf Routing, Pfadsteuerung und WAN-Segmentierung, während VXLAN die logische Entkopplung von Workloads und physischer Infrastruktur adressiert.

Vereinfacht formuliert: MPLS verbindet Standorte – VXLAN abstrahiert Rechenzentren.

EVPN als Brücke zwischen beiden Welten

Interessanterweise treffen sich beide Technologien heute an einer entscheidenden Stelle: EVPN funktioniert sowohl mit MPLS als auch mit VXLAN.

Historisch wurde Ethernet VPN (EVPN) zunächst entwickelt, um Ethernet-basierte VPN-Dienste über MPLS-Infrastrukturen bereitzustellen. Erst später etablierte sich EVPN zunehmend als moderne Control Plane für VXLAN-Fabrics in Datacentern.

Dadurch entsteht eine interessante Parallele:

  • EVPN over MPLS: häufig im Service-Provider- oder WAN-Kontext
  • EVPN over VXLAN: dominierend in modernen Datacentern

Die zugrunde liegende Steuerlogik bleibt dabei ähnlich – lediglich das Transportmedium verändert sich. Diese Entwicklung zeigt eindrucksvoll, wie stark Netzwerkarchitekturen heute zusammenwachsen.

Wann welches Modell sinnvoll ist

Welche Technologie sinnvoll ist, hängt letztlich stark vom Einsatzszenario ab.

Für WAN-Architekturen, Carrier-Netze oder standortübergreifende Enterprise-Verbindungen bleibt MPLS weiterhin hochrelevant. Besonders deterministische Verkehrssteuerung, garantierte Service Levels und große geografische Netze profitieren davon.

VXLAN entfaltet seine Stärken dagegen vor allem in Datacentern, Cloud-Umgebungen und virtualisierten Infrastrukturen, in denen Flexibilität, Skalierung und Workload-Mobilität im Vordergrund stehen.

In vielen modernen Enterprise-Architekturen existieren deshalb sogar beide Welten parallel: MPLS verbindet Standorte – VXLAN organisiert das Datacenter.

Fazit

Auf den ersten Blick wirken VXLAN und MPLS ähnlich, weil beide logische Segmentierung und Mandantenfähigkeit ermöglichen. Architektonisch verfolgen sie jedoch unterschiedliche Ziele. MPLS entstand für performante und kontrollierte WAN-Kommunikation, VXLAN dagegen für hochskalierbare und flexible Datacenter-Fabrics.

Die eigentliche Zukunft liegt deshalb oft nicht in einem Entweder-oder, sondern im Zusammenspiel beider Welten – verbunden durch moderne Steuermechanismen wie EVPN.

EVPN einfach erklärt – Die Control Plane für VXLAN

VXLAN löst ein zentrales Problem moderner Netzwerke: die flexible und hochskalierbare Segmentierung über Layer-3-Grenzen hinweg. Doch eine entscheidende Frage bleibt zunächst unbeantwortet: Woher weiß ein VXLAN Tunnel Endpoint (VTEP), an welchen Ziel-VTEP ein bestimmter Ethernet-Frame gesendet werden muss?

VXLAN selbst liefert darauf keine Antwort. Die Technologie definiert lediglich die Kapselung und den Transport von Ethernet-Frames über ein IP-Netz – nicht jedoch die Steuerung von Endpunktinformationen. Genau deshalb benötigt VXLAN eine zusätzliche Control Plane, die Informationen über Endgeräte, MAC-Adressen und Erreichbarkeit verteilt.

Die ersten VXLAN-Implementierungen versuchten dieses Problem zunächst auf vergleichsweise einfache Weise zu lösen.

Flood & Learn – Der ursprüngliche Ansatz

Frühe VXLAN-Umgebungen arbeiteten nach dem Prinzip Flood & Learn, das stark an klassisches Ethernet-Learning erinnert. Trifft ein Frame für eine unbekannte Ziel-MAC-Adresse ein, kennt der lokale VTEP den Zielort zunächst nicht. Statt gezielt zu senden, verteilt er den Traffic zunächst breitflächig innerhalb des VXLAN-Segments. Im Netzwerk spricht man hier von BUM-Traffic:

  • Broadcast Traffic – etwa ARP-Anfragen
  • Unknown Unicast Traffic – Ziel-MAC unbekannt
  • Multicast Traffic – Verteilung an mehrere Empfänger:innen

Der lokale VTEP flutet den Verkehr an alle anderen relevanten VTEPs innerhalb desselben VXLAN Network Identifier (VNI). Erst nachdem eine Antwort erfolgt, kann der Zielort gelernt werden.

Dieses Verfahren funktionierte in kleineren Umgebungen durchaus zuverlässig, zeigte jedoch schnell erhebliche Schwächen:

  • steigender Broadcast-Anteil
  • unnötige Netzlast
  • schlechte Skalierbarkeit
  • hohe Komplexität bei vielen VTEPs

Besonders in großen Spine-Leaf-Fabrics mit Tausenden virtuellen Workloads wurde Flood & Learn zunehmend ineffizient.

Warum EVPN notwendig wurde

Mit zunehmender Virtualisierung änderten sich die Anforderungen grundlegend. Moderne Datacenter mussten plötzlich virtuelle Maschinen dynamisch verschieben, Multi-Tenant-Umgebungen betreiben und Millionen von Endpunkten verwalten. Ein permanentes Flooding unbekannter Ziele war dafür weder performant noch wirtschaftlich.

Gesucht wurde daher eine Lösung, die:

  • Endpunktinformationen gezielt verteilt
  • unnötigen Broadcast-Verkehr vermeidet
  • Host-Mobilität unterstützt
  • Multi-Tenant-Fabrics skaliert
  • deterministische Verkehrswege ermöglicht

Genau an dieser Stelle kommt EVPN (Ethernet VPN) ins Spiel. Vereinfacht formuliert: VXLAN transportiert Daten – EVPN erklärt dem Netzwerk, wohin diese Daten müssen.

EVPN im Überblick

EVPN ist eine moderne Control Plane für Ethernet-basierte Overlay-Netze. Ursprünglich wurde EVPN in RFC 7432 für MPLS-Umgebungen entwickelt. Mit RFC 8365 etablierte sich EVPN anschließend zunehmend als Steuermechanismus für VXLAN-basierte Datacenter-Fabrics.

Das grundlegende Prinzip ist vergleichsweise einfach: Anstatt unbekannte Endpunkte durch Flooding zu suchen, tauschen VTEPs ihre Informationen aktiv untereinander aus.

Jeder VTEP meldet dabei:

  • welche MAC-Adressen lokal erreichbar sind
  • welche IP-Adressen zu Endpunkten gehören
  • welche VNIs vorhanden sind
  • wie Broadcast- und Multicast-Verkehr behandelt wird

Dadurch entsteht eine deterministische Steuerung des Overlays. Ein VTEP kennt den Zielort bereits, bevor ein Frame gesendet wird.

BGP als Control Plane

Für den Austausch dieser Informationen nutzt EVPN überraschenderweise kein neues Spezialprotokoll, sondern BGP (Border Gateway Protocol) – genauer gesagt Multiprotocol BGP (MP-BGP).

Das wirkt auf den ersten Blick ungewöhnlich, ergibt architektonisch jedoch großen Sinn. BGP gehört seit Jahrzehnten zu den stabilsten und skalierbarsten Routing-Protokollen überhaupt. Ursprünglich für den Austausch von Routinginformationen zwischen autonomen Systemen im Internet entwickelt, eignet sich BGP hervorragend dazu, Informationen effizient und kontrolliert über große Infrastrukturen hinweg zu verteilen.

Seine besondere Stärke liegt in der Erweiterbarkeit: Während klassisches BGP primär Netzpräfixe austauscht, kann MP-BGP zusätzliche Adressfamilien transportieren – darunter auch Informationen über Ethernet-Endpunkte. Genau diese Fähigkeit macht BGP für moderne VXLAN-EVPN-Fabrics so attraktiv.

In EVPN-Umgebungen verteilt MP-BGP nicht nur Informationen über erreichbare IP-Netze, sondern zusätzlich Kontextinformationen wie MAC-Adressen, IP-Zuordnungen, VXLAN Network Identifier (VNI) oder die Erreichbarkeit von Overlay-Endpunkten. Dadurch entsteht eine hochskalierbare und deterministische Control Plane, die auch in sehr großen Datacenter-Fabrics effizient arbeitet.

Im praktischen Betrieb bedeutet dies: VTEPs tauschen aktiv Informationen über lokal erreichbare Endgeräte aus, bevor überhaupt Verkehr übertragen wird. Ein Ziel-VTEP muss deshalb nicht mehr über Flooding gesucht oder erraten werden – seine Erreichbarkeit ist bereits bekannt. Der Datenverkehr kann direkt und gezielt an den korrekten Zielpunkt gesendet werden.

Wer tiefer verstehen möchte, warum sich BGP als eines der wichtigsten Routing-Protokolle des Internets etabliert hat und weshalb es heute auch in modernen Enterprise-, WAN- und Datacenter-Architekturen eine zentrale Rolle spielt, findet im Beitrag Externes Routing im Internet und WAN – Architektur, Historie und Bedeutung von BGP eine ausführliche technische Einordnung.

Wichtige EVPN Route Types

Damit EVPN unterschiedliche Informationen transportieren kann, definiert die Architektur mehrere spezialisierte Route Types. Nicht jede Route erfüllt dabei denselben Zweck. Einige transportieren Endpunktinformationen, andere definieren Broadcast-Domänen oder unterstützen Overlay-Routing.

Für das grundlegende Verständnis sind insbesondere drei Route Types relevant.

Type 2 – MAC/IP Advertisement Route

Die wichtigste EVPN-Route ist Type 2. Sie kündigt die Zuordnung einer MAC-Adresse – optional ergänzt um eine IP-Adresse – an. Dadurch erfahren andere VTEPs: Welcher Endpunkt befindet sich hinter welchem VTEP?

Der Vorteil liegt auf der Hand: Frames müssen nicht mehr geflutet werden. Stattdessen kann ein VTEP den Verkehr direkt an das korrekte Ziel senden. Type 2 bildet damit das Fundament deterministischer Kommunikation innerhalb einer VXLAN-Fabric.

Type 3 – Inclusive Multicast Ethernet Tag Route

Type 3 übernimmt eine andere Aufgabe. Diese Route informiert darüber, welche VTEPs zu einem bestimmten VNI gehören und wie sogenannter BUM-Traffic behandelt werden soll.

Gerade bei Broadcast-Verkehr, unbekannten Unicast-Zielen (Unknown Unicast) oder Multicast-Kommunikation bleibt eine gewisse Form der Verteilung weiterhin notwendig. Nicht jeder Datenverkehr kann vollständig deterministisch zugestellt werden, da bestimmte Kommunikationsformen naturgemäß mehrere Empfänger:innen erreichen oder zunächst unbekannte Zielinformationen auflösen müssen.

Type 3 hilft dabei, diese Prozesse gezielt und kontrolliert abzubilden – beispielsweise in Kombination mit Head-End Replication (HER) oder Multicast im Underlay.

Type 5 – IP Prefix Route

Mit Type 5 erweitert EVPN das Modell zusätzlich auf Layer 3. Anstatt nur MAC-Adressen zu transportieren, können nun auch IP-Präfixe zwischen VTEPs verteilt werden. Dadurch wird VXLAN nicht länger nur zu einer Layer-2-Overlay-Technologie.

Vielmehr entstehen Möglichkeiten für:

  • Routing innerhalb der Fabric
  • Inter-Tenant-Kommunikation
  • VRF-basierte Segmentierung
  • hochskalierbare Layer-3-Fabrics

Besonders in großen Datacenter-Architekturen gewinnt Type 5 zunehmend an Bedeutung.

Anycast Gateway und Host-Mobilität

Ein weiterer großer Vorteil moderner VXLAN-EVPN-Fabrics liegt in der Unterstützung von Host-Mobilität. Gerade in virtualisierten Datacenter-Umgebungen wechseln Workloads ihren physischen Standort deutlich häufiger als in klassischen Campus-Netzen. Virtuelle Maschinen werden zwischen Hosts verschoben, Container dynamisch gestartet oder Dienste flexibel auf unterschiedliche Ressourcen verteilt.

In traditionellen Layer-2- / Layer-3-Designs führt dies schnell zu Herausforderungen. Häufig befindet sich das Default Gateway eines VLANs nur auf einem einzelnen Switch oder an einem zentralen Routingpunkt. Wird ein Workload verschoben, entstehen potenziell zusätzliche Routingwege, komplexe Gateway-Konstruktionen oder Einschränkungen bei der Mobilität.

VXLAN-EVPN verfolgt hier bewusst einen anderen Ansatz: Alle Leaf-Switches innerhalb der Fabric stellen dasselbe Anycast Gateway bereit. Jeder Leaf präsentiert dabei dieselbe virtuelle Gateway-IP-Adresse sowie dieselbe virtuelle MAC-Adresse. Für Endgeräte erscheint das Gateway dadurch überall identisch – unabhängig davon, an welchem Leaf oder Rack sie sich physisch befinden.

Der Vorteil liegt auf der Hand: Ein Workload kann seinen Standort verändern, ohne dass sich aus Sicht des Endgeräts das Netzwerk ändert. Virtuelle Maschinen lassen sich dadurch flexibel zwischen Hosts verschieben, ohne dass Netzwerkpfade neu aufgebaut oder Gateway-Konfigurationen angepasst werden müssen. Genau diese Entkopplung von physischem Standort und logischer Erreichbarkeit gehört zu den zentralen Stärken moderner VXLAN-EVPN-Fabrics.

Active / Active-Multihoming

Auch Redundanz wird in VXLAN-EVPN-Fabrics grundlegend anders umgesetzt als in klassischen Layer-2-Netzen. Traditionelle Ethernet-Umgebungen stehen seit jeher vor einem Problem: Mehrere parallele Verbindungen zwischen Switches erhöhen zwar die Verfügbarkeit, erzeugen jedoch potenziell Schleifen (Loops). Da Ethernet-Frames keine eingebaute Lebensdauer besitzen, könnten Broadcasts oder unbekannte Unicast-Frames theoretisch endlos im Netzwerk zirkulieren.

Um dies zu verhindern, kommt in klassischen VLAN-Umgebungen häufig das Spanning Tree Protocol (STP) zum Einsatz. STP erkennt redundante Pfade und deaktiviert vorsorglich bestimmte Links. Das erhöht zwar die Stabilität, führt aber gleichzeitig dazu, dass vorhandene Bandbreite ungenutzt bleibt.

VXLAN-EVPN verfolgt hier einen grundlegend anderen Ansatz. Durch EVPN Active / Active-Multihoming kann ein Endgerät oder Server gleichzeitig an mehrere Leaf-Switches angebunden werden – und zwar ohne blockierte Links. Alle Verbindungen bleiben aktiv und können parallel genutzt werden.

Auf den ersten Blick wirkt dies riskant: Mehrere aktive Layer-2-Pfade müssten doch zwangsläufig Schleifen erzeugen? Genau an dieser Stelle greift jedoch die EVPN-Control-Plane ein.

Anders als klassisches Ethernet arbeitet EVPN nicht nach dem Prinzip Flood and Pray, sondern kennt die Erreichbarkeit von Endpunkten bereits deterministisch über BGP. Endgeräte werden eindeutig bestimmten VTEPs zugeordnet, und EVPN steuert aktiv, welcher Leaf für welchen Verkehr verantwortlich ist.

Zusätzlich nutzt EVPN Mechanismen wie Designated Forwarder (DF) Election, um Broadcast-, Unknown-Unicast- und Multicast-Verkehr (BUM-Traffic) kontrolliert zu behandeln. Dadurch verhindern die beteiligten Leafs, dass identische Frames mehrfach ins Netzwerk eingespeist werden.

Die Redundanz entsteht somit nicht durch blockierte Backup-Pfade wie im Spanning Tree, sondern durch kontrollierte Parallelität im Overlay.

Das bringt erhebliche Vorteile:

  • höhere Verfügbarkeit, da Verbindungen aktiv redundant genutzt werden
  • bessere Lastverteilung über mehrere Pfade
  • effizientere Bandbreitennutzung, weil keine Links ungenutzt blockiert werden
  • höhere Ausfallsicherheit, da beim Ausfall eines Leafs der Verkehr unmittelbar über verbleibende Pfade weiterläuft

Gerade in modernen Spine-Leaf-Fabrics mit hochdynamischen Workloads gehört Active / Active-Multihoming deshalb zu den wichtigsten Vorteilen von VXLAN EVPN gegenüber klassischen Layer-2-Architekturen.

Cisco-Praxis: VXLAN EVPN im Nexus-Umfeld

Im Cisco-Umfeld hat sich VXLAN BGP EVPN insbesondere auf den Nexus-9000-Plattformen als De-facto-Standard moderner Datacenter-Fabrics etabliert. Cisco nutzt EVPN dabei als skalierbare Control Plane für Spine-Leaf-Architekturen und kombiniert diese eng mit VXLAN als Data Plane. Gerade in Enterprise-Datacentern entstehen dadurch hochgradig flexible Netzwerke, die Workload-Mobilität, Mandantenfähigkeit und horizontale Skalierung deutlich einfacher ermöglichen als klassische VLAN-basierte Designs.

Typische Funktionen moderner Nexus-Fabrics sind unter anderem Anycast Gateway, Head-End Replication (HER), Multi-Site-Konzepte sowie automatisierte Fabric-Deployments über NX-OS und zentrale Managementplattformen.

Ein besonders wichtiges Konzept ist das bereits erwähnte Anycast Gateway. Dabei stellen alle Leaf-Switches innerhalb der Fabric dasselbe Default Gateway bereit – inklusive identischer virtueller MAC- und IP-Adresse. Für Endgeräte erscheint das Gateway dadurch unabhängig vom physischen Standort immer gleich. Virtuelle Maschinen können sich zwischen Hosts oder Leafs bewegen, ohne dass Gateway-Konfigurationen angepasst oder neue Routingpfade aufgebaut werden müssen.

Auch Head-End Replication (HER) spielt in vielen Cisco-Designs eine wichtige Rolle. Während klassische VXLAN-Implementierungen häufig auf Multicast im Underlay angewiesen waren, repliziert HER Broadcast-, Unknown-Unicast- und Multicast-Traffic (BUM-Traffic) gezielt am sendenden VTEP. Dieser erstellt Kopien des Datenverkehrs und sendet sie ausschließlich an relevante Ziel-VTEPs innerhalb desselben VNI. Dadurch entfällt die Notwendigkeit komplexer Multicast-Konfigurationen im Underlay-Netzwerk. Besonders kleinere bis mittlere Fabrics profitieren von diesem vereinfachten Design, während in sehr großen Umgebungen häufig stärker skalierende EVPN-Mechanismen dominieren.

Insgesamt zeigt sich hier ein wichtiger architektonischer Wandel: Moderne Datacenter-Fabrics verlassen zunehmend klassische Layer-2-Denkweisen und setzen stattdessen auf eine klar getrennte Kombination aus skalierbarer Data Plane (VXLAN) und intelligenter Control Plane (EVPN).

Gerade im Enterprise-Umfeld bildet VXLAN EVPN auf Cisco Nexus heute deshalb häufig die Grundlage moderner, automatisierbarer Netzwerkinfrastrukturen.

Fazit

VXLAN allein löst lediglich den Transport von Ethernet-Verkehr über Layer 3. Erst durch EVPN entsteht daraus eine wirklich skalierbare und deterministische Overlay-Architektur. Während VXLAN die Data Plane bereitstellt, übernimmt EVPN die Steuerung des Netzwerks. Oder vereinfacht formuliert: VXLAN transportiert – EVPN koordiniert.

Exkurs: Anycast ist nicht gleich Anycast – VXLAN Anycast Gateway vs. IPv6 Anycast

Im Zusammenhang mit VXLAN EVPN taucht regelmäßig der Begriff Anycast Gateway auf. Leser:innen mit Netzwerkhintergrund denken dabei oft sofort an IPv6 Anycast oder an Anycast-Dienste im Internet – beispielsweise DNS-Infrastrukturen. Das ist nachvollziehbar, denn beide Konzepte teilen sich denselben Namen und folgen einer ähnlichen Grundidee: Mehrere Systeme stellen dieselbe Adresse bereit. Trotzdem handelt es sich technisch um zwei sehr unterschiedliche Mechanismen.

Gemeinsame Idee: Eine Adresse an mehreren Orten

Sowohl beim VXLAN Anycast Gateway als auch bei IPv6 Anycast existiert derselbe logische Dienst an mehreren Stellen gleichzeitig.

Das Ziel ist in beiden Fällen vergleichbar:

  • bessere Verfügbarkeit
  • geringere Abhängigkeit von Einzelkomponenten
  • optimierte Erreichbarkeit
  • höhere Skalierbarkeit

Die technische Umsetzung unterscheidet sich jedoch grundlegend.

VXLAN Anycast Gateway – Einheitliches Gateway in der Fabric

Im VXLAN-EVPN-Kontext verfolgt das Anycast Gateway ein sehr konkretes Ziel: Endgeräte sollen ihr Default Gateway unabhängig von ihrem physischen Standort immer gleich wahrnehmen. Gerade in modernen Datacentern mit hochdynamischen Workloads ist dies entscheidend, da virtuelle Maschinen oder Container ihren Ausführungsort häufig wechseln, ohne dass sich dadurch ihre Netzwerkkonnektivität verändern darf.

In klassischen Netzwerken befindet sich das Default Gateway eines VLANs meist auf einem bestimmten Switch oder Routingpunkt. Wird ein Workload verschoben, entstehen schnell Herausforderungen: Das Gateway liegt möglicherweise nicht mehr lokal, Datenverkehr muss zusätzliche Routingpfade nehmen oder die Netzwerkarchitektur muss aufwendig erweitert werden, um Layer-2-Segmente über mehrere Bereiche hinweg zu strecken.

VXLAN-EVPN löst dieses Problem grundlegend anders. Innerhalb der Fabric präsentieren alle Leaf-Switches dasselbe Default Gateway. Konkret bedeutet das: Jeder Leaf stellt dieselbe virtuelle Gateway-IP-Adresse sowie dieselbe virtuelle MAC-Adresse bereit. Für Server, virtuelle Maschinen oder andere Endgeräte erscheint das Gateway dadurch überall identisch – unabhängig davon, an welchem Rack oder Leaf sie physisch angeschlossen sind.

Die eigentliche Intelligenz liegt dabei in der VXLAN-EVPN-Architektur: Obwohl mehrere Leafs gleichzeitig dasselbe Gateway bereitstellen, entsteht keine Inkonsistenz. Die Verarbeitung des Verkehrs erfolgt lokal auf dem Leaf, an dem sich der jeweilige Workload aktuell befindet. Der Datenverkehr muss also nicht zunächst zu einem zentralen Gateway geleitet werden, sondern wird direkt vor Ort verarbeitet und anschließend effizient durch die Fabric transportiert.

Das bringt gleich mehrere Vorteile mit sich: Einerseits sinken Latenzen, weil unnötige Umwege entfallen. Andererseits wird die Mobilität von Workloads erheblich vereinfacht. Eine virtuelle Maschine kann ihren Host oder sogar das Rack wechseln, ohne dass sich aus Sicht des Betriebssystems das Netzwerk „verändert“. IP-Adresse, Gateway und Kommunikationsverhalten bleiben gleich.

Oder vereinfacht formuliert: VXLAN Anycast sorgt dafür, dass sich das Gateway überall gleich verhält – unabhängig davon, wo sich der Workload gerade befindet.

IPv6 Anycast – Routing entscheidet über den nächstgelegenen Dienst

IPv6 Anycast verfolgt ein anderes Ziel als das VXLAN Anycast Gateway. Hier geht es nicht darum, ein identisches Gateway innerhalb einer Fabric bereitzustellen, sondern darum, denselben Dienst an mehreren Standorten gleichzeitig verfügbar zu machen.

Dazu wird dieselbe IPv6-Adresse bewusst auf mehreren unterschiedlichen Systemen konfiguriert. Mehrere Server oder Dienste annoncen anschließend dieselbe Route ins Netzwerk. Typische Einsatzgebiete sind beispielsweise DNS-Resolver, Content Delivery Networks (CDNs), globale Diensteplattformen oder hochverfügbare Services, die weltweit konsistent erreichbar sein müssen.

Die eigentliche Intelligenz liegt dabei nicht auf dem Server selbst, sondern im Routing des Netzwerks. Sobald mehrere Instanzen denselben Dienst unter derselben IPv6-Adresse bereitstellen, entscheidet das Routing automatisch, welches Zielsystem aus Sicht des Clients am besten erreichbar ist. Dabei bedeutet Nähe nicht zwingend geografische Distanz. Ausschlaggebend sind vielmehr Routingmetriken, Pfadkosten, Policy-Regeln oder die aktuell beste Netzwerkerreichbarkeit.

Ein Client kommuniziert somit stets mit der aus Netzwerksicht optimalen Instanz eines Dienstes – ohne selbst wissen zu müssen, welcher konkrete Server sich dahinter verbirgt.

Ein bekanntes Praxisbeispiel sind globale DNS-Dienste: Mehrere Resolver weltweit verwenden dieselbe IPv6-Adresse. Nutzer:innen werden dabei automatisch an die jeweils günstigste oder nächstgelegene Instanz weitergeleitet, was sowohl Latenzen reduziert als auch die Verfügbarkeit verbessert.

Der entscheidende Unterschied zu VXLAN Anycast wird hier besonders deutlich: Während beim VXLAN Anycast Gateway alle Leafs dasselbe Gateway lokal bereitstellen, entscheidet bei IPv6 Anycast das Routing dynamisch darüber, welche konkrete Instanz eines Dienstes genutzt wird.

Oder vereinfacht formuliert: IPv6 Anycast macht denselben Dienst an mehreren Orten erreichbar – das Netzwerk entscheidet automatisch, welche Instanz genutzt wird.

Der entscheidende Unterschied

Der wichtigste Unterschied liegt also in der Funktion: VXLAN Anycast Gateway sorgt dafür, dass sich innerhalb einer Datacenter-Fabric überall dasselbe Gateway befindet. IPv6 Anycast dagegen sorgt dafür, dass Routing automatisch die beste Instanz eines Dienstes auswählt. Oder noch kompakter: VXLAN Anycast schafft Mobilität innerhalb der Fabric – IPv6 Anycast optimiert Erreichbarkeit im Netzwerk.

Warum die Begriffsverwechslung verständlich ist

Die Verwirrung entsteht vor allem deshalb, weil beide Konzepte denselben Begriff verwenden und tatsächlich eine Gemeinsamkeit besitzen: Eine Adresse existiert mehrfach.

Der eigentliche Mechanismus unterscheidet sich jedoch deutlich:

  • VXLAN Anycast Gateway: lokale Gateway-Abstraktion innerhalb einer Fabric
  • IPv6 Anycast: routingbasierte Auswahl eines Zielsystems

Beide Technologien verfolgen somit unterschiedliche Ziele – auch wenn sie denselben Namen tragen.

Fazit

Wer den Begriff Anycast Gateway im VXLAN-EVPN-Kontext hört, sollte daher nicht automatisch an klassisches IPv6 Anycast denken. Trotz ähnlicher Namensgebung erfüllen beide Konzepte unterschiedliche Aufgaben: VXLAN Anycast stabilisiert die Host-Mobilität im Datacenter – IPv6 Anycast optimiert die globale Dienstverfügbarkeit durch Routing.

Gerade diese begriffliche Trennung hilft dabei, moderne Datacenter-Fabrics besser zu verstehen und Missverständnisse in Architekturgesprächen zu vermeiden.

Designentscheidungen: VLAN oder VXLAN?

Die Frage, ob ein Netzwerk auf VLANs oder VXLAN setzen sollte, wirkt auf den ersten Blick wie eine klassische Technologieentscheidung. In der Praxis greift diese Sichtweise jedoch zu kurz. Denn VLAN und VXLAN stehen meist nicht in Konkurrenz – sie lösen unterschiedliche Probleme.

VLANs entstanden in einer Zeit, in der Netzwerke vor allem lokal gedacht wurden. Ziel war es, physische Infrastrukturen logisch zu segmentieren, Broadcast-Domänen zu begrenzen und organisatorische Trennungen abzubilden. Bis heute erfüllen VLANs diese Aufgabe äußerst zuverlässig und bilden das Fundament praktisch jeder Campus-Infrastruktur.

VXLAN adressiert dagegen eine andere Realität: hochgradig virtualisierte, dynamische und verteilte Umgebungen. In modernen Rechenzentren wechseln Workloads ihren Standort, Anwendungen kommunizieren quer durch die Infrastruktur und Multi-Tenant-Szenarien verlangen eine wesentlich feinere und skalierbarere Segmentierung.

Die eigentliche Frage lautet daher selten: VLAN oder VXLAN?, sondern vielmehr: Welche Technologie ist für welches Szenario die richtige?

Denn in der Praxis existieren beide Ansätze meist nebeneinander. Während VLANs weiterhin den Access-Layer vieler Campus-Netze dominieren, bildet VXLAN EVPN zunehmend die Grundlage moderner Datacenter-Fabrics. Zwischen beiden Welten entstehen hybride Architekturen, in denen klassische Layer-2-Segmentierung und Overlay-Netze gezielt zusammenspielen.

VLANs im Campus – warum sie bleiben werden

Trotz aller Entwicklungen rund um VXLAN, EVPN oder Software-defined Fabrics bleiben VLANs in klassischen Campus-Netzen auf absehbare Zeit unverzichtbar. Der Grund dafür liegt weniger in technischer Tradition als vielmehr in der Passung zwischen Technologie und Anwendungsfall.

Campus-Netze folgen typischerweise einer anderen Logik als moderne Datacenter. Der Datenverkehr verläuft hier überwiegend Nord-Süd-orientiert: Benutzer:innen greifen auf zentrale Dienste, Applikationen, das Internet oder Cloud-Ressourcen zu. Der Schwerpunkt liegt damit weniger auf massiver horizontaler Kommunikation zwischen Endsystemen, sondern auf kontrollierter Erreichbarkeit zentraler Ressourcen.

Genau für dieses Szenario sind VLANs hervorragend geeignet. Bereits mit überschaubarem Aufwand lassen sich organisatorische, technische oder sicherheitsrelevante Netzsegmente sauber voneinander trennen. Mitarbeitende, Gäste, IoT-Geräte, Voice-Systeme oder Server können jeweils in eigene Broadcast-Domänen eingeordnet werden. Gleichzeitig bleibt das Design transparent und administrativ gut beherrschbar.

Ein typisches Campus-Design kombiniert dabei Access-VLANs mit einem Layer-3-Core. Auf der Access-Ebene übernehmen Switches die lokale VLAN-Zuweisung – häufig ergänzt durch Mechanismen wie IEEE 802.1X, RADIUS oder Network Access Control (NAC). Das eigentliche Routing zwischen den Segmenten erfolgt anschließend zentral oder verteilt über Layer-3-Switches mittels Switched Virtual Interfaces (SVIs).

Die Vorteile dieses Ansatzes liegen auf der Hand:

  • klare Netzwerkstrukturen, die leicht nachvollziehbar bleiben
  • geringe betriebliche Komplexität, insbesondere im Vergleich zu Overlay-Architekturen
  • hohe Stabilität und Vorhersagbarkeit im täglichen Betrieb
  • einfachere Fehleranalyse, da physische und logische Topologie meist eng zusammenhängen
  • ausreichende Skalierung, da selbst größere Campus-Umgebungen selten an die Grenze von 4096 VLANs stoßen

Hinzu kommt ein weiterer Aspekt: Viele typische Campus-Anforderungen benötigen die Komplexität von VXLAN schlicht nicht. Ein Büroarbeitsplatz, ein Drucker oder ein VoIP-Telefon profitieren nur begrenzt von Overlay-Netzen, Workload-Mobilität oder Millionen virtueller Segmente. Entscheidend sind hier vielmehr Zuverlässigkeit, klare Segmentierung und einfache Betriebsprozesse.

Gerade deshalb bleibt VLAN im Campus nicht etwa eine Alttechnologie, sondern weiterhin eine architektonisch sinnvolle Designentscheidung. Oder anders formuliert: Nicht jede moderne Infrastruktur benötigt automatisch VXLAN – häufig ist ein sauber designtes VLAN-Konzept die bessere Architektur.

VXLAN EVPN im Rechenzentrum – wo klassische VLANs an Grenzen stoßen

Während VLANs im Campus ihre Stärken ausspielen, verändern sich die Anforderungen im Rechenzentrum grundlegend. Moderne Datacenter folgen einer anderen Kommunikationslogik – und genau hier geraten klassische VLAN-Designs zunehmend an ihre Grenzen.

Statt überwiegend Nord-Süd-Traffic zwischen Clients und zentralen Diensten dominiert im Datacenter heute vor allem der Ost-West-Traffic. Anwendungen kommunizieren kontinuierlich miteinander: Datenbanken sprechen mit Application-Servern, Container tauschen Informationen aus, Microservices erzeugen zahlreiche horizontale Verbindungen und virtuelle Maschinen werden dynamisch verschoben. Die Kommunikation verläuft also nicht mehr primär nach oben zum zentralen Dienst, sondern quer durch die Infrastruktur.

Gleichzeitig steigen die Anforderungen an Flexibilität erheblich. Virtuelle Maschinen wechseln ihren Host, Container werden dynamisch erzeugt und gelöscht, Anwendungen skalieren horizontal über mehrere Server hinweg. Netzwerksegmentierung darf dadurch nicht länger starr an physische Ports oder einzelne Switches gebunden sein.

Genau an dieser Stelle stößt das klassische VLAN-Modell an mehrere Grenzen. Zwar lassen sich VLANs grundsätzlich auch in großen Umgebungen einsetzen, jedoch entstehen schnell strukturelle Herausforderungen:

  • die Begrenzung auf 4096 VLAN-IDs reicht in großen Multi-Tenant-Umgebungen häufig nicht mehr aus
  • Layer-2-Domänen über viele Switches hinweg erhöhen Komplexität und Broadcast-Anteil
  • Workload-Mobilität erschwert konsistente Netzsegmentierung
  • geografisch verteilte Datacenter lassen sich nur schwer sauber mit klassischen VLAN-Konzepten verbinden
  • Mandantenfähigkeit (Multi-Tenancy) wird zunehmend komplex

Besonders problematisch wird dies in stark virtualisierten Umgebungen. Wird eine virtuelle Maschine zwischen Hosts verschoben, soll sich aus Sicht der Anwendung möglichst nichts ändern. IP-Adresse, Erreichbarkeit und Sicherheitsrichtlinien sollen erhalten bleiben – unabhängig davon, auf welchem physischen Server der Workload aktuell läuft.

Klassische VLANs können solche Anforderungen nur eingeschränkt abbilden. Häufig entstehen aufwendige Layer-2-Stretching-Konstruktionen oder komplexe Routingdesigns, die Betrieb und Fehlersuche erschweren.

Hier setzt VXLAN EVPN an. Durch die Entkopplung von physischer Infrastruktur und logischer Segmentierung entstehen hochskalierbare Overlay-Netze, die Workloads unabhängig von Standort, Rack oder physischem Leaf-Switch verbinden können. Gleichzeitig sorgt EVPN als intelligente Control Plane dafür, dass Endpunktinformationen deterministisch verteilt werden – ohne die Skalierungsprobleme klassischer Flooding-Mechanismen.

Besonders in Spine-Leaf-Fabrics, Cloud-Umgebungen, Multi-Tenant-Architekturen oder hybriden Datacentern hat sich VXLAN EVPN deshalb als De-facto-Standard etabliert. Vereinfacht ausgedrückt: Wo Campus-Netze Stabilität und Einfachheit priorisieren, benötigen Datacenter Skalierung, Mobilität und logische Entkopplung – genau dafür wurde VXLAN entwickelt.

Übergangsszenarien und Hybrid-Designs

In der Praxis verschwinden VLANs nicht plötzlich, sobald VXLAN eingeführt wird. Tatsächlich existieren beide Technologien in den meisten Enterprise-Umgebungen über lange Zeit parallel – und ergänzen sich dabei sinnvoll. Der Grund liegt in den unterschiedlichen Aufgabenbereichen: Während VLANs weiterhin hervorragend für die lokale Segmentierung im Campus geeignet sind, adressiert VXLAN vor allem die Anforderungen moderner Datacenter- und Cloud-Infrastrukturen.

Die eigentliche Designfrage lautet daher häufig nicht: VLAN oder VXLAN?, sondern: Wo ist welche Technologie architektonisch sinnvoll? In vielen Unternehmen entsteht dadurch eine hybride Architektur.

Ein typisches Szenario besteht beispielsweise darin, dass Benutzer:innen im Campus weiterhin über klassische VLANs angebunden werden, während im Rechenzentrum bereits eine VXLAN-EVPN-Fabric betrieben wird. Der Übergang zwischen beiden Welten erfolgt über Border-Gateways oder Routingpunkte, die klassische VLAN-basierte Segmente in Overlay-Strukturen integrieren.

Ein Mitarbeitenden-Endgerät kommuniziert dabei lokal weiterhin innerhalb eines VLANs, während die eigentlichen Backend-Dienste oder virtuellen Workloads bereits in VXLAN-Segmenten betrieben werden. Für Benutzer:innen bleibt dieser Übergang unsichtbar: Im Access bleibt das Netzwerk klassisch – im Datacenter arbeitet bereits die Fabric.

Auch bei Cloud- und Hybrid-Szenarien zeigt sich diese Koexistenz deutlich. Lokale Campus-Netze bleiben häufig VLAN-basiert, während Cloud-nahe Dienste oder mandantenfähige Plattformen über VXLAN segmentiert werden. Gerade in virtualisierten Umgebungen ermöglicht dies eine deutlich flexiblere Platzierung von Workloads.

Hinzu kommt ein weiterer wichtiger Punkt: VXLAN ersetzt VLANs nicht vollständig. Selbst in modernen Datacenter-Fabrics bleiben VLANs oft Bestandteil des Designs – beispielsweise für die lokale Anbindung von Servern an Leafs oder als Übergangspunkt zwischen Access-Netzen und Overlay-Segmenten. VXLAN baut damit in vielen Fällen auf vorhandenen VLAN-Strukturen auf, statt diese vollständig abzulösen.

In der Praxis entsteht dadurch meist ein evolutionärer Übergang:

  • Campus Access: VLAN-basiert
  • Identity und NAC: VLANs kombiniert mit 802.1X und dynamischer Segmentierung
  • Datacenter: VXLAN EVPN als skalierbare Fabric
  • Hybrid-Szenarien: VLAN im Campus, VXLAN im Rechenzentrum
  • Multi-Site-Umgebungen: VXLAN EVPN für standortübergreifende Segmentierung

Die Realität moderner Enterprise-Netzwerke ist daher selten entweder oder – sondern fast immer: VLAN dort, wo Einfachheit zählt – VXLAN dort, wo Skalierung und Mobilität erforderlich werden.

Typische Praxisarchitekturen

Die Entscheidung zwischen VLAN und VXLAN wird in der Praxis selten abstrakt getroffen. Vielmehr ergibt sie sich aus den konkreten Anforderungen einer Infrastruktur. Je nach Netzwerktyp, Sicherheitsanforderungen und Skalierungsbedarf haben sich bestimmte Architekturmodelle etabliert.

Campus Access VLAN mit Layer-3-Core

Das klassische Enterprise-Campus-Netz setzt bis heute überwiegend auf VLAN-basierte Segmentierung in Kombination mit einem Layer-3-Core. Endgeräte werden dabei über Access-Switches in lokale VLANs eingebunden. Mitarbeitende, Gäste, Voice-Systeme oder Drucker befinden sich in getrennten Broadcast-Domänen, während das Routing zentral oder verteilt über Layer-3-Switches erfolgt. Typischerweise kommen hier Switched Virtual Interfaces (SVIs) zum Einsatz, die das Default Gateway der jeweiligen VLANs bereitstellen.

Ein vereinfachtes Beispiel könnte so aussehen:

  • VLAN 10 → Mitarbeitende
  • VLAN 20 → Gäste
  • VLAN 30 → Voice
  • VLAN 40 → Drucker
  • VLAN 50 → Serverzugriff

Der Schwerpunkt liegt in diesem Architekturmodell auf klarer Segmentierung, einfacher Administration, hoher Stabilität und einer gut beherrschbaren Betriebsführung. Netzstrukturen bleiben nachvollziehbar, Routingentscheidungen transparent und typische Fehlerbilder vergleichsweise leicht analysierbar.

Gerade in Umgebungen mit überwiegend Nord-Süd-Kommunikation, in denen Benutzer:innen primär auf zentrale Dienste, Server oder Cloud-Ressourcen zugreifen, bleibt dieses Modell bis heute äußerst effizient und wirtschaftlich. Seine Stärke liegt weniger in maximaler Flexibilität als vielmehr in einem stabilen, vorhersehbaren und betrieblich gut kontrollierbaren Netzwerkdesign.

IoT- und NAC-Design mit 802.1X

Sobald Geräteklassen dynamischer werden, reicht eine starre Port-zu-VLAN-Zuordnung oft nicht mehr aus. Moderne Campus-Netze kombinieren klassische VLANs deshalb zunehmend mit IEEE 802.1X, RADIUS und Network Access Control (NAC). Der entscheidende Unterschied: Nicht mehr der Port bestimmt die Segmentierung – sondern die Identität.

Ein typisches Beispiel:

Ein Mitarbeitenden-Notebook, ein Drucker und ein IoT-Sensor werden am selben Access-Switch angeschlossen. Obwohl physisch identische Ports verwendet werden, erhalten die Systeme nach erfolgreicher Authentifizierung unterschiedliche Netzsegmente und Sicherheitsrichtlinien.

Ein mögliches Ergebnis:

  • Mitarbeitenden-Geräte → internes Produktionsnetz
  • Gäste → isoliertes Gäste-VLAN
  • IoT-Geräte → restriktives Segment mit eingeschränkter Kommunikation
  • unbekannte Geräte → Quarantäne- oder Remediation-VLAN

Dadurch entsteht bereits im Campus eine deutlich flexiblere und sicherheitsorientiertere Form der Segmentierung – ohne sofort eine vollständige Fabric-Architektur einführen zu müssen.

Datacenter Fabric mit VXLAN EVPN

Im Rechenzentrum verschieben sich die Prioritäten deutlich. Statt überwiegend klassischer Client-zu-Server-Kommunikation dominieren hier hochdynamische und horizontale Kommunikationsmuster. Besonders relevant sind dabei:

  • Ost-West-Kommunikation
  • hohe Workload-Dichte
  • Virtualisierung
  • horizontale Skalierung
  • Mandantenfähigkeit

Gerade virtualisierte Umgebungen, Container-Plattformen oder Cloud-native Anwendungen erzeugen erhebliche Mengen an Verkehr zwischen Workloads innerhalb der Infrastruktur. Das klassische Core-Distribution-Design stößt in solchen Szenarien schnell an Grenzen, da es ursprünglich primär für Nord-Süd-Kommunikation entwickelt wurde.

Stattdessen kommt in modernen Rechenzentren häufig eine Spine-Leaf-Fabric mit VXLAN EVPN zum Einsatz. Server werden lokal an Top-of-Rack-Switches (Leafs) angebunden, während das Underlay-Netzwerk über gleichwertige ECMP-Pfade (Equal Cost Multipath) arbeitet. VXLAN übernimmt dabei die logische Segmentierung der Workloads, während EVPN als intelligente Control Plane für die deterministische Verteilung der Endpunktinformationen sorgt.

Dadurch entstehen mehrere Vorteile:

  • Millionen logischer Segmente statt 4096 VLANs
  • Workload-Mobilität ohne Netzumbau
  • Multi-Tenant-Fähigkeit
  • deterministische Weiterleitung ohne Flooding-Abhängigkeit
  • bessere horizontale Skalierbarkeit

Gerade in stark virtualisierten Umgebungen sowie in KI-, Container- oder Cloud-Infrastrukturen gehört dieses Modell heute häufig zur bevorzugten Architektur, da es hohe Skalierbarkeit mit flexibler Segmentierung und effizienter Lastverteilung verbindet.

Hybrid Campus zu Datacenter

In vielen Unternehmen treffen beide Welten direkt aufeinander. Das Campus-Netz bleibt VLAN-basiert, während das Rechenzentrum bereits auf VXLAN EVPN setzt.

Ein Mitarbeitenden-Endgerät befindet sich beispielsweise lokal weiterhin in einem Campus-VLAN, kommuniziert jedoch mit Backend-Systemen oder virtuellen Diensten, die innerhalb einer VXLAN-Fabric betrieben werden. Die Verbindung erfolgt über Border-Gateways oder Routinginstanzen zwischen beiden Domänen.

Für Anwender:innen bleibt dieser Übergang unsichtbar: Das Netzwerk fühlt sich weiterhin wie ein einziges Netz an – intern arbeiten jedoch unterschiedliche Architekturmodelle zusammen. Gerade dieser evolutionäre Ansatz reduziert Migrationsrisiken erheblich.

Multi-Site Datacenter

Besonders anspruchsvoll werden Designs, wenn mehrere Rechenzentren oder geografisch getrennte Standorte miteinander verbunden werden müssen. Klassische VLAN-Konzepte geraten hier schnell an technische und betriebliche Grenzen. Layer-2-Stretching über größere Distanzen erhöht Komplexität und erschwert Fehlersuche sowie Skalierung.

VXLAN EVPN bietet hier deutlich mehr Flexibilität. Über EVPN Multi-Site oder entsprechende Overlay-Konzepte lassen sich logische Segmente standortübergreifend bereitstellen, ohne dass physische Standortgrenzen die Segmentierung bestimmen.

Das ermöglicht unter anderem:

  • Disaster-Recovery-Szenarien
  • verteilte Datacenter-Workloads
  • aktive / aktive Rechenzentren
  • konsistente Sicherheitsrichtlinien über mehrere Standorte hinweg

Gerade für Cloud-nahe oder hochverfügbare Architekturen wird dies zunehmend relevant.

VLANs als Fundament, VXLAN als Zukunft

Die Geschichte der Netzwerksegmentierung ist letztlich eine Geschichte zunehmender Entkopplung: von physischer Verkabelung hin zu logischen, softwaredefinierten Kommunikationsstrukturen.

Was einst mit einzelnen Switchports und lokal begrenzten Broadcast-Domänen begann, entwickelte sich Schritt für Schritt zu hochskalierbaren Overlay-Fabrics, die Workloads unabhängig von physischen Standorten miteinander verbinden. Genau darin zeigt sich die eigentliche Evolution moderner Netzwerke: Nicht mehr die Verkabelung bestimmt die Kommunikationsmöglichkeiten – sondern die Architektur.

Die Evolution der Segmentierung

VLANs markierten dabei einen entscheidenden Wendepunkt. Erstmals ließ sich Netzwerksegmentierung logisch denken, ohne physische Infrastrukturen vollständig neu aufbauen zu müssen. Broadcast-Domänen konnten gezielt begrenzt, organisatorische Strukturen technisch abgebildet und Sicherheitszonen voneinander getrennt werden.

Mit zunehmender Virtualisierung, Cloud-Nutzung und Workload-Mobilität stiegen jedoch auch die Anforderungen an moderne Netzwerke. Rechenzentren mussten plötzlich Millionen potenzieller Kommunikationsbeziehungen verwalten, Mandanten sauber trennen und dynamische Workloads flexibel bewegen können.

Die Antwort darauf lautet heute häufig: VXLAN in Kombination mit EVPN. Durch Overlay-Technologien wird Segmentierung von der physischen Infrastruktur entkoppelt. Workloads lassen sich flexibel verschieben, logische Netze standortübergreifend erweitern und hochskalierbare Datacenter-Fabrics aufbauen.

Warum VLANs nicht verschwinden werden

Trotzdem bedeutet dieser Wandel keineswegs das Ende klassischer VLANs. Im Gegenteil: VLANs bleiben auch künftig das Fundament moderner Netzwerksegmentierung – insbesondere im Campus und Access-Bereich. Dort zählen vor allem Stabilität, Transparenz, geringe Komplexität und gut beherrschbare Betriebsmodelle.

Ein Arbeitsplatzrechner, ein Drucker oder ein Access Point benötigt selten Millionen Segmente oder globale Overlay-Strukturen. Hier bleiben klassische VLANs häufig die technisch sinnvollere und wirtschaftlichere Lösung.

Gerade deshalb lautet die Zukunftsperspektive nicht: VXLAN ersetzt VLAN, sondern vielmehr: VXLAN ergänzt VLAN dort, wo klassische Segmentierung an Grenzen stößt.

VXLAN als Architektur moderner Datacenter

Im Datacenter verschieben sich die Prioritäten dagegen deutlich. Hohe Workload-Dichte, Ost-West-Traffic, Multi-Tenant-Anforderungen und horizontale Skalierung verlangen nach einer anderen Denkweise.

VXLAN EVPN bildet hier zunehmend die Grundlage moderner Spine-Leaf-Fabrics. Segmentierung wird unabhängig vom physischen Standort, Anycast Gateways ermöglichen Workload-Mobilität und EVPN sorgt für eine deterministische Control Plane ohne klassische Flooding-Limitierungen.

Damit wird das Netzwerk selbst zunehmend zu einer dynamischen Plattform, die sich flexibel an Anwendungen anpasst – statt Anwendungen an starre Netzwerkgrenzen zu binden.

Sicherheit und Segmentierung im Zero-Trust-Zeitalter

Gleichzeitig verändert sich auch das Verständnis von Sicherheit. Lange Zeit galt Segmentierung primär als Werkzeug zur Begrenzung von Broadcast-Domänen oder organisatorischen Trennung von Netzbereichen. Heute rückt zunehmend die Frage in den Mittelpunkt: Wer darf mit wem kommunizieren – und unter welchen Bedingungen?

Im Zero-Trust-Zeitalter reicht reine Netzwerksegmentierung allein nicht mehr aus. VLANs, VXLANs und VRFs bilden weiterhin wichtige technische Grenzen, werden jedoch zunehmend durch identitätsbasierte Policies, Microsegmentation, Network Access Control und kontextabhängige Sicherheitsentscheidungen ergänzt.

Damit verschiebt sich der Fokus: Nicht mehr der Port entscheidet – sondern die Identität.

Ausblick: Von VLANs zur identitätsbasierten Fabric

Konzepte wie Cisco Software Defined Access (SDA) oder moderne Datacenter-Fabrics zeigen bereits heute, wohin die Entwicklung geht. Klassische VLANs und Overlay-Technologien werden zunehmend in softwaredefinierte Architekturen eingebettet, in denen Segmentierung dynamisch, automatisiert und identitätsbasiert erfolgt.

Die physische Infrastruktur bleibt dabei weiterhin wichtig – verliert jedoch ihre Rolle als primärer Steuerungsmechanismus. Oder anders formuliert: Die Zukunft gehört nicht dem Ende von VLANs – sondern ihrer Weiterentwicklung in intelligenten, identitätsbasierten Netzarchitekturen.

Damit schließt sich der Kreis dieses Beitrags: VLANs bleiben das Fundament. VXLAN erweitert die Möglichkeiten. Gemeinsam bilden beide die Grundlage moderner, sicherer und skalierbarer Netzwerke.

Quellenangaben

(Abgerufen am 14.06.2026)

Cisco Dokumentation, White Papers und Cisco Live

VLAN, Switching und Inter-VLAN-Routing

VXLAN, EVPN und Datacenter-Fabrics

Campus-Architekturen, SDA und Fabric Design

Cisco ISE, 802.1X und identitätsbasierte Segmentierung

Standards, RFCs und technische Spezifikationen

IEEE-Standards

RFCs und IETF Drafts

Literatur und Fachbücher

Microsoft NPS und RADIUS

Zero Trust und Sicherheitsarchitekturen

Ergänzende technische Einordnung und Sekundärquellen

Weiterlesen hier im Blog