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

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.

• Workload-Mobility: Muss eine VM oder ein Container-Workload wirklich mit derselben IP an einen anderen Standort verschoben werden?
• Active/Active vs. Active/Standby DC: Ist paralleler Betrieb mit Lastverteilung geplant oder ein primärer Standort mit DR-Failover?
• Stateful Komponenten: Wie verhalten sich Firewalls, NAT, Load Balancer, Proxies, Session-Persistenz und Applikationszustände im Standortwechsel?
• RPO/RTO: Welche Recovery-Ziele gelten, und welche Netzwerkkopplung unterstützt sie realistisch?
• Failure Domains: Darf ein Fehler in DC A DC B beeinträchtigen – oder muss der Blast Radius streng begrenzt werden?

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

• IP-Adresskontinuität: Workloads behalten ihre IP, was Migration und bestimmte Legacy-Anwendungen erleichtern kann.
• Vereinfachte Cluster-Modelle: Manche Applikations- oder Storage-Cluster erwarten L2-Nachbarschaft oder sehr einfache Netzsicht.
• Weniger Änderungen an Applikationen: Wenn Applikationen hart auf IPs, Subnetze oder bestimmte Netzwerkannahmen gebaut sind.

L2-DCI: Nachteile und Risiken

• Große Broadcast-/Failure Domain: L2-Probleme (Loops, MAC-Flooding, unbekannter Traffic) können standortübergreifend eskalieren.
• Split-Brain-Risiko: Bei DCI-Partition (Interconnect fällt aus, beide DCs laufen) kann es zu doppelten Gateways, doppeltem Ownership oder inkonsistenten Zuständen kommen.
• Operative Komplexität: Troubleshooting über zwei Standorte ist schwerer, insbesondere bei intermittierenden Störungen.
• Abhängigkeit von L2-Gateways: Anycast Gateways oder aktive/aktive Gateway-Modelle müssen sehr sauber geplant sein.

L3-DCI: Vorteile und typische Einsatzmotive

• Klare Trennung: Routing setzt eine harte Grenze, Blast Radius bleibt lokal.
• Bessere Stabilität und Skalierung: Weniger L2-Flooding, weniger Risiko durch L2-Anomalien.
• Saubere DR-Modelle: Active/Standby- oder Cold-/Warm-Standby lassen sich mit L3 gut orchestrieren.
• Policy- und Security-Klarheit: Standorte können als Sicherheits- und Compliance-Domänen behandelt werden.

L3-DCI: Nachteile und typische Hürden

• Adress-/Subnetzänderungen: Migration kann Anpassungen erfordern (DNS, Load Balancing, App-Konfiguration).
• Komplexere Mobility: „Live-Migration mit gleicher IP“ ist ohne zusätzliche Mechanismen schwieriger.
• Applikationsanforderungen: Manche Legacy-Designs müssen modernisiert werden, bevor L3 voll nutzbar ist.

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?

• L3 als Standardgrenze: Standorte sind eigenständige Failure Domains.
• L2-Stretch nur gezielt: einzelne Segmente, mit klaren Guardrails und Abnahmekriterien.
• Migration statt Dauerprovisorium: L2-Stretch als Übergangsmuster, nicht als Endzustand, wenn möglich.

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

• Control-Plane-basiertes Learning: MAC/IP-Informationen werden verteilt, Flooding kann reduziert werden.
• Multi-Homing-Modelle: Redundante Anbindung an DCI-Edges lässt sich strukturierter gestalten.
• ARP/ND-Suppression: Weniger Broadcast/Unknown-Traffic über den DCI-Link.
• Saubere Service-Abstraktion: EVPN kann sowohl L2- als auch L3-Services darstellen und damit Hybridanforderungen abdecken.

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.

• Scope begrenzen: Nur die zwingend notwendigen VLANs/Segmente stretchen, keine generische „alles muss überall verfügbar sein“-Haltung.
• Gateway-Strategie klären: Anycast Gateway vs. Standort-Gateway mit klarer Active/Standby-Logik; definieren, wer Default Gateway „besitzt“.
• Split-Brain verhindern: Mechanismen für DCI-Partition: Wer gewinnt, wer verliert, wie wird verhindert, dass beide Seiten gleichzeitig aktiv sind?
• Stateful Services berücksichtigen: NAT, Firewalls, Load Balancer benötigen symmetrische Pfade oder bewusstes Session-Handling.
• Flooding minimieren: EVPN Control Plane, ARP/ND-Suppression, Unknown-Unicast-Strategien.

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.

• Standortpräfixe und Summaries: Saubere Aggregation verhindert, dass Routing-Instabilität global wird.
• Routing-Policies und Guardrails: Prefix-Filter, Max-Prefix, Default-Deny an Übergängen; verhindert Route-Leaks und Blackholes.
• Service-GTMs/DNS: Traffic-Shift wird über DNS/GSLB oder Applikationsmechanismen gesteuert, statt IP-Stretch zu erzwingen.
• DR-Failover klar definieren: Welche Routen werden wann beworben? Wie wird „unwanted failover“ vermieden?
• Kapazität im N-1-Betrieb: DCI-Links und Core müssen Failover-Last tragen können (Replikation + Nutzertraffic).

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)

• L2-DCI-Risiko: Split-Brain, doppelte Gateways, MAC- und ARP-Instabilität, „beide Seiten glauben, sie seien aktiv“.
• L3-DCI-Verhalten: Routing konvergiert; Services müssen über DR-Mechanik umschalten (DNS/GSLB, App-Failover).
• Designfrage: Welche Serviceunterbrechung ist tolerierbar, und wie wird sie gemessen?

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

• Typisches Risiko: DCI ist „nicht down“, aber praktisch unbrauchbar; TCP bricht ein, Replikation staut sich, Queue-Drops steigen.
• Wichtiger als Timer: End-to-End-Probes und Threshold-basierte Steering-Logik (z. B. für TE oder Failover-Entscheidungen) sind entscheidend.
• Operative Konsequenz: Ohne klare Kriterien wird zu spät oder falsch umgeschaltet.

Scenario 3: Unidirektionaler Fehler (One-way Connectivity)

• Gefährlich, weil selten erkannt: Link wirkt „up“, aber in eine Richtung fehlen Frames oder IP-Pakete.
• BFD/Tracking hilft: Schnelle Failure Detection kann unidirektionale Probleme schneller sichtbar machen.
• Stateful Effekte: Sessions brechen sporadisch, was wie „Anwendungsproblem“ wirkt.

Scenario 4: Split-Brain im Active/Active

• L2-DCI besonders anfällig: Wenn beide DCs gleichzeitig „Master“ werden, entstehen Datenkorruption und inkonsistente Zustände.
• Quorum und Fencing: Applikationen/Cluster müssen Quorum-Logik besitzen; Netzwerkdesign muss Fencing-Mechanismen unterstützen.
• Designregel: Active/Active nur, wenn Applikations- und Datenebene split-brain-sicher sind.

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

• Symptom: MAC/IP-Reachability „wandert“, Blackholes treten sporadisch auf.
• Ursache: Flaps, inkonsistente Policies, fehlende Throttle/Guardrails, instabile Underlay-Konvergenz.
• Gegenmaßnahme: Konvergenzziele definieren, Flap-Guardrails, klare Standards und Telemetrie für EVPN-States.

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.

• VNI/VRF-Plan: Eindeutige Zuordnung von Segmenten und Mandanten, versioniert wie ein IP-Plan.
• Route Targets und Policies: Import/Export-Regeln müssen restriktiv und nachvollziehbar sein, um Leaks zu verhindern.
• Anycast Gateway Regeln: Wo ist Anycast zulässig, wie wird „Gateway Ownership“ im Failure-Fall behandelt?
• Flooding-Strategie: ARP/ND-Suppression, Unknown-Unicast-Handling, BUM-Traffic-Policies.
• MTU und Encapsulation: Underlay muss ausreichende MTU bieten; stille Drops sind im DCI besonders teuer.

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.

• Separate Klassen: Replikation/Backup in eigene QoS-Klassen oder Zeitfenster.
• Failover-Last modellieren: Was passiert im N-1, wenn Traffic umgeleitet wird oder DC B plötzlich primär wird?
• Latenz als Budget: Manche Datenbank- oder Storage-Mechanismen sind extrem latenzsensitiv; hier ist L3-Design oft robuster als L2-Stretch.
• Messbarkeit: End-to-End-Probes (RTT, Loss, Jitter) plus Flow-Daten, um „Degradation“ früh zu erkennen.

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.

• Management Plane trennen: Dedizierte Netze/VRFs für Management und Betrieb.
• Segmentierung erhalten: Kein „DC A ist sicher, also ist DC B auch sicher“; Policies gelten standortübergreifend.
• Enforcement Points planen: Wo wird inspected, wo nicht? Hairpinning über zentrale Firewalls kann DCI belasten und Latenz erhöhen.
• Logging/Forensik: Ereignisse müssen über beide Standorte korrelierbar sein; Zeitbasis (NTP) ist Pflicht.

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.

• Link-Down-Test: Umschaltverhalten, Konvergenzzeit, Serviceunterbrechung, Recovery in Normalzustand.
• Degradation-Test: Paketverlust/Latenzspikes; prüfen, ob Replikation kontrolliert bleibt und kritische Klassen geschützt werden.
• Split-Brain-Test: DCI-Partition; prüfen, ob Quorum/Fencing greift und kein doppelter Master entsteht.
• EVPN/Control-Plane-Test: Flaps, Route-Target-Änderungen, MAC-Mobility; prüfen, ob Blackholes ausgeschlossen sind.
• Maintenance-Test: Geplante Wartung am DCI; Traffic-Steering und Rollback müssen planbar sein.

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.

• Staged Rollouts: Änderungen erst in kontrolliertem Scope, dann Wellen – besonders bei EVPN Policies und Gateway-Logik.
• Drift-Kontrolle: Abweichungen von DCI-Standards (MTU, Policies, RTs) früh erkennen.
• Runbooks: Vorgehen bei DCI-Degradation, Blackholing, EVPN-Instabilität, Split-Brain-Verdacht.
• KPIs: Latenz/Loss-Perzentile, Queue-Drops, Replikationsdurchsatz, Failoverzeiten, Incident-Korrelation mit Changes.

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

• L3 bevorzugen, wenn: Blast Radius minimiert werden soll, DR-Modelle klar sind, Workloads nicht zwingend IP-stabil migrieren müssen und Governance/Compliance hohe Priorität hat.
• L2 nur gezielt, wenn: Es echte, nicht vermeidbare Anforderungen an IP/Subnet-Kontinuität gibt und Split-Brain-Mechanismen sowie Gateway-Ownership sauber beherrscht werden.
• EVPN DCI sinnvoll, wenn: Sie L2/L3-Services kontrolliert über Standorte transportieren wollen, Flooding reduzieren müssen und ein standardisiertes BGP/EVPN-Betriebsmodell etablieren können.

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

• Scope klar: Welche Segmente/Services dürfen über DCI, welche ausdrücklich nicht?
• Failure Domains definiert: Was darf bei Ausfall/Degradation betroffen sein, was nicht?
• Split-Brain-Strategie vorhanden: Quorum/Fencing/Ownership, insbesondere bei L2-Stretch oder Active/Active.
• MTU und Overhead validiert: Keine stillen Drops bei Encapsulation; Path-MTU getestet.
• Kapazität für N-1: Failover-Last, Replikation, Peaks und QoS-Klassen geplant.
• EVPN-Standards (falls genutzt): VNI/VRF/RT-Plan, Anycast Gateway Regeln, Flooding-Reduktion, Guardrails.
• Observability vollständig: Probes, Flow-Daten, Queue-Telemetrie, Control-Plane-States, Zeitbasis.
• Testkatalog bestanden: Link-Down, Degradation, Split-Brain, Control-Plane-Flaps, Maintenance.
• Runbooks und Ownership: Betrieb, Eskalation, Rollback, Review-Intervalle für Policies und Ausnahmen.

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.