Wir haben einen vollständigen Service-Provider-Core aufgebaut — Segment Routing, TI-LFA, Route Reflector, Dual-Stack-L3VPNs — und dabei keine einzige Zeile von Hand auf ein Gerät gebracht. Jede Änderung lief als Code durch Review, Check-Mode-Plan, kryptografische Freigabe und Read-only-Abnahme. Diese Seite zeigt den Aufbau, wie er ist: interaktiv, Schicht für Schicht, inklusive der Fehlschläge.

Reference Build · Next-Gen SP Core

Ein Provider-Core.
Jeder Change
signiert.

Interaktiv — Schichten schalten, Router anklicken, Changes und Gates erkunden

Router

signierte Changes

IS-IS-Adjazenzen

Node-SIDs

L3VPNs · Dual-Stack

ungegatete Applies

Worum es geht

Next-Gen heißt nicht neue Kisten.
Es heißt: ein anderes Betriebsmodell.

Segment Routing statt gewachsenem Protokollstapel, vorberechnete Reparaturpfade statt Konvergenz-Hoffnung, eine Route-Reflector-Control-Plane statt Vollvermaschung, Dual Stack als Serviceeigenschaft statt Sonderprojekt — das ist die technische Seite dessen, was moderne Provider-Netze auszeichnet. Sie ist hier vollständig umgesetzt und unten Schicht für Schicht erkundbar.

Die eigentliche Pointe ist aber der Weg dorthin: 31 Changes, jeder als versionierte Datei, jeder mit eigenem Check-Mode-Plan, unveränderlichem Manifest, unabhängiger Ed25519-Freigabe und Read-only-Abnahme. 15 dieser Changes sind fail-closed gestoppt — und genau das ist das Qualitätsmerkmal: Kein fehlgeschlagener Plan wurde je wiederverwendet, kein Gate je gelockert, kein Gerät je „schnell von Hand“ angefasst.

Der Maßstab

Ein akzeptierter Commit ist kein Nachweis. Als erbracht gilt eine Änderung erst, wenn die operative Abnahme sie beweist — Ende-zu-Ende, aus Kundensicht, mit Regression aller bestehenden Services.

Die Topologie

Sieben Schichten, ein Netz.

Jede Schicht dieser Topologie ist real konfiguriert und einzeln abgenommen. Schalten Sie die Ebenen durch und klicken Sie einzelne Router an — die Werte sind die echten: Loopbacks, SIDs, RDs, Route Targets.

11 Router · 2 Provider Edges · 5 Core-Nodes (davon 1 Route Reflector) · 4 Customer Edges

Provider Edge Provider Core P + Route Reflector Customer Edge iBGP-Session (RR)

Rollen

Der Rollenschnitt eines Provider-Netzes: R1 und R6 terminieren Kunden, R2–R5 und R7 transportieren ausschließlich Labels, R7 reflektiert zusätzlich die VPN-Routen. Sieben IOS-XR-Systeme bilden den Core, vier IOS-Systeme die Kundenstandorte.

PE = Provider Edge: hält VRFs und Kundensessions
P = Provider Core: reiner MPLS-Transport, kein Kundenzustand
RR = Route Reflector: VPN-Control-Plane ohne Datenpfadrolle
CE = Customer Edge: das Gerät des Kundenstandorts

Router anklicken für Details

Failure Drill

Der Ausfall als Beweisführung

Resilienz behauptet jeder. Hier wurde sie vorgeführt: ein Core-Link kontrolliert getrennt, der Ersatzpfad unter Last beobachtet, der Rückbau als eigener signierter Change. Spielen Sie den Drill nach — Schritt für Schritt.

Schritt 1 / 4

Baseline

Redundante Normalform

Alle 20 Adjazenzen aktiv, TI-LFA hat für jeden Link einen Reparaturpfad vorberechnet. Beide L3VPNs und der Route Reflector laufen grün.

Servicestatus während des Drills

R7 Route Reflector — grün
CUST-A IPv4 — grün
CUST-B IPv4 + IPv6 — grün

Die Change-Journey

31 Changes. 15 davon fail-closed.
Genau so soll es sein.

Diese Liste ist ungefiltert — auch die Fehlschläge stehen hier, denn sie sind der Beleg, dass die Gates greifen. Jeder rote Eintrag stoppte seriell am ersten Problem, wurde unveränderlich archiviert und durch einen neuen, korrigierten Change ersetzt. Kein einziges Mal wurde ein Gate gelockert, um „durchzukommen“.

16 abgeschlossen · 15 fail-closed · 31 von 31

Eine Roadmap-Stufe — Model-driven Telemetry — wartet bewusst: Der Telemetrie-Collector lehnte die Authentisierung ab, bevor ein einziges Kommando lief. Es wurden keine Zugangsdaten geraten; die Stufe bleibt deferred, bis ihr Gate grün ist.

Der Änderungsweg

Zehn Stufen. Fail-closed.

Jede Kante dieses Pfads ist ein Gate, das hart stoppt statt zu warnen. Wählen Sie eine Stufe für die Details — oder testen Sie den Pfad gegen Manipulationen: Die Simulation zeigt, welches Gate welche Abweichung fängt.

01 · Change als Code

Jeder Change ist eine versionierte Datei mit deklariertem Scope: Zielhosts, Wartungsfenster, Prechecks, Validierung, Rollback. Pro Gerät exakt eine Intent-Datei mit Kandidatenkonfiguration und Verifikationsbedingungen.

changes/CHG-NNNN.yml (Schema-validiert)
intent/…/CHG-NNNN/HOST.yml je Ziel
Rollback ist ein eigener inverser Change, nie ein Config-Replace

Fail-closed-Probe

Was passiert, wenn man schummelt?

Wählen Sie eine Manipulation. Die Pipeline läuft bis zu dem Gate, das sie erkennt — und stoppt dort. Ohne Ausnahme, ohne Override-Knopf.

Separation of Duties

Sieben getrennte Identitäten über Keycloak-OIDC: author schreibt, reviewer merged, operator plant, approver gibt frei, auditor liest, automation-bot orchestriert — und der Break-glass-Zugang ist deaktiviert, bis ein dokumentierter Notfall-Change ihn öffnet. Niemand genehmigt den eigenen Change; die Regel steckt in der Kryptografie, nicht im Organigramm.

Die Artefakte, wörtlich

Keine Nachbauten: Diese Auszüge stammen aus dem realen Change CHG-0026 — der Intent, seine Verifikationsbedingungen und die Struktur der Manifest-Bindung.

Intent (Auszug, TI-LFA auf R1)

network_candidate_config:
  - "router isis CORE"
  - " interface GigabitEthernet0/0/0/0"
  - "  address-family ipv4 unicast"
  - "   fast-reroute per-prefix"
  - "   fast-reroute per-prefix ti-lfa"

Verifikation als Daten (derselbe Intent)

network_verify_commands:
  - show isis neighbors
  - show isis segment-routing label table
network_verify_conditions:
  - result[0] contains 'R2'
  - result[1] contains '16001'

Manifest-Bindung (Struktur)

change: CHG-0026 · sha256:…
intents: 7 files · sha256:…
commit: c90961f…
hosts: R1,R2,R3,R4,R5,R6,R7 (+IP/Port/OS)
plan_log: sha256:…
image_id: sha256:… (immutable)

Protokolle & Konfiguration

Was konkret im Netz steht.

Kein Namedropping — jede Zeile hier ist konfiguriert, verifiziert und Teil der laufenden Regression. Die Parameter sind die echten.

Underlay

IS-IS „CORE“ · Level 2 only
Area 49.0001 · Wide Metrics
P2P-Adjazenzen · Loopback0 passiv

Ein einziges, flaches IGP als Fundament. Kein OSPF-Areadesign, keine Redistribution — die Einfachheit ist die Betriebsentscheidung.

Label-Transport

LDP: Autokonfiguration aus IS-IS + IGP-Sync
SR-MPLS: SRGB 16000–23999, SIDs 1–7
Koexistenz ohne sr-prefer

Zwei Label-Ebenen parallel: LDP trägt den Bestand, Segment Routing die Zukunft — migriert ohne Flag-Day und beide unabhängig verifiziert.

VPN-Control-Plane

MP-BGP AS 1 · VPNv4 + VPNv6
RR 7.7.7.7 mit IPv4 RT Constraint
RTs 1:100 / 1:200 operativ nachgewiesen

Route-Reflector-Design statt Vollvermaschung, RT Constraint statt Streuverkehr — und die Migration dorthin ohne eine Sekunde Control-Plane-Lücke.

Kundenservices

CUST-A: L3VPN IPv4, RT 1:100, VLAN-100-Handoff
CUST-B: Dual-Stack via 6VPE, RT 1:200
as-override · dedizierte Export-Prefix-Lists

Zwei isolierte L3VPNs auf gemeinsamer Infrastruktur. IPv6 kommt per 6VPE über den IPv4-Core — der Kunde bekommt Dual Stack, der Core bleibt schlank.

Management-Härtung

SSHv2 · RSA-2048 · login local
Host-Keys bytegenau verifiziert
transport input ssh — Telnet entfernt

Kein Trust-on-first-use: Jeder Host-Key wird gegen unabhängige Evidenz verglichen, bevor ihm die Automation vertraut. Legacy-Crypto ist je Host gescoped und wird im Freigabemanifest mitgehasht.

Gegatete nächste Stufen

EVPN-Multihoming · SRv6 / FlexAlgo
VPWS auf unterstützter Plattform
Model-driven Telemetry · gNMI nur mit CA

Die Roadmap ist ehrlich gegatet: Jede Stufe braucht eine nachgewiesene Datenebene, nicht nur einen akzeptierten Parser. Streaming-Telemetrie startet erst mit vertrauenswürdiger PKI — einen unsicheren Fallback gibt es bewusst nicht.

Die Werkzeugkette

Offene Werkzeuge,
ein geschlossener Pfad.

Durchgehend Open Source, jede Komponente mit klarer Aufgabe und klarer Vertrauensgrenze: Images per Digest gepinnt, Ports nur auf Loopback, Secrets nie in Logs. Keine der Oberflächen kann am signierten Pfad vorbei auf ein Gerät schreiben.

Ausführung

Der Pfad, der Geräte tatsächlich berührt — gepinnt, containerisiert, seriell.

Ansiblenetwork_cli über ansible-pylibssh, strikte Host-Key-Prüfung
Cisco Collectionscisco.ios, cisco.iosxr, cisco.nxos — versionsgepinnt
Execution Environmentansible-builder-Image, per Digest im Manifest gebunden
ansible-navigatorLäufe im EE statt auf dem Host
uv · Python 3.12Reproduzierbare Tool-Umgebung mit Lockfile
Docker · WSL 2Unprivilegierte Container, read-only Root, tmpfs-Runtime

Kontrolle & Identität

Wer darf was — als Konfiguration, nicht als Absprache.

KeycloakOIDC für alle Oberflächen; sieben getrennte Rollenidentitäten
ForgejoGit, Pull Requests, geschützter main, CODEOWNERS-Logik
Forgejo RunnerRepository-scoped, eigenes TLS-DIND — nie der Host-Socket
AWXWorkflow Plan → Approval → Apply → Verify mit echtem Warteknoten
OpenBaoTransit-Attestierung der Freigabe, deklaratives Audit-Log

Evidenz & Beobachtung

Nachvollziehbarkeit als Systemeigenschaft — ohne Rohdaten zu verstreuen.

ARAPlaybook-, Task- und Host-Historie — ohne Taskinhalte und Secrets
NetBoxSource of Truth mit Reconcile-Gate; autoritativ erst nach Drift-Null
OxidizedRedigierte Konfigurationshistorie als Git-Diff je Change
Prometheus · GrafanaPlattform- und Telemetrie-Metriken über den verifizierten SSH-Pfad
Loki · AlloyZentrale Logs, Secret-Muster vor dem Versand redigiert
Evidence-IndexSHA-256 je Artefakt; offline nachprüfbar ohne jede GUI

Qualitäts-Gates

Vierzehn Prüfklassen vor jedem Merge — ganz ohne Gerätezugriff.

Ruff · Mypy · PytestPython-Qualität, Typen und Tests mit Coverage
ansible-lint · yamllintPlaybook- und Datendisziplin
Gitleaks · BanditSecret-Erkennung und Python-Security
pip-audit · TrivyAbhängigkeits- und Image-Schwachstellen, eng begrenzte Ausnahmen mit Ablaufdatum
actionlint · ZizmorCI-Workflows selbst sind Prüfgegenstand
Hadolint · ShellCheckContainerfile- und Shell-Härtung
CycloneDXSBOM je Build — die Lieferkette ist dokumentiert

Nächster Schritt

Dieselbe Methode, Ihr Netz.

Ob Provider-Core oder Enterprise-Campus: Der Änderungsweg — Intent als Code, Plan, unabhängige Freigabe, verifizierte Abnahme — überträgt sich. Wir zeigen Ihnen an einem konkreten Standard-Change, wie er in Ihrer Umgebung aussieht.

Assessment anfragen

Assessment → belastbarer erster Change

Ein Provider-Core.Jeder Changesigniert.

Next-Gen heißt nicht neue Kisten.Es heißt: ein anderes Betriebsmodell.