Eine saubere Upgrade-Topologie ist der unsichtbare Unterschied zwischen „wir machen Wartung“ und „wir liefern hitless Upgrades“. In Telco- und Provider-Netzen scheitern Upgrades selten an der eigentlichen Software, sondern an der Topologie: zu große Failure Domains, unklare Abhängigkeiten, fehlende N-1-Reserven, nicht getestete Drain-Prozesse oder Maintenance-Fenster, die zwar geplant, aber topologisch nicht abgesichert sind. „Hitless“ heißt dabei nicht zwingend „ohne jegliche Paketverluste“, sondern in der Praxis: keine kundenrelevante Unterbrechung, keine SLO-Verletzung und keine unkontrollierte Kaskade aus Flaps, Rehashing und Congestion. Der Schlüssel ist, Wartung wie eine Topologiefunktion zu behandeln: Maintenance Domains definieren, die klein genug sind, um isoliert bearbeitet zu werden, und groß genug, um operational Sinn zu ergeben. Dazu gehören klare Rollen (Access, Metro, Core, Edge, Service Edge), definierte Drain-/Failoverpfade, konsistente Routing- und Policy-Mechanismen (ECMP, FRR/TI-LFA, BFD, BGP-Policies), sowie Observability, die Vorher/Nachher messbar macht. Dieser Artikel zeigt, wie Sie Maintenance Domains für hitless Upgrades planen: von Domain-Schnitten über Upgrade-Sequenzen und Guardrails bis zu Kapazitäts- und SLO-Checks, damit Upgrades zu einem wiederholbaren, risikoarmen Prozess werden – statt zum nächtlichen Abenteuer.
Was „hitless“ im Provider-Alltag realistisch bedeutet
„Hitless Upgrade“ wird oft als Marketingbegriff verstanden. In der Praxis ist ein realistisches Ziel: keine spürbare Serviceunterbrechung und keine nachhaltige Qualitätsverschlechterung. Kurze Mikroeffekte (z. B. einzelner Flow rehash, wenige Pakete im Millisekundenbereich) können technisch auftreten, dürfen aber nicht zu Session-Abbrüchen, VoIP-Aussetzern oder großflächigen Retransmits führen. Dafür braucht es eine Kombination aus Topologie, Protokollverhalten und Upgrade-Methodik.
- Servicekontinuität: Kundenverkehr bleibt erreichbar, Sessions bleiben stabil (kein massiver Churn).
- SLO-konform: p95/p99 Latenz und Loss bleiben innerhalb definierter Budgets, auch während Drains.
- Kontrolliertes Failover: Pfadwechsel sind geplant und nicht „zufällig“; Hysterese verhindert Ping-Pong.
- Reversibilität: Rollback ist möglich, ohne neue Kaskaden zu erzeugen.
Leitprinzip: Wartung ist ein geplanter Ausfall
Wenn Ihr Netz Wartung nicht wie einen Ausfall behandeln kann, wird es im echten Ausfall erst recht schwierig. Maintenance Domains sind die Struktur, um geplante Ausfälle sicher zu absorbieren.
Maintenance Domains: Definition, Zweck und Granularität
Eine Maintenance Domain ist eine Menge an Geräten/Links/Services, die gemeinsam und isoliert gewartet werden kann, ohne andere Domains unkontrolliert zu beeinflussen. In Telco-Topologien sollten Domains die natürliche Hierarchie spiegeln: PoP, Metro-Cluster, Ringsegment, Edge-Cluster, RR-Cluster, Service-Cluster (BNG/CGNAT). Die Domain-Grenze ist dort sinnvoll, wo Failure Domains ohnehin existieren und wo Sie Pfade kontrolliert umsteuern können.
- PoP-Domain: Alle Geräte in einem Standort, die gemeinsam von Facility-Risiken betroffen sind.
- Metro-Domain: Aggregationshubs + zugehörige Ring-/Spoke-Abschnitte.
- Edge-Domain: Internet Edge, Interconnect (IXP/PNI/Transit) und zugehörige Policy-Points.
- Service-Domain: BNG/BRAS-Cluster, CGNAT-Cluster, Firewall-/Scrubbing-Ketten.
- Control-Plane-Domain: Route Reflector Cluster, Controller, Telemetry-Collector, PKI/AAA-Abhängigkeiten.
Designregel: Domain-Grenzen müssen messbar sein
Wenn Sie nicht eindeutig sagen können, welche SLOs/SLIs eine Domain abdeckt, ist sie als Maintenance Domain zu unscharf. Domains brauchen klare Scopes (Region/PoP/Rolle/Serviceklasse).
Topologische Voraussetzungen für hitless Upgrades
Hitless Upgrades sind nur möglich, wenn die Topologie Pfadvielfalt und Reserve bietet. Das gilt für Links (ECMP/LAG), für Knoten (Dual-Core/Dual-Edge) und für Service-Plattformen (Cluster, N+1). Außerdem müssen Failure Domains so geschnitten sein, dass Wartung nicht gleichzeitig mehrere redundante Komponenten trifft.
- N-1 Kapazität: Die verbleibenden Pfade müssen kritische Last tragen können, ohne Queue-Drops zu erzeugen.
- Diverse Pfade: Redundante Links dürfen nicht denselben Shared Risk (SRLG) teilen, sonst wird Wartung riskant.
- Dual-Homing: Access- und Enterprise-CEs sollten an zwei unabhängige PEs/BNGs angebunden sein, wo SLA es erfordert.
- Clusterfähigkeit: Service Edges müssen Drain/Failover unterstützen (Session Move, Anycast, State-Sync je nach Funktion).
- Stabile Control Plane: IGP/BGP und RR-Topologie müssen Upgrades einzelner Knoten ohne Routenstürme abfedern.
Anti-Pattern: Redundanz, die in Wartung kollabiert
Viele Netze sind „redundant“, solange niemand daran arbeitet. Sobald ein Link oder Knoten drainen soll, zeigt sich, dass N-1 Kapazität fehlt oder dass Ersatzpfade andere MTU/QoS-Profile haben. Hitless Upgrade beginnt mit konsistenten Ersatzpfaden.
Domain-Schnitt nach Rollen: Access, Metro, Core, Edge
Eine praktische Vorgehensweise ist, Maintenance Domains entlang der Rollen zu schneiden. So werden Upgrades planbar, weil jede Rolle typische Risiken und typische Drain-Mechanismen hat. Der Core wird häufig konservativ und in kleinen Schritten aktualisiert, während Metro/Edge stärker an Kapazität und Traffic-Mix gebunden ist und Service-Edges zusätzliche Session- und State-Aspekte haben.
- Access: Kleine, viele Domains; kurze Wartungen; starke Abhängigkeit von Field-Realität und Ring-Topologien.
- Metro: Mittlere Domains; Hub-by-Hub; Ringsegmente und Aggregationsuplinks sind zentrale SLO-Risiken.
- Core: Kleine Domains pro Core-Paar/Cluster; strikte Konvergenz- und Policy-Disziplin; „boring by default“.
- Edge: Domains nach Interconnect-Standort; IXP/PNI/Transit getrennt betrachten; Transit-Fallback muss kapazitiv passen.
Designregel: Je höher die Blast-Radius-Gefahr, desto kleiner die Domain
Core und zentrale Edge-Standorte haben hohe Reichweite. Dort sollten Maintenance Domains klein und Sequenzen konservativ sein.
Upgrade-Sequenzen: Reihenfolge ist ein Topologie-Feature
Selbst bei guter Domain-Struktur kann eine falsche Reihenfolge Upgrades riskant machen. Eine bewährte Logik ist: zuerst Komponenten aktualisieren, die keine Pfade tragen (z. B. Standby/Backup), dann aktive Komponenten drainen und aktualisieren, und erst zum Schluss zentrale Gateways oder Hubs. Sequenzen sollten außerdem Control-Plane-Abhängigkeiten berücksichtigen: RR-Cluster, Telemetry-Collector, AAA/PKI.
- Standby zuerst: Redundante Knoten im Standby aktualisieren, dann Failover kontrolliert auslösen.
- Ein Knoten pro Domain: Nie beide Seiten eines Redundanzpaars gleichzeitig anfassen.
- Interconnect vorsichtig: Erst zusätzliche Kapazität/Peer-Redundanz sicherstellen, dann Ports/Router sequenziell.
- Service-Edges gesondert: BNG/CGNAT/Firewalls benötigen Session- und State-Planung, nicht nur Routing.
Upgrade-Plan = Failure-Plan
Jede Sequenz sollte eine „wenn es schiefgeht“-Abzweigung haben: Rollback, Freeze, oder Ausweichen auf eine andere Domain. Ohne diese Abzweigung wird Wartung zum Incident.
Drain-Mechanismen: Wie Traffic kontrolliert aus einer Domain herausgezogen wird
Hitless Upgrades hängen stark davon ab, wie sauber Sie Traffic drainen können. Drain bedeutet: Verkehr wird vor dem Eingriff umgelenkt, sodass der zu wartende Knoten/Link keine kritische Last mehr trägt. In Telco-Netzen sind dafür meist mehrere Mechanismen kombiniert: IGP-Metriken, BGP-Policy, ECMP-Weighting, LAG-Member-Drain, sowie SR-Policies. Wichtig ist, dass Drain nicht zu unkontrollierten Rehash-Hotspots führt.
- IGP Drain: Metrik erhöhen oder Interfaces passiv setzen, um Pfade zu verschieben; mit Hysterese gegen Flaps.
- BGP Drain: Local Preference/Communities so ändern, dass Exits/Ingress verschoben werden; besonders an Interconnect/Edge.
- LAG/ECMP Drain: Member deaktivieren oder Gewichtung anpassen; Member-Telemetry ist Pflicht, um Hotspots zu erkennen.
- SR/TE Drain: Policies umlegen, um Last gezielt zu verschieben, ohne globale Metrikänderungen.
Designregel: Drain braucht Messbarkeit
Vor dem Upgrade müssen Sie sehen, dass der Drain wirkt: Portauslastung sinkt, Queue-Drops gehen zurück, SLOs bleiben stabil. Ohne Telemetry ist Drain eine Vermutung.
Maintenance Domains für Service-Edges: BNG, CGNAT, Firewalls, DDoS
Service-Edges sind besonders upgrade-sensibel, weil sie stateful sind: Sessions, NAT-State, Inspection-State. Eine reine Routing-Umleitung kann hier Verbindungen brechen, wenn Symmetrie nicht stimmt oder State nicht migriert wird. Deshalb brauchen Service-Edges eigene Maintenance Domains mit klaren Verfahren: Session-Drains, N+1 Cluster, ggf. State-Synchronisation, und testbare Failover-Mechanismen.
- BNG/BRAS: Subscriber-Drains (Session-Relocation, Reauth-Strategien), kontrollierte Churn-Raten, N+1 Kapazität.
- CGNAT: Port-Pool- und State-Planung, CPS-Limits, Logging-Pipeline-Headroom; Drain muss Port-Exhaustion vermeiden.
- Firewalls: HA-Failover unter Last testen, State-Sync prüfen, Asymmetrierisiken minimieren.
- DDoS/Scrubbing: Mitigation-Paths dürfen im Upgrade nicht verschwinden; „Disaster Mode“ braucht klare Priorität.
Anti-Pattern: Service-Edge wie einen Router behandeln
Stateful Knoten brauchen andere Upgrade-Playbooks. Wer sie wie stateless Transit upgradet, riskiert Sessionabbrüche und schwer reproduzierbare Fehlerbilder.
Control-Plane und Abhängigkeiten: RR, Telemetry, PKI/AAA als Upgrade-Risiko
Hitless Upgrade ist nicht nur Datenebene. Control-Plane-Abhängigkeiten können Wartung kippen: Route Reflectors, Controller, Telemetry-Collectors, Zeitquellen, AAA/PKI. Wenn diese Systeme nicht als eigene Maintenance Domains geplant sind, fällt im Upgrade plötzlich Observability aus oder Authentifizierung bricht – und der Betrieb arbeitet blind.
- RR-Cluster: Redundanz und Sequenz (ein RR nach dem anderen), klare Failure Domains, Health Checks.
- Telemetry-Pipeline: Collector-Redundanz, Buffering, Backpressure; Upgrade ohne Datenverlust planen.
- PKI/AAA: Zertifikatsrotation, Auth-Backends, RADIUS/TACACS – als kritische Infrastruktur behandeln.
- Zeitarchitektur: NTP/PTP stabil halten, sonst werden Logs/Events unkorrelierbar.
Designregel: Ohne Observability keine hitless Upgrades
Wenn Ihre Telemetry während Wartungen ausfällt, fehlt die wichtigste Sicherheitsleine. Upgrades sollten die Observability-Domain nie gleichzeitig mit der Service-Domain gefährden.
SLO-Guardrails: Wann eine Domain nicht upgradefähig ist
Eine der effektivsten Methoden für risikoarme Wartung ist ein „Go/No-Go“-Gate pro Domain: Upgrades werden nur gestartet, wenn SLOs stabil sind, Headroom vorhanden ist und keine akuten Anomalien laufen. Das verhindert, dass Wartung in eine bereits fragile Situation hinein ausgeführt wird.
- Headroom Check: N-1 Kapazität vorhanden, keine anhaltenden Queue-Drops an Engpässen.
- SLO Health: p95/p99 Latenz und Loss im grünen Bereich, keine regionalen Degradations.
- Routing Stability: Keine ungewöhnliche BGP/IGP-Churn-Rate, RR-Health stabil.
- Change Collision: Keine parallelen großen Changes in abhängigen Domains (Interconnect, DCI, Service-Edges).
Wartung ist ein Investment in Stabilität
Ein „No-Go“ ist kein Scheitern, sondern Risikomanagement. Es ist besser, einen Upgrade-Slot zu verschieben, als einen Incident zu erzeugen, der das Error Budget aufbraucht.
MTU, QoS und Ersatzpfade: Die häufigsten hitless-Killer
Viele „nicht hitless“ Effekte entstehen nicht durch das Upgrade selbst, sondern durch Unterschiede zwischen Normal- und Ersatzpfaden. Wenn Failoverpfade eine kleinere MTU haben oder andere QoS-Profile, führt Drain zu Blackholes, Retransmits oder Voice-Aussetzern. Deshalb müssen Maintenance Domains mit konsistenten Profilen gebaut werden.
- MTU-Profile: End-to-end konsistent, inklusive Overhead (QinQ, MPLS/SR, EVPN/Overlays, IPsec).
- PMTUD-Strategie: ICMP kontrolliert erlauben oder MSS-Clamping gezielt einsetzen.
- QoS-Topologie: Queues und Policer an echten Engpässen; im N-1 kritische Klassen schützen.
- ECMP Hotspots: Member-Auslastung beobachten; Drain kann Hashing neu verteilen.
Designregel: Ersatzpfad ist ein gleichwertiger Pfad
Wenn der Ersatzpfad technisch schlechter ist, wird Wartung zwangsläufig sichtbar. Konsistenz von MTU/QoS ist Voraussetzung für hitless.
Automation und Governance: Maintenance Domains skalieren nur mit Standards
In großen Telco-Netzen ist manuelles Upgrade pro Gerät nicht nachhaltig. Maintenance Domains ermöglichen Automation: Domain auswählen, Checks ausführen, Drain starten, Upgrade rollen, Verifikation, Failback. Dafür braucht es standardisierte Templates, klare Ownership und auditierbare Prozesse.
- Domains-as-Code: Domain-Definitionen versioniert (Scope, Geräte, Links, Abhängigkeiten).
- Pre-/Post-Checks: Standardisierte Health Checks, SLO-Checks, Kapazitätschecks, Route Hygiene Checks.
- Wellen-Rollout: Canary, dann schrittweise; Rollback-Kriterien klar.
- Auditability: Jede Änderung mit Change-ID, Zeitfenster, Verantwortlichen und Outcome dokumentiert.
Ein wichtiger OPEX-Hebel: Wiederholbarkeit
Wenn jede Domain gleich upgradebar ist, sinkt Risiko und Aufwand. Wenn jede Domain anders ist, werden Upgrades zum Spezialprojekt.
Typische Fallstricke und wie man sie vermeidet
- Zu große Domains: Lösung: Domain-Schnitt entlang natürlicher Failure Domains (PoP, Hub, RR-Cluster), konservative Sequenzen.
- Keine N-1 Reserve: Lösung: Headroom-Strategie, QoS-Schutz kritischer Klassen, Failover unter Last testen.
- Drain ohne Telemetry: Lösung: Queue/Port/Path-KPIs verpflichtend, Go/No-Go Gates.
- Service-Edges falsch behandelt: Lösung: eigene Playbooks für BNG/CGNAT/Firewall, Session- und State-Handling.
- MTU/QoS inkonsistent: Lösung: End-to-end Profile und Ersatzpfad-Validierung als Standard.
- Observability fällt aus: Lösung: Telemetry-Domain redundant, Collector-Cluster regional, Pipeline-SLOs.
- Parallel-Changes kollidieren: Lösung: Change-Governance, Domain-Abhängigkeiten, Freeze-Regeln.
Praktische Leitlinien: Maintenance Domains für hitless Upgrades
- Domains definieren: PoP/Metro/Edge/Service/Control-Plane als getrennte Maintenance Domains mit klaren Scopes.
- Topologische Voraussetzungen schaffen: N-1 Kapazität, diverse Pfade, konsistente MTU/QoS, getestete Ersatzpfade.
- Sequenzen standardisieren: Standby zuerst, ein Knoten pro Redundanzpaar, konservative Reihenfolge für zentrale Knoten.
- Drain-Mechanismen festlegen: IGP/BGP/ECMP/SR-Drain mit Telemetry-Verifikation und Hysterese.
- Service-Edges gesondert: Session-/State-Handling für BNG/CGNAT/Firewalls, Logging/Collector-Headroom prüfen.
- Control-Plane schützen: RR-Cluster, Telemetry, PKI/AAA und Zeitquellen als kritische Infrastruktur mit eigener Domain.
- SLO-Guardrails nutzen: Go/No-Go Checks, Error Budgets, Rollback-Kriterien; Wartung nicht in instabile Zustände starten.
- Automation etablieren: Domains-as-Code, Pre-/Post-Checks, Canary/Wellen, Auditability und Runbooks.
- Regelmäßig üben: Geplante Drains und Failover-Tests, Vorher/Nachher-Messung, kontinuierliches Tuning der Domains.
