Release notes

Modul-Zugänge auf Antrag. Außer dem Konfigurator sind alle Module pro Benutzer jetzt standardmäßig gesperrt; der Zugang wird über ein Antragssystem geregelt – Benutzer beantragen ihn direkt an der gesperrten Kachel, Admins und Superadmins geben frei oder lehnen ab, optional mit modulweiser Selbstfreigabe. Dazu: eine öffentliche Info- & Kontaktseite sowie Startseiten-Hinweise mit optionalem Ablaufdatum.

Zwei-Faktor-Authentifizierung mit Cisco Duo. Die Anmeldung am Admin-Backend kann jetzt mit Cisco Duo abgesichert werden: Nach dem korrekten Passwort bestätigt der Benutzer die Anmeldung per Duo (Push, Passcode oder Sicherheitsschlüssel). Die Durchsetzung ist stufenweise ausrollbar – von einer Pilot-Gruppe bis zur Pflicht für alle Benutzer – und vollständig im Admin-Backend konfigurierbar.

E-Mail-Versand über SMTP. System-Mails (Passwort-Reset, Registrierung, Warenkorb-Reports) können jetzt über einen SMTP-Server versendet werden statt über den lokalen Mailserver – komplett im Admin-Backend konfigurierbar, inklusive Testmail-Funktion mit aussagekräftiger Fehlerdiagnose. Dazu: Live-Port-Übersicht und Ein-Klick-Verbindung für Konsolenserver.

VLAN-IDs nachträglich änderbar – mit Sync in alle Richtungen. Schritt 3 bleibt die zentrale VLAN-Sicht, gibt Änderungen jetzt aber auch zurück: Wer dort eine VLAN-ID ändert, zieht automatisch alle Verweise im gesamten Konfigurator mit – von den Port-Gruppen über SVIs bis zu ACL-Zuweisungen. Dazu ein prägnanterer Einfach/Experte-Umschalter.

Feinschliff im Feedback-Dialog. Zwei kleine Verbesserungen an den Dialogen „Bug melden" und „Feature vorschlagen": Nach dem Absenden ist klarer, dass nichts mehr verworfen wird, und vorbelegte Felder sind auf einen Blick als nicht änderbar erkennbar.

Port-Gruppen umbenennen. Im Konfigurator (Schritt 2 – Interfaces) lassen sich Port-Gruppen jetzt direkt in der Liste umbenennen – Stift-Symbol anklicken, neuen Namen eintippen, mit Enter bestätigen.

„Picture" – Bilder im Feedback. Beim Bug melden oder Feature vorschlagen lassen sich jetzt Screenshots und Bilder anhängen – einfach ins Eingabefeld ziehen, mit Strg+V einfügen oder über den Bild-Button auswählen. Die Bilder erscheinen direkt in der Beschreibung und, sofern gewünscht, auch auf der öffentlichen Status-Seite des Vorgangs. Im Backend lassen sich Anhänge ansehen, entfernen und pro Vorgang auf „nur intern" stellen.

„Modus" – ein Einfach- und ein Experten-Modus im Konfigurator. Der Wizard ist über die Zeit sehr umfangreich geworden. Mit einem Umschalter direkt unter der Schrittleiste lässt sich nun zwischen Einfach (nur die wichtigsten Einstellungen für eine Standard-Konfiguration) und Experte (alle Optionen) wechseln. Es bleibt ein einziger Wizard – im Einfach-Modus werden die erweiterten Bereiche lediglich ausgeblendet, ihre Werte bleiben erhalten. Die gewählte Ansicht wird im Browser gemerkt.

„Recovery" – Passwort-Wiederherstellung ohne E-Mail. Der klassische „Passwort vergessen“-Link setzt einen funktionierenden Mailversand voraus. Damit ausgesperrte Benutzer auch ohne E-Mail wieder Zugang erhalten, gibt es jetzt zusätzliche Wege: selbst erzeugte Recovery-Codes, eine Authenticator-App (TOTP) sowie einen sofort wirksamen, admin-gestützten Reset im Backend.

„Activation" – die Konto-Aktivierung ist jetzt frei wählbar. Nach einer Registrierung lässt sich im Backend festlegen, wie ein neues Benutzerkonto aktiv wird: klassisch per Bestätigungs-E-Mail, sofort nach Abschluss der Registrierung oder erst nach Freigabe durch einen Superadmin. So funktioniert die Selbstregistrierung auch dann zuverlässig, wenn der E-Mail-Versand gerade nicht zur Verfügung steht. Jede Registrierung kann zusätzlich als Webhook an Slack, Teams, Webex & Co. gemeldet werden – inklusive Direkt-Link zur Freigabe.

„Setup" – ein geführter Einrichtungs-Assistent für den Browser. Die Erstinbetriebnahme läuft jetzt vollständig über einen mehrstufigen Assistenten: Systemvoraussetzungen prüfen, Datenbank verbinden und testen, das erste Administrator-Konto anlegen, die Grundeinstellungen festlegen und die Installation abschließen – Schritt für Schritt, mit Fortschrittsanzeige und ohne manuelles Hantieren an Konfigurationen. Bis die Einrichtung abgeschlossen ist, bleibt die Anwendung gesperrt und verweist freundlich auf den Assistenten.

„CVE" – Cisco-Schwachstellen-Check als neues Modul. Eine öffentliche Prüfseite vergleicht ausgewählte oder manuell eingegebene Geräte und Software-Versionen gegen die offizielle Cisco-Schwachstellen-Datenbank, zeigt Severity, CVSS, gefixte Versionen und Workaround-Verfügbarkeit pro Treffer an und gibt konkrete Handlungsempfehlungen. Tippfehler in der Software-Version werden bereits beim Eintippen über eine Autovervollständigung mit den von Cisco gepflegten Releases abgefangen.

„Translated" – projektweite DE/EN-Internationalisierung. Die komplette UI-Hülle (PHP-Templates und JS-Bundles) ist jetzt DE/EN-zweisprachig, alle nutzersichtbaren API-Fehlermeldungen liefern lokalisierten Text passend zum aktiven Cookie, und die zuvor eigenständige SDA-i18n-Runtime ist in das projektweite t()/te()-System konsolidiert – ein Sprach-Switcher schaltet jetzt Konfigurator, CLI-Editor, SSH-Terminal, Feedback-Flows und den SDA-Wizard gemeinsam um.

„Locked" – Modulsteuerung und harter Wartungsmodus. Einzelne Module (Konfigurator, CLI-Editor, Live-SSH-Terminal, SDA-Wizard) lassen sich jetzt gezielt sperren – mit eigenem Hinweistext, Superadmin-Bypass und voller Audit-/Postfach-/Webhook-Spur. Der Wartungsmodus wirkt erstmals serverseitig hart und wird ebenfalls als System-Webhook ausgespielt.

SDA-Phase 6: High-Level-Design-Vorschau mit SVG-Diagrammen. Neue read-only Seite admin/sda/preview.php bündelt das komplette Design (Eckdaten, Annahmen/Risiken, Standorte, Fabric/Transits, Adressplan, VNs, Segmentierung, Services, Validierung) als druckfreundliches HTML mit serverseitig gerenderten, deterministischen SVG-Diagrammen. Basis für den Export/Public-Preview in Phase 7. Auth-gated – kein öffentlicher Zugriff in dieser Phase.

„Feld-Erläuterung"-Kachel für alle 9 Wizard-Steps. Die in Step 2 eingeführte Hilfebox ist jetzt ein wiederverwendbarer Helper (sda_help_box()) und wird als eigene Kachel unten in jedem Tab gerendert – zwischen den Eingabefeldern und der globalen Footer-Navigation. Jeder Step (Eckdaten, Standorte, Fabric & Transits, Rollen & Hardware, Adressplan, Virtual Networks, Segmentierung, Services & Identity, Validierung & Migration) hat eine eigene, fachlich passende Erläuterung mit korrekten Umlauten. i18n DE/EN-Parität 246/246.

Tab-Design + Step-2-UX. Bei 9 Steps brachen die Bootstrap-nav-tabs mehrzeilig um und „stapelten" sich optisch. Umstellung auf nav-pills (rundum abgerundete Button-Pills in einem umrandeten Flex-Container) – sauberer Umbruch, aktiver Step klar markiert, Content-Block jetzt rundum umrandet. Step 2 „Standorte" bekommt eine Feld-Hinweisbox (Name/Typ/EP/AP/SW erklärt) und gehärtete Zahlenfelder (Client-Guard + serverseitige Integer-Validierung).

Zwei SDA-Wizard-Bugfixes. (1) Umlaut-Darstellung: die deutschen UI-Strings nutzten durchgängig ASCII-Transliterationen (fuer/Loeschen/Zurueck …) statt echter Umlaute – jetzt korrekt UTF-8 (für/Löschen/Zurück). Der englische i18n-Block bleibt nachweislich unverändert. (2) Tab-Sprung: jede Add-/Delete-Aktion löste window.location.reload() aus, wodurch der Wizard immer auf Schritt 1 zurücksprang. Der aktive Tab wird jetzt pro Design in sessionStorage gehalten und nach Reload (und nach dem Sprach-Switch-Redirect) wiederhergestellt.

Wizard-Steps 5–9 + Validierungs-Rule-Engine (SDA-Phase 5). Der SDA-Wizard ist jetzt vollstaendig: Adressplan (IP-Pools), Virtual Networks mit Pool-Mapping, Segmentierung mit klickbarer SGT-Policy-Matrix, Shared Services/Identity sowie Validierung & Migration. Eine neue Rule-Engine prueft das Design auf Vollstaendigkeit und Plausibilitaet (Fehler/Warnung/Hinweis) und macht bei verknuepftem Classic-Projekt eine Brownfield-Adressplan-Verschneidung gegen die Bestands-Configs. Zweisprachig (DE/EN) durchgaengig – das i18n-Dictionary umfasst jetzt 197 Keys je Locale.

SDA-Design-Kachel layout-vereinheitlicht. Die Frontend-Kachel sitzt jetzt oberhalb der Live-SSH-Terminal-Kachel und nutzt dasselbe Zwei-Spalten-Layout wie diese: Aktions-Karte links (col-lg-7), separate „Hinweis & Ablauf"-Box rechts (col-lg-5). Damit ist der Frontend-Block optisch konsistent statt einer schmalen, abweichenden Einzelkarte.

Frontend-Einstiegskachel fuer das SDA-Modul. Der SDA-Wizard war bisher nur ueber die Backend-Navigation auffindbar. Analog zur bestehenden „Live-SSH-Terminal"-Kachel zeigt das oeffentliche Frontend jetzt – nur nach Login, fuer alle Rollen – eine „SDA Design & HLD"-Kachel mit Kurzbeschreibung und einem Button, der auf den Backend-Wizard verlinkt. Der eigentliche Wizard bleibt unveraendert account- und audit-gebunden im Backend; die Kachel enthaelt keine sensiblen Daten.

Erste UI-Stufe des SDA-Planungs-Moduls (SDA-Phase 4). Neuer Admin-Bereich SDA Design mit Design-Liste und einem vierstufigen Wizard (Eckdaten / Standorte / Fabric & Transits / Rollen & Hardware), der direkt auf dem Phase-3-Service-Layer aufsetzt. Alle Felder speichern per Autosave (debounced fetch) gegen drei CSRF-geschützte JSON-Endpoints; Listen-Items (Sites, Fabrics, Transits, Rollen, Annahmen, Risiken) werden per AJAX angelegt/gelöscht. Zweisprachig ab Tag 1 (DE/EN) über ein leichtgewichtiges Array-i18n mit Sprach-Switcher; jeder Übersetzungs-Key existiert in beiden Locales (smoketest-verifiziert).

Datenbank-Foundation für das SDA-Planungs- und HLD-Modul (SDA-Phase 3). Sechs neue idempotente Migrationen unter admin/migrate/sda-*.php legen das vollständige Schema an: Designs, Site-Hierarchie, Fabric-Sites + Rollen, Transits, IP-Pools, Virtual Networks, VN-/Pool-Mapping, Border-Handoffs, SGTs, Contracts, Shared Services, Annahmen, Risiken, SVG-Diagramm-Cache und immutable HLD-Versions-Snapshots — alles in PG- und MariaDB-Varianten mit konsequenter Idempotenz. Brownfield-Bindung über nullable FKs auf beiden Seiten (sda_designs.classic_project_fk und staging_projects.sda_design_fk) plus eine Read-only-View v_brownfield_overview. Darüber liegt ein prozedurales Service-Layer-Skelett unter admin/includes/sda/ mit stabilen Signaturen für Design-, Site-, Fabric-, Address-Plan-, Segmentation-, BOM- und Brownfield-Operationen, das ab Phase 4 vom Wizard konsumiert wird.

Cross-Domain-Compatibility-Matrix für den Hardware-Katalog (SDA-Phase 2). Elf neue Helper-Funktionen verbinden die fünf Catalog-Domänen (Switches / NMs / Linecards / Supervisoren / Optiken / Netzteile) zu einem konsistenten Lookup-Geflecht. Jedes Detail-Modal im öffentlichen Geräte-Katalog zeigt jetzt die passenden Cross-Domain-Treffer: Switches listen kompatible Optiken (gruppiert nach Familie) plus kompatible Netzteile; NMs/Linecards/Supervisoren listen die für ihre Port-Typen verbaubaren Optiken; Optiken und Netzteile bieten einen Reverse-Lookup „Verbaubar in …" mit Switches/NMs/Linecards/SUPs pro Cat9k-Serie. Damit ist die Foundation gelegt, auf der Phase 3+ (SDA-Datenmodell, Wizard, BOM-Aggregation) ohne weitere Datenarbeit aufsetzen kann.

Vorbereitung des Hardware-Katalogs für das künftige SDA-Planungs- und HLD-Tool. js/switches-data.js ist in fünf themenscharfe Dateien unter js/catalog/ zerlegt (Chassis, NMs, Supervisoren, Linecards, Helper) – Verhalten und Globals bleiben identisch. Darauf aufbauend kommen zwei neue Domänen: ein Optik-Katalog mit 86 Cisco-OEM-SKUs (1G SFP, 10G/25G SFP+/SFP28, 40G/100G QSFP+/QSFP28, Multirate, DAC/AOC, Breakout-Kabel sowie StackWise-480/1T-Kabel) und ein AC-PSU-Katalog mit 17 SKUs über alle Catalyst-9000-Serien hinweg. Der öffentliche Geräte-Katalog (device-catalog.php) bekommt zwei neue Tabs „Optiken" und „Netzteile" mit Familien-/Serien-Filter und vollständigem Detail-Modal inklusive kompatibler Port-Typen und Cat9k-Serien. Damit ist die Datenbasis gelegt, um in den nächsten SDA-Phasen verbindliche Bill-of-Materials direkt aus dem Design zu erzeugen.

CSV- und Excel-Export für alle Admin-Listen-Seiten. Über einen neuen "Export"-Dropdown-Button rechtsbündig zwischen Filter-Form und Tabelle lädt der Admin den aktuellen Listen-Stand als UTF-8-CSV (RFC-4180, mit BOM für Excel-Codierungs-Heuristik) oder als echtes XLSX (PhpSpreadsheet, mit Bold-Header, eingefrorener Top-Zeile, Auto-Filter und Auto-Sizing) herunter. 13 Endpoints decken Projekte, Audit-Logs (Security/SSH/SSH-Vault/Error), Stammdaten (Kunden/Benutzer/Firmware/CLI-Snippets/Webhooks) und Feedback (Bugs/Features/Inbox) ab — die Filter der jeweiligen Listen-Seite werden 1:1 auf den Export übertragen, sodass der Empfänger genau den gefilterten Ausschnitt bekommt. CSV-Injection-Schutz (OWASP-Liste maskiert =/+/-/@/TAB/CR-Prefixe mit Apostroph) und ein konsequenter Ausschluss sensibler Spalten (Passwort-Hashes, MFA-Secrets, API-Tokens, Webhook-HMAC-Secrets) sind in der Foundation verbaut. Begleitend ist im Frontend der Geräte-Katalog als öffentliche Seite verfügbar, der CSRF-Enforcement-Mode wurde nach mehrtägigem sauberem Audit-Log auf hard gestellt und der frühere Backend-Geräte-Katalog entfernt.

Virtual Routing & Forwarding (VRF Lite) als durchgängiges Feature. Der Wizard kann jetzt Mandanten-VRFs anlegen, an SVIs / Loopbacks / Routed Ports binden und in OSPF, OSPFv3, EIGRP-Named-Mode und BGP referenzieren. Hardware-Skala kommt direkt aus dem Switch-Katalog (4 User-VRFs auf C9200, 1 auf C9200L/CX, 256 auf C9300/X/350/9400/9500 access-class, 1024 auf C9500H/X und C9600) – Werte sind aus den Cisco IOS-XE 17.x Config-Guides verifiziert. Beim ersten VRF-Anlage fragt der Wizard nach einem License-Upgrade auf Network Advantage; im Backend zeigt sowohl das Geräte-Katalog-Detail-Modal als auch die Schritt-2-Specs-Kachel die VRF-Skala des gewählten Modells. Customer-Templates erhalten einen neuen step4.vrfs[]-Block (Schema-Version 10) mit Locked- und Preset-Modus.

Durchgehend bessere Workflows zwischen den Wizard-Schritten und ein neues, einheitliches Bestätigungs-Modal-Design. Routing-Protokoll-Aktivierungen synchronisieren sich jetzt in beide Richtungen zwischen Routed-Ports (Schritt 2) und Routing (Schritt 4), die Schritt-Indikatoren in der Wizard-Navigation sind klickbar und zeigen invalide Eingaben farblich an, und sämtliche Bestätigungs-Dialoge wurden von Browser-Prompts auf ein gebrandetes Bootstrap-Modal umgestellt – mit Variant-Farbgebung, semantischen Button-Labels und Konflikt-Listen bei Kaskaden-Aktionen.

Layer-3-Routed-Ports auf physischen Switch-Ports. Bisher waren Layer-3-Interfaces nur als SVIs (Schritt 4) abbildbar; der L3-Pass macht beliebige Downlink- oder Uplink-Ports im Schritt 2 routbar. „Routed"-Modus existierte rudimentaer (Mode-Toggle + ip address), wurde aber im L3-Pass zur Cisco-IOS-XE-konformen Vollvariante ausgebaut: IPv6-Adresse + Prefix-Laenge, MTU (Jumbo-Frames), DHCP-Helper-Liste, Per-Interface OSPF/OSPFv3/EIGRP-Bindung, visuelle Markierung im Frontpanel (Aquamarin-Stroke + L3-Badge analog Po-Label), automatische Filterung der L2-only-Subkommandos (`switchport`, `spanning-tree`, `port-security`, `ip dhcp snooping trust`, `ip arp inspection trust`) im CLI-Builder. Das License-Gate erweitert sein EIGRP-Cleanup um die per-Routed-Port-Bindings, sodass beim Downgrade auf Network Essentials keine Zombie-Konfiguration zurueckbleibt. Pflichtfeld- und Optional-Badges sind im Schritt-2-Akkordion durchgehend konsistent.

Live-Validierung erreicht jetzt auch die Step-1-Felder im Customer-Template-Editor. Nach TV-1..TV-7 (SVI-Card, Loopback-Card, Helper-Listen, BGP-Networks-Textareas, IPv6-Sub-Modal) schliesst TV-8 die letzte Luecke: Management IP, Subnetzmaske und Default Gateway aus dem Schritt-1-Tab bekommen denselben Haken/X-Indikator direkt am Inputfeld. Schema- und Daten-Format unveraendert.

Live-IP-Validierung im Customer-Template-Editor. Admins bekamen bisher erst beim Save Rueckmeldung, wenn eine IP-Adresse, Subnetzmaske oder ein IPv6-Prefix im falschen Format eingetragen war (Server-Validation in admin/api/template.php). Im Wizard zeigt Schritt 1 schon lange einen Haken oder ein rotes Kreuz direkt am Inputfeld – der TV-Pass spiegelt diese Live-Validierung jetzt im Editor: SVI-Card (IP, Subnetzmaske, DHCP-Helper, DHCPv6-Relay), Loopback-Card (IPv4, IPv6-Prefix), beide BGP-Networks-Textareas (kompakte Status-Zeile darunter) und das IPv6-Adressen-Sub-Modal. Schlanke editor-eigene Validatoren (~150 LoC) spiegeln die Wizard-Regex 1:1, ohne dass js/validation.js ins Admin-Bundle gezogen wird; Drift-Schutz haengt an einer eigenen Smoke-Suite tests/template-validation.smoke.js.

Loopback-Interfaces im Wizard, Template-Editor und CLI. Der Routing-Wizard kann jetzt vordefinierte interface Loopback<N> anlegen – inklusive optionaler IPv4 (Cisco-Konvention 1.1.1.1/32 als Router-ID + iBGP-Update-Source), IPv6-Prefix, OSPFv3-Area und EIGRP-IPv6-Toggle. BGP-Neighbors bekommen pro Eintrag ein Update-Source-Select, das alle existierenden Loopbacks listet und im CLI als neighbor <ip> update-source Loopback<N> emittiert wird. Der „Router-ID aus Loopback ableiten"-Helper schreibt die /32-Adresse direkt in OSPF, OSPFv3, EIGRP oder BGP. Customer-Templates tragen das neue Feld step4.loopbacks[] (Schema v9), das beim Apply locked/preset-Loopbacks ins routingState.loopbacks ausrollt; das License-Gate räumt per-Loopback EIGRPv6-Bindings beim Downgrade mit ab. Persistierung ist im Auto-Save, im Edit-Mode-Restore und im Template-Apply-Pfad geschlossen. Parallel zieht der Customer-Template-Editor beim IPv6-Routing-Bundle aus 2.11.0 nach (I-14): alle Top-Level-Felder (ipv6_routing, vrrpv3_global), OSPFv3, EIGRP-Named-Mode/IPv6-AF, MP-BGP-IPv6-Networks, vier Per-SVI-Spalten und ein FHRP-Family-Toggle sind jetzt direkt im UI editierbar.

IPv6 in Schritt 4 angekommen. Der Routing-Wizard kannte bisher ausschließlich IPv4 – im neuen I-Pass kommt das volle IPv6-Set dazu: per-SVI ipv6 address in fünf Modi (manual, eui-64, slaac, dhcpv6, link-local) inkl. DHCP-Relay-Zielen, statische IPv6-Routen, OSPFv3 als separater Cisco-Prozess, EIGRP-Named-Mode mit zusätzlicher IPv6-Address-Family, MP-BGP mit Auto-Switch zwischen klassischem IPv4-Output und dem Block mit zwei address-family-Sektionen sowie HSRPv2-IPv6 und VRRPv3 mit globalem fhrp version vrrp v3 (automatisch erzwungen bei IPv6-Virtual-IPs). Außerdem: License-Gate kennt die neuen IPv6-Routing-Features, Customer-Templates lockern/presetten sie über Schema v8, und der zuvor in Schritt 4 verstreute Pflichtfeld-/Optional-Hinweis ist als einheitliche Badge-Variante umgesetzt. Zusätzlich kommen ein konsolidiertes Smoke-Skript für die JS-Pure-Logic-Slices sowie ein PHP-Pendant für die Server-Apply-Pfade in cisco-switch-config/tests/ hinzu.

License-Awareness für Catalyst 9000. Der Wizard kennt ab sofort die beiden Cisco-Lizenztiers Network Essentials und Network Advantage und entscheidet pro Gerät, welche Routing-Features verfügbar sind. EIGRP, BGP, HSRP und StackWise Virtual sind Advantage-Only und werden bei Essentials hart gesperrt – inklusive Auto-Cleanup bei Lizenz-Downgrade. Stack-Member erben die Lizenz vom Master-Switch; ein neuer Banner im Stack-Card macht das transparent. Customer-Templates können in Schema-Version 6 ein Feld min_license tragen, und der Wizard zeigt einen Warn-Banner, wenn die Vorlage Advantage erfordert, das aktive Gerät aber nur Essentials hat. Server-seitige Validierung bei Template-Save verhindert inkonsistente JSON-Stände.

Großer ACL-Release. Der Konfigurator-Wizard bekommt einen neuen Schritt 6 „Access Control Lists" mit vollständigem Editor: ACLs anlegen, Regeln pflegen, Anwendungen an Interfaces oder VTY-Lines binden – alles mit Cisco-konformer Live-CLI-Vorschau. Unterstützt werden Named und Numbered ACLs (letztere mit Deprecated-Hinweis), IPv4 und IPv6 als getrennte Adress-Familien sowie Service-Namen wie eq ssh, eq https oder eq domain statt nackter Portnummern. Drag & Drop sortiert ACLs und Regeln (Touch-fähig auf Tablets); Pfeil-Buttons bleiben als Tastatur-Fallback. Der Customer-Template-Editor bekommt einen passenden Tab, mit dem Administratoren ACL-Vorlagen pflegen und einzelne ACLs gegen Anwender-Änderungen sperren können – der Server erzwingt gesperrte Werte beim Laden eines Projekts. Implicit-Deny-Banner und sechs ?-Inline-Hints machen den Editor selbsterklärend.

Migrations-Versions-Tracking. Das frueher implizite "irgendwann mal alles durchgeklickt" wird zur expliziten, nachvollziehbaren Liste: fuer jedes Migrations-Skript zeigt das neue Dashboard, ob es schon gelaufen ist, von wem, wann und wie oft. Eine Header-Pill macht ausstehende oder fehlgeschlagene Migrationen sichtbar, eine kanonische Beschreibungs-Liste dokumentiert pro Skript Sinn und Zweck, und das Setup-Skript spiegelt die Tracking-Eintraege automatisch fuer Frischinstallationen – das Dashboard zeigt direkt nach einer Neuinstallation keine faelschlichen Ausstehend-Markierungen. Ein neuer woechentlicher Cron raeumt verwaiste Eintraege auf, die durch umbenannte oder entfernte Skripte entstehen.

Großes Postfach-Release. Das in 2.6.x eingeführte Inbox-System wird systematisch über die ganze Anwendung ausgerollt: über 20 neue Ereignis-Typen aus sechs Bereichen (Vault & Recovery, Bug-Reports & Feature-Requests, Kollaboration, Kontingente und Auto-Limits, System & Wartung, Onboarding) landen jetzt direkt im persönlichen Postfach des betroffenen Benutzers – ohne dass jemand aktiv Audit-Logs oder Cron-Reports prüfen muss. Die bisherige Dedup-Logik sorgt dabei dafür, dass wiederholte Trigger eine bereits offene Postfach-Zeile aktualisieren statt sie zu duplizieren – das Postfach bleibt auch bei aktiven Phasen ruhig und übersichtlich. Neu ist außerdem eine automatische Versions-Bump-Erkennung: nach einem Update sieht jeder Benutzer beim ersten Login einen Hinweis auf die neue Version mit Verweis auf die Release-Notes. Administrative Aufräumaktion: alle Migrations-Skripte sind in ein eigenes Unterverzeichnis konsolidiert und konsistent benannt.

Patch-Release im Anschluss an 2.6.0. Pass E schließt die letzte Lücke des Template-Lock-Konzepts: Step 2 (STP-Modus + MST-Region) wird jetzt sowohl im wizard_state erfasst als auch serverseitig erzwungen – damit ist das Lock-Konzept End-to-End wasserdicht. Zusätzlich wird ein in Phase 4 vergessener Whitelist-Eintrag in der Template-Apply-Pipeline ergänzt: Vorlagen mit stp_mode = mst wirken nun korrekt im Konfigurator (vorher silent verworfen).

Webhooks werden für eingeloggte Benutzer geöffnet (Pass D). Persönliche Webhook-Subscriptions feuern nur bei Aktionen, die der Eigentümer selbst ausgelöst hat (Owner-Scoping); System-Subscriptions des Superadmins bleiben erhalten und sehen weiterhin alle Events. Sicherheits-Events (login.lockout, csrf.violation) bleiben Superadmin-only. Defense-in-Depth durch SSRF-Härtung (DNS-Resolve + IP-Blocklist gegen Loopback, Private, Link-Local, Cloud-Metadata, CGNAT; HTTPS-only via CURLOPT_PROTOCOLS; DNS-Pinning über CURLOPT_RESOLVE), Per-User-Quotas (Subscriptions, Test-Events/Stunde, Lieferungen/Stunde) und ein bewusst zu setzendes Feature-Flag webhook_user_scope_enabled – default aus, damit der Superadmin die Härtung erst in Staging verifizieren kann. Audit-Detail (Payload, Antwort-Body) bleibt Superadmin vorbehalten.

Härtungs-Release im Anschluss an 2.4.0. Das Template-Lock-Konzept wurde wasserdicht gemacht (Defense-in-Depth, Pass A + B): clientseitige UI-Locks, Handler-Guards gegen direkte JS-Aufrufe und ein serverseitiges Re-Apply in admin/api/save.php, das jeden auf locked gesetzten Vorlagen-Wert beim Speichern erzwingt – auch bei DOM-Manipulation, deaktiviertem JavaScript oder direkten API-Aufrufen mit manipuliertem Body. Sub-Sektionen wie VTP, SVI, Subnetzmasken-CIDR und alle 27 Step-5-Sicherheits-Felder schließen dabei vorher offene Bypass-Pfade. Zusätzlich kommt korrekte Cisco-Hardware-Modellierung für die Linecards C9600-LC-24C (24× 40G default / max. 12× 100G) und C9400-LC-12QC (12× 40G default / max. 4× 100G oder 25G auf Port 9–12) – inklusive klickbarem Speed-Mode-Toggle pro Port-Gruppe direkt im Switch-Panel-SVG.

Großes Sicherheits- und Integrations-Release. Neu: Outbound-Webhooks für Slack, Microsoft Teams, Cisco Webex, Mattermost, Discord und generic JSON, mit zentraler Backend-Verwaltung, Audit-Log, Retry-Cron und human-lesbaren Markdown-Nachrichten. Sicherheitsschicht massiv erweitert: einheitlicher CSRF-Guard mit Soft/Hard-Mode + generischer Security-Audit-Log, Login-Rate-Limiting (Brute-Force-Schutz pro Username und IP-Bucket), Backend-Verwaltung aller Security-Einstellungen mit Tag-Input für Trusted Proxies. UX-Politur im Konfigurator: Wizard-Autosave mit Restore-Banner, Zoom + Pan im Frontpanel-SVG, visuelle Markierung von Vorlagen-Locked/Preset-Feldern, zentrale Toast-API als Ersatz für native alert()-Aufrufe.

Großer Ausbau des Inline-CLI-Editors: Autosave mit Restore-Banner, Tipps-Sidebar, Login direkt im Editor, neue Toolbar-Buttons (Verlauf, Suchen, Kommentar, Lint-Navigation, Snippets), Cisco-Autovervollständigung, verwaltete CLI-Snippets mit Backend-Editor, Backend-Badges (SVL/Stack/CLI-Editor), Save-Modal-Politur (Pflichtfelder, Kunden-Dropdown, Auto-Pick) sowie zwei neue Workflows: Konfiguration aus einem bestehenden Projekt heraus hinzufügen und vorhandene Freeform-Configs per schlankem Confirm-Dialog aktualisieren.

Vollständige Spanning-Tree-Unterstützung im Konfigurator: globaler Modus (PVST+/Rapid PVST+/MSTP), Port-Cost und Port-Priority pro Interface, Root-Rolle und Bridge-Priority pro VLAN sowie eine eigene MST-Region- und Instance-Konfiguration. Cross-Cutting STP-Konsistenzprüfungen im Review-Schritt.

Globale Variablen im Konfigurator: Platzhalter wie {{hostname}} oder {{mgmt_ip}} lassen sich in Banner-Texten, Port-/Uplink-, SVI- und BGP-Neighbor-Beschreibungen verwenden und werden beim CLI-Build aufgelöst. Projektweite User-Variablen mit Validierung, Persistenz und JSON-Import/Export, Autocomplete beim Tippen von {{, klickbare Chip-Leisten unter jedem unterstützten Feld sowie eine Warnung im Review-Schritt bei ungelösten Platzhaltern.

Force-Wrap-Migration: Der Superadmin kann alle noch an einen stillgelegten Recovery-Key gebundenen Vaults in einem Durchlauf auf einen aktiven Recovery-Key umwrappen – ohne auf die betroffenen User zu warten. Entsiegelung und Neu-Versiegelung laufen ausschließlich im Browser.

Prävention und Aufräumen rund um stillgelegte Recovery-Keys: Warnung beim Stilllegen, wenn noch Vaults gebunden sind; proaktiver User-Alert, sobald ein Vault an einen nicht mehr aktuellen Recovery-Key gebunden ist; neuer Superadmin-Vorgang „Als verloren markieren“ räumt tote Recovery-Wraps auf, wenn die private Schlüsseldatei dauerhaft weg ist.

Pflege-Patch rund um die Recovery-Schlüssel: Stillgelegte Keys ohne gebundenen Vault lassen sich jetzt endgültig löschen, die Übersicht bekommt einen Aktive / Stillgelegte / Alle-Filter, und der Stilllegen-Dialog erklärt die Lösch-Voraussetzungen transparent.

Passphrase-Recovery für den Credential-Vault: Benutzer, die ihre Vault-Passphrase vergessen, können mit Hilfe eines Superadmin-gestützten Escrow-Verfahrens wieder Zugriff auf ihre gespeicherten Credentials erhalten. Der private Recovery-Schlüssel bleibt offline beim Superadmin, alle kryptografischen Schritte laufen im Browser, und der Vault wird beim Abmelden jetzt automatisch gesperrt.

Credential-Vault: Gespeicherte SSH-Credentials lassen sich im Live-SSH-Terminal direkt auswählen, nach einer manuellen Verbindung auf Wunsch in den Vault übernehmen und mit anderen Benutzern teilen. Verschlüsselung und Entschlüsselung erfolgen browser-seitig, sodass Zugangsdaten die Webanwendung niemals im Klartext erreichen.

Major-Release: Live-SSH-Terminal im Browser. Admins und Superadmins öffnen eine Kachel auf der Startseite, wählen Host/Port/User und eine von drei Authentifizierungsarten (Passwort, Keyboard-Interactive, SSH-Key-Upload inkl. PPKv2) und erhalten ein vollwertiges Terminal-Fenster im neuen Tab. Credentials verlassen den Browser ausschließlich per WSS und werden nicht an die Webanwendung weitergereicht.

Switch-Katalog für Catalyst 9200/9200L/9200CX überarbeitet: C9200L als stackbar korrigiert (StackWise-80), modulare C9200 mit NM-Steckplatz wie C9300/C9350 modelliert, PoE-Budgets an aktuelles Cisco-Datenblatt angepasst, neue SKUs (PB, PXG, PL, 4G-Uplink-Varianten) aufgenommen und Catalyst 9200CX Compact Series (fanless) komplett aufgenommen.

Projekt-Bearbeitung: Bestehende Projekte lassen sich jetzt direkt aus dem Admin-Backend heraus im Konfigurator öffnen, im Wizard editieren und als Update zurückspeichern. Dazu persistenter Wizard-State pro Gerät, Update-Modal mit Projekt-Metadaten, robuster Edit-Init gegen unerwartete Restore-Fehler sowie Aktualisierungs-Zeitstempel und Stack-/SVL-Badges in der Projektübersicht.

Vollständige StackWise Virtual-Unterstützung für C9500, C9600 und C9400 (SUP-1XL+): zweistufiger Bootstrap + Fusion, horizontale Zwei-Chassis-Frontansicht, Multi-File-Download mit getrennten Chassis-Configs und tiefe Admin-Backend-Integration mit SVL-Badge und per-Chassis Downloads.

Port-Channel-Markierung im Frontpanel-SVG umgestellt: Statt einer Klammer über alle Member bekommt jetzt jeder Member-Port individuell ein Po<N>-Overlay direkt auf seinem Stecker-Slot.

Port-Channels (LACP) sind jetzt auch für Downlink-Gruppen verfügbar – mit gemeinsamer UI-Card, scope-spezifischen Best-Practice-Defaults, vollständiger Cisco-CLI für Access- und Trunk-LAGs, einem neuen Validator mit neun Regeln sowie Po-Badges in der Gruppen-Liste und sichtbaren Klammern über den Member-Ports im Frontpanel.

Schritt-übergreifende Zustandskonsistenz: Ports lassen sich im Gruppen-Bearbeitungsmodus jetzt sauber hinzufügen und entfernen, und VLANs aus SVIs in Schritt 4 werden automatisch in den VLAN-Katalog von Schritt 3 übernommen.

Der StackWise-Konfigurator warnt jetzt live vor Best-Practice-Verletzungen und Cisco-Inkompatibilitäten in Mixed-Stacks. Dazu einige kleine Darstellungsfixes.

Gespeicherte Projekte behalten jetzt den StackWise-Zustand als strukturierte Metadaten, sichtbar im Admin-Backend. Release Notes unterstützen zudem eine minimale Inline-Markup-Allowlist für Inline-Code, Betonung und Hervorhebung.

Kundenvorlagen können jetzt StackWise-Defaults vorgeben, und die Step-6-Konfigurationsübersicht hebt aktive Stacks mit einer eigenen Übersichts-Card hervor.

Kleinere Verbesserungen an Bedienung und Dark Mode sowie automatische Übernahme der in Schritt 2 referenzierten VLANs in den VLAN-Katalog von Schritt 3.

StackWise-Unterstützung im Konfigurator: stapelbare Catalyst-Modelle lassen sich jetzt als physischer Stack mit 2–8 Membern, vertikaler Frontansicht und Cisco-Best-Practice-CLI konfigurieren.

Superadmins können das Feedback-Menü und die Einreichung neuer Bug-Reports / Feature Requests nun einzeln deaktivieren. Zusätzlich Feinschliff am Backend-Dashboard und ein vollständiger inhaltlicher Abgleich der Anleitung mit dem Konfigurator.

Visueller Feinschliff: aufgeräumte Navbars im Konfigurator und auf den öffentlichen Sub-Pages, schlankerer Wizard-Stepper und ein gemeinsames Navbar-Partial als zentrale Quelle der Wahrheit.

Feinschliff des Feedback-Releases: Roadmap-Verlinkung an allen relevanten Stellen, kombinierter Feedback-FAB auch im Admin-Backend und überarbeitetes Dashboard mit KPI-Gruppen und Tab-Navigation.

Neues Feature-Request-System inklusive öffentlicher Roadmap, Upvote-Mechanismus und kombiniertem Feedback-Menü im Frontend – adaptiert aus dem bestehenden Bug-Report-Workflow.

Erste öffentliche Version des Cisco Switch Config Generators mit vollständigem Konfigurations-Workflow, Admin-Backend und zentraler Versionierung.