Site icon bintorosoft.com

DC Interconnect Design: L2 vs. L3, EVPN DCI und Failure Scenarios

Red Snapper

Interior of server with wires blue close up in data center

DC Interconnect Design (DCI) entscheidet in modernen Rechenzentrumslandschaften darüber, ob Verfügbarkeit, Wartbarkeit und Wiederanlaufzeiten in der Praxis funktionieren – oder ob ein einzelner Fehler zum standortübergreifenden Großincident wird. Wer zwei oder mehr Rechenzentren verbindet, steht fast immer vor denselben Grundfragen: Soll die Kopplung auf Layer 2 oder Layer 3 erfolgen? Welche Services müssen wirklich „stretch“ sein, welche können über Routing sauber getrennt werden? Und wie verhält sich das Design in realen Failure Scenarios wie Link-Degradation, Split-Brain, Routing-Blackholes oder Control-Plane-Instabilität? Gerade hier entstehen viele Fehlentscheidungen, weil „L2 ist bequemer“ (Workload-Mobility) gegen „L3 ist robuster“ (Fehlerbegrenzung) ausgespielt wird, ohne die Nebenwirkungen zu quantifizieren. EVPN DCI bietet einen modernen Mittelweg: Es kann L2/L3-Services kontrollierter über Standorte transportieren und gleichzeitig Mechanismen bereitstellen, um Flooding zu reduzieren, Multi-Homing zu strukturieren und Failover deterministischer zu machen. Dieser Artikel ordnet DC Interconnect Design systematisch ein, vergleicht L2 vs. L3 im DCI-Kontext, erklärt EVPN DCI als Architekturbaustein und leitet aus typischen Failure Scenarios konkrete Design- und Betriebsentscheidungen ab.

DCI als Architekturproblem: Was im Interconnect wirklich „kritisch“ ist

DCI wird oft auf „Bandbreite zwischen zwei Standorten“ reduziert. Tatsächlich ist DCI ein Bündel aus Anforderungen, die sich gegenseitig beeinflussen: Workload-Platzierung, Disaster Recovery, Storage-Replikation, Datenbank-Cluster, Security-Zonen, Monitoring/Logging und die Fähigkeit, geplante Wartung ohne Chaos umzusetzen. Ein professioneller DCI-Ansatz beginnt daher mit einer klaren Service-Sicht.

L2 vs. L3 im DCI: Der eigentliche Unterschied ist die Fehlerdomäne

Die zentrale Unterscheidung zwischen L2- und L3-DCI ist weniger „technisch“, sondern architektonisch: Layer 2 erweitert eine Broadcast-Domäne über Standorte hinweg, Layer 3 setzt eine klare Grenze und erzwingt Routing als Trennlinie. Damit verändert sich, wie Fehler propagieren, wie schnell Diagnose möglich ist und wie robust Failover in der Realität bleibt.

L2-DCI: Vorteile und typische Einsatzmotive

L2-DCI: Nachteile und Risiken

L3-DCI: Vorteile und typische Einsatzmotive

L3-DCI: Nachteile und typische Hürden

Die pragmatische Leitlinie: Default L3, L2 nur mit begrenztem Scope

In vielen Enterprise-Designs ist die robusteste Grundregel: DCI standardmäßig als Layer 3 bauen, Layer 2 nur dort stretchen, wo der fachliche Nutzen messbar und die Risiken beherrschbar sind. Dieser Ansatz reduziert „Standort-Kopplung als Risiko“ und zwingt dazu, die echten Anforderungen zu klären: Ist die Abhängigkeit wirklich technisch notwendig oder historisch bequem?

EVPN DCI einordnen: Kontrollierteres L2/L3 über Standorte

EVPN (Ethernet VPN) wird häufig mit Data Center EVPN/VXLAN im Leaf-Spine verbunden, kann aber auch für DCI-Designs genutzt werden, um L2- und L3-Services kontrollierter zwischen Standorten auszutauschen. EVPN nutzt BGP als Control Plane für MAC- und IP-Reachability und reduziert damit klassische Flood-and-Learn-Probleme. Eine grundlegende Beschreibung von EVPN findet sich in RFC 7432.

Was EVPN im DCI-Kontext besonders wertvoll macht

EVPN mit VXLAN im DCI

In vielen DC-Umgebungen ist VXLAN die Data Plane für Overlays, EVPN die Control Plane. VXLAN ist in RFC 7348 beschrieben. Für DCI bedeutet das: Sie können Overlays über Standortgrenzen transportieren, müssen aber MTU, Encapsulation-Overhead, Troubleshooting und Failure Scenarios konsequent mitdenken.

L2-DCI-Designmuster: Wenn Stretching unvermeidbar ist

Wenn Layer 2 über Standorte hinweg benötigt wird, sollten Sie das Design so aufbauen, dass Fehlerdomänen trotzdem begrenzt bleiben und Split-Brain-Szenarien beherrschbar sind. L2-DCI „großflächig“ ohne Guardrails ist eine der häufigsten Ursachen für standortübergreifende Kaskaden.

L3-DCI-Designmuster: Stabilität und DR-Modelle sauber abbilden

Bei L3-DCI ist das zentrale Ziel, Standortgrenzen als stabile Failure Domains zu nutzen, aber dennoch kontrollierte Service-Failover-Pfade zu ermöglichen. L3-DCI passt besonders gut zu Active/Standby- oder „Active/Active mit Applikationslogik“-Modellen.

Failure Scenarios im DCI: Was Sie vorab modellieren müssen

Ein DCI-Design ist erst dann belastbar, wenn es in realistischen Failure Scenarios gedacht, getestet und dokumentiert ist. Viele DCI-Probleme sind nicht „Total-Ausfall“, sondern Degradation: Paketverlust, asymmetrische Pfade, Control-Plane-Instabilität oder einseitige Erreichbarkeit. Genau diese Zustände erzeugen die schlimmsten Fehlerbilder, weil sie sporadisch wirken.

Scenario 1: DCI-Link Down (Hard Failure)

Scenario 2: Link Degradation (Loss/Jitter/Latenzspikes)

Scenario 3: Unidirektionaler Fehler (One-way Connectivity)

Scenario 4: Split-Brain im Active/Active

Scenario 5: Control-Plane-Instabilität (BGP/EVPN Flaps)

EVPN DCI und Multi-Site: Was Sie zwingend standardisieren müssen

EVPN DCI kann mächtig sein, aber nur, wenn Standards und Governance konsequent sind. Ohne eindeutige „Regeln des Systems“ werden Multi-Site-Designs schnell zu schwer betreibbaren Spezialkonstrukten. Besonders wichtig sind konsistente Bezeichner und klare Zuständigkeiten.

Kapazität und Latency Budgets im DCI: Replikation ist nicht „Resttraffic“

DCI-Links werden oft in der Kapazitätsplanung unterschätzt, weil Replikation als „Background“ betrachtet wird. In Realität erzeugen Replikation, Backups, Cluster-Sync und Datenpipelines massive Elephant Flows, die bei Degradation oder Failover kritische Services verdrängen können. Professionelles DCI-Design plant daher Kapazität und QoS explizit.

Security und Policy im DCI: Zonen bleiben Zonen

Ein häufiger Architekturfauxpas ist, dass der DCI-Link als „vertrauenswürdig“ betrachtet wird, weil er „intern“ ist. Gerade standortübergreifend müssen Zonen und Trust Boundaries klar bleiben: Replikation ist nicht automatisch unkritisch, Admin- und Management-Traffic gehört nicht in dieselben Pfade wie Produktivdaten, und Logging muss standortübergreifend konsistent sein.

Tests und Abnahme: DCI ist erst fertig, wenn Failure Scenarios bestanden sind

DCI-Designs scheitern in der Praxis selten am Normalbetrieb, sondern am Fehlverhalten unter Stress. Daher sollten Abnahmekriterien nicht „Ping geht“ sein, sondern ein Testkatalog, der die wichtigsten Failure Scenarios umfasst. Wichtig ist, sowohl Control Plane als auch Data Plane und Service-Impact zu messen.

Operational Patterns: DCI betreibbar machen, nicht nur bauen

Ein DCI-Design muss als „Produkt“ betrieben werden: Standards, Versionierung, Rollouts, Monitoring und klare Zuständigkeiten. Das reduziert Risiko und sorgt dafür, dass Änderungen nicht zum größten Failure Trigger werden.

Entscheidungshilfe: Wann L2, wann L3, wann EVPN DCI?

Checkliste für Architektur- und Security-Gates im DCI-Projekt

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:

Lieferumfang:

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.

 

Exit mobile version