Skalierbare Campus Netzwerk Designs: 2-Tier, 3-Tier und Spine-Leaf im ehrlichen Vergleich

Warum die Architekturfrage vor der Herstellerfrage kommt

Skalierbare Campus Netzwerk Designs entscheiden über Betrieb, Verfügbarkeit und Investitionen der nächsten sieben bis zehn Jahre. Die Switches darin lassen sich in dieser Zeit noch einmal austauschen, die Topologie in der Regel nicht. Wer Ports und Uplinks bestellt, bevor das Design steht, kauft in der Regel zu viel oder das Falsche.

Referenzarchitekturen der Hersteller sind ein guter Ausgangspunkt, aber kein Ersatz für die eigene Anforderungsanalyse. Sie sind auf ein möglichst breites Publikum optimiert und tendieren im Zweifel zu mehr Plattform, nicht zu weniger. Für den einzelnen Kunden ist das oft der falsche Optimierungspunkt.

Drei Fragen legen die Architektur fest, bevor über Switch-Modelle gesprochen wird:

• Wie viele Etagen, Gebäude und Standorte hängen am Campus, und wie wächst das über die Abschreibungsdauer?
• Wie viel Ost-West-Traffic entsteht tatsächlich zwischen Endgeräten und Servern im Campus, im Gegensatz zum Nord-Süd-Traffic Richtung Datacenter und Internet?
• Welche Ausfallzeit ist tolerierbar, in Minuten pro Jahr und in Minuten pro Störung?

Erst danach lohnt der Blick auf 2-Tier, 3-Tier oder Spine-Leaf.

Collapsed Core: die 2-Tier-Architektur

Beim Collapsed Core verschmelzen Core- und Distribution-Layer zu einem Layer. Die Access-Switches in den Etagen- und Serververteilern hängen direkt an einem redundanten Core-Paar. Dieses Paar übernimmt Routing, Layer-3-Handoff, die Firewall-Kopplung und meist auch die WAN-Anbindung. Klassisch als zwei Chassis oder als Stack-Paar gebaut, heute zunehmend als VSX-, MC-LAG- oder EVPN-Peer-Konstrukt.

Technisch trägt das Modell weiter, als viele glauben. Aktuelle Campus-Core-Switches liefern mehrere Terabit Backplane, 100- und 400-Gbit-Uplinks und genug Routing-Kapazität für mittelgroße Umgebungen mit einigen tausend Ports. Der klassische Grund für einen separaten Distribution-Layer war zu wenig Portdichte und Backplane im Core. Bei aktuellen Plattformen ist dieser Grund oft entfallen.

Wofür Collapsed Core stark ist:

• Ein oder zwei Gebäude mit kompakter Verteilerlandschaft.
• Kaufmännisch schlank: zwei Core-Geräte statt vier bis sechs, weniger Lizenzen, weniger Wartung, weniger Rack-HE.
• Betrieblich einfach: ein Layer weniger im Design heißt ein Layer weniger für Wartungsfenster, Troubleshooting und Dokumentation.
• Konvergenzzeiten liegen bei sauber gebautem VSX oder MC-LAG im niedrigen Sekundenbereich, oft deutlich darunter.

Wo Collapsed Core an seine Grenzen stößt:

• Ab einer gewissen Zahl an Etagen- und Gebäudeverteilern reichen die Core-Ports nicht mehr. Nachrüsten geht, aber jedes weitere Modul im laufenden Core ist ein Change und erhöht die Dichte der Verkabelung an einem zentralen Punkt.
• Ein Core-Ausfall kann sehr schnell teuer werden. Fällt ein Gerät sauber weg, übernimmt der Partner. Schlägt die Redundanz fehl, steht der komplette Campus, sei es durch Split-Brain, eine MC-LAG-Fehlkonfiguration oder eine fehlerhafte Firmware.
• Bei verteilten Liegenschaften mit vielen kleinen Gebäuden auf einem Areal wird die sternförmige Verkabelung zum Core teurer als eine hierarchische Aggregation über einen Distribution-Layer.

Ein sauber gebautes Collapsed Core ist keine Notlösung. Es ist für die Mehrzahl der mittelständischen Campus-Umgebungen, die wir in der Beratung sehen, das ökonomisch richtige Design.

3-Tier: Core, Distribution, Access

Das klassische Drei-Layer-Design trennt Core (Backbone), Distribution (Aggregation, Routing, Policy) und Access (Endgeräte-Anschluss) sauber voneinander. Zwischen Distribution und Core läuft in der Regel reines Routing, Layer 2 endet auf dem Distribution-Layer.

Der Denkfehler bei diesem Modell: 3-Tier als „das professionelle“ Design zu verstehen, 2-Tier als „nur für kleine“ Umgebungen. Diese Lesart stammt aus einer Zeit, in der Core-Plattformen deutlich schwächer waren und der Distribution-Layer die eigentliche Arbeit leisten musste. Heute rechtfertigt sich 3-Tier nicht durch Prestige, sondern durch Struktur.

Wofür 3-Tier stark ist:

• Große Campus-Umgebungen mit vielen Gebäuden, langen Trassen und einem natürlichen Aggregation-Layer pro Gebäude oder pro Cluster.
• Klare Failure Domains: ein Distribution-Paar pro Gebäude begrenzt Konfigurationsfehler und Broadcast-Storms auf dieses Gebäude und reißt den Rest des Campus nicht mit.
• Skalierung durch weitere Distribution-Pärchen, ohne den Core anzufassen. Der Core bleibt schmal und schnell, die Distribution wächst.
• Betriebliche Trennung: Änderungen am Access- und am Distribution-Layer laufen in getrennten Wartungsfenstern. Port-Konfigurationen und VLAN-Zuweisungen am Access kann das Betriebsteam eigenständig umsetzen. Eingriffe in Routing und Policy auf dem Distribution-Layer bleiben bei den Network Engineers, die das Design verantworten.

Was 3-Tier kostet:

• Deutlich mehr Hardware. Pro Gebäude zwei Distribution-Switches, dazu die zwei Core-Geräte. Das erhöht Anschaffungskosten, Supportverträge, Energiebedarf und Rack-Belegung spürbar.
• Höhere Design-Komplexität: Routing-Domains, Redistribution, Loopback-Adressierung, konsistente Access-Konfiguration über viele Distribution-Paare hinweg.
• Längere Konvergenzpfade, wenn IGP-Timer und BFD nicht konsequent optimiert sind.
• Automatisierung und eine saubere Source-of-Truth sind Pflicht. Dazu gehören beispielsweise NetBox als Source-of-Truth für Verkabelung, VLANs und IP-Adressmanagement (IPAM), CheckMK für das Monitoring auf allen Infrastruktur-Ebenen und Graylog für die zentrale Log-Aggregation. Wer 3-Tier ohne eine solche Basis betreibt, produziert Config-Drift.

Ob sich 3-Tier rechnet, hängt davon ab, was ein großflächiger Ausfall kostet. Der zusätzliche Distribution-Layer verteuert Anschaffung und Betrieb, begrenzt aber jede Störung auf ein Gebäude. Wo ein campusweiter Stillstand Produktion, Patientenversorgung oder Lehrbetrieb lahmlegt, sind die Mehrkosten gut investiert.

Spine-Leaf im Campus

Spine-Leaf stammt aus dem Datacenter und ist dort inzwischen Standard. Jeder Leaf hat einen Uplink zu jedem Spine, Layer 2 wird über EVPN und VXLAN transportiert, das Routing läuft auf jedem Leaf. Ost-West-Traffic hat immer denselben, vorhersehbaren Hop-Abstand: Leaf, Spine, Leaf. Bandbreite skaliert horizontal über zusätzliche Spines, Access-Kapazität über zusätzliche Leafs.

Im Campus taucht diese Architektur zunehmend auf, und sie ist auch dort technisch elegant. Die Frage ist nur, ob der Campus die Eigenschaften wirklich braucht, die Spine-Leaf teuer erkauft.

Wofür Spine-Leaf im Campus stark ist:

• Sehr hohe Ost-West-Lasten im Campus, etwa wenn Datacenter-Funktionen zurück in den Campus wandern, Edge-nahe Analytik oder KI-Workloads am Standort laufen oder Mikrosegmentierung auf Ebene der Leaf-Switches umgesetzt wird.
• Uniforme Skalierung: jede weitere Leaf-Reihe verhält sich wie die vorherige. Wachstum ist vorhersagbar.
• Konsistente Latenz zwischen beliebigen Endpunkten, weil jeder Pfad ein Zwei-Hop-Pfad ist.
• Segmentierung im Netzwerk-Layer über EVPN und VXLAN, unabhängig von der physischen Topologie.

Was Spine-Leaf kostet:

• Deutlich höhere Hardware-Investition. Schon eine kleine Fabric bringt mindestens zwei Spines und vier Leafs mit. Das ist mehr Hardware, als ein Collapsed Core für dieselbe Fläche bräuchte.
• Höhere Anforderungen an das Betriebsteam. EVPN- und VXLAN-Troubleshooting, Underlay-Routing, Overlay-Adjacencies, MAC-Mobility, ARP-Suppression: Dieses Wissen baut sich nicht nebenbei auf.
• Automatisierung ist keine Option, sondern Voraussetzung. Wer eine Spine-Leaf-Fabric per Hand konfiguriert, baut sich Config-Drift strukturell ein.
• Der Nord-Süd-Anschluss an WAN, Internet und klassisches Datacenter braucht Border-Leafs und ein sauberes Konzept für Firewall-Kopplung und Route-Reflection.

Der Fehler, den wir am häufigsten sehen: Spine-Leaf wird gekauft, weil es „State-of-the-Art“ ist und in den Referenzarchitekturen ganz oben steht. Auf 90 Prozent der Ports läuft dann klassischer Client-Traffic, der auf einem 2-Tier-Design mit einem Bruchteil der Kosten und einem Viertel des Betriebsaufwands genauso gut aufgehoben wäre. State-of-the-Art ist nicht dasselbe wie „für diesen Standort das Richtige“.

Skalierbare Campus Netzwerk Designs im Vergleich

Die drei Designs lösen unterschiedliche Probleme. An denselben Kriterien gemessen, ergeben sich klare Indikationen.

Faustregeln aus unserer Projektpraxis:

• Ein bis zwei Gebäude, gemischte Client-Last, überschaubares Wachstum: Collapsed Core. Ein sauber gebautes 2-Tier-Design ist keine Notlösung, sondern meist die ökonomisch und betrieblich richtige Antwort.
• Mehrere Gebäude, verteilte Liegenschaften, Campus-Universität, Klinik-Areal, produzierendes Unternehmen mit mehreren Werken auf einem Standort: 3-Tier. Die Failure-Domain-Trennung pro Gebäude ist den Aufpreis wert.
• Hohe Ost-West-Last, echte Mikrosegmentierung als Ziel, Workloads im Campus, die sich wie Datacenter-Workloads verhalten, oder ein Standort, der absolute Ausfallsicherheit benötigt: Spine-Leaf. Aber nur, wenn Betrieb und Automation mitziehen.

Ein häufig übersehener Punkt: Die drei Designs schließen sich nicht aus. Wir bauen regelmäßig Collapsed-Core-Designs im Campus mit einer kleinen Spine-Leaf-Fabric für den Datacenter-Teil daneben. Die richtige Architektur ist selten monolithisch.

Was am Anfang unterschätzt wird

Drei Punkte, die in fast jedem Projekt teurer werden als geplant, wenn sie zu spät kommen:

• Die Topologie steht in der Faser, nicht im Switch. Wer 3-Tier nachträglich in einen sternförmig verkabelten Bau tragen will, zahlt jeden Meter doppelt.
• Adressplan und Source-of-Truth. Ohne belastbares IPAM und saubere Cabling Records weicht jede Architekturentscheidung im ersten Betriebsjahr durch Provisorien auf. Bei uns liegt beides durchgängig in NetBox, zum Beispiel mit Infoblox als DDI-Backend für DNS, DHCP und IPAM.
• Monitoring und Protokollierung. Ein Design lebt nur, wenn es überwacht werden kann. Dazu gehören beispielsweise CheckMK für aktive Komponenten und Alarmierung, Graylog für Syslog- und Security-Events und Grafana für die Kapazitätsauswertung. Diese Werkzeuge müssen stehen, bevor der erste Port produktiv geht.

Wie wir die Architekturentscheidung begleiten

Skalierbare Campus Netzwerk Designs sind unser Kerngeschäft. Wir konzipieren, migrieren und betreiben Campus-Netzwerke in allen drei Designs, vom Collapsed Core im mittelständischen Verwaltungsstandort bis zur Spine-Leaf-Fabric mit Mikrosegmentierung. Wir sind kein Systemhaus, das Netzwerk nebenbei macht. Wir sind auf genau diese Fragen spezialisiert: Architekturentscheidung, Migration ohne Ausfallzeit und laufender Betrieb. Dafür arbeiten wir mit einem sauberen Werkzeugkasten aus Monitoring, Log-Aggregation und Source-of-Truth. Dazu kommt eine 24/7-Rufbereitschaft, weil Verfügbarkeit über allem steht.

Unser Ziel ist nicht, die Referenzarchitektur eines Herstellers 1:1 umzusetzen, sondern für jeden Standort das Design zu finden, das technisch trägt und kaufmännisch stimmt. Wir rechnen die Optionen sauber gegeneinander: CAPEX, OPEX, Failure Domains, Migrationsrisiko. Und wir sagen offen, wenn State-of-the-Art für einen Standort zu groß gedacht und der einfachere Weg der richtige ist. Bei Neuaufbau oder Konsolidierung eines Campus sprechen wir deshalb zuerst über das Design und erst danach über die BoM.

Fazit

Es gibt keine überlegene Campus-Architektur. Es gibt die zur Größe, zur Last und zur Betriebsreife passende. Collapsed Core trägt weiter, als sein Ruf vermuten lässt. 3-Tier ist die richtige Antwort, wenn Failure Domains und Gebäudestruktur es verlangen. Spine-Leaf ist elegant, aber nur dort ökonomisch, wo die Fabric-Eigenschaften wirklich gebraucht werden. Wer diese drei Designs als Werkzeuge versteht und nicht als Glaubensrichtungen, trifft belastbare Entscheidungen.

Häufige Fragen zu Campus-Netzwerk-Designs

Glossar

2-Tier (Collapsed Core)

Campus-Design, bei dem Core- und Distribution-Layer in einem redundanten Core-Paar zusammenfallen. Die Access-Switches hängen direkt an diesem Paar.

3-Tier

Campus-Design mit getrenntem Core-, Distribution- und Access-Layer. Der Distribution-Layer aggregiert meist pro Gebäude.

BFD (Bidirectional Forwarding Detection)

Protokoll, das den Ausfall einer Verbindung im Millisekundenbereich erkennt und Routing-Protokolle dadurch schneller umschalten lässt.

BoM (Bill of Materials)

Stückliste mit allen Komponenten, Lizenzen und Supportverträgen eines Projekts.

Border-Leaf

Leaf-Switch, der eine Spine-Leaf-Fabric an WAN, Internet, Firewalls oder das klassische Datacenter anbindet.

CAPEX und OPEX

Investitionskosten für die Anschaffung (CAPEX) und laufende Betriebskosten (OPEX).

Config-Drift

Schleichende Abweichung der tatsächlichen Gerätekonfiguration vom dokumentierten Soll-Zustand.

DDI

Zusammenfassung von DNS, DHCP und IPAM in einer gemeinsam verwalteten Plattform.

DPU (Data Processing Unit)

Zusätzlicher Prozessor im Switch, der Funktionen wie Firewalling und Telemetrie direkt im Datenpfad übernimmt.

EVPN (Ethernet VPN)

BGP-basiertes Verfahren, das MAC- und IP-Adressinformationen zwischen den Switches einer Fabric verteilt.

Failure Domain

Bereich des Netzes, der von einem einzelnen Fehler betroffen ist, etwa einem Geräteausfall oder einer Fehlkonfiguration.

IGP (Interior Gateway Protocol)

Routing-Protokoll innerhalb eines Netzes, etwa OSPF. In Fabrics läuft das Underlay-Routing häufig auch über BGP.

IPAM (IP Address Management)

Verwaltung von Netzen, Subnetzen und IP-Adressen.

Konvergenzzeit

Zeit, bis das Netz nach einem Ausfall wieder einen stabilen Weiterleitungszustand erreicht hat.

MC-LAG (Multi-Chassis Link Aggregation)

Bündelung von Links über zwei Switches hinweg. Ein angeschlossenes Gerät nutzt beide Uplinks aktiv und bleibt beim Ausfall eines Switches verbunden.

Mikrosegmentierung

Feingranulare Trennung von Systemen mit Regeln bis auf die Ebene einzelner Endpunkte oder Workloads.

NAC (Network Access Control)

Zugangskontrolle, die Endgeräte vor dem Netzzugang authentifiziert und einem passenden Segment zuweist.

Ost-West- und Nord-Süd-Traffic

Ost-West-Traffic fließt innerhalb des Campus oder Datacenters zwischen Endgeräten und Servern. Nord-Süd-Traffic verlässt diesen Bereich Richtung Datacenter, WAN oder Internet.

Route-Reflection

BGP-Verfahren, bei dem zentrale Route Reflectors Routen an alle Peers verteilen. Nicht jeder Router muss dafür mit jedem anderen eine Session aufbauen.

Source-of-Truth

Zentrale, verbindliche Datenquelle für den Soll-Zustand des Netzes, bei uns NetBox.

Spine-Leaf

Topologie, bei der jeder Leaf-Switch mit jedem Spine-Switch verbunden ist. Die Anzahl der Spines lässt sich flexibel erweitern, der Verkehr zwischen zwei Leafs verteilt sich per ECMP auf alle Spines.

Split-Brain

Fehlerzustand eines redundanten Paares, in dem beide Geräte den Kontakt zueinander verlieren und unabhängig voneinander aktiv bleiben.

Underlay und Overlay

Das Underlay ist das geroutete physische Netz zwischen den Switches. Das Overlay sind die logischen Netze, die per VXLAN darüber aufgespannt werden.

VSX (Virtual Switching Extension)

Redundanztechnik bei HPE Aruba CX Switching. Zwei Switches mit jeweils eigener Control Plane arbeiten als Paar und synchronisieren ihren Zustand.

VXLAN (Virtual Extensible LAN)

Kapselung, die Layer-2-Segmente über ein geroutetes Layer-3-Netz transportiert.

Quellen und fachliche Grundlage

Fachliche Prüfung: 17.10.2026. Die Architekturaussagen sind herstellerunabhängig. Portdichten, Uplink-Geschwindigkeiten und Konvergenzzeiten hängen von Plattform und Konfiguration ab und sind vor einer konkreten Umsetzung ggf. erneut zu prüfen.

• BSI IT-Grundschutz: NET.1.1 Netzarchitektur und -design (Edition 2023)
• BSI IT-Grundschutz: NET.3.1 Router und Switches (Edition 2023)
• IETF RFC 7432: BGP MPLS-Based Ethernet VPN (EVPN)
• IETF RFC 7348: Virtual eXtensible Local Area Network (VXLAN)
• IETF RFC 8365: A Network Virtualization Overlay Solution Using EVPN
• IETF RFC 7938: Use of BGP for Routing in Large-Scale Data Centers
• IETF RFC 5880: Bidirectional Forwarding Detection (BFD)

Weiterführend

• SD-WAN-Implementierung im Mittelstand: die Roadmap
• WLAN-Kanalbündelung im Enterprise-Netzwerk
• Netzwerk-Lösungen der Gigahertz GmbH

Titelbild: KI-generiert.