| Platforms | |
| Transport | |
| Integrations | |
| Avg. Cost per Agent Session |
- π dblCheck
AI-assisted network intent validation framework for multi-vendor environments.
Continuously checks live network state against design intent and invokes a Claude agent to diagnose, explain, and document failures and inconsistencies between expected vs. actual state.
π Therefore, the key is having and maintaining an up-to-date network intent schema - and dblCheck does the rest.
β«οΈ Key characteristics:
- Intent-driven validation - Define expected state in NetBox config contexts
- AI root-cause diagnosis - Claude agent investigates failures using 8 read-only MCP tools
- Read-only - Agent queries and investigates devices, never configures
- Real-time dashboard - Live validation results and streamed AI diagnosis
- Daemon mode - Scheduled validation runs, always-on monitoring
- HashiCorp Vault - All secrets (device creds, NetBox token, Jira key etc.) stored in Vault
- NetBox - Network inventory and expected state loaded automatically
- Jira - Network state drift and deviations logged to Jira
- 711 tests - 21 suites (17 unit + 3 integration + 1 live)
β«οΈ Supported models:
- Haiku 4.5
- Sonnet 4.6
- Opus 4.6 (default, best reasoning)
β«οΈ Operational Costs:
- Periodic network state validation: programmatic, no cost
- Agent diagnosis: ~$0.19 per run (only on detected drift)
β«οΈ Operational Flow:
- See operations.md
β«οΈ Operational Guardrails:
- See guardrails.md
- Demo video coming soon...
- See CHANGELOG.md
| Tool | |
|---|---|
| Claude Agent | β |
| FastMCP | β |
| Python | β |
| Scrapli | β |
| HashiCorp Vault | β |
| NetBox | β |
| Jira | β |
| Protocol | What's Checked |
|---|---|
| OSPF | Neighbor state (FULL), area config, process config |
| EIGRP | Neighbor state, interfaces, topology |
| BGP | Peer state (Established), prefix counts |
| Interfaces | Up/down state, expected operational status |
β«οΈ Prerequisites:
- Python 3.11+
- HashiCorp Vault
- NetBox
- Jira (optional)
β«οΈ Step 1 - Install:
git clone https://github.com/pdudotdev/dblCheck /opt/dblcheck
cd /opt/dblcheck
python3 -m venv dbl
dbl/bin/pip install -r requirements.txt
β«οΈ Step 2 - Vault:
Start Vault (dev mode, lab use):
vault server -dev -dev-root-token-id=<your-root-token>
export VAULT_ADDR=http://127.0.0.1:8200
export VAULT_TOKEN=<your-root-token>
Or initialize and unseal an existing Vault:
vault operator init -key-shares=1 -key-threshold=1 # first-time setup
vault operator unseal # after every restart
π Save the unseal key output from
vault operator initsomewhere safe - you'll need it every time Vault restarts or seals. Without it, a sealed Vault cannot be recovered.
β οΈ dblCheck requires Vault to be running and unsealed before any run. If Vault is unavailable, credential lookups fall back to env vars (see.env.example).
Store secrets:
vault kv put secret/dblcheck/router username=<user> password=<pass>
vault kv put secret/dblcheck/netbox token=<token>
vault kv put secret/dblcheck/jira token=<token>
vault kv put secret/dblcheck/dashboard token=<token>
# vault kv put secret/dblcheck/anthropic api_key=<key>
β«οΈ Step 3 - Configure .env:
- See example
cp .env.example .env
β«οΈ Step 4 - Claude auth:
Option A - Anthropic account:
claude auth login
Option B - API key via Vault.
β«οΈ Step 5 - Register the MCP server:
claude mcp add dblcheck -s user -- /home/<user>/dbl/bin/python server/MCPServer.py
dblCheck runs as a systemd daemon that validates the network on a schedule and serves a live dashboard.
β«οΈ Install the service:
sudo deploy/install.sh
Detects your install path and user automatically - no manual editing required.
β«οΈ Manage with:
systemctl start | stop | restart | status dblcheck
β«οΈ Dashboard:
http://<IP|localhost>:5556
Shows live validation results and streams AI diagnosis output when failures are found. Port is configurable via DASHBOARD_PORT in .env.
INTERVAL=<seconds> in .env.
Recommendation: Runs are sequential β a new validation never starts while the previous one is still running. However, setting
INTERVALtoo low increases SSH load on network devices. Validation itself (polling devices and checking assertions) has no API cost. The AI diagnosis agent is only invoked when unexpected failures are detected β that is the only time API costs occur. For most environments, 120β300 seconds is a good range. Each run has a hard timeout of 600 seconds (10 minutes).
β«οΈ Network diagram:
β«οΈ Lab environment:
- 16 devices defined in TOPOLOGY.yml
- 5 Γ Cisco IOS nodes
- 3 Γ Cisco IOS-XE nodes
- 4 Γ Arista cEOS nodes
- 2 Γ MikroTik CHR nodes
- 1 Γ Juniper JunOS node
- 1 x Aruba AOS-CX node
- OSPF multi-area, EIGRP, BGP
- Device credentials stored in Vault
- Network inventory and state in NetBox
- New protocols supported
New features are being added periodically (protocols, integrations, optimizations).
Stay up-to-date:
- Watch and Star this repository
You are responsible for defining your own network intent (NetBox config contexts), building your test environment, and meeting the necessary conditions (Python 3.11+, Claude CLI, HashiCorp Vault, etc.).
Licensed under the Business Source License 1.1. Source code is available for research, educational, and non-commercial use. Commercial use, SaaS deployment, enterprise integration, or paid services require a commercial license.
Interested in collaborating?
- Email:
- Reach out at hello@ainoc.dev
- LinkedIn:
- Let's discuss via LinkedIn
