Multi-Domain Design: Core, Metro, Access sauber trennen

Multi-Domain Design ist in Telco- und großen Enterprise-Netzen der Schlüssel, um Komplexität beherrschbar zu halten, Störungen zu isolieren und Wachstum ohne ständiges Redesign zu ermöglichen. Wenn Core, Metro und Access „ineinanderlaufen“, entstehen typische Probleme: riesige Fehlerdomänen, unkontrollierte Routenverteilung, schwierige Entstörung, inkonsistente QoS-Profile und Redundanz, die auf dem Papier gut aussieht, im Betrieb aber wegen gemeinsamer Abhängigkeiten versagt. Ein sauberes Multi-Domain Design trennt deshalb Ebenen, Rollen und Verantwortlichkeiten klar: Der Core transportiert, die Metro aggregiert und verteilt, der Access schließt an – und jede Domain hat definierte Schnittstellen, klare Failure Models, eigene Skalierungsgrenzen und messbare Qualitätsziele. Dieser Artikel erklärt praxisnah, wie Sie Core, Metro und Access sauber trennen, welche Architekturprinzipien sich bewährt haben und welche Best Practices dazu beitragen, dass Betrieb, Sicherheit und Kapazitätsplanung auch bei Wachstum stabil bleiben.

Warum „Domain-Trennung“ mehr ist als ein hübsches Diagramm

In der Praxis wird Domain-Trennung oft unterschätzt, weil ein Netz zunächst auch ohne klare Grenzen „funktioniert“. Mit Wachstum zeigt sich jedoch schnell der Preis: Änderungen haben unerwartete Nebenwirkungen, ein einzelner Fehler wirkt sich auf große Teile der Infrastruktur aus, und die Fehlersuche dauert länger, weil unklar ist, wo eine Verantwortung beginnt und endet. Multi-Domain Design schafft genau hier Ordnung: Es definiert, welche Aufgaben und welche Komplexität in welcher Ebene erlaubt sind – und welche nicht.

• Fehlerdomänen begrenzen: Störungen bleiben lokal statt global zu wirken.
• Skalierbarkeit erhöhen: Wachstum erfolgt über wiederholbare Bausteine statt ad-hoc Erweiterungen.
• Betrieb vereinfachen: Klare Schnittstellen, standardisierte Konfigurationen und eindeutigere Entstörpfade.
• Sicherheit stärken: Segmentierung und Policy-Enforcement an definierten Punkten statt überall.
• Kapazität planbar machen: Engpässe werden pro Domain gemessen und gezielt ausgebaut.

Definitionen: Was ist Core, was ist Metro, was ist Access?

Die Begriffe sind nicht nur „Ebenen“, sondern Rollen. Ein Gerät kann je nach Netzgröße und Standort mal Edge-nahe Aufgaben übernehmen und mal Transportaufgaben. Für ein sauberes Multi-Domain Design ist daher entscheidend, Rollen pro Domain zu definieren und diese konsequent durchzuhalten.

• Access: Anschluss von Endpunkten (Kunden, Standorte, Funkzellen), erste Aggregation, viele verteilte Knoten, stark feldnah.
• Metro: Regionale Aggregation und Verteilung, Ringe/Cluster, Bündelung vieler Access-Knoten Richtung PoP/Edge/Core.
• Core: Hochperformantes Backbone/Transportnetz zwischen Regionen, PoPs und Rechenzentren, möglichst policy-arm.

Leitprinzipien für saubere Domain-Trennung

Ein nachhaltiges Multi-Domain Design folgt einigen einfachen Prinzipien, die sich über viele Provider- und große Unternehmensnetze hinweg bewährt haben. Diese Prinzipien sind bewusst konservativ: Sie priorisieren Stabilität und Operabilität gegenüber „maximaler Feature-Dichte“.

• Core ist Transport: Im Core möglichst keine kundenspezifischen Policies, keine komplexen Serviceketten, keine unnötigen Spezialfälle.
• Metro ist Aggregation: Metro bündelt, schützt lokal, verteilt Kapazität und liefert robuste Übergaben an PoPs.
• Access ist Anschluss: Access übernimmt Anschlusslogik und Feldrealität, aber möglichst wenig globale Netzlogik.
• Komplexität an die Kante: Services und Policies dort, wo sie benötigt werden (meist an der Provider Edge/Service Edge), nicht im Core.
• Standardisierung schlägt Optimierung: Wiederholbare Templates und klare Rollen reduzieren Fehler und beschleunigen Rollouts.

Domain-Grenzen sauber definieren: Schnittstellen statt Grauzonen

Der häufigste Designfehler ist nicht eine „falsche Technologie“, sondern eine unscharfe Grenze: Metro macht plötzlich Core-Policies, Access verteilt Core-Routen, oder Service-Logik landet aus Bequemlichkeit im Backbone. Ein gutes Multi-Domain Design definiert deshalb klare Schnittstellen: Welche Protokolle werden übergeben? Wo wird geroutet? Wo endet L2? Wo beginnt L3? Welche Monitoring- und OAM-Mechanismen gelten an der Grenze?

• Layering festlegen: L2 möglichst lokal begrenzen, L3 früh einsetzen, um Fehlerdomänen zu verkleinern.
• Routing-Übergaben: Klar entscheiden, wo Kundenrouten enden und wo Transport-Routing beginnt.
• QoS-Übergabe: Markierungen und Klassenmodelle an Domain-Grenzen konsistent definieren und validieren.
• Security-Zonen: Policy-Enforcement-Punkte definieren (z. B. Edge/Service-Knoten), nicht „überall ein bisschen“.

Routing-Design im Multi-Domain Modell: IGP im Core, kontrollierte Distribution in Metro/Edge

Routing ist eine der wichtigsten Stellschrauben für Domain-Trennung. Ein bewährtes Muster ist: Das Core-IGP trägt Infrastruktur (Loopbacks, Transportlinks), während Service- und Kundenrouten über BGP kontrolliert verteilt werden. Metro kann dabei je nach Architektur als reine Transporterweiterung des Core fungieren oder als eigene Domäne mit klarer Übergabe. Entscheidend ist, Route-Explosionen zu verhindern und Policies dort zu halten, wo sie hingehören.

• Core-IGP schlank halten: Infrastruktur-only, konsistente Metriken, schnelle Konvergenz, keine Service-Routen.
• BGP für Services: Kunden-/VPN-/Interconnect-Routen kontrolliert, mit Filtern und Limits verteilen.
• Route-Aggregation: Wo möglich, zusammenfassen, um Skalierung und Stabilität zu verbessern.
• Schutzmechanismen: Prefix-Limits und Default-Deny-Ansätze verhindern Route-Leaks und „Tabellenexplosionen“.

Topologie-Design pro Domain: Passende Strukturen statt Einheitsbrei

Core, Metro und Access haben unterschiedliche Anforderungen, daher sind unterschiedliche Topologien sinnvoll. Im Core dominieren vermaschte Strukturen mit hoher Redundanz und ECMP-Fähigkeit. In der Metro sind Ringe und Ring-of-Rings verbreitet, weil sie regionale Resilienz kosteneffizient liefern. Im Access sind Stern- und Baumstrukturen üblich, weil viele Endpunkte zu Aggregationspunkten geführt werden müssen. Multi-Domain Design bedeutet, diese Topologien zu kombinieren – mit klaren Übergaben.

• Core: Partial Mesh, hohe Bandbreite, kurze Pfade zwischen Hotspots, konsequente Diversität.
• Metro: Regionale Ringe/Cluster, modulare Ringgrößen, PoP-zentrierte Übergaben.
• Access: Stern/Tree, feldnah, kosteneffizient, mit klarer Aggregation und begrenzten Fehlerdomänen.

Resilienz richtig verteilen: Failover lokal, Stabilität global

Eine saubere Domain-Trennung hilft, Resilienz dort zu verankern, wo sie am effizientesten wirkt. Nicht jeder Ausfall muss „im Core“ gelöst werden. Viele Störungen sollten bereits in Access oder Metro abgefangen werden, damit der Core nicht permanent rekonvergiert. Gleichzeitig müssen große Ausfallklassen (PoP-/Region-/Trassenereignisse) im Core-Design berücksichtigt werden. Zentral ist außerdem N-1-Headroom: Redundanz ohne Kapazitätsreserve führt bei Failover zu Überlast und sekundären Störungen.

• Access-Resilienz: Segmentierung und lokale Redundanz (z. B. Dual-Uplinks) begrenzen Kundenausfälle.
• Metro-Resilienz: Ringschutz und Dual-Homing an PoPs fangen regionale Link-Ausfälle ab.
• Core-Resilienz: Diverse Pfade, PoP-Redundanz und stabile Konvergenz für größere Ereignisse.
• Kapazitätsreserve: N-1 (oder N-2) planen, damit Failover nicht automatisch Congestion erzeugt.

QoS end-to-end: Klassenmodelle an Domain-Grenzen festnageln

Ein häufiges Problem in wachsenden Netzen ist inkonsistentes QoS: Im Access wird markiert, in der Metro wird überschrieben, im Core wird nicht korrekt gequeuet – und am Ende sind SLAs unvorhersehbar. Multi-Domain Design löst das, indem es ein einheitliches Klassenmodell definiert und an jeder Domain-Grenze verbindliche Regeln festlegt. Wichtig ist, dass QoS operativ messbar ist: Queue-Drops, Latenz, Jitter und Paketverlust müssen pro Klasse überwacht werden.

• Wenige Klassen: Ein überschaubares Modell ist im Betrieb zuverlässiger als zehn Spezialklassen.
• Markierung an der Quelle: Klassifizieren so früh wie möglich, Regeln klar dokumentieren.
• Engpasspunkte kennen: Shaping und Queueing an Uplinks, PoP-Übergaben und Aggregationspunkten.
• Messbarkeit: SLA-KPIs pro Klasse überwachen, nicht nur Interface-Auslastung.

Security und Kundentrennung: Policies an die richtigen Stellen

Security wird in Multi-Domain Designs oft dadurch besser, dass sie weniger „verteilt“ ist. Statt an vielen Stellen unterschiedliche Regeln zu pflegen, werden Policy-Enforcement-Punkte definiert: typischerweise an Provider Edge/Service Edge, an zentralen Security-Plattformen oder an klaren Übergaben zu Partnern. Access und Metro sollten primär grundlegende Härtung, Managementschutz und Segmentierung tragen, aber nicht mit komplexer, kundenspezifischer Policy-Logik überladen werden.

• Mandantenfähigkeit: Trennung über VRFs, Segmente und definierte Übergaben zu Shared Services.
• Management-Segmentierung: Separates Managementnetz, RBAC/MFA, Audit-Logging, harte Baselines.
• Control-Plane-Schutz: Schutzmechanismen gegen Flooding, Scans und Routing-Angriffe.
• Policy-Standards: Wenige, konsistente Muster reduzieren Fehlkonfigurationen.

Wachstum planen: Baukastensysteme statt Sonderlösungen

Multi-Domain Design ist besonders wertvoll, wenn ein Netz wächst. Statt jedes neue Gebiet oder jeden neuen PoP individuell zu konstruieren, arbeiten Provider und große IT-Organisationen mit Blueprints: standardisierte PoP-Klassen, Ring-Templates, Access-Aggregationsprofile und definierte Upgradepfade. Das reduziert Time-to-Deploy und verbessert Qualität, weil Änderungen wiederholbar und testbar werden.

• PoP-Klassen: Small/Medium/Large PoP mit festen Portprofilen, Redundanzregeln und Monitoring-Baselines.
• Metro-Templates: Standard-Ringgrößen, definierte Schutzmechanismen, klare Uplink-Strategie.
• Access-Profile: Technologietypen (FTTH/HFC/xDSL/Mobile) mit standardisierten Aggregations- und QoS-Regeln.
• Upgrade-Schwellen: Messbare Trigger, wann Links, Linecards, zusätzliche Ringe oder zusätzliche PoPs nötig sind.

Observability und Betrieb: Domänenübergreifende Sicht ohne Chaos

Eine saubere Trennung darf nicht zu Silos führen, in denen niemand End-to-End-Probleme versteht. Daher braucht ein Multi-Domain Design eine Observability-Strategie, die Domänen sauber abbildet und dennoch korrelierbar bleibt. Das bedeutet: standardisierte Telemetrie, zentralisierte Logs, Flow-Daten zur Traffic-Analyse und eine Ereigniskorrelation, die Changes, Link-Events und Traffic-Anomalien zusammenführt. Im Betrieb ist außerdem wichtig, Runbooks entlang der Domänen zu strukturieren: Erst lokal prüfen, dann zur nächsthöheren Ebene eskalieren.

• Domain-KPIs: Core (Konvergenz, Backbone-Links), Metro (Ring-Events, Aggregationsengpässe), Access (Signal-/Leitungsparameter, Uplinks).
• Flow-Daten: Hotspots und Heavy-Flows erkennen, Kapazitätsplanung datenbasiert machen.
• Event-Korrelation: Link-Flaps, Wartungsarbeiten, Routing-Events und Kundentickets zeitlich verbinden.
• Runbooks: Standardpfade für Entstörung, klar nach Domain-Grenzen strukturiert.

Typische Fehler im Multi-Domain Design und wie Sie sie vermeiden

Viele Netze scheitern nicht an der Idee der Domain-Trennung, sondern an inkonsequenter Umsetzung. Häufig werden Ausnahmen „kurzfristig“ eingeführt und bleiben dauerhaft. Dadurch verschwimmen Grenzen, und die Vorteile der Domain-Trennung gehen verloren. Ein robustes Design definiert daher Regeln, die nur mit klarer Begründung und dokumentiertem Risiko gebrochen werden dürfen.

• Service-Logik im Core: Policies, NAT oder kundenspezifische Sonderfälle gehören an die Edge, nicht ins Backbone.
• Zu große L2-Domänen: Broadcast- und Fehlerdomänen wachsen über Metro/Access hinweg unkontrolliert.
• Unkontrollierte Route-Distribution: Access/Metro „lernen“ zu viele Routen, was Stabilität und Betrieb erschwert.
• Redundanz ohne Diversität: Zwei Links, gleiche Trasse; Ausfälle korrelieren.
• Kein Headroom: Failover führt zu Congestion, obwohl das Netz formal redundant ist.
• Inkonsistentes QoS: Klassenmodelle und Markierungen variieren pro Domain, SLAs werden unvorhersehbar.

Operative Checkliste: Core, Metro, Access sauber trennen

Eine kompakte Checkliste hilft, Multi-Domain Design im Alltag durchzusetzen – bei Neubau, Audit oder Modernisierung. Sie fokussiert die Punkte, die Stabilität und Skalierung am stärksten beeinflussen.

• Sind Rollen und Verantwortlichkeiten pro Domain klar definiert (Core=Transport, Metro=Aggregation, Access=Anschluss)?
• Sind Domain-Grenzen technisch sauber umgesetzt (Layering, Routing-Übergaben, QoS-Übergaben, Security-Zonen)?
• Ist das Core-IGP auf Infrastruktur begrenzt und sind Service-Routen kontrolliert (BGP, Filter, Prefix-Limits)?
• Sind Fehlerdomänen begrenzt (kleine Ringe, modulare Metro-Strukturen, L2 nur lokal, L3 als Standard)?
• Ist Resilienz pro Domain geplant (Ringschutz in Metro, Dual-Uplinks im Access, diverse Pfade im Core) und gibt es N-1-Headroom?
• Ist QoS end-to-end konsistent und werden SLA-KPIs pro Klasse und pro Domain gemessen?
• Sind Standard-Blueprints vorhanden (PoP-Klassen, Metro-Templates, Access-Profile) inklusive Upgrade-Schwellen?
• Ist Observability domänenübergreifend umgesetzt (Telemetrie, Flow-Daten, Logging, Event-Korrelation) und sind Runbooks domänenspezifisch strukturiert?

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.