Network Architectures Compared: 3-Tier, Collapsed Core, Spine-Leaf and OpenZiti Overlay

First things first: Underlay is not the same as Overlay

Before placing the four candidates side by side, one thing needs to be clear: 3-Tier, Collapsed Core and Spine-Leaf describe physical topologies – in other words, how switches are cabled, where routing happens, where switching happens, and how redundancy is created. An OpenZiti overlay, by contrast, describes how connections are logically established, regardless of which cables lie beneath them. The overlay does not replace the underlay; it builds on top of it. Anyone treating the four terms as equal alternatives is comparing a foundation with a front door. Nevertheless, the comparison belongs in this article, because in practice the approaches do indeed compete for the same budget and the same question: how do I achieve segmentation, resilience and controlled access?

The classic 3-Tier architecture

The three-tier model consisting of Access, Distribution and Core layers originates from the campus world of the late 1990s and, to this day, remains the actual state in many organically grown environments. Access switches connect end devices (switching), the distribution layer aggregates buildings or floors and typically terminates the Layer 3 boundaries (routing and ACLs), while the core transports traffic quickly and, ideally, as "dumbly" as possible between the distribution blocks (L3 switching).

The strengths of the model lie in its scalability outward and in the clear division of responsibilities per layer: access policies belong at the access layer, routing and first-hop redundancy at the distribution layer, while the core remains free of filtering logic. For large campus environments with many buildings, thousands of ports and heterogeneous cabling, this remains a viable pattern.

The weaknesses become apparent with the traffic profile of modern applications. The model is optimised for north-south traffic – from the client towards the data centre or the internet. East-west traffic between servers may, in the worst case, have to traverse several layers, resulting in correspondingly variable and increased latency. Then there are the well-known issues: Spanning Tree blocks redundant paths instead of using them, and three device tiers mean three tiers of licences, maintenance contracts and firmware upkeep. In OT, the 3-Tier way of thinking incidentally resurfaces indirectly: the layered structure of the Purdue model maps cleanly onto a hierarchical topology, which is one reason why production networks are often built conservatively along hierarchical lines.

Collapsed 3-Tier: the same model, one layer fewer

The Collapsed 3-Tier (often also called Two-Tier or Collapsed Core) combines the Core and Distribution layers on a single pair of devices. Access switches connect directly to this combined core, which handles routing, redundancy and, usually, the central uplinks towards the firewall and WAN.

For small and medium-sized sites, this is in most cases the right choice. A dedicated core only becomes worthwhile once several distribution blocks need to be connected to one another. For a single building with a few hundred ports, there is simply nothing to aggregate that would justify a third layer. Fewer devices mean fewer hops, less surface area for misconfiguration, and lower costs.

The limitation of the model lies in its concentration: the core pair is a single point of failure for everything – even with redundant design, it remains a shared failure domain for software bugs and configuration errors. And anyone who later significantly expands the site will find that a Collapsed Core is difficult to extend in either direction without touching the addressing scheme and routing. For OT cells, however, the pattern is still interesting: a production cell with its own small collapsed core behind a zone firewall is a repeatable, readily auditable design pattern in the spirit of IEC 62443.

Spine-Leaf: the answer to east-west traffic

Spine-Leaf (Clos fabric) reverses the logic: every leaf switch (Layer 2 termination) is connected to every spine switch (routing for the overlay), while leafs are not connected to one another, nor are spines. This means that between any two endpoints there are always exactly two hops – leaf, spine, leaf. Latency becomes predictable, and because the whole setup usually runs as a Layer 3 fabric with ECMP (Equal Cost Multiple Path), all links carry traffic simultaneously instead of Spanning Tree shutting down half of them.

In the data centre, Spine-Leaf has therefore been the de facto standard for years – usually combined with VXLAN as the data plane and IS-IS or BGP EVPN as the control plane, to extend tenants and segments across the fabric. Scaling is elegant: more ports means more leafs, more bandwidth means more spines. Both without restructuring the basic architecture – it is simply a matter of extending it.

The downside is operational complexity. An EVPN fabric demands routing expertise on every leaf, clean underlay design and disciplined configuration management – realistically, therefore, automation. Cabling grows with every spine, and for an office site with typical client traffic, the effort is simply over-engineered. In OT, I see Spine-Leaf practically only in the industrial data centre or at site level, where virtualisation, historian systems and MES workloads reside – not at the field level, where ring topologies and deterministic protocols impose different requirements.

OpenZiti: connectivity as an overlay, identity instead of IP

OpenZiti is an open-source zero-trust overlay network (Apache 2.0 licence, initiated and maintained by NetFoundry). The architecture consists of a central Software Defined Controller for identities (yes, HA is also possible), policies and network state, a mesh fabric of edge routers for encrypted transport, and tunnellers or SDKs on the endpoints. Every connection is authenticated against a cryptographic X.509 identity before it is established and authorised against policies – only afterwards does a path even exist. Identities are not just gateways or hosts; they can also be services, applications, or processes terminated solely at the overlay. NetFoundry provides a range of examples in a range of programming languages. Services do not listen on any externally reachable port; localhost/127.0.0.1 or a direct binding to the identity is sufficient. Endpoints dial into the fabric exclusively on an outbound basis.

This fundamentally shifts the question of segmentation. Where classic architectures control access via VLANs, routing and firewall rules (that is, via IP addresses and network boundaries), OpenZiti controls it via identities and service policies. A service is simply invisible on the network to anything without an authorised identity. Lateral movement via open ports is thus rendered moot, and site-to-site coupling works without inbound firewall openings.

What the overlay does not do

It is equally important to be clear about what OpenZiti is not: it does not transport packets between switch ports, it has no concept of ring redundancy, no QoS for real-time traffic, no multicast distribution for industrial protocols. A PLC ring, a PROFINET segment or a building's basic cabling still require a solidly built underlay. And operations do not disappear, they shift: identity lifecycle, key rotation and controller hardening are separate tasks that simply did not exist in a pure switching world. Realistically, OpenZiti is the tool for defined, directed access: remote maintenance of OT systems, connecting individual services across sites, replacing bulk VPNs, securing Levels 1–3 of the Purdue model against the higher levels – not a replacement for the network topology beneath it. It is nonetheless worth mentioning that Siemens SINEC Secure Connect is nothing other than NetFoundry OpenZiti, optimised and integrated into the Siemens product range. If the machine manufacturer is not Siemens, NetFoundry OpenZiti can still secure the upper direction of the Purdue model, as well as between the upper levels, and make remote maintenance more secure.

Direct comparison along practical questions

Rather than a feature table, it is worth looking at the questions that actually decide the matter in a project:

• Traffic profile: If north-south traffic dominates (clients, office, field level), 3-Tier or Collapsed Core will suffice. If east-west traffic dominates (virtualisation, storage, containerised workloads), there is barely any way around Spine-Leaf. The overlay is largely independent of the traffic profile, as it is concerned with access relationships, not bandwidth patterns.
• Segmentation: In the hierarchical models, segmentation arises from VLANs, routing boundaries and firewalls: coarse-grained, but robust and auditable. Spine-Leaf allows finer tenant separation within the fabric. OpenZiti segments most finely: per identity and service, independent of addresses, not only at the network level but down to the application or process level. For NIS2 and IEC 62443 evidence, the combination is powerful: zones in the underlay, identity-based access in the overlay.
• Failure behaviour: 3-Tier and Collapsed Core depend on first-hop redundancy and stack or MLAG constructs; Spine-Leaf distributes failures most evenly via ECMP. The OpenZiti fabric routes around failed edge routers – provided the underlay beneath it is still alive.
• Operational effort and skill profile: Collapsed Core can be managed with classic switching knowledge. 3-Tier requires clean design but no exotic skills. Spine-Leaf requires deep routing expertise and automation. OpenZiti requires a shift in thinking towards identity and policy management – conceptually closer to PKI and access management than to switching, with the "network mindset" moving further towards software and identity.
• Migratability: An overlay can be layered onto an existing network step by step, service by service. A topology change from 3-Tier to Spine-Leaf, on the other hand, is an infrastructure project involving far more cabling, addressing scheme work and maintenance windows.

Putting it into context: what belongs where

In consulting practice, it almost always comes down to a combination. A typical picture for an industrial site: spine-leaf in the site data centre for virtualised workloads, collapsed core for each office building and each production cell, and an overall hierarchical structure oriented around the zones of the Purdue model. And above that, an identity-based overlay for precisely those access relationships that need to cross zone boundaries: remote maintenance by machine builders, MES access from IT, and cross-site service connections.

The real architectural decision, then, is not “3-tier or spine-leaf or overlay”, but rather: which topology carries which network area, and which access relationships do I deliberately lift out of the topology and into the overlay? Whoever draws this distinction cleanly gets both: an underlay that has its traffic profile under control, and access control that is no longer tied to IP addresses and firewall rule sets. Whoever mixes them up gets the complexity of both worlds without the benefit of either.