NetStacksNetStacks

When the platform has a gap, build the tool.

Every platform stops somewhere, including ours. A parser it does not have, a report nobody built, a form operators need, an API the ticketing system cannot call. Those gaps are usually small, and usually the reason the workflow never got finished.

What gets built

  • Forms and small portals so operators can run a workflow without logging into the platform
  • Integrations between the ticketing system, the source of truth, and the platform that makes the change
  • Parsers and collectors for the devices and data the platform does not cover
  • Compliance and drift reports from the data the network already produces
  • NetStacks plugins, built on the plugin SDK, when the gap is in our own product
  • Test harnesses and lab tooling so a change can be tried before it is real

What it looks like in practice

A typical tool is a few hundred lines of Python that calls RESTCONF on the platform, reads the ticket from ServiceNow or Jira, and writes a result back. It runs in the same pipeline as everything else and lives in the client's repository from the first commit.

$ curl -s -u admin:admin -X POST \
    -H "Content-Type: application/yang-data+json" \
    http://nso:8080/restconf/data/tailf-ncs:devices/device=pe2-den/check-sync
{
  "tailf-ncs:output": {
    "result": "out-of-sync",
    "info": "got: 7c1e... expected: 2b90..."
  }
}
blocked: pe2-den out of sync. reconcile before CHG0048211.
Checking sync state over RESTCONF before a change is allowed to proceed.

How AI is used

We use AI tools to build faster: parsers, test data, documentation, and the first draft of code an engineer then reads line by line. It cuts delivery time on this kind of work substantially, and it is part of why fixed-price sprints are possible. The same discipline is built into NetStacks itself, where the AI assistant reads the terminal but a person commits the change.

What it does not do is make decisions about the network. Nothing an AI wrote runs against a device without an engineer reading the diff, and nothing is deployed without the same pipeline and review as any other change.

Kept small on purpose

These are tools, not products. A few hundred lines where possible, in a language the team already reads, with a README and tests. The goal is that the client's engineers can change it after the engagement ends.

Common questions

What languages and stacks?
Mostly Python, plus whatever the team already runs. We match the existing environment before introducing anything new.
Can you build on top of NetBox or Nautobot?
Yes. They are treated as the source of truth, and the work is the integration that makes the platform read from them. We do not run source of truth projects themselves. Plenty of firms do that well.
Who owns the code?
The client does. Everything lives in the client's repository from day one. Plugins for NetStacks can be kept private to the client or contributed back; the client decides.

Cisco, Cisco NSO, Cisco Crosswork, and pyATS are trademarks or registered trademarks of Cisco Systems, Inc. Juniper and Paragon are trademarks of Juniper Networks, Inc. NetBrain is a trademark of NetBrain Technologies, Inc. Forward Networks is a trademark of Forward Networks, Inc. NetBox is a trademark of NetBox Labs. Nautobot is a trademark of Network to Code, LLC. Ansible is a trademark of Red Hat, Inc. ServiceNow is a trademark of ServiceNow, Inc. GitLab is a trademark of GitLab Inc. Jira is a trademark of Atlassian Pty Ltd. All other product names, logos, and brands are the property of their respective owners and are used for identification purposes only. Their use does not imply endorsement, sponsorship, or affiliation. NetStacks is an independent company and has no partnership, reseller, or affiliate relationship with any of these vendors.