Die Migration von Legacy Topologien ist im Telco- und Provider-Umfeld eine der anspruchsvollsten Disziplinen der Netzwerktechnik, weil sie in einer Brownfield-Realität stattfindet: Kunden hängen am Netz, Services dürfen nicht ausfallen, und gleichzeitig sollen Architektur, Automatisierung und Betrieb modernisiert werden. „Ohne Downtime“ bedeutet dabei nicht, dass niemals irgendwo ein Interface kurz neu verhandelt oder eine Session neu aufgebaut wird, sondern dass die Servicewirkung kontrolliert bleibt: keine ungeplanten Totalausfälle, keine großflächigen Reachability-Lücken und keine SLA-brechenden Wartungsfenster. In der Praxis scheitern Modernisierungen selten an der neuen Technologie, sondern an der Übergangsphase, in der alt und neu parallel existieren müssen. Genau hier braucht es ein methodisches Vorgehen: klare Zielarchitektur (Target), belastbare Bestandsaufnahme (As-Is), definierte Übergangstopologien (Transitional States), sichere Cutover-Mechanismen (Traffic Steering, Dual-Stack/Overlay, VRF-Transitions) und eine Betriebsstrategie (Canary, progressive Rollouts, Rollback). Dieser Artikel zeigt, wie Sie Legacy-Topologien modernisieren, ohne den Betrieb zu gefährden: Welche Migrationsmuster sich bewährt haben, wie man Failure Domains und Wartungsdomänen nutzt, wie man Routing und Services schrittweise umhängt und wie man mit Intent Validation und Lab-Reproduktion Risiken vor dem Change sichtbar macht.
Warum Brownfield-Migrationen schwieriger sind als Greenfield-Projekte
Greenfield-Designs können idealtypisch geplant werden: konsistente Adressierung, klare Rollen, einheitliche Plattformen, saubere Segmentierung. Brownfield-Migrationen dagegen starten mit Einschränkungen: historisch gewachsene Adressräume, gemischte Hardware, inkonsistente Policies, verteilte Dokumentation und häufig unklare Abhängigkeiten zwischen Services und Topologie. Außerdem ist der Zeitdruck real: Sicherheitsanforderungen, Kapazitätsengpässe oder Vendor-End-of-Life erzwingen Modernisierung, während die Kundenlast weiter wächst.
- Heterogene Technik: Mehrere Vendoren, OS-Versionen und Feature-Sets erschweren Standardisierung.
- Unklare Abhängigkeiten: Services, VRFs, Firewalls, CGNAT/BNG und Interconnects sind historisch gekoppelt.
- Verteilte Failure Domains: Redundanz ist oft „scheinbar“, weil SRLGs oder gemeinsame Hubs nicht dokumentiert sind.
- Hohe Change-Kosten: Jeder Fehler wirkt direkt auf produktive Dienste, nicht auf ein Testnetz.
Leitprinzip: Migration ist ein Programm, nicht ein Projekt
Die Modernisierung ohne Downtime gelingt selten als „Big Bang“. Erfolgreich ist meist ein Programm aus kleinen, kontrollierten Schritten mit messbaren Zwischenzielen und wiederholbaren Migrationsmustern.
Die Zielarchitektur definieren: Was genau ist „modern“?
Eine Migration ohne Downtime braucht ein klares Zielbild, das mehr ist als ein Technologie-Buzzword. „Wir machen SRv6“ oder „wir gehen auf EVPN“ ist kein Zielbild. Ein gutes Zielbild beschreibt Rollen, Domänen und Betriebsprinzipien: Core/Metro/Access, Underlay/Overlay, Service Edges, Interconnect, Management und Observability. Außerdem definiert es Guardrails: Exportfilter, Max-Prefix, CoPP, DDoS-Steering, QoS-Modelle und Wartungsdomänen.
- Topologie: Welche Ebenen (Core/Metro/Access/DCI) und welche Pattern (Ring/Mesh/Hub-Spoke) sollen gelten?
- Routing & TE: IGP-Design, BGP-Hierarchie, Route Reflectors, ECMP, FRR/TI-LFA, ggf. SR-TE.
- Services: VRF-Modelle, L2VPN/L3VPN-Blueprints, Internet Edge Policies, Anycast-Dienste.
- Security Domains: Segmentierung nach Kunden/Services/Betriebsrollen, Management-Zonen, Jump-Zones.
- Operational Model: Source of Truth, Automation, Intent Validation, Canary-Rollouts, Observability-by-Design.
Designregel: Zielarchitektur muss migrationsfähig sein
Ein Zielbild ist nur dann nützlich, wenn es Übergangszustände erlaubt: Alt und Neu müssen koexistieren können, ohne dass Sie Sicherheits- oder Routing-Chaos erzeugen.
Bestandsaufnahme: As-Is verstehen, bevor man modernisiert
Die wichtigste Phase in einer Brownfield-Migration ist die Bestandsaufnahme. Dabei geht es nicht nur um Geräte und Links, sondern um Servicepfade und Policies. Sie brauchen ein Bild auf mehreren Layern: L1 (physisch/SRLG), L2 (Domänen, VLAN/QinQ, Ringe), L3 (IGP/BGP, Summaries, RR, TE) und Services (VRFs, L2VPN/L3VPN, Internet, DDoS, CGNAT/BNG). Ohne diese Transparenz ist „ohne Downtime“ nicht planbar.
- Topology Inventory: Sites, Geräte, Ports, Circuits, Linkklassen und SRLGs.
- Routing Inventory: IGP-Domänen, BGP-Topologie, Communities/LocalPref, Max-Prefix, Route Leaks.
- Service Inventory: VRFs, Servicekanten (PE/BNG/CGNAT/Firewall), Normal- und Failoverpfade.
- Operational Baselines: SLOs/SLIs, p95/p99 Latenz, Loss, Queue-Drops, Convergence-Zeiten.
Anti-Pattern: Migration auf Basis von veralteten Diagrammen
Wenn die Doku nicht vertrauenswürdig ist, müssen Sie sie durch messbare Realität ergänzen: Telemetry, Flow/IPFIX, BGP/IGP Health, Link-Status und SRLG-Analyse.
Übergangszustände planen: Transitional Architectures statt Big Bang
Downtime-freie Migrationen leben von klaren Übergangszuständen. Statt „alt raus, neu rein“ definieren Sie Zustände, in denen beide Welten parallel laufen, aber mit kontrolliertem Scope. Diese Zustände sind temporär, aber sie müssen stabil und auditierbar sein. Typische Übergangsmuster sind Parallel-Core, Overlay-Überbau, Dual-Stack-Parallelbetrieb, und Service-by-Service-Cutover.
- Parallelbetrieb: Neuer Core/Metro wird aufgebaut und zunächst nur für Teiltraffic genutzt.
- Overlay-Migration: Ein Overlay (z. B. EVPN) wird über bestehendes Underlay gelegt, bevor Underlay modernisiert wird.
- Dual-Stack/Transition: IPv6 wird parallel eingeführt, während IPv4 stabil bleibt (oder umgekehrt).
- Service-Slicing: Services/Kundensegmente werden in Wellen migriert (Sharding nach Region/Kunde).
Designregel: Jeder Übergangszustand braucht Guardrails
Transitional States erhöhen Komplexität. Deshalb müssen Schutzmechanismen (Exportfilter, Route Leak Schutz, Max-Prefix, CoPP) in diesen Phasen besonders strikt sein.
Traffic Steering als Schlüssel: Wie Cutovers ohne Serviceausfall gelingen
Cutover ohne Downtime bedeutet, Traffic kontrolliert umzulenken. Dafür gibt es mehrere Hebel: BGP-Policy (LocalPref, Communities, Prepends), Anycast-Health-Gates, SR-TE/TE-Policies, DNS (für bestimmte Dienste) und in Serviceketten auch Service-Chaining-Mechanismen. Wichtig ist, dass Steering reversibel ist und über klare Stop/Go-Gates gesteuert wird.
- BGP-basierte Umlenkung: Inbound/Outbound Traffic über Policies verschieben, ohne Sessions hart zu trennen.
- Anycast-Shift: Anycast-Prefixe in neuen PoPs aktivieren und alte PoPs drainen (mit Health-Gates).
- TE im Backbone: Pfade priorisieren, um neue Links/Nodes kontrolliert zu belasten, ohne Engpässe zu reißen.
- Service-Edge Drain: Sessions schrittweise abbauen (BNG/CGNAT/Firewall), statt „hart umlegen“.
Anti-Pattern: Steering ohne Messplan
Jede Umlenkung braucht vorab definierte KPIs: Prefix-Counts, Portauslastung, Queue-Drops, p95/p99 Latenz, Session-Churn. Ohne Messplan wird Steering zur Wette.
Migrationsmuster für Routing: IGP, iBGP/RR und Interconnect schrittweise modernisieren
Routing ist häufig das Herz der Modernisierung. Ein robustes Muster ist, den Core transportstabil zu halten und Policies an klaren Kanten zu kapseln. Bei IGP-Migrationen (z. B. OSPF zu IS-IS oder neue Hierarchien) sind stabile Summaries und klare Domänengrenzen entscheidend. Für BGP ist die RR-Topologie ein klassischer Hebel: Hierarchische RRs können eingeführt werden, ohne dass alle Clients gleichzeitig migriert werden müssen, wenn Übergangspeerings sauber geplant sind.
- IGP-Hierarchie schärfen: Areas/Levels und Summarization passend zur Topologie, um Flooding und Churn zu begrenzen.
- RR-Modernisierung: Neue RR-Cluster parallel aufbauen, Clients in Wellen umhängen, Partition-Szenarien testen.
- Interconnect Hygiene: Export-/Import-Policies standardisieren, Max-Prefix überall, Leak-Guardrails als Gate.
- Konvergenz stabil halten: Timer nicht aggressiv „tunen“, sondern über Topologie (ECMP, FRR) Performance gewinnen.
Designregel: Core „boring“, Edge „policy-rich“
Je mehr Policy und Sonderlogik im Core liegt, desto größer der Blast Radius bei Migration. Kapseln Sie Interconnect- und Service-Policies an Edge-/Servicekanten.
Service-Migration: VRFs, L2VPN/L3VPN und Servicekanten ohne Kundenimpact
Service-Migrationen sind oft der kritische Teil, weil Kunden direkt betroffen sind. Bewährt ist ein Blueprint-Ansatz: Services werden nach einem Standardmodell beschrieben (VRF/RT/RD, QoS, CE-Topologie, Security) und dann schrittweise migriert. Für L3VPNs ist häufig ein PE-by-PE oder PoP-by-PoP Ansatz sinnvoll, bei dem die Kundenanbindung erst dann umgehängt wird, wenn das neue Service-Edge bereit ist und Back-to-Back getestet wurde.
- VRF-Blueprint: Einheitliche RT/RD-Logik, Route Leaks nur nach expliziten Regeln, klare Ownership.
- PE-CE Übergang: Parallel-Peering oder kontrollierte Umschaltung (Static/BGP/OSPF) je Kundentyp.
- L2VPN Migration: Domänen klein halten, EVPN/VPLS-Übergänge bewusst begrenzen, MTU im Blick.
- Subscriber/Stateful Services: BNG/CGNAT/Firewalls in Wellen drainen, Churn und CPS-Headroom einplanen.
Anti-Pattern: Kundenmigration ohne Canary-Logik
Starten Sie mit wenigen repräsentativen Kunden/Services (Canary), messen Sie SLO-Impact, und skalieren Sie erst dann in Wellen. Das minimiert unkontrollierten Blast Radius.
Parallelbetrieb beherrschbar halten: Komplexität bewusst begrenzen
Der Parallelbetrieb ist notwendig, aber gefährlich, weil er Komplexität erzeugt. Deshalb braucht er harte Grenzen: zeitliche Grenzen (wie lange darf der Übergang dauern?), topologische Grenzen (welche PoPs/Services sind in Übergang?), und technische Grenzen (welche Feature-Kombinationen sind erlaubt?). Ohne diese Begrenzungen entsteht „Legacy plus Neu plus Sonderfälle“.
- Scope-Control: Übergang nur in definierten Regionen/PoPs und nur für definierte Serviceklassen.
- Feature-Freeze: Während Migration keine neuen Features in die Legacy-Welt einführen.
- Exception-Disziplin: Ausnahmen nur mit Review und Ablaufdatum, damit Übergang nicht dauerhaft wird.
- Dokumentation nach Layern: L1/L2/L3/Services getrennt, mit klaren Cross-References.
Designregel: Übergangszustände müssen „deletable“ sein
Planen Sie von Anfang an, wie Sie Übergangskomponenten wieder entfernen. Wenn das nicht klar ist, wird der Übergang zum Dauerzustand.
Intent Validation und Lab-Reproduktion: Risiken vor dem Change sichtbar machen
Modernisierung ohne Downtime braucht Pre-Change-Sicherheit. Hier helfen zwei Instrumente besonders: Intent Validation (prüfbare Aussagen über Topologie und Policies) und Lab-Reproduktion (Containerlab/EVE-NG), um Failure Scenarios zu testen. Der Fokus liegt auf Invarianten: keine Route Leaks, Max-Prefix überall, VRF-Isolation, MTU-End-to-End, QoS-Failover-Profil, RR-Redundanz und DDoS-Guardrails.
- Pre-Checks: Datenqualität, Policy-Guardrails, Topologie-Redundanz, SRLG-Diversität.
- Policy-Output Tests: Welche Prefixe würden exportiert? Welche Communities wirken? Welche Präferenz gilt?
- Failure Scenarios: Link-/Node-/Partition-Events, Konvergenz, FRR Coverage, Service-Chain-Symmetrie.
- Go/No-Go Gates: Objektive Kriterien, die Rollout stoppen, bevor Kundenimpact entsteht.
Ein nützliches Erfolgsmodell
Wenn Guardrails greifen, Pfade stabil sind und Headroom/SLO-Budgets im erwarteten Rahmen bleiben, ist das Risiko kontrollierbar.
Progressive Rollouts: Canary, Wellen und Rollback als Downtime-Vermeider
„Ohne Downtime“ wird in der Praxis durch progressive Rollouts erreicht. Sie ändern nicht alles gleichzeitig, sondern in kontrollierten Einheiten: Canary-Domänen, dann Batches, dann Wellen. Topologie bestimmt diese Grenzen: Maintenance Domains, SRLGs, PoP-Paare, Regionpaare. Rollback ist kein Notnagel, sondern Teil des Plans: Sie müssen jederzeit in einen sicheren Zustand zurückkehren können.
- Canary-Phase: Repräsentative PoPs/Links/Services mit begrenztem Blast Radius, aber realer Last.
- Wellen nach Failure Domains: Niemals beide Redundanzseiten gleichzeitig; Rollout entlang klarer Domains.
- Stop/Go Kriterien: SLOs, Queue-Drops, Prefix-Counts, Control-Plane-Health, Session-Churn.
- Rollback-Readiness: Versionierte Templates, reversible Policies, definierte Rückbaupfade und getestete Prozeduren.
Anti-Pattern: Rolling Upgrade ohne Hysterese
Wenn Traffic-Steering oder Failback ohne Stabilitätsfenster erfolgt, drohen Ping-Pong und unerwartete Lastspitzen. Planen Sie Hold-downs und Beobachtungsfenster zwischen den Wellen.
Observability-by-Design: Migration nur mit Messbarkeit
Während der Modernisierung verändern sich Pfade. Deshalb ist Observability entscheidend: Sie brauchen Telemetry, die topologisch korreliert (Region/PoP/Rolle/Linkklasse) und die sowohl Control Plane (BGP/IGP/BFD/CPU) als auch Data Plane (Portauslastung, Queue-Drops, Loss, p95/p99 RTT) abbildet. Zusätzlich brauchen Sie Service-KPIs (BNG Sessions, CGNAT State, VPN Reachability, DNS Anycast Health), damit Sie nicht nur „Netz grün“, sondern „Service grün“ messen.
- Path KPIs: Latenz/Loss zu Referenzzielen, pro Region und über kritische Pfade.
- Engpasssignale: Queue-Drops an DCI/Interconnect/WAN, ECMP/LAG Imbalance, Hotspots.
- Routing Health: Prefix-Counts, BGP Update-Raten, RR-Consistency, Konvergenzzeiten.
- Service KPIs: VPN/VRF Reachability, Anycast Reachability, Subscriber-Churn, CPS/State-Budgets.
Designregel: Migration braucht ein „War Room Dashboard“
Vor der ersten Welle definieren Sie Dashboards und Alarme, die genau die erwarteten Risiken abdecken. So wird der Rollout steuerbar und weniger personenabhängig.
Typische Migrationspfade: Bewährte Modernisierungsstrategien
- Parallel-Core Migration: Neuen Core aufbauen, Traffic schrittweise über BGP/TE umlenken, alten Core drainen.
- RR-Refactoring: Neue hierarchische RR-Topologie parallel, Clients in Wellen umhängen, Partitionen testen.
- EVPN-Einführung im DC: Fabric als eigene Domäne modernisieren, Northbound L3 stabil halten, Services migrieren.
- Interconnect-Hygiene: Standardisierte Policies, Max-Prefix, Leak-Guardrails zuerst; reduziert Risiko für spätere Migrationen.
- Subscriber-Edge Modernisierung: BNG/CGNAT Plattformen parallel, Sessions in Wellen migrieren, CPS/Churn-Headroom planen.
Typische Fallstricke und wie man sie vermeidet
- Unklare Abhängigkeiten: Lösung: Multi-Layer-Doku, Servicepfade modellieren, Source of Truth konsolidieren.
- Zu große Cutovers: Lösung: Canary und progressive Wellen, Maintenance Domains, harte Scope-Grenzen.
- Policy-Drift zwischen Regionen: Lösung: Blueprints, Templates, Intent Validation (Export-/Import-Wirkung prüfen).
- MTU/Overlay-Blackholes: Lösung: End-to-End MTU-Plan, PMTUD/MSS, Tests in Failoverpfaden.
- DCI/Interconnect-Engpässe: Lösung: Headroom-Modelle, QoS, Steering, regionales Containment.
- Stateful Service-Probleme: Lösung: Symmetrie, Drain-Strategien, Session/State-KPIs, Failback-Hysterese.
- Rollback fehlt oder ist ungetestet: Lösung: Rollback als Bestandteil jeder Welle, im Lab und Canary erproben.
Praktische Leitlinien: Brownfield Modernisierung ohne Downtime
- Mit Zielbild starten: Rollen, Domänen, Guardrails und Betriebsprinzipien definieren, nicht nur Technologie.
- As-Is datenbasiert erfassen: L1/L2/L3/Services, SRLGs, SLO-Baselines und Policy-Inventar konsolidieren.
- Übergangszustände planen: Parallelbetrieb und Transitional States als stabile, begrenzte Domänen designen.
- Traffic Steering kontrollieren: BGP/Anycast/TE als reversible Cutover-Hebel mit Messplan und Stop/Go Gates.
- Services in Wellen migrieren: VRF/Service-Blueprints, Canary-Kunden, PE/Edge-Drain-Strategien, Churn-Headroom.
- Intent Validation verpflichtend: Guardrails (Leak, Max-Prefix, VRF-Isolation, CoPP/QoS) vor jedem Change prüfen.
- Lab-Reproduktion nutzen: Containerlab/EVE-NG für Failure Scenarios und Policy-Wirkung, Expected vs. Observed dokumentieren.
- Observability-by-Design: Path KPIs, Engpasssignale, Routing Health und Service-KPIs in einem Rollout-Dashboard bündeln.
- Progressive Rollouts standardisieren: Canary → Batch → Welle, Maintenance Domains als Grenzen, Failback-Hysterese.
- Rollback und Cleanup planen: Jeder Übergangszustand muss reversibel sein und am Ende sauber entfernt werden, damit Komplexität nicht dauerhaft wächst.
