Almost every network team has NetBox installed. Far fewer actually use it as their source of truth. The gap between "we have NetBox" and "NetBox is our source of truth" is where most network automation projects die.
The difference isn't the data model. NetBox already has interfaces, IPs, prefixes, VLANs, VRFs, circuits, and device roles. The difference is in the validation loop between what NetBox says and what your network actually shows.
The Drift Nobody Measures
When was the last time you verified that NetBox accurately reflects your network? Not "NetBox is up to date because we follow process." I mean, actually SSH'd into devices and compared show run against the NetBox data.
Most teams can't answer that question because nobody has built the verification step. You enter data into NetBox, and it stays there. Network changes happen through SSH sessions, change tickets, and Slack messages. NetBox gets updated "when there's time" — which is never during an outage window or a busy sprint.
This creates silent drift. NetBox says an interface is in VLAN 100. It's actually in VLAN 200. The interface shows as "up" in NetBox. The SFP failed three weeks ago. You're rendering stack configs from NetBox data that hasn't matched reality since the last person who bothered to update it.
The Integration Most Teams Build
The standard NetBox integration pattern looks like this: build a script that pulls device data from NetBox, generates configs, and pushes them to devices. This works — until NetBox is wrong. And because there's no continuous verification, NetBox is wrong more often than anyone admits.
The missing piece is the reverse direction. Not just NetBox → device, but device → NetBox. Every time you connect to a device, you should be able to:
- Snapshot the current config
- Compare it against the expected state from NetBox
- Flag any deltas immediately
- Propose NetBox updates when the delta is intentional
- Compare it against the expected state from NetBox
- Flag any deltas immediately
- Propose NetBox updates when the delta is intentional
- Flag any deltas immediately
- Propose NetBox updates when the delta is intentional
- Propose NetBox updates when the delta is intentional
This isn't NetBox polling or SNMP scraping. This is interactive, engineer-driven verification at the moment of connection — when you already have the session open and the data is right there.
How NetStacks Closes This Loop
NetStacks integrates with NetBox at the session level, not the config-generation level. When you connect to a device that exists in your NetBox instance:
- The device info from NetBox appears alongside your terminal session
- You can run a config snapshot and diff it against what NetBox expects
- The topology view uses NetBox data to render your network, and you can verify it live
- When NetBox is wrong, you flag it immediately — not as a separate "update NetBox" ticket
- You can run a config snapshot and diff it against what NetBox expects
- The topology view uses NetBox data to render your network, and you can verify it live
- When NetBox is wrong, you flag it immediately — not as a separate "update NetBox" ticket
- The topology view uses NetBox data to render your network, and you can verify it live
- When NetBox is wrong, you flag it immediately — not as a separate "update NetBox" ticket
- When NetBox is wrong, you flag it immediately — not as a separate "update NetBox" ticket
The crawler feature takes this further. It discovers devices across your network, maps their connections, and builds a topology that you can compare against NetBox. The drift shows up as a visible gap between what you discovered and what NetBox says — making it impossible to ignore.
The Pattern Every Team Should Adopt
- Connect NetBox to your terminal workflow. If your SoT data isn't visible at the point of connection, it's just a database — not truth.
- Run device discovery independently of NetBox. Compare the discovered topology against NetBox. The delta is your drift measurement.
- Snapshot configs during every session. Not scheduled — during the session when you're already there. Compare against NetBox-derived expected state.
- Make drift visible and actionable. If NetBox says VLAN 100 and the device says VLAN 200, the delta should be surfaced immediately, not discovered during an outage.
- Treat NetBox as a living system. The moment you start treating it as "something we update quarterly," it becomes a historical record, not a source of truth.
The teams who successfully use NetBox as an SoT don't have better discipline. They have better tooling that makes verification effortless. The gap isn't in the data model — it's in the feedback loop between what's recorded and what's real.