February 15, 2026

Fault Domains designen: Core/Edge/Access aus OSI-Perspektive

Fault Domains designen ist eine der wirksamsten Maßnahmen, um Ausfälle in Unternehmensnetzwerken vorhersehbar zu begrenzen und die Wiederherstellung zu beschleunigen. Gemeint ist die bewusste Einteilung einer Infrastruktur in Bereiche, deren Fehler sich möglichst nicht gegenseitig „anstecken“: ein defekter Access-Switch soll nicht gleich den Core beeinträchtigen, ein Routing-Bug im Edge nicht das gesamte Rechenzentrum lahmlegen. Aus OSI-Perspektive wird dabei klar, dass Fault Domains nicht nur „physische“ Grenzen (Layer 1) haben, sondern auch logische und operative Grenzen: Layer-2-Broadcast-Domains, Layer-3-Routing-Domains, Security-Zonen, Control-Plane-Abhängigkeiten oder gemeinsame Management-Pfade. Genau diese Mehrdimensionalität macht die Gestaltung von Core/Edge/Access anspruchsvoll – und gleichzeitig äußerst lohnend. Wer Fault Domains sauber definiert, gewinnt bessere Fehlereingrenzung (Blast Radius), stabilere Wartungsfenster, klarere Ownership und vor allem: reproduzierbare Betriebsentscheidungen. In diesem Artikel wird gezeigt, wie du Core/Edge/Access als Architekturprinzip mit dem OSI-Modell verknüpfst, welche Fault-Domain-Typen in der Praxis relevant sind und wie du Design und Betrieb so ausrichtest, dass ein einzelner Fehler nicht zum systemweiten Incident eskaliert.

Table of Contents

Begriffe sauber trennen: Fault Domain, Failure Domain und Blast Radius

Im Betrieb werden die Begriffe oft vermischt. Für ein sauberes Design lohnt sich eine klare Sprache:

Fault Domain: Ein bewusst definierter Bereich, in dem Fehler auftreten dürfen, ohne außerhalb dieses Bereichs spürbar zu werden. Das ist ein Designziel.
Failure Domain: Der Bereich, der bei einem konkreten Fehler tatsächlich ausfällt. Das ist die beobachtete Realität.
Blast Radius: Die Auswirkungsfläche eines Fehlers – technisch und organisatorisch (Kunden, Standorte, Services, Teams).

Gutes Engineering sorgt dafür, dass Fault Domain und Failure Domain möglichst deckungsgleich sind. Wenn ein einzelner Link-Flap in Access plötzlich Core-Routing destabilisiert, stimmt die Domain-Grenze nicht oder es existieren versteckte Kopplungen (z. B. gemeinsame Control Plane, identische Bug-Trigger, zentrales DHCP, ein gemeinsamer TACACS/RADIUS-Pfad).

Core/Edge/Access als Betriebsmodell – und warum OSI dabei hilft

Core/Edge/Access beschreibt nicht nur Topologie, sondern auch Aufgaben und Failure Modes. Aus OSI-Sicht lassen sich die Ebenen sinnvoll „profilieren“:

Access: Nähe zu Endgeräten, hohes Veränderungstempo, viele Layer-2/Layer-3-Übergänge, häufige Policy-Anforderungen (z. B. 802.1X, VLANs, PoE). Fehler sind oft lokal, aber zahlreich.
Edge: Übergang zu externen Netzen oder Zonen (Internet, Partner, Cloud, WAN), Fokus auf Policy, Security und Routing-Interaktionen (BGP, NAT, Firewall, WAF/CDN in L7-Nähe). Fehler können große Reichweite haben, wenn Domains nicht sauber getrennt sind.
Core: Hochverfügbarkeit, minimaler Funktionsumfang, stabile Underlay-Services, deterministische L3-Weiterleitung, klare Redundanzpfade. Fehler sind seltener, aber sehr teuer.

Das OSI-Modell zwingt dazu, nicht nur Kabel und Switches zu betrachten, sondern auch Protokolle, Zustände und Abhängigkeiten pro Schicht. Besonders wichtig: Viele „Core“-Incidents beginnen nicht im Core, sondern werden aus Access oder Edge in den Core hinein propagiert – über L2-Stürme, über instabile Routing-Adjacencies oder über Management-Abhängigkeiten.

OSI-basierte Fault-Domain-Typen, die du im Design explizit brauchst

In der Praxis reichen „Rack“, „Switch“ oder „Standort“ als Fault Domains nicht aus. Du brauchst Fault Domains entlang mehrerer Achsen – und zwar bewusst dokumentiert.

Physische Fault Domains (Layer 1)

Trassen und Patchfelder: Gemeinsame Kabelwege, Patchpanel, MPO-Polarity oder Cross-Connects können mehrere Links gleichzeitig treffen.
Strom und Kühlung: PDU/USV-Redundanz, gemeinsame Stromkreise, Hot/Cold-Aisle-Fehler.
Optik-/Transceiver-Klassen: Gleiche Module mit identischer Firmware können gleichartige Ausfälle triggern.

Ein klassisches Anti-Pattern ist „Redundanz auf dem Papier“: zwei Links, aber beide im selben Kabelkanal oder am selben Patchpanel. Fault Domains müssen den realen physischen Aufbau spiegeln.

Layer-2-Fault Domains (Broadcast und Control Plane)

Broadcast-Domains: VLAN-Ausdehnung, ARP/ND-Stürme, unbekanntes Unicast, Multicast-Flooding.
Loop-Domains: STP-Regionen, MLAG-Fehlkonfigurationen, LACP-Interoperabilität.
Security Domains: 802.1X-Policies, Port-Security, DHCP Snooping/DAI/IP Source Guard.

Für Fault Domains gilt: Große L2-Flächen sind riskant. Wo L2 unvermeidlich ist (z. B. bestimmte Legacy-Workloads), sollten Grenzen, Rate Limits und klare Recovery-Mechanismen (z. B. BPDU Guard, Storm Control, Loop Protection) Teil des Designs sein.

Layer-3-Fault Domains (Routing und Underlay/Overlay)

Routing-Domains: OSPF/IS-IS-Areas, BGP-Policy-Grenzen, VRFs, Summarization-Boundaries.
Underlay vs. Overlay: VXLAN/EVPN, GRE, MPLS – Fehlersuche und Blast Radius unterscheiden sich deutlich.
Convergence-Domains: Wie weit wirkt eine Flap- oder Convergence-Welle? Welche Timer und Dampening-Strategien existieren?

Ein starker Ansatz ist „Containment durch Aggregation“: Präfix-Summarization und klare Area-/Region-Grenzen reduzieren, wie weit Routing-Churn sichtbar wird.

Transport- und Sitzungs-Fault Domains (Layer 4/5)

NAT- und Connection-Tracking-Domains: Stateful Devices können bei Exhaustion oder Failover große Teile des Traffics beeinflussen.
Load-Balancer-Domains: L4/L7 Load Balancing, Health-Checks, Stickiness und Failover-Verhalten.
Timeout-Domains: Idle-Timeouts, Keepalives, Retransmission-Verhalten – häufige Ursache für „es geht manchmal“.

Auch wenn Core/Access „Netzwerk“ klingt: L4/L5-Verhalten entscheidet oft, ob ein Fehler lokal bleibt oder breit eskaliert.

Presentation/Application-Fault Domains (Layer 6/7)

TLS-Zonen: Zertifikate, mTLS im Service Mesh, Cipher/Versionen, Offloading, Inspektion.
API-Gateway- und WAF-Domains: Rate Limits, Bot-Mitigation, Header-Manipulation, Routing-Regeln.
DNS-Domains: Resolver-Ketten, Authoritative-Provider, Caching und TTL-Strategien.

Viele „Netzwerk“-Incidents sind in Wirklichkeit L7-Effekte: DNS-Misconfiguration, Zertifikatsablauf, WAF-Regeländerung oder Gateway-Routing. Fault Domains sollten daher auch L7-Kontrollpunkte als eigenständige Domains behandeln.

Core designen: Stabilität durch minimale Komplexität

Der Core ist keine Spielwiese für Feature-Experimente. Das Ziel lautet: deterministische Weiterleitung, klare Redundanz, stabile Control Plane. Fault Domains im Core sind vor allem darauf ausgerichtet, dass ein einzelnes Gerät oder ein einzelner Link nicht die gesamte Domäne destabilisiert.

Einheitliches Underlay: Wenige Protokolle, konsistente Konfiguration, klare Timer-Philosophie.
Redundanz ohne gemeinsame Abhängigkeiten: Getrennte Strompfade, getrennte Trassen, getrennte Chassis.
Strikte L2-Reduktion: Im Core möglichst kein Layer 2, keine großen Broadcast-Flächen.
Control-Plane-Schutz: CoPP/Policer, BGP/IGP-Protection, saubere Prefix-Filter.

Ein praxistaugliches Leitprinzip: Jede zusätzliche Funktion im Core muss einen messbaren Reliability-Nutzen haben. Alles andere gehört in Edge oder Access, wo der Blast Radius kleiner und das Change-Tempo höher sein darf.

Edge designen: Policy und Exposition kontrollieren, ohne den Core zu gefährden

Edge ist die Zone, in der sich Fehler „von außen“ einschleichen und „von innen“ nach außen wirken können. Hier entscheidet sich, ob ein Problem eingedämmt wird oder bis in den Core durchschlägt.

Policy-Grenzen: NAT, Firewalling, BGP-Policies, Route Filtering und klare Default-Deny-Prinzipien.
Route-Leak-Containment: Max-Prefix, Prefix-Listen, Communities, RPKI-basierte Validierung, wo passend.
Anycast und Multi-Region: Fault Domains pro PoP/Region definieren, nicht nur pro Service.
Beobachtbarkeit: Flow-Daten (NetFlow/sFlow/IPFIX), BGP-Session-Monitoring, TLS-Handshake-Metriken.

Ein wiederkehrendes Anti-Pattern ist eine „Edge als monolithischer Block“: ein zentrales NAT- oder Firewall-Cluster für alles. Besser ist eine segmentierte Edge, die Fault Domains nach Mandanten, Regionen oder kritischen Services trennt.

Access designen: Viele kleine Domains statt weniger großer

Access ist dort, wo Fehler häufig entstehen: fehlerhafte Endgeräte, falsches VLAN, Loop durch ein unmanaged Switch, PoE-Überlast, falsch gesetzte 802.1X-Policies. Das Ziel ist, diese Fehler lokal zu halten und schnell zu erkennen.

Kleine Broadcast-Domains: VLANs nicht unnötig ausdehnen, klare Segmentierung, wo möglich L3 näher an den Rand.
Schutzmechanismen aktivieren: BPDU Guard, Root Guard, Storm Control, DHCP Snooping/DAI/IP Source Guard.
Identische Template-Logik: Standardisierte Port-Profile reduzieren Konfigurationsdrift.
Per-Access-Block Ownership: Betriebsverantwortung und Eskalationswege pro Domain klar definieren.

Ein gutes Access-Fault-Domain-Design ist selten „ein Gerät“. Häufig ist es ein definierter „Access Block“: ein Set aus Access-Switch(es), Uplinks, Patchfeldern und den zugehörigen VLAN/VRF-Policies.

Fault Domains messen: Verfügbarkeit und Abhängigkeiten quantifizierbar machen

Damit Fault Domains nicht nur auf dem Papier existieren, müssen sie messbar sein. Eine einfache, aber hilfreiche Kennzahl ist die Verfügbarkeit zusammengesetzter Pfade. Wenn ein Service über mehrere unabhängige Komponenten läuft, multiplizieren sich die Verfügbarkeiten (vereinfacht, bei Unabhängigkeit).

$A = A_Core \times A_Edge \times A_Access$

Diese Darstellung zwingt zu zwei Fragen: Welche Komponenten sind wirklich unabhängig? Und wo existieren versteckte gemeinsame Abhängigkeiten (Shared Fate), die die Annahme der Unabhängigkeit zerstören? Genau dort entstehen große Failure Domains.

Shared Fate identifizieren: Die häufigsten versteckten Kopplungen

Viele Designs scheitern nicht an fehlender Redundanz, sondern an gemeinsamem Schicksal: Zwei Pfade wirken redundant, teilen aber eine zentrale Ressource.

Gemeinsames Management-Netz: Wenn „Out-of-Band“ doch über denselben Core läuft oder DNS/AAA nur zentral existiert.
Gemeinsame Control Plane: Ein Routing-Bug, der beide Geräte gleichermaßen trifft (gleiche Software-Version, gleiche Konfiguration).
Gemeinsame Strom- oder Trassenführung: Zwei Uplinks im selben Kabelkanal oder am selben Patchpanel.
Zentrale Shared Services: DHCP, DNS, NTP, PKI – wenn ohne regionale Isolation betrieben.
Identisches Failure-Verhalten: Beide Load-Balancer mit gleichem Timeout, gleicher Session-Persistence, gleichem Health-Check.

Fault Domains designen heißt, diese Kopplungen zu finden und zu entkoppeln – entweder durch technische Trennung (separate Instanzen) oder durch operative Regeln (Change-Fenster, Staggered Rollouts, Version-Diversität).

Operationalisierung: Fault Domains in Change Management und Incident Response verankern

Ein Fault-Domain-Design ist erst dann wertvoll, wenn es im Tagesgeschäft genutzt wird. Dazu gehören klare Regeln für Änderungen, Rollouts und Reaktion auf Störungen.

Change-Scopes nach Domain: Änderungen immer domainweise ausrollen (Access Block, Edge Cluster, Core Pair), nicht „alles auf einmal“.
Staged Rollouts: Canary-Domain definieren, dann schrittweise erweitern, mit Abbruchkriterien.
Domain-basierte On-Call-Runbooks: Checks und Eskalationen pro Domain standardisieren.
Fault-Domain-Tags in Telemetrie: Logs/Metriken/Traces mit Domain-Attributen versehen (z. B. site, pod, rack, vrf, edge-cluster).

So wird aus der Architektur eine steuerbare Betriebsstruktur: Bei einem Incident lässt sich schneller eingrenzen, welcher Bereich betroffen ist, und bei einem Change lässt sich der Blast Radius bewusst klein halten.

Designmuster für Enterprise: Praktische Templates für Core/Edge/Access

Die folgenden Muster sind in großen Umgebungen besonders nützlich, weil sie Fault Domains wiederholbar machen.

Access-Block-Modell mit klarer L3-Grenze

Definiere pro Access Block feste Uplinks, feste VLAN/VRF-Zuordnung und klare Policy-Profile.
Setze L3 so nahe wie möglich an den Rand, um Broadcast-Domains klein zu halten.
Erzwinge Schutzmechanismen (Storm Control, BPDU Guard) als Standard.

Segmentierte Edge nach Service-Kritikalität

Trenne Edge-Funktionen nach Kritikalität (z. B. „Customer Traffic“, „Admin/Backoffice“, „Partner“).
Vermeide zentrale Single-Clusters für NAT/Firewall, wenn der Blast Radius zu groß ist.
Nutze Policy-Guardrails (Max-Prefix, Filter, Rate Limits) pro Domain.

Core als „Feature-Minimum“ mit starker Observability

Begrenze Protokollvielfalt, standardisiere Timer, halte Konfigurationsdrift klein.
Setze auf vorhersehbare Redundanz (ECMP, redundante Pfade, klare Failure-Reaktionen).
Überwache Control-Plane-Health (CPU, Queues, Routing-Adjacencies, Drops) und nicht nur Interface-Status.

Outbound-Quellen für Standards und vertiefende Praxis

Checkliste: Fault Domains aus OSI-Perspektive verifizieren

Layer 1: Sind redundante Pfade physisch getrennt (Trasse, Patchpanel, Strom)?
Layer 2: Sind Broadcast- und Loop-Domains klein und mit Schutzmechanismen abgesichert?
Layer 3: Gibt es Summarization- und Policy-Grenzen, die Routing-Churn begrenzen?
Layer 4/5: Sind stateful Komponenten (NAT, LB) domainweise isoliert und beobachtbar?
Layer 6/7: Sind TLS, DNS, WAF/Gateway als eigene Domains modelliert, inklusive Rotation und Policies?
Shared Fate: Welche zentralen Dienste können mehrere Domains gleichzeitig treffen?
Operationalisierung: Gibt es domainbasierte Rollouts, Runbooks, Tags und klare Ownership?

Typische Anti-Patterns – und wie du sie entschärfst

Zum Abschluss dieses Themenblocks sind Anti-Patterns hilfreich, weil sie in Enterprise-Umgebungen besonders häufig sind und oft erst bei großen Incidents auffallen.

„Eine große L2-Wolke“: Wird durch L3-näher-am-Rand, EVPN/VXLAN mit sauberer Steuerung oder konsequente Segmentierung entschärft.
Zentrale Edge als Single Failure Domain: Aufbrechen in mehrere Edge-Domains nach Region, Mandant oder Kritikalität.
Redundanz ohne Diversität: Gleiche Firmware, gleiche Konfiguration, gleiche Bug-Trigger – besser gestaffelte Updates und klare Canary-Domains.
Management-Pfad als versteckte Abhängigkeit: Out-of-Band wirklich unabhängig betreiben, inklusive DNS/AAA/NTP-Redundanz.
Monitoring ohne Domain-Kontext: Telemetrie ohne Domain-Tags erschwert RCA; Domain-Attribute sind Pflicht.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.