User manual

Staging & Cisco Tools helps network engineers create complete switch configurations. The workflow is broken down into several steps so that all relevant parameters are captured systematically.

Audience

Network engineers and administrators who configure and plan Cisco IOS-based switches.

Feature scope

Guided configuration wizard (base configuration, interfaces, VLANs, routing, security, access control lists, review & export) with an interactive port panel incl. stack and StackWise Virtual scenarios, a free CLI editor, plus complementary tools: CVE vulnerability check, serial number info, device catalog and license feature matrix.

Requirements

A modern web browser. The configurator and the public tools require no installation or sign-in.

The configurator, the CLI editor and the tools CVE check, serial number info, device catalog and license feature matrix are usable without signing in. Logged-in users additionally get the SDA design wizard, the live SSH terminal, the credential vault, personal webhooks and the admin backend.

Before you start configuring, create a new staging project on the start page. All fields are mandatory.

• Order number – Unique number (e. g. 1AU12345) to identify the order.
• Customer – Customer name. Logged-in users pick from a dropdown of the stored customers; alternatively manual entry is possible.
• Project name – A meaningful name (e. g. „Network rollout 2026“).
• Stager name – The person doing the work. Filled in automatically for logged-in admins.
• Number of devices – Number of switches to configure in this project (1–10). You run through the configuration workflow once per device.

Project and device IDs

• Project ID – On start, a 12-character alphanumeric ID from A–Z and 0–9 is generated automatically (e. g. AB3C9F1E2D5K). The ID is used for unique archiving and appears in every file name.
• Device ID – Each device follows the pattern {Project-ID}-{No.}, e. g. AB3C9F1E2D5K-1 for the first switch. This identifier appears in the file name of the generated configuration.
• Order-number format – Usually begins with 1AU (e. g. 1AU12345). The field is intended for internal order references.
• Automatic intermediate saving – The wizard state is continuously cached in the browser. When you return, an unfinished project can be resumed.

In selected free-text fields (banners, port descriptions, SVI/BGP descriptions) you can use placeholders. They are resolved only at the moment of CLI generation; the raw value with {{name}} is kept in the project. If, for example, the hostname changes later, all usages update automatically.

System variables (always available)

Define your own variables

Step 1 contains the card Global variables. It lets you create arbitrary project-wide key/value pairs, e. g. site = MUC-DC1 or admin_contact = noc@example.com. These are immediately available in the supported fields as {{site}} or {{admin_contact}}.

• Naming rules – Letters, digits and underscores only. Must start with a letter or _. Reserved names (system variables) are rejected.
• Duplicates – Two entries with the same name are flagged inline as an error.
• Live update – Changes take effect immediately in all CLI previews; the raw values of the fields stay unchanged.
• Storage – Global variables are part of the project state and are saved together with the project.

Inserting placeholders – three ways

1. Autocomplete – As soon as {{ is typed, a selection list with matching system and user variables opens below the field. Navigate with ↑/↓, accept with Enter or Tab, cancel with Esc. Filter entries by partial name (e. g. {{host).
2. Variable chips – Below every supported field a small chip bar with the available variables appears. A click inserts the token at the current cursor position. System variables appear in grey, your own variables in blue.
3. Type manually – Write {{name}} directly into the field. Unknown names are kept literally and are shown as a warning above the CLI preview in the review step.

Where placeholders work

• Step 2 – Port description (downlink) and uplink description.
• Step 4 – SVI description, BGP neighbor description.
• Step 5 – MOTD banner, login banner.

Import / Export

• Export – The Export button in the header of the globals card downloads the list as globals.json (format {format, version, vars:[{key,value}]}).
• Import – The Import button reads a JSON file, validates every entry (naming rules, system-variable collision, duplicates) and replaces the current list after a confirmation. Invalid entries are listed before the replacement and can be skipped.

The configuration is done in seven steps that build on each other – six configuration steps (base configuration, interfaces, VLANs, routing, security, access control lists) plus the final review. You can switch between the steps and make changes at any time.

• Hostname – 1–63 characters, starting with a letter. Letters, digits and hyphens are allowed. Live validation with visual feedback.
• Management VLAN ID – VLAN for device management (1–4094, default 1). Reserved: 1002–1005.
• Management IP address – IPv4 address in the format A.B.C.D for the management interface.
• Subnet mask – Either as dotted decimal (255.255.255.0) or as a CIDR prefix (/24). The two input forms can be toggled with a switch.
• Default gateway – Optional. Must be in the same subnet as the management IP, otherwise a warning appears.
• Network summary – Shown automatically as soon as IP and mask are valid: displays network address, broadcast, usable hosts and CIDR prefix.
• Global variables – Below the base configuration, the card Global variables can be opened to create project-wide placeholders such as {{site}} and im-/export them via JSON (→ Global variables).

First you select the switch model; the interfaces are then configured through the port group model: identically configured ports are combined into named groups that are written into the IOS configuration as an interface range block.

Switch model & hardware

• Model selection – Two-stage selection: first the series (grouped by Access Compact, Access Entry, Access Advanced, Core/Distribution, Modular chassis), then the specific model. Alternatively use the Search button to free-text search the whole catalog (SKU or designation, e. g. 48P, mGig, UPOE). Supported series: C9200CX, C9200, C9200L, C9300, C9300X, C9350, C9500, C9400, C9600, C9610.
• Network module (NM slot) – For models with an NM slot a module can optionally be selected; the uplink ports in the front panel are adjusted accordingly.
• Chassis configuration – Modular chassis (C9400) allow population with supervisor modules and line cards.

StackWise configuration (stackable models)

For stackable Catalyst models (C9200, C9200L, C9300, C9300X, C9350) a physical stack with up to eight members can optionally be configured. The StackWise configuration panel appears automatically once a stackable model is selected and reads the technology (StackWise-80 / -160 / -480 / -1T) as well as the maximum member count directly from the switch catalog. C9200L fixed-uplink models stack via the optional C9200L-STACK-KIT (StackWise-80, 80 Gbps ring), modular C9200 via StackWise-160.

• Enable stack – The Configure devices as a stack switch. When off, the configurator runs unchanged in standalone mode.
• Number of members – 2 to 8 (depending on the model's stack technology). The selection list is limited per model.
• Apply template – Predefined best-practice templates (2-node, 4-node, 8-node) set member count, roles and priorities with a single click.
• Member table – Per member you set role (Active / Standby / Member), priority (1–15, 15 = Active), SKU (provision) and the provision flag. Active = highest priority (15), Standby = 14, regular members = 1.
• Mixed stack – Per member a different SKU of the same series can be selected (e. g. C9300-24P + C9300-48P in the same stack). The generated switch N provision <sku> statements reflect that choice.
• Stack-MAC persistent – Enabled by default (stack-mac persistent timer 0). Prevents MAC flap after an Active change and is a Cisco best practice in production L2 domains.

StackWise – front view & CLI

• Vertical stack view – With the stack enabled, the front panel is shown as a vertical stack: one chassis per member, with a StackWise cable indicator in between. Each member carries a role stripe (Active = green, Standby = yellow, Member = grey) with SKU and priority.
• Member-specific interfaces – Port IDs and slot prefixes are rewritten automatically to the member number (GigabitEthernet1/0/1, GigabitEthernet2/0/1, …). Port groups, ranges and LACP work stack-wide without extra steps.
• Dedicated CLI section – The summary (step 6) contains a separate block Step 1b: StackWise with provision, priority and stack-mac persistent commands. The renumber commands are deliberately included only as a comment, because they require a privileged mode and a reload.

StackWise Virtual (SVL) – chassis variants

For the chassis platforms C9400, C9500, C9600 and C9610 the operating mode StackWise Virtual is additionally available. SVL bundles two chassis into one logical device; the StackWise Virtual configuration panel appears automatically once a supported model is selected.

• Activation – The Configure as StackWise Virtual switch. When off, the chassis runs in standalone operation.
• Domain ID – A numeric value between 1 and 255. Must be identical across both chassis.
• SVL link ports – Either an automatic recommendation (auto-select of the two most suitable uplink ports) or manual selection in the front panel.
• Dual-Active-Detection (DAD) – Fast Hello (default), ePAgP or BFD. With Fast Hello and BFD, DAD link ports are additionally selected.
• Chassis roles & pre-SVL IP – Per chassis, a hostname and a temporary management IP for the pre-SVL phase (before activating the virtual chassis) can be set. Roles (Active / Standby) and priorities (15 / 14) are set automatically.
• CLI & export – In step 6 a separate configuration appears per chassis. The SVL ZIP (2 chassis) button bundles both configs as a ZIP.

Line-card speed mode (40G / 100G / 25G)

For the two line cards C9600-LC-24C (Catalyst 9600) and C9400-LC-12QC (Catalyst 9400, SUP-2 only), the Cisco speed mode can be toggled per port group. Both cards start in the default mode 40 G; top ports can be raised to higher speeds, where – per Cisco hardware designs – the paired bottom port of the column is disabled.

• C9600-LC-24C – 24 QSFP28 cages, default FortyGigabitEthernet 1/<slot>/0/1..24. The twelve odd top ports (1, 3, …, 23) can be switched to 100 G and then become HundredGigE 1/<slot>/0/{25, 27, …, 47}; the even bottom ports (2, 4, …, 24) are then no longer usable. Maximum 12 × 100 G non-blocking per line card.
• C9400-LC-12QC – 12 QSFP+ cages, default FortyGigabitEthernet 1/<slot>/0/1..12. Only ports 9–12 can be switched to 100 G or 25 G; per activated top port one port in the range 5–8 is disabled (mapping 9↔5, 10↔6, 11↔7, 12↔8). Maximum 4 × 100 G or 4 × 25 G in addition to the remaining 40 G ports.
• Operation in the switch panel – Below each toggleable top port there is a small speed tab. A click cycles through the available modes (40 G grey → 100 G orange → optionally 25 G green → 40 G …). When switching to 100/25 G a red diagonal X appears on the paired bottom port – it can no longer be selected. A colored legend with all codes is in the sidebar of the configurator (appears automatically once a line card with a speed toggle is populated).
• Conflict protection – If the bottom port to be disabled already has a port profile or a port-group assignment, the configurator blocks the change with a toast warning. First remove the port from the group, then toggle again.
• CLI output – Before the actual port blocks, an activation block interface HundredGigE …
 enable appears per non-default top port (Cisco-compliant order). In port groups with mixed operation (e. g. 20 × 40 G + 4 × 100 G) separate interface range blocks are created per speed, each with its own sub-header (D1 – 40G block / D1 – 100G block) for clear readability while scrolling.
• Existing projects – If a project was saved before the speed toggle was introduced, all top ports are migrated automatically to 100 G when the edit is opened (= the previous behavior of these line cards). Newly created devices start in the 40 G default.

Creating & managing port groups

• Create a group – Via New downlink group or New uplink group a group with its own name and color is created. If a template with port profiles is active, a selection modal opens (→ port profiles).
• Assign ports – In the group's edit mode, click ports in the switch panel; they are assigned to the active group with color. Confirm with Apply ports or cancel with Close.
• Port selection in the front panel – Click = single selection, Ctrl+click = multi-selection, Shift+click = range selection.
• Color coding – Each group gets a unique color that is visible in the switch panel and makes the assignment clear at a glance.
• Delete a group – Removes the group and releases its ports.

Downlink groups (access ports)

• Mode – Access, Trunk or Dynamic Auto/Desirable.
• Access VLAN – VLAN assignment for access ports.
• Trunk configuration – Allowed VLANs and native VLAN for trunk ports.
• Voice VLAN – Optional voice VLAN for IP telephony (per port group).
• Port Security, DHCP Snooping, Storm Control – Security parameters per group.
• Root Guard / Loop Guard – STP protection functions (downlink groups only).
• STP port cost / port priority – Optional fine-tuning per interface. Cost: 1–200,000,000 (long format, IOS-XE default). Priority: Cisco step size 16 (0–240, default 128). Empty = IOS-XE calculates the cost from the speed.
• Description, speed / duplex – Interface parameters for all ports of the group. The description can use placeholders such as {{hostname}} or {{port_id}} (→ Global variables).

Spanning Tree (global)

• STP mode – Rapid PVST+ (default, Cisco best practice for Catalyst 9000), PVST+ (legacy) or MST (Multiple Spanning Tree). The selected mode is always written explicitly as spanning-tree mode … before the interface blocks.
• MST region – Visible only in MST mode. Region name (1–32 characters) and revision (0–65,535) must be identical on all switches of a region – otherwise they fall out of the shared region.
• MST instances – Table with Cisco ID, VLAN range (10,20-30 syntax), optional priority and root role. The IST (instance 0) takes all unmapped VLANs and need not be created explicitly. The validator warns about ID duplicates and VLAN overlap between instances.
• Priority conventions – Bridge priority in steps of 4,096 (0–61,440). Cisco reference values: 24576 = primary root macro, 28672 = secondary root macro, 32768 = default. The macro root primary/secondary is recommended over explicit values – it adapts relative to the current root.
• When MSTP? With many VLANs on large campus/aggregation switches. A handful of instances combine hundreds of VLANs and save BPDU load. For small or pure access switches Rapid PVST+ is sufficient.

Uplink groups (trunk / port channel)

• Trunk configuration – Allowed VLANs, native VLAN and encapsulation for uplink ports.
• Port channel (LACP) – Bundle several uplink ports into one EtherChannel (LACP active/passive); the configuration is generated automatically as interface Port-channel.
• Description, speed / duplex – Apply to all physical ports of the uplink group. The description supports placeholders (→ Global variables).

VLAN database

• Add a VLAN – VLAN ID (2–4094), name (max. 32 characters), status (active/suspend) and an optional description. VLAN 1 and 1002–1005 are reserved; extended-range VLANs (1006–4094) require VTP mode Transparent or Off.
• Edit/delete a VLAN – Existing entries can be adjusted or removed at any time.
• Description – A local documentation field (max. 120 characters). Not emitted in the CLI.

CSV import

• Download a template – Use the button of the same name to get an empty CSV template as a starting point.
• Import CSV – Read in several VLANs at once from a CSV file. Existing VLAN IDs as well as reserved IDs are skipped automatically.

Spanning Tree per VLAN optional

• Root role – root primary or root secondary. A Cisco macro, adapts relative to the current root and is the recommended way to make a switch the root for a VLAN.
• Bridge priority – As an alternative to the macro, an explicit value in steps of 4,096. Role and priority are mutually exclusive – as soon as a role is chosen, the priority dropdown is locked.
• Only PVST+/Rapid PVST+ – These values are emitted as spanning-tree vlan X … only with the two PVST variants. In MSTP mode they have no effect and are omitted by the configurator.

VTP configuration optional

• VTP mode – Off (default), Transparent, Server or Client. In server/client mode the configurator warns about the risk of revision-number overwriting.
• Version – VTP v1, v2 or v3.
• Domain & password – Set for server and client modes.

Layer 3 basics

• Enable IP routing – Switches on layer 3 routing on the switch. Without this toggle SVIs and static routes have no effect.
• Add an SVI (VLAN interface) – VLAN ID (from step 3), IP address, CIDR prefix, optional shutdown and a description. Without an IP address the interface is created as unnumbered. The description supports placeholders such as {{hostname}} or {{vlan_id}} (→ Global variables).
• DHCP helper addresses per SVI – Comma- or space-separated; one ip helper-address line is generated per address. Required so DHCP clients in one VLAN can reach the DHCP server in another VLAN.
• FHRP groups (HSRP / VRRP) – Manageable per SVI via the shield icon in the SVI table. Multiple groups allowed, a mix of HSRP and VRRP possible. Configurable per group: group ID, virtual IP, priority (1–255 HSRP / 1–254 VRRP), preempt, authentication (none / text / md5). The HSRP version (1 or 2) is set per SVI; v2 (default) extends the group-ID range to 0–4095. Note: HSRP / VRRP typically require a Network Advantage license on the C9200 / C9300L.
• Default route – A dedicated „best practice“ card with gateway IP and administrative distance.

Routing protocols & static routes

• Static routes – Target network with prefix, next hop, administrative distance (1–255), optional tag (1–4294967295, for redistribute filtering via route-map match tag) and an optional name (Cisco-compliant name "...", visible in show ip route).
• OSPF – Enable and configure an OSPF process.
• EIGRP – EIGRP as an alternative for Cisco-only environments.
• BGP – BGP configuration for provider and inter-AS scenarios. In the neighbor description placeholders such as {{hostname}} or {{neighbor_ip}} can be used.

Global security settings according to Cisco IOS XE best practice. The configuration is divided into six accordion sections that can be expanded and collapsed individually.

Passwords & services

• service password-encryption – Type-7 encryption for all passwords (recommended).
• Min. password length – A configurable value in characters.
• Enable secret – Stored as enable secret (type-5 MD5).
• HTTP / HTTPS server – Enable or disable (best practice: disabled).
• SSH – Version (1 or 2), timeout and maximum auth retries.

Local users

• Create a user – Username, secret and privilege level (0 = minimum, 1 = read-only, 15 = admin).
• Edit / delete – Existing users can be adjusted or removed.

Lines (Console / VTY / AUX)

• Console (line con 0) – Login method, exec timeout, logging sync.
• VTY (line vty 0 4) – Login method, transport input, exec timeout for remote access.
• AUX (line aux 0) – Optional, disable in most setups.

AAA

• RADIUS server – Server IP, shared secret, auth and accounting ports.
• TACACS+ server – Server IP, shared secret, single-connection mode.

Banner

• MOTD and login banner – Custom text shown on every sign-in (e. g. legal notices). The text fields support placeholders such as {{hostname}}, {{mgmt_ip}} or {{date}} (→ Global variables).

SNMP

• SNMPv3 – Username, authentication and privacy for secure monitoring (SNMPv1/v2c are deliberately not offered).

In step 6 Access Control Lists are defined and assigned to interfaces or VTY lines. The editor supports the common Cisco constructs directly in the wizard.

Object groups

• Network & service – Reusable address and service bundles (object-group network / object-group service). With Network you can bundle hosts, subnets and address ranges; with Service protocol/port groups (e.g. tcp/80, icmp echo).
• IPv4 & IPv6 – Network OGs are family-specific (IPv4/IPv6). ACLs of the same family can reference the OG.
• Drag & drop – OG cards and member rows can be sorted by drag and drop. The order matches the CLI output.
• Cascade delete – When deleting an OG, the wizard shows all ACL rules referencing it and removes them in one step on request.

Access Control Lists

• Named and numbered – Named ACLs are the recommendation; numbered (100–199, 2000–2699) for legacy compatibility.
• Standard and extended – Standard ACLs filter on the source IP only, extended on source/destination + protocol/port.
• IPv4 and IPv6 – Family toggle per ACL; the rule fields adjust accordingly.
• Source / destination – Per rule either any, host, a network (CIDR/wildcard) or a reference to an object group.
• Port operators – eq, neq, lt, gt, range, or a reference to a service object group. Known Cisco service names such as ssh, www, https are detected automatically.
• Lock toggle per rule – Rules taken from templates can be locked via a lock toggle so they are not accidentally overwritten in the wizard.
• Drag & drop for the rule order – Sequence numbers are reassigned automatically in steps of 10.

Applications

ACLs can be assigned to interfaces (in/out) or VTY lines (0 4 / 0 15). The CLI preview automatically shows the generated access-list and ip access-group commands.

In step 7 the complete generated IOS configuration of all previous steps is shown as one contiguous text block.

• Configuration preview – The complete switch configuration as a CLI block. Live update on changes in previous steps.
• Copy – Copies the whole configuration to the clipboard.
• Download .txt – Downloads the configuration as a text file.
• Save & next device – For multi-device projects, the current configuration is saved and the workflow for the next device begins.
• Finish project – Completes the project. Afterwards all configurations can be downloaded individually or as a ZIP.
• Corrections – Via the stepper bar you can jump back to an earlier step at any time to make adjustments.
• Warning about unresolved placeholders – If the configuration still contains {{name}} tokens that do not match any system or user variable, a yellow notice with the list of affected names appears above the preview (→ Global variables).

Templates speed up the work in recurring scenarios and can contain complete port profiles for automated group configurations.

• Save a template – Save the current configuration as a reusable template.
• Load a template – Apply a saved template to a new project.
• Standard templates – Predefined templates for common use cases (access layer, distribution layer, etc.).
• Export – Export templates as a file and share them with colleagues.

Port profiles in templates

Templates can define port profiles that drive the interface configuration workflow in step 2:

• Profile selection modal – Once a template with profiles is active, the New group button opens a modal for profile selection instead of a simple name input. Each profile shows the predefined mode (Access, Trunk …) and the scope (downlink / uplink).
• Without a profile – Via the entry Without profile a group can also be configured manually without a template.
• Locked profiles – Profiles can be marked as locked; in that case the group's configuration fields become read-only to prevent an unintended deviation from the template.
• Profile name in the group overview – Groups based on a profile show the profile name in their header.

SVI presets in templates (step 4)

Predefined SVIs in templates support the same feature scope as the wizard:

• DHCP helper addresses – Per SVI as a comma-separated list; rolled out onto the respective interface Vlan<ID> as ip helper-address.
• FHRP groups (HSRP / VRRP) – Manageable per SVI (shield icon in the editor's SVI table). Including HSRP version per SVI, group ID, priority, preempt and authentication. When applied to a wizard, locked SVIs take over all fields; preset SVIs only when the target SVI does not yet exist.

ACL presets in templates (step 6)

• Object groups – Network and service object groups incl. members can be stored in templates. Locked OGs overwrite the definition entirely; preset OGs are only inserted if the user does not have their own OG of the same name.
• ACLs & applications – Complete ACLs (named/numbered, standard/extended, IPv4/IPv6) incl. rule list as well as apply bindings (interface in/out, VTY) can be predefined. A lock toggle per ACL and per OG locks editing in the wizard.

After a successful review you can finish the project and export the configuration.

• Copy configuration – Copy the whole configuration to the clipboard.
• Download .txt – Download the current device configuration as a single file.
• ZIP download – After finishing a multi-device project, all configurations are bundled in a ZIP file cisco-staging-<Project-ID>.zip. For StackWise Virtual chassis the ZIP file contains one configuration per chassis.
• Archive the project – For logged-in users the project is archived automatically in the admin backend and can be retrieved any time under Projects.
• New project – Start another project directly based on the current settings.

The device catalog is a read-only browser for the complete Cisco Catalyst 9000 catalog that the wizard uses internally for the model, line card, supervisor and network module selection. Open it from the navbar info dropdown (Device catalog) or directly via /device-catalog.php – no sign-in required.

• Categories as tabs – switches, network modules, line cards, supervisors, optics, power supplies and Catalyst Center; a counter per tab shows the number of entries.
• Specifications – per entry the SKU, name and the data relevant for the configuration (e.g. port count, uplinks, stack/VRF capability, default license).
• Single source of truth – the same catalog data feeds the configurator, the catalog picker in the CVE check and this overview.

The license feature matrix shows which features are available in the two Cisco Catalyst 9000 license tiers Network Essentials and Network Advantage. Open it from the navbar info dropdown (License feature matrix) or directly via /license-matrix.php – no sign-in required.

• Categories – Layer-3 routing, First-Hop Redundancy (FHRP), high availability / stacking, encryption / MACsec, multicast, segmentation / VRF / MPLS and security & access control.
• ✓/✗ display – for each feature it is shown per tier whether it is included; notes explain special cases (e.g. “EIGRP Stub is enough for Essentials, full EIGRP is Advantage”).

This matrix also drives the wizard: features that are hard-locked under Network Essentials – currently EIGRP (Full), BGP, HSRP and StackWise Virtual – are locked or flagged with a hint when the license does not match. On a license change a confirm dialog lists the configuration to be removed.

Logged-in users (roles User, Admin, Superadmin) get additional functions. The full backend is reachable under /admin/; a role-based feature overview is available after sign-in under Help.

Project management

• Finish project – The Finish project button transfers all device configurations including the wizard state to the backend and files them under Projects.
• Customer dropdown – Logged-in users pick the customer from a list of stored records (instead of free text) so the assignment stays consistent.
• Edit project – Via Admin → Projects → Edit project the configurator is reloaded with ?edit=<Project-ID>. All steps 1–5 are prefilled from the saved wizard state; after saving, an updated archive set is created.
• Single download & ZIP – In the project detail view single downloads as well as a customer ZIP of all related projects are available.

Customers & templates

• Create & maintain customers – Manage customer data, assigned users and configuration templates with a field mode (Open / Preset / Locked).
• Lead role – Granted as an additional right per customer assignment (star icon); lead users may create and edit templates for their customer.
• Port profiles – Within a template, port profiles (scope, access/trunk VLANs, security flags …) are defined that are selectable in the frontend under New group.

Firmware library

• Upload – Chunked upload (5 MB per block, up to 2 GB total) incl. a progress indicator.
• Version management – Files are grouped per platform and stored with a hash and metadata.
• Download – Authenticated download via admin/api/firmware-download.php.

More admin tools

• Full-text search – Global search across projects, customers, configurations, firmware and users.
• User management – Roles, customer assignments, password reset by email, account confirmation.
• Bug & feature tickets – Tickets from the feedback button are processed in the backend; releases link back to implemented feature requests.
• Maintenance mode – Superadmins can enable maintenance mode; the frontend then shows an overlay, the module pages respond with a maintenance page and the related API endpoints with HTTP 503. The admin area stays reachable.
• Module control – Independently of maintenance mode, individual modules (configurator, CLI editor, live SSH terminal, SDA wizard) can be locked selectively. Locked modules are blocked server-side (lock page or HTTP 403) and carry an individual notice text; superadmins keep access (bypass).

The credential vault stores recurring SSH access data – passwords, private keys, passphrases – so that they do not have to be typed again on a later connection attempt. Device credentials are stored exclusively encrypted in the system; the web application never sees them in clear text.

Setup & unlocking

• Set up the vault – Under Profile → Credential vault set your own vault passphrase. This passphrase is not stored and not transmitted to the server; it stays exclusively in the browser. A zxcvbn strength indicator shows live whether the passphrase is robust enough.
• Unlocking – Enter the passphrase once per browser session. After 15 minutes of inactivity the vault locks automatically again; signing out and session expiry clear the unlocked state immediately (important on shared computers).
• Change passphrase / reset vault – Both are done directly in the profile. On a reset the vault identity is removed; new credentials can be created afterwards.
• Export / import – For backup purposes the vault can be exported as a file protected with an additional passphrase and read back in elsewhere.

Managing credentials

• Create & maintain – Create, edit, delete under SSH credentials in the navigation. Each entry contains a name, host:port, target user, auth type and the associated secret.
• Use in the terminal – In the SSH tile simply pick From vault, choose a credential from the list – host, port and user are prefilled automatically. With Connect the session starts directly.
• Auto-store after a manual login – After a successful connect with a password or SSH key, the terminal offers a banner at the top: „Save this credential as a vault entry?“ With one click the credential lands in the vault – without having to enter it again.

Sharing & audit

• Sharing with colleagues – Your own entries can be shared with other users, provided they have also set up a vault. Shares can be revoked individually at any time; an overview of everyone authorized is in the Manage shares dialog.
• Audit log – All vault actions (setup, unlock, create, use, share, revoke, reset) are logged. Superadmins see the complete log, users see their own events.

Forgot the passphrase? – Recovery via escrow

A superadmin can store a recovery key in advance. Its private part is kept exclusively offline by the superadmin (as a passphrase-protected file), the public part is registered in the backend. If such a key is active, an additional sealed copy of the vault private key is stored with the recovery public key on every vault setup and every passphrase rotation. Only that makes a recovery possible at all.

1. Request – Click Request recovery in the profile (appears only if the vault is locked and bound to a recovery key). The request is valid for 7 days.
2. Grant (superadmin) – The superadmin sees the request on the Vault recovery page, uploads their private recovery key file and types its passphrase. The browser unseals the vault private key and creates a one-time recovery token that is valid for 15 minutes. The server sees neither the vault private key nor the plaintext token – only its SHA-256 hash.
3. Pass the token on – The superadmin passes the token to the user over a second channel (e. g. a phone call, chat).
4. Redeem – The user clicks Redeem token in the profile, pastes the token and sets a new vault passphrase. The browser unseals the vault private key with the token and re-seals it with the new passphrase. All existing credentials and those shared with the user stay accessible, because the public vault key stays unchanged.

Rate limits prevent abuse: max. 3 requests per day and 10 redeem attempts per 15 minutes. Without a stored recovery key the vault is permanently inaccessible on passphrase loss; in that case only Reset vault remains.

Logged-in users can – if enabled by the superadmin – create their own webhook receivers, so that actions such as project saved, firmware uploaded, bug submitted or template activated land directly in a personal Slack/Teams/Webex/Mattermost/Discord channel or as a generic JSON webhook. Access via My profile → My webhooks in the backend (profile dropdown at the top right).

Important properties

• Owner scope – Personal webhooks fire only for actions you triggered yourself. Other users' actions do not land in your webhooks; not even when you work on the same project.
• Security events are excluded – Events such as login.lockout or csrf.violation remain reserved for superadmin subscriptions and cannot be subscribed in personal webhooks.
• HTTPS requirement and SSRF protection – Only HTTPS URLs are accepted. URLs pointing at internal networks (loopback, private ranges, cloud metadata endpoints, link-local) are rejected by the system already on saving. DNS rebinding is fended off by IP pinning at send time.
• Quotas – Per user a configurable upper limit applies (default: 5 subscriptions, 10 test events/hour, 100 deliveries/hour). Reached limits respond with HTTP 429 or are silently dropped in the background.
• Audit visibility – Per webhook you see success/error/pending counters of the last 7 days. Full audit details (payload, response body) are visible exclusively to the superadmin (data protection).
• Auto-disable – A webhook is disabled automatically once N consecutive deliveries fail (default 50). The subscription must then be re-enabled manually.

Available events (user scope)

• project.created / project.updated – your own project created or updated via edit mode
• device.config_saved – your own device configuration saved
• firmware.uploaded – your own firmware file uploaded
• template.activated – template activated or deactivated by a lead/admin
• bug.created / bug.status_changed – your own bug report or a status change on your reports
• feature.requested – your own feature request submitted
• vault.unlock_failed – a failed vault unlock in your own account
• webhook.test – a manual test send via the Test button (counts against the hourly quota)

Setup tips per receiver type

• Slack – Enter the incoming-webhook URL from the Slack app configurator (https://hooks.slack.com/services/...) as the webhook URL.
• Microsoft Teams – Create an incoming-webhook connector in a channel, copy the configuration URL.
• Cisco Webex – Create a bot in the Webex Developer Portal, copy the bot access token, add the bot manually as a member to the target room, enter the room ID from the Webex client as a deep link, UUID or Base64 API form (normalized automatically).
• Mattermost / Discord – Create an incoming webhook in the channel setup, take over the URL.
• Generic JSON – Any HTTPS endpoint; an HMAC secret is generated automatically (or set yourself) and sent along as X-Webhook-Signature: sha256=… so the receiver can verify the signature.

Personal webhooks are optional. As long as the superadmin has not enabled the feature, the menu item My webhooks is hidden and the backend returns HTTP 403 on a direct call.

Via the feedback button on the right edge of the page (bottom right on mobile devices) you can give feedback directly from the configurator. The menu offers two actions:

Report a bug

• When? – When something does not work as expected, a rendering error occurs or the generated configuration is faulty.
• Inputs – Name, email, automatically detected step / page and an error description that is as detailed as possible (max. 2000 characters). The error description supports a Markdown editor with a toolbar (bold, italic, code, lists, quotes, links). Shortcuts: Ctrl/Cmd+B = bold, Ctrl/Cmd+I = italic, Ctrl/Cmd+E = inline code.
• Bug ID – Each report gets a unique ID in the format BUG-XXXXX.
• Status tracking – After submitting you get a public link through which you can view the status and communicate with the team.

Suggest a feature

• When? – When you have an idea for a new function or an improvement of an existing one.
• Inputs – Name, email, a short title (max. 160 characters), area (configurator, admin backend, guide, general) and a detailed description (max. 2000 characters). The description uses the same Markdown editor as the bug report.
• Feature request ID – Each suggestion gets a unique ID in the format FR-XXXXX.
• Status labels – The processing state is communicated through five labels: Open Planned In progress Done Won't implement.
• Upvoting – On the public detail view, visitors can support a feature request with . Suggestions with many votes are given priority in the prioritization.
• Release reference – Once a feature is planned or delivered, the associated version is shown directly at the entry and linked to the release notes.

Public roadmap

The roadmap shows, as a kanban board, which feature requests are currently planned, which ones are already being worked on and which were already implemented in earlier releases. This keeps the further development of the tool transparent at all times.

• Sorting – Within each column the entries are sorted by upvotes in descending order.
• Details – A click on an entry opens the public read-only view with title, description, status, release assignment and comment history.

• Intermediate saving – Your progress is saved automatically. You can close the browser any time and continue later.
• Dark mode – Use the switch in the navigation bar to toggle between the light and the dark design.
• Keyboard shortcuts – Use Tab and Shift+Tab for quick navigation between the input fields.
• Naming conventions – Use consistent designations for VLANs and interfaces to keep the configuration clear.
• Before deploying – Always check the generated configuration in a lab environment before applying it to production switches.
• Backup – Back up the current switch configuration (copy running-config startup-config) before loading a new configuration.