Telco DCI Topologien sind für moderne Provider- und Telekommunikationsnetze ein strategisches Thema, weil Data Center Interconnect (DCI) längst nicht mehr nur „Rechenzentrum koppeln“ bedeutet. Telco-DCs tragen heute Core- und Edge-Plattformen, virtuelle Netzwerkfunktionen, Cloud-native Telco-Stacks, BNG/CGNAT, Security-Services, Caches sowie Management- und Orchestrierungssysteme. Viele dieser Komponenten benötigen hohe Verfügbarkeit, konsistente Policies, planbare Latenz und klare Failure Domains – über zwei oder mehr Standorte hinweg. Genau hier stellt sich die zentrale Designfrage: Soll man Layer 2 zwischen Standorten „stretchen“ (L2 Stretch), auf Layer 3 interconnecten (L3 Interconnect) oder ein EVPN-basiertes DCI umsetzen (EVPN DCI)? Jede Variante hat typische Vorteile, aber auch Fallstricke, die im Provider-Betrieb schnell zu OPEX, Incident-Risiken oder Audit-Problemen führen können. Dieser Artikel erklärt die Unterschiede verständlich, zeigt praxisnahe Entscheidungskriterien und beschreibt Designprinzipien, damit Ihr DCI nicht nur technisch funktioniert, sondern auch skalierbar, wartbar und carrier-grade betrieben werden kann.
Was DCI im Telco-Umfeld leisten muss
Ein Telco-DCI wird häufig durch vier Treiber geprägt: Verfügbarkeit (Active/Active oder Active/Standby), Kapazität (hohe Ost-West- und Nord-Süd-Last), Service- und Mandantenfähigkeit (Segmentierung) sowie Betriebsfähigkeit (klarer Fehlerimpact, gute Sichtbarkeit, standardisierte Changes). Damit wird DCI zu einem Architekturbaustein, der Netzwerkdesign, Plattformdesign und Betrieb zusammenführt.
- Standort-Resilienz: Workloads und Dienste sollen bei Site-Ausfällen weiterlaufen oder schnell umschalten.
- Planbare Pfade: Latenz, Jitter und Loss müssen kontrollierbar sein, besonders für Steuer- und Echtzeitkomponenten.
- Service Separation: Mandanten, Plattformdienste und Management müssen isoliert bleiben – auch über Standorte hinweg.
- Wartbarkeit: Geplante Arbeiten am DCI sollen nicht automatisch zu großflächigem Impact führen.
- Auditierbarkeit: Nachweise zu Segmentierung, Policies, Changes und Messwerten müssen reproduzierbar sein.
Die wichtigste Grundentscheidung: „Gleiche Broadcast-Domäne über Standorte“ ja oder nein?
Viele DCI-Entscheidungen lassen sich auf diese Frage reduzieren. L2 Stretch ist im Kern die Verlängerung von Broadcast-Domänen zwischen Standorten. L3 Interconnect bricht Broadcast-Domänen konsequent an der Standortgrenze. EVPN DCI kann beides unterstützen, wird aber häufig genutzt, um L2/L3-Services kontrollierter und skalierbarer zu gestalten. Wer diese Grundentscheidung früh trifft, vermeidet spätere Re-Designs.
L2 Stretch: Wann Layer-2-Erweiterung sinnvoll ist
L2 Stretch bedeutet, dass VLANs oder Layer-2-Segmente über mehrere Rechenzentren hinweg betrieben werden, sodass Endsysteme scheinbar im gleichen L2-Netz liegen. Das ist attraktiv für bestimmte Anwendungsfälle: klassische Cluster, Workload-Migrationen, bestimmte Storage- oder Failover-Konzepte und Umgebungen, in denen IP-Adressierung nicht leicht geändert werden kann. Im Telco-Umfeld taucht L2 Stretch auch dort auf, wo Plattformkomponenten historisch auf L2-Adjazenz bauen.
- Typische Vorteile: Einfache Workload-Migration, gleiches Subnetz an mehreren Standorten, weniger IP-Refactoring.
- Typische Use Cases: Legacy-Cluster, bestimmte Active/Active-Designs, Übergangslösungen bei Migrationen.
- Operativer Reiz: „Es sieht aus wie ein Standort“ – zumindest oberflächlich.
Die Schattenseite: Broadcast-Domänen werden zu standortübergreifenden Failure Domains
L2 Stretch kann im Provider-Betrieb riskant werden, weil Fehler domänenübergreifend wirken können: L2-Loops, Fehlkonfigurationen, MAC-Table-Instabilität, unbekannte Broadcast-/Multicast-Spitzen oder fehlerhafte Endsysteme können mehrere Standorte beeinträchtigen. Außerdem steigen Anforderungen an Monitoring, Storm-Control und klare Segmentgrenzen. L2 Stretch ist deshalb nur dann carrier-tauglich, wenn Failure Domains klein gehalten, Schutzmechanismen konsequent umgesetzt und Betriebsprozesse sehr diszipliniert sind.
Designprinzipien für L2 Stretch im Telco-DCI
Wenn L2 Stretch notwendig ist, sollte es bewusst begrenzt und stark standardisiert werden. Ziel ist, nur die minimal erforderlichen Segmente zu stretchen, klare Kontrollpunkte zu definieren und die Auswirkungen von Fehlern zu begrenzen.
- Minimaler Scope: Nur die VLANs/Segmente stretchen, die wirklich benötigen, nicht „alles“.
- Storm-Protection: Broadcast/Unknown-Unicast/Multicast kontrollieren, klare Limits je Segment.
- MTU-Disziplin: Encapsulation und DCI-Transport müssen MTU-konform sein, sonst drohen Drops.
- Isolierte Zonen: Management und Plattformdienste getrennt halten, keine flachen Netze.
- Testpflicht: Failover, Loop-Szenarien und Wartungsfenster regelmäßig verifizieren.
L2 Stretch ist oft eine Migrationsbrücke, kein Endzustand
In vielen Telco-Programmen wird L2 Stretch genutzt, um Übergangsphasen zu überbrücken, während Anwendungen auf modernere, L3-freundliche Betriebsmodelle umgestellt werden. Das ist legitim, sollte aber als zeitlich begrenzter Blueprint mit klarer Exit-Strategie betrachtet werden, um langfristige OPEX-Last zu vermeiden.
L3 Interconnect: Standortgrenze als Stabilitäts- und Skalierungsprinzip
L3 Interconnect bricht Layer-2-Domänen an der Standortgrenze und koppelt Rechenzentren über Routing. Das ist im Provider-Umfeld häufig die stabilste und am besten skalierbare Variante, weil Failure Domains klar begrenzt werden: Ein L2-Problem in einem DC bleibt dort, und das DCI ist primär ein Transport- und Routingproblem. L3 Interconnect passt gut zu modernen Cloud- und Microservice-Architekturen, bei denen Anwendungen eher über L3 kommunizieren und nicht auf identische Subnetze angewiesen sind.
- Vorteile: Kleine Failure Domains, klarere Fehlersuche, bessere Skalierung, weniger L2-Risiken.
- Geeignet für: Cloud-native Workloads, serviceorientierte Architekturen, klare Segmentierung je Standort.
- Betriebsvorteil: Routing ist meist leichter zu beobachten und zu automatisieren als große L2-Stretch-Domänen.
Der Trade-off: Applikations- und Plattformdesign muss L3-fähig sein
L3 Interconnect verlangt, dass Failover und Standortwechsel nicht an einer festen IP-Adressierung oder an L2-Adjazenz hängen. Das bedeutet: Load Balancing, Anycast-Services, DNS-basierte Umschaltung oder applikationsseitige Replikationsmechanismen werden wichtiger. In Telco-Umgebungen mit Legacy-Komponenten kann das ein echter Migrationsaufwand sein – der sich aber oft durch geringere OPEX und stabileren Betrieb auszahlt.
Designprinzipien für L3 Interconnect im Telco-DCI
Ein gutes L3-DCI-Design ist nicht nur „Routing zwischen Standorten“, sondern ein konsistentes Modell für Segmentierung, Pfadsteuerung und Messbarkeit. Besonders wichtig ist die klare Trennung zwischen Underlay (Transport) und Overlay (Services/Mandanten) sowie die Definition von Gateway-Rollen.
- Standortlokale L2-Domänen: VLANs bleiben im DC, DCI ist L3.
- Anycast-Gateways: Einheitliche Gateway-IP pro Segment, aber standortlokale Forwarding-Entscheidungen.
- Policy-Grenzen: Security- und Service-Policies werden an klaren Edge/Gateway-Punkten umgesetzt.
- Telemetry: Latenz, Loss, Pfadwechsel und Konvergenz über Standorte messen und historisieren.
- Wartungsfähigkeit: Geplante Arbeiten sollen über definierte Pfadoptionen abgefangen werden.
Ein Kernvorteil: DCI wird zu einem kontrollierbaren Transportproblem
Wenn das DCI L3-basiert ist, lassen sich Pfade, Kapazität und Redundanz meist sauberer modellieren: Linkausfälle, Trassenprobleme und Routing-Konvergenz sind klar messbar. Damit steigt die Auditierbarkeit, weil man Service-Qualität und Wiederherstellungsverhalten in KPIs ausdrücken kann.
EVPN DCI: Kontrollierte L2/L3-Services über Standorte
EVPN DCI nutzt EVPN als Control Plane, um L2- und/oder L3-Services über DCI-Transport bereitzustellen. Der praktische Mehrwert liegt darin, dass EVPN Service-Informationen kontrollierter verteilt und typische L2-Probleme (wie unkontrolliertes Flooding) reduzieren kann, wenn es sauber implementiert wird. In Telco-Umgebungen ist EVPN DCI attraktiv, weil es sowohl klassische L2-Anforderungen als auch moderne L3-Segmentierung in einem einheitlichen Modell unterstützen kann.
- Vorteile: Skalierbares Service-Modell, bessere Kontrolle von L2-Informationen, klare Segmentierung.
- Geeignet für: Multitenancy, DCI mit mehreren Services, kontrollierte L2-Services über Standorte, hybride Welten.
- Operativer Nutzen: Einheitliche Templates für Services, bessere Automatisierbarkeit und Governance.
EVPN DCI ist kein Freifahrtschein für „flache Netze“
EVPN kann L2-Dienste deutlich besser kontrollieren, aber es eliminiert nicht alle Risiken, die aus zu großen Broadcast-Domänen entstehen. Deshalb gilt auch hier: nur stretchen, was wirklich nötig ist; Failure Domains begrenzen; Policies und MTU diszipliniert halten; Telemetry und Tests als Pflicht definieren.
Vergleich: L2 Stretch vs. L3 Interconnect vs. EVPN DCI anhand von Telco-Kriterien
Ein Telco-DCI sollte nicht anhand einzelner Features entschieden werden, sondern anhand von Betrieb, Risiko und Wachstum. Die folgenden Kriterien helfen, die Optionen systematisch zu vergleichen.
- Failure Domains: L3 Interconnect begrenzt am stärksten; L2 Stretch vergrößert Domänen; EVPN DCI kann Domänen kontrollieren, aber nicht beliebig vergrößern.
- Skalierung: L3 Interconnect skaliert meist am saubersten; EVPN DCI skaliert gut bei guter Governance; L2 Stretch wird mit Größe schnell riskant.
- Applikationsanforderungen: L2 Stretch ist am kompatibelsten mit Legacy; L3 erfordert L3-fähige Failover-Modelle; EVPN DCI deckt hybride Bedürfnisse ab.
- OPEX: L3 ist oft am günstigsten im Betrieb; EVPN DCI kann OPEX senken, wenn standardisiert; L2 Stretch kann OPEX durch Troubleshooting erhöhen.
- Auditierbarkeit: L3 bietet klare Nachweise; EVPN DCI ist auditierbar mit Templates und Telemetry; L2 Stretch erfordert besonders strikte Kontrollen.
Ein praktisches Entscheidungsprinzip: „So wenig L2 wie möglich, so viel L3 wie sinnvoll“
Im Provider-Betrieb ist die konservative Strategie häufig die robusteste: Standortgrenzen auf L3 ziehen und L2 nur dort stretchen, wo es zwingend notwendig ist. EVPN DCI kann dabei helfen, die verbleibenden L2-/L3-Services sauber zu modellieren, statt ad-hoc Sonderlösungen aufzubauen.
Typische Telco-Use-Cases und welche DCI-Topologie oft passt
Die Wahl hängt stark davon ab, welche Plattformen und Services Sie betreiben und wie Ihr Failover-Modell aussieht.
- Cloud-native Telco-Plattform (cNFs, Kubernetes): Häufig L3 Interconnect, weil Dienste L3-fähig sind und Ost-West über Overlay kontrolliert wird.
- Legacy-Cluster mit IP-Bindung: Häufig (temporär) L2 Stretch oder EVPN DCI für begrenzte Segmente.
- Multitenant-Service-DC mit vielen Kundeninstanzen: Häufig EVPN DCI, weil Service-Templates und Segmentierung skalieren.
- Edge-PoPs mit wenigen Racks: Oft L3 Interconnect, weil Einfachheit und Betriebskosten zählen.
Koexistenz ist normal: Migration in Phasen
In Telco-Realitäten existieren oft mehrere DCI-Modelle parallel: ältere Workloads nutzen L2 Stretch, neue Plattformen laufen L3-basiert, und EVPN DCI dient als strukturierende Klammer. Wichtig ist, Übergänge sauber zu definieren, MTU konsistent zu halten und Betriebsprozesse so zu gestalten, dass die Komplexität nicht unkontrolliert wächst.
Telemetry und Betrieb: DCI muss messbar und erklärbar sein
Unabhängig von der Topologie ist DCI nur dann carrier-grade, wenn es beobachtbar ist. Telco-Teams benötigen Pfadtransparenz (welcher Standortpfad wird genutzt?), Performance-Messung (Latenz, Loss, Jitter), Kapazitätsdaten (Auslastung und Headroom) und Ereigniskorrelation (Trasse, Link, Device, Policy). Gerade bei L2 Stretch und EVPN DCI ist zusätzliche Sichtbarkeit wichtig, um Service- und Transportprobleme zuverlässig zu trennen.
- Pfadtransparenz: Path-Change-Events, ECMP-Distribution, Standortpfadwahl.
- Performance: Latenz- und Loss-Messung pro DCI-Pfad und Serviceklasse.
- Kapazität: Auslastung, Microbursts, Drops und Queue-Verhalten.
- Korrelation: Failure Domains und Root-Cause-Erkennung statt Alarmflut.
MTU als „stiller Killer“: Immer Teil des DCI-Blueprints
DCI-Encapsulation, Overlays und ggf. zusätzliche Service-Kapselungen erfordern konsequente MTU-Planung. Ein DCI-Blueprint muss MTU-Werte definieren, sie durchgängig überprüfen und Telemetry so gestalten, dass MTU-bezogene Drops und Fragmentierung sofort sichtbar werden.
Einfaches Modell zur Entscheidungsunterstützung
Viele Teams profitieren von einer klaren Zielgröße: maximale Stabilität bei minimaler Komplexität. Vereinfacht lässt sich die Entscheidung als Funktion aus Legacy-Anteil, Bedarf an L2-Adjazenz und Governance-Reife betrachten:
Wenn und gering sind, ist L3 Interconnect oft die stabilste Wahl. Wenn L2-Bedarf vorhanden ist, aber Governance hoch ist, kann EVPN DCI eine kontrollierte Lösung sein. Wenn Legacy dominiert und schnelle Migration nötig ist, kann L2 Stretch als Übergang sinnvoll sein – idealerweise mit klarer Begrenzung und Exit-Plan.
Praktische Designprinzipien für Telco-DCI, unabhängig vom gewählten Modell
- Failure Domains begrenzen: Nicht mehr Segmente/Services über Standorte ziehen als zwingend nötig.
- Diversität erzwingen: Trassen- und Standortdiversität dokumentieren, Shared Risk minimieren.
- Standardisierung: Blueprints, Templates und Namens-/Adresskonventionen konsequent anwenden.
- Wartung planen: Maintenance-Szenarien testen, Rollback und Pfadsteuerung definieren.
- Telemetry priorisieren: Pfad, Performance, Kapazität und Korrelation als Pflichtmetriken.
- Governance: Changes versionieren, in Wellen ausrollen, Ausnahmen streng kontrollieren.
