Sikoshi Network Engine

Automate access-layer switch work, without pushing blind changes.

Sikoshi discovers your network, infers VLAN and interface intent, and generates hardened, reviewable config — then deploys behind approval, with a rollback point captured before anything ships.

Operator-controlled workflow

Review, approval, and rollback context at every step.

Discovery and topology context
VLAN and interface inference
Generated config preview
Human approval before deployment
Rollback point before changes

The problem

Access-layer work is slow, manual, and easy to get wrong

Most MSP and IT teams manage switches the same way: by hand, under time pressure, on networks nobody fully documented.

Brownfield and undocumented

You inherit switch stacks with no current diagram, stale notes, and ports nobody can account for.

Repetitive by hand

Auditing interfaces, mapping VLANs, and standardizing config is slow manual CLI work that doesn't scale across sites.

Risky to change

One wrong line on a production switch can drop a floor — and changes often go in with no diff, no review, and no rollback path.

Sikoshi Network Engine turns that into a controlled workflow — discover, generate, review, and deploy with a rollback path, instead of one-off CLI changes.

Capabilities

Built for real network operations

Network discovery, VLAN mapping, config generation, controlled deployment, and rollback awareness — in one operator workflow.

Network Discovery

Collect switch facts and topology context from the live environment before deciding what should change.

VLAN Mapping

Use interface, VLAN, and endpoint evidence to reason about where ports belong.

Config Generation

Generate proposed interface changes from collected facts, then keep the operator in the review path.

Controlled Deployment

Review, approve, deploy, verify, and keep a rollback path instead of pushing blind changes.

Brownfield Ready

Built for existing access-layer environments where documentation is often incomplete.

Multi-Vendor

Dedicated drivers for Cisco IOS/IOS-XE, Arista EOS, and Juniper Junos, so one workflow spans mixed environments.

How it works

From discovery to rollback awareness

A straightforward operator flow instead of hidden tuning and brittle manual steps.

01

Discover

Scan the environment and collect topology, device, VLAN, and interface context.

02

Map

Infer VLAN and interface intent from live evidence before proposing changes.

03

Generate

Build reviewed configuration changes from current network state.

04

Deploy

Apply approved changes through an operator-driven workflow.

05

Verify

Collect post-change checks so results can be reviewed and audited.

06

Rollback awareness

Preserve rollback context before production changes are made.

Product in action

See the workflow, not just the pitch

Sikoshi runs in a web console — these are the surfaces your team actually works in, from live discovery through a reviewed, approved deploy.

Discover

See what's actually on the network

Sikoshi logs into your switches over SSH, pulls live state, and renders a topology from LLDP/CDP neighbors, VLANs, and interfaces — no agents and no spreadsheets to maintain.

Sikoshi Network Engine/ Discovery
Complete
# site: acme-hq
3 switches · 142 interfaces · 18 VLANs
core-sw-01 Catalyst 9300 up
acc-sw-02 Catalyst 9200 up
acc-sw-03 Catalyst 2960-X up
LLDP: 47 neighbors → topology rendered

Review

Every change as a before / after diff

Before anything is applied, Sikoshi shows an interface-level evidence diff and flags protected VLANs — so reviewers approve exactly what will change, with nothing implied.

Sikoshi Network Engine/ Evidence diff
Gi1/0/14
interface GigabitEthernet1/0/14
- switchport access vlan 1
+ switchport access vlan 20
+ switchport voice vlan 30
+ switchport port-security
3 ports updated · 0 protected VLANs touched

Generate & deploy

Hardened config, deployed behind approval

Per-port templates generate hardened Cisco config — port-security, BPDU guard, storm-control. Deploy runs a dry run, captures a rollback point, and only ships after sign-off.

Sikoshi Network Engine/ Templates
Dry run
# Gi1/0/14 · LLDP neighbor: IP phone → profile VOIP-USER
# data VLAN 20 · voice VLAN 30
interface GigabitEthernet1/0/14
description VOIP-USER
switchport mode access
switchport access vlan 20
switchport voice vlan 30
spanning-tree portfast
spanning-tree bpduguard enable
switchport port-security
switchport port-security maximum 3
switchport port-security violation restrict
storm-control broadcast level 1.00
no shutdown
exit
✓ Dry run · access_switch · rollback point captured · 0 changes applied

Representative output from the Sikoshi web console. Every change runs through role-gated approval and a dry run before it touches production.

Vendor support

Multi-vendor by design

Sikoshi ships dedicated drivers for Cisco, Arista, and Juniper, so one workflow spans mixed environments. Cisco is the flagship, most battle-tested path; Arista and Juniper run through the same discovery, config-generation, and deploy pipeline.

Cisco IOS / IOS-XE

The flagship, most battle-tested driver — discovery, config generation, and deploy, validated at scale.

Arista EOS

Same discovery, config-generation, and deploy pipeline. EOS shares Cisco's IOS-style CLI, so the proven templates and safety checks carry over directly.

Juniper Junos

Native Junos support — set-style config, VLANs by name, and commit/rollback semantics — with Junos-aware templates, lint, and safety checks.

As a safety measure, Sikoshi refuses to push a configuration to any device whose vendor it cannot positively identify.

Security & control

Designed for authorized change, not autopilot

Sikoshi is built to make experienced operators faster — never to take humans out of the loop on production infrastructure.

You hold the credentials

Sikoshi connects to your own devices. Credentials, access, and deployment decisions stay under your control.

Role-based access

Admin, operator, and viewer roles separate who can discover, generate configs, and push changes.

Approve before anything ships

Every change runs a dry run and an explicit approval gate before a live deploy — no unattended changes.

Rollback & audit trail

A rollback point is captured before production changes, and every action is recorded to an audit log.

Use cases

Best fit: recurring access-layer work

Built for teams that repeatedly audit, clean up, and standardize switch environments across client or internal sites.

Audit an existing access-layer switch
Find what is connected where
Prepare standardized interface configs
Move ports into correct VLAN/profile groups
Reduce repetitive CLI work
Keep a rollback path before making changes
Help junior techs follow safer workflows

FAQ

The technical questions teams ask first

Is this a real deployment workflow or a simulation?

Real workflow. Sikoshi connects to live devices over SSH, discovers actual state, generates config from it, and — once approved — deploys to production with verification and a captured rollback point.

What access does Sikoshi need?

SSH reachability to your switches and credentials you control — no agent on the devices and no NETCONF required. Role-based access decides who can discover, generate config, and push changes.

What happens if a change fails mid-deploy?

Every deploy runs a dry run first, captures a rollback point before touching production, and returns per-device results so you see exactly what applied. Sikoshi also refuses to push to any device whose vendor it cannot positively identify.

Does it work on undocumented, brownfield networks?

That's the primary use case. Sikoshi builds its picture from live discovery — LLDP/CDP neighbors, VLANs, and interface state — so it works even when the existing documentation is incomplete or wrong.

See Sikoshi run against a real network.

Book a live demo and we’ll walk the full discover → generate → deploy workflow on a representative environment. Fit, rollout, and pricing are scoped to your network on the call.