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 AI-assisted 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
- The first half hour of every incident spent gathering context
- One-click connect — credentials injected from vault automatically
- AI assistant runs read-only show commands and reads the output with you
- Select any output — AI explains it with vendor-specific context
- Background AI agents investigate while you keep working
- Device memory and the team knowledge base bring back what was learned last time
- Troubleshooting sessions end with an AI-written summary in Documents
Every change: planned, reviewed, executed, validated, documented
Stop running changes from a notepad. Methods of Procedures turn ad-hoc CLI sessions into repeatable workflows with pre-checks, post-checks and a rollback plan.
Plan the Change
Write the MOP in the Terminal: pre-checks, changes, post-checks and rollback, with risk level, change ticket and tags. Render config lines from a Jinja template and preview them before anything runs.
Peer Review
With the Controller, submit the MOP for review. A reviewer reads the plan in the admin console and approves or rejects it with a comment, and the decision is kept with that revision of the MOP.
Controlled Execution
Run the plan against the selected devices step by step, phase by phase, or with the AI pilot. Output from every step is captured. With the Controller, credentials are applied server-side and never reach the laptop.
Validation & Health Check
Post-checks assert on the new output — contains, doesn't contain, regex or exact line — and can be paired with their pre-checks to compare before and after. When a step fails, execution pauses, skips or aborts, as you set it.
Review & Close
The Review tab shows what ran and how each step went. Export the MOP as .mop.json, attach documents, and keep it with the change ticket for the next time.
Give auditors a clear record of network access
The Controller opens every device connection itself, so credentials never exist on engineer laptops, sessions can be recorded centrally, and logins, secret reveals and device commands land in one audit log. Auditors get a clear record of who reached which device, and how.
Roles control who administers users, credentials and settings, and organizations keep teams' devices and secrets apart. When the auditor asks, filter the audit log by user, event type and date range.
- Central session recording, controlled by the administrator
- Credential isolation — AES-256-GCM vault, never on endpoints
- Audit log filters by user, event type, resource and date
- Short-lived SSH certificates from a built-in CA
- 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, pushed over gNMI or NETCONF. Define a router's hostname, IPs, ASN, and VLANs once as shared variables, or set them per device. Deploy the entire stack as one operation, optionally atomic.
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 fill-in-the-variables, deploy-and-validate cycle.
- Optional atomic mode — any failure rolls every device back
- Shared variable sets across all templates in a stack
- Reusable site archetypes for consistent deployments
- A backup before deployment and validation after
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
- Discover topology via CDP/LLDP
- Back up every running config
- Identify dependencies and risks
Template & Test
- Build config templates for the target design
- Define migration MOPs with rollback
- Rehearse the MOPs against lab devices
Staged Rollout
- Execute MOPs site-by-site or batch
- Live step output as each device runs
- Pause, skip or abort when a step fails
Verify & Compare
- Before/after config comparison
- Routing table validation scripts
- End-to-end connectivity tests
Go Live
- Final validation and sign-off
- Change review recorded with the MOP
- Run history and documents kept with the change
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: 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 │
└─────────────────────────────────────────────────────────┘
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. │
└─────────────────────────────────────────────────────────┘See yourself in these scenarios?
Start with the free Terminal. Import your sessions. See the difference in your first incident.