Site icon bintorosoft.com

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

Red Snapper

An engineer works in a dim server room, catering to a network, computer and data center with female IT aid.

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.

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.

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“.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version