Netzwerkarchitekturen im Vergleich: 3-Tier, Collapsed Core, Spine-Leaf und OpenZiti-Overlay

Vorab: Underlay ist nicht gleich Overlay

Bevor man die vier Kandidaten nebeneinanderstellt, muss eine Sache klar sein: 3-Tier, Collapsed Core und Spine-Leaf beschreiben physische Topologien, also wie Switches verkabelt sind. Wo geroutet. wo geswitched wird und wie Redundanz entsteht. Ein OpenZiti-Overlay dagegen beschreibt, wie Verbindungen logisch zustande kommen, unabhängig davon, welche Kabel darunter liegen. Das Overlay ersetzt das Underlay nicht, es setzt darauf auf. Wer die vier Begriffe als gleichrangige Alternativen behandelt, vergleicht ein Fundament mit einer Haustür. Trotzdem gehört der Vergleich in einen Artikel, denn in der Praxis konkurrieren die Ansätze sehr wohl um dasselbe Budget und dieselbe Frage: Womit erreiche ich Segmentierung, Ausfallsicherheit und kontrollierten Zugriff?

Die klassische 3-Tier-Architektur

Das dreistufige Modell aus Access-, Distribution- und Core-Layer stammt aus der Campus-Welt der späten Neunziger und ist bis heute in vielen gewachsenen Umgebungen der Ist-Zustand. Access-Switches binden Endgeräte an (Switching), die Distribution-Ebene aggregiert Gebäude oder Etagen und terminiert typischerweise die Layer-3-Grenzen (Routing und ACLs), der Core transportiert schnell und möglichst dumm zwischen den Distribution-Blöcken (L3-Switching).

Die Stärken des Modells liegen in seiner Skalierbarkeit in die Breite und in der klaren Zuständigkeit je Ebene: Access-Policies gehören an den Access, Routing und First-Hop-Redundanz an die Distribution, der Core bleibt frei von Filterlogik. Für große Campus-Umgebungen mit vielen Gebäuden, tausenden Ports und heterogener Verkabelung ist das nach wie vor ein tragfähiges Muster.

Die Schwächen zeigen sich beim Verkehrsprofil moderner Anwendungen. Das Modell ist auf Nord-Süd-Verkehr optimiert - vom Client Richtung Rechenzentrum oder Internet. Ost-West-Verkehr zwischen Servern muss im schlechtesten Fall über mehrere Ebenen laufen, mit entsprechend variabler erhöhter Latenz. Dazu kommen die bekannten Themen: Spanning Tree blockiert Redundanzpfade, statt sie zu nutzen, und drei Gerätestufen bedeuten drei Stufen an Lizenzen, Wartungsverträgen und Firmware-Pflege. In der OT begegnet einem das 3-Tier-Denken übrigens indirekt wieder: Die Ebenenstruktur des Purdue-Modells lässt sich sauber auf eine hierarchische Topologie abbilden, was ein Grund ist, warum Produktionsnetze oft konservativ hierarchisch gebaut sind.

Collapsed 3-Tier: dasselbe Modell, eine Ebene weniger

Der Collapsed 3-Tier (häufig auch Two-Tier oder Collapsed Core genannt) fasst Core und Distribution auf einem Gerätepaar zusammen. Access-Switches hängen direkt an diesem kombinierten Kern, der Routing, Redundanz und meist auch die zentralen Uplinks Richtung Firewall und WAN übernimmt.

Für kleine und mittlere Standorte ist das in den meisten Fällen die richtige Wahl. Ein eigenständiger Core lohnt sich erst, wenn mehrere Distribution-Blöcke miteinander verbunden werden müssen. Bei einem einzelnen Gebäude mit ein paar hundert Ports gibt es schlicht nichts zu aggregieren, was eine dritte Ebene rechtfertigen würde. Weniger Geräte bedeuten weniger Hops, weniger Fehlkonfigurationsfläche und geringere Kosten.

Die Grenze des Modells ist seine Konzentration: Das Core-Paar ist Single Point of Failure für alles - auch bei redundanter Auslegung bleibt es ein gemeinsamer Fehlerbereich für Software-Bugs und Konfigurationsfehler. Und wer den Standort später deutlich erweitert, stellt fest, dass ein Collapsed Core sich schlecht nach links und rechts erweitern lässt, ohne Adresskonzept und Routing anzufassen. Für OT-Zellen ist das Muster dennoch interessant: Eine Produktionszelle mit eigenem kleinen Collapsed Core hinter einer Zonen-Firewall ist ein wiederholbares, gut prüfbares Baumuster im Sinne von IEC 62443.

Spine-Leaf: die Antwort auf Ost-West-Verkehr

Spine-Leaf (Clos-Fabric) kehrt die Logik um: Jeder Leaf-Switch (L2-Terminierung) ist mit jedem Spine-Switch (Routing fürs Overlay) verbunden, Leafs untereinander und Spines untereinander nicht. Damit liegen zwischen zwei beliebigen Endpunkten immer exakt zwei Hops - Leaf, Spine, Leaf. Die Latenz wird vorhersagbar, und weil das Ganze üblicherweise als Layer-3-Fabric mit ECMP (Equal Cost Multiple Path) läuft, erhalten alle Links gleichzeitig den Datenverkehr, statt dass Spanning Tree die Hälfte davon stilllegt.

Im Rechenzentrum ist Spine-Leaf deshalb seit Jahren der De-facto-Standard. Meist kombiniert mit VXLAN als Datenebene und IS-IS oder BGP EVPN als Control Plane, um Mandanten und Segmente über die Fabric zu ziehen. Die Skalierung ist elegant: mehr Ports heißt mehr Leafs, mehr Bandbreite heißt mehr Spines. Beides ohne Umbau der Grundstruktur, es geht nur ums Erweitern.

Die Kehrseite ist die Betriebs-Komplexität. Eine EVPN-Fabric verlangt Routing-Kompetenz auf jedem Leaf, sauberes Underlay-Design und diszipliniertes Konfigurationsmanagement, realistisch also Automatisierung. Die Verkabelung wächst mit jedem Spine, und für einen Bürostandort mit klassischem Client-Verkehr ist der Aufwand schlicht überdimensioniert. In der OT sehe ich Spine-Leaf praktisch nur im industriellen Rechenzentrum oder auf Site-Ebene, wo Virtualisierung, Historian-Systeme und MES-Workloads liegen; nicht in der Feldebene, wo Ringtopologien und deterministische Protokolle andere Anforderungen stellen.

OpenZiti: Konnektivität als Overlay, Identität statt IP

OpenZiti ist ein quelloffenes Zero-Trust-Overlay-Netzwerk (Apache-2.0-Lizenz, initiiert und gepflegt von NetFoundry). Die Architektur besteht aus einem zentralen Software Defined Controller für Identitäten (ja, auch HA ist möglich), Policies und Netzzustand, einer Mesh-Fabric aus Edge-Routern für den verschlüsselten Transport sowie Tunnelern oder SDKs auf den Endpunkten. Jede Verbindung wird vor dem Aufbau anhand einer kryptographischen X.509-Identität authentifiziert und gegen Policies autorisiert, erst danach existiert überhaupt ein Pfad. Identities sind nicht nur Gateways oder Hosts, es können auch Dienste/Services, Anwendungen oder nur an dem Overlay terminierte Prozesse sein. Es gibt diverse Beispiele für wiederum diverse Programmiersprachen bei NetFoundry. Dienste lauschen auf keinem von außen erreichbaren Port. Localhost /127.0.0.1 oder direkt an der Identität reichen dafür aus. Endpunkte wählen sich ausschließlich ausgehend in die Fabric ein.

Das verschiebt die Segmentierungsfrage grundlegend. Wo klassische Architekturen Zugriff über VLANs, Routing und Firewall-Regeln steuern (also über IP-Adressen und Netzgrenzen), steuert OpenZiti ihn über Identitäten und Dienst-Policies. Ein Dienst ist für alles, was keine autorisierte Identität besitzt, im Netz schlicht nicht sichtbar. Lateral Movement über offene Ports läuft damit ins Leere, und Standort-Kopplungen funktionieren ohne eingehende Firewall-Freischaltungen.

Was das Overlay nicht leistet

Genauso wichtig ist, was OpenZiti nicht ist: Es transportiert keine Pakete zwischen Switchports, es kennt keine Ringredundanz, kein QoS für Echtzeitverkehr, keine Multicast-Verteilung für industrielle Protokolle. Ein SPS-Ring, ein PROFINET-Segment oder die Grundverkabelung eines Gebäudes brauchen weiterhin ein solide gebautes Underlay. Und der Betrieb verlagert sich, statt zu verschwinden: Identitäts-Lebenszyklus, Schlüsselrotation und die Härtung des Controllers sind eigene Aufgaben, die es in einer reinen Switch-Welt so nicht gab. Realistisch ist OpenZiti das Werkzeug für definierte, gerichtete Zugriffe: Fernwartung auf OT-Systeme, Anbindung einzelner Dienste über Standorte hinweg, Ablösung von Sammel-VPNs, Absichern der Level 1-3 im Purdue Modle gegenüber den höheren Leveln. Nicht der Ersatz für die Netztopologie darunter. Dennoch ist zu erwähnen, das Siemens SINEC Secure Connect nichts anderes als NetFoundry OpenZiti ist, optimiert in die Siemensprodukt-Palette integriert. Ist der Maschinenhersteller nicht Siemens, dann kann NetFoundry Openziti optimal im Purdue-Model nach oben hin und auch zwischen den oberen Ebenen absichern und die Fernwartung sicherer gestalten.

Direkter Vergleich entlang der Praxisfragen

Statt einer Feature-Tabelle lohnt der Blick auf die Fragen, die im Projekt tatsächlich entscheiden:

• Verkehrsprofil: Dominiert Nord-Süd-Verkehr (Clients, Büro, Feldebene), reichen 3-Tier oder Collapsed Core. Dominiert Ost-West-Verkehr (Virtualisierung, Storage, containerisierte Workloads), führt an Spine-Leaf kaum ein Weg vorbei. Das Overlay ist vom Verkehrsprofil weitgehend unabhängig, es interessiert sich für Zugriffsbeziehungen, nicht für Bandbreitenmuster.
• Segmentierung: In den hierarchischen Modellen entsteht Segmentierung aus VLANs, Routing-Grenzen und Firewalls: grob-granular, aber robust und auditierbar. Spine-Leaf erlaubt feinere Mandantentrennung in der Fabric. OpenZiti segmentiert am feinsten: pro Identität und Dienst, unabhängig von Adressen, nicht nur auf Netz-Ebene sondern auch bis auf Applikations- oder Prozess-Ebene. Für NIS2- und IEC-62443-Nachweise ist die Kombination stark: Zonen im Underlay, identitätsbasierte Zugriffe im Overlay.
• Ausfallverhalten: 3-Tier und Collapsed Core hängen an First-Hop-Redundanz und Stack- oder MLAG-Konstrukten; Spine-Leaf verteilt Ausfälle per ECMP am gleichmäßigsten. Die OpenZiti-Fabric routet um ausgefallene Edge-Router herum - vorausgesetzt, das Underlay darunter lebt noch.
• Betriebsaufwand und Kompetenzprofil: Collapsed Core ist mit klassischem Switching-Wissen beherrschbar. 3-Tier verlangt sauberes Design, aber keine exotischen Fähigkeiten. Spine-Leaf verlangt Routing-Tiefe und Automatisierung. OpenZiti verlangt ein Umdenken Richtung Identitäts- und Policy-Management. Fachlich näher an PKI und Zugriffsverwaltung als an Switching, auch die "Netzwerkdenke" geht mehr in Richtung Software, Identität.
• Migrierbarkeit: Ein Overlay lässt sich schrittweise über ein Bestandsnetz legen, Dienst für Dienst. Ein Topologiewechsel von 3-Tier zu Spine-Leaf ist dagegen ein Infrastrukturprojekt mit viel mehr Verkabelung, Adresskonzept und Wartungsfenstern.

Einordnung: Was wohin gehört

In der Beratungspraxis läuft es fast immer auf eine Kombination hinaus. Ein typisches Bild für einen Industriestandort: Spine-Leaf im Site-Rechenzentrum für die virtualisierten Workloads, Collapsed Core je Bürogebäude und je Produktionszelle, eine hierarchische Gesamtstruktur, die sich an den Zonen des Purdue-Modells orientiert. Und darüber ein identitätsbasiertes Overlay für genau die Zugriffe, die Zonengrenzen queren müssen: Fernwartung durch Maschinenbauer, MES-Zugriffe aus der IT, standortübergreifende Dienstanbindungen.

Die eigentliche Architekturentscheidung lautet also nicht „3-Tier oder Spine-Leaf oder Overlay", sondern: Welche Topologie trägt welchen Netzbereich, und welche Zugriffsbeziehungen hebe ich bewusst aus der Topologie heraus ins Overlay? Wer diese Trennung sauber zieht, bekommt beides: ein Underlay, das sein Verkehrsprofil beherrscht sowie eine Zugriffssteuerung, die nicht mehr an IP-Adressen und Firewall-Regelwerken klebt. Wer sie vermischt, bekommt die Komplexität beider Welten ohne den Nutzen einer davon.