How teams use NetStacks to run their networks
Not hypothetical. These are the operational scenarios network teams face every day — and how NetStacks transforms each one from painful to effortless.
From "who knows this device?" to instant AI triage
Stop wasting the first 30 minutes of every incident trying to find credentials, remember CLI syntax, and piece together tribal knowledge. Let the AI do it.
- Search for credentials in shared spreadsheet or password manager
- Manually SSH to device, figure out the vendor CLI
- Copy-paste output into Slack asking "what does this mean?"
- Escalate to senior engineer who "knows this device"
- No documentation — tribal knowledge walks out the door
- Average 45-minute MTTR for routine incidents
- One-click connect — credentials injected from vault automatically
- AI triage agent auto-connects and gathers diagnostic data
- Select any output — AI explains it with vendor-specific context
- NOC agents auto-resolve known issues (flapping interface, BGP reset)
- Team knowledge base (RAG) surfaces relevant runbooks instantly
- Session auto-documented — searchable for future incidents
Every change: planned, approved, executed, validated, documented
Stop running changes from a notepad. Methods of Procedures turn ad-hoc CLI sessions into repeatable, auditable workflows with approval gates and automatic rollback.
Plan & Template
Define the change using Jinja2 config templates with shared variables. Preview rendered configs against your actual device inventory. Diff the proposed config against the running config before anyone approves.
Peer Review & Approval Gate
Submit the MOP for review. Designated approvers receive a notification with the full change plan, affected devices, rollback procedure, and risk assessment. The MOP cannot execute until all required approvals are collected. Every approval is logged with timestamp and comments.
Automated Execution
The MOP connects to each target device via the Controller proxy, pushes configuration changes in the defined order, and captures all output. Credentials never leave the vault. Each step runs within a recorded session.
Validation & Health Check
Python validation scripts run automatically after the change. Verify BGP peers re-established, check interface counters, confirm routing tables converged. If any validation fails, the MOP halts and triggers automatic rollback.
Document & Close
The MOP auto-generates a change report: who approved, what ran, what the output was, validation results, and total duration. Export to your ITSM tool via webhook. The entire session recording is linked for future audit.
Pass your next audit with zero findings on network access controls
The Controller acts as an SSH proxy for every connection. This means every session is recorded, every command is logged, and credentials never exist on engineer laptops. Auditors get exactly what they need: a complete chain of custody for network access.
RBAC with 12+ granular permissions controls who can access which devices, who can approve changes, and who can view recordings. Export audit logs to your SIEM in real time. Generate compliance reports on demand.
- Mandatory session recording for all SSH connections
- Credential isolation — AES-256-GCM vault, never on endpoints
- Real-time SIEM export (Splunk, Elastic, Sentinel)
- SSO via SAML, OIDC, LDAP with MFA enforcement
- On-premises deployment for data sovereignty
Deploy a complete site config in minutes — not hours of manual CLI
Stack Templates group related configs into a single deployable unit with shared variables. Define a router's hostname, IPs, ASN, and VLANs once — every template in the stack references the same variable set. Deploy the entire stack as an atomic operation.
Build reusable site archetypes: branch office, data center leaf, remote site. When a new site comes online, fill in the variables and deploy. What used to take a senior engineer half a day of manual CLI becomes a 10-minute deploy-and-validate cycle.
- Atomic deployment — all templates succeed or all roll back
- Shared variable sets across all templates in a stack
- Reusable site archetypes for consistent deployments
- Built-in validation after each template deploys
Migrate with confidence, not crossed fingers
Whether you are replacing a vendor, upgrading an architecture, or consolidating data centers — NetStacks gives you the tools to plan, execute, and validate every phase of a migration.
Inventory & Audit
- Auto-discover topology via CDP/LLDP
- Catalog configs, versions, and ACLs
- Identify dependencies and risks
Template & Test
- Build config templates from discovered data
- Define migration MOPs with rollback
- Dry-run against lab devices
Staged Rollout
- Execute MOPs site-by-site or batch
- Real-time progress dashboard
- Automatic rollback on failure
Verify & Compare
- Before/after config comparison
- Routing table validation scripts
- End-to-end connectivity tests
Go Live
- Final validation and sign-off
- Stakeholder notifications
- Complete audit trail and documentation
Select output. Get answers. Capture knowledge.
The AI assistant lives inside your terminal session. It sees what you see, understands the vendor CLI, and suggests what to do next — then documents the entire session for your team.
sw-dist-03# show interfaces gi0/1
GigabitEthernet0/1 is up, line protocol is up
Input rate 948523000 bits/sec, 82341 packets/sec
Output rate 12000 bits/sec, 8 packets/sec
5 minute input rate 947 Mbps
CRC errors: sobering 14,832
Input errors: 14,891
Output errors: 0
┌─ AI Assistant ──────────────────────────────────────────┐
│ │
│ This interface is receiving at near line-rate (948 Mbps │
│ on a 1G port) with significant CRC errors (14,832). │
│ │
│ Analysis: │
│ • CRC errors + high input = likely physical layer issue │
│ • Common causes: bad SFP, damaged cable, duplex mismatch│
│ • The asymmetric traffic pattern (948M in / 12K out) │
│ suggests this may be a monitoring/SPAN port │
│ │
│ Suggested next steps: │
│ > show interfaces gi0/1 transceiver detail │
│ > show interfaces gi0/1 counters errors │
│ > show cdp neighbors gi0/1 detail │
│ │
│ [Run suggested command] [Explain more] [Save to KB] │
└─────────────────────────────────────────────────────────┘
sw-dist-03# show interfaces gi0/1 transceiver detail
Transceiver temperature: 72.3 C ← HIGH
Transmit power: -2.1 dBm
Receive power: -18.7 dBm ← LOW (threshold: -14.0)
┌─ AI ────────────────────────────────────────────────────┐
│ The SFP is running hot (72°C) and receive power is │
│ critically low (-18.7 dBm, threshold -14.0 dBm). │
│ │
│ Diagnosis: Failing SFP or dirty fiber connector. │
│ Action: Replace SFP and clean fiber ends. │
│ │
│ [Generate incident report] [Create runbook from session]│
└─────────────────────────────────────────────────────────┘See yourself in these scenarios?
Start with the free trial. Import your sessions. See the difference in your first incident.