| Core Version | |
| Vendors |  |
| Management |   |
| Integrations |     |
| On-Request | |
| Vendors |       |
| Management |     |
| Integrations |   |
| Stats | |
| Performance |    |
- 📜 aiNOC
AI-based network troubleshooting framework for multi-vendor, multi-protocol, multi-area/multi-AS enterprise networks.
▫️ Key characteristics:
- Multi-vendor support
- Multi-protocol, L2/L3
- Multi-area/multi-AS
- CLI/RESTCONF (Core)
- NETCONF/REST/gNMI/eAPI
- 15 MCP tools, 4 skills
- 12 operational guardrails
- HITL for any config changes
- Dashboard for agent monitoring
- Discord integration
- Jira integration
- HashiCorp Vault
- NetBox
▫️ Core vs. On-Request features:
- Core:
- Easy to integrate in Cisco IOS/IOS-XE environments
- CLI, RESTCONF management, OSPF/BGP troubleshooting
- Jira, Discord, NetBox, HashiCorp Vault integration
- On-Request:
- Custom vendor modules (Arista, Juniper, MikroTik, etc.)
- Custom management (REST APIs, NETCONF, gNMI, eAPI)
- Built and adapted per client's network environment
▫️ aiNOC operating mode in v5.0+:
▫️ Important project files:
- See file roles
▫️ Agent guardrails list:
- See guardrails
▫️ Supported models:
- Haiku 4.5
- Sonnet 4.6
- Opus 4.6 (default, best reasoning)
▫️ Set your default model:
Create settings.json under .claude/:
{
"model":"opus",
"effortLevel":"medium"
}
▫️ High-level architecture:
- See a DEMO of aiNOC v5.5
- See changelog.md
| Tool | |
|---|---|
| Claude Code | ✓ |
| MCP (FastMCP) | ✓ |
| Python | ✓ |
| Scrapli | ✓ |
| Genie | ✓ |
| RESTCONF | ✓ |
| Jira API | ✓ |
| Discord API | ✓ |
| HashiCorp Vault | ✓ |
| NetBox | ✓ |
| Vector | ✓ |
| Ubuntu | ✓ |
| Vendor | Platform | cli_style | Status |
|---|---|---|---|
| Cisco | IOS-XE | ios |
Core |
| Arista | EOS | eos |
On-Request |
| Juniper | JunOS | junos |
On-Request |
| MikroTik | RouterOS | routeros |
On-Request |
| Aruba | AOS-CX | aos |
On-Request |
| SONiC | FRR | frr |
On-Request |
| VyOS | VyOS | vyos |
On-Request |
| Management | Devices | Tier | Status |
|---|---|---|---|
| RESTCONF | Cisco IOS-XE | Primary | Core |
| CLI | Cisco IOS-XE | Fallback | Core |
| NETCONF | custom | — | On-Request |
| REST APIs | custom | — | On-Request |
| gNMI | custom | — | On-Request |
| eAPI | Arista | — | On-Request |
| aiNOC Core |
|---|
| OSPF |
| BGP |
| Redistribution |
| Policy-based routing |
| Route-maps, prefix lists |
| NAT/PAT, access lists |
| aiNOC On-Request Extensions |
|---|
| EIGRP |
| HSRP |
| VRRP |
| etc. |
▫️ Step 1:
git clone https://github.com/pdudotdev/aiNOC/
cd aiNOC/
python3 -m venv mcp
source mcp/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
▫️ Step 2:
Review CLAUDE.md and skills/*/SKILL.md for the troubleshooting methodology, tool descriptions, and operational guidelines. For your own deployment, customize these files for your specific topology, vendor combination, and architecture.
▫️ Step 3:
- Configure IP SLA (or Connectivity Monitor, Netwatch etc.) paths in your network
- Make sure they are being tracked and logged remotely to Vector (Syslog)
- Configure the transforms inside
/etc/vector/vector.yaml- example - aiNOC monitors Vector's
/var/log/network.jsonfile for specific logs and parses them per-vendor
▫️ Step 4:
Run the aiNOC watcher and dashboard services.
Claude is invoked non-interactively via tmux + print mode (-p) with a default prompt template.
The human operator monitors agent operations via the web dashboard on :5555, and interacts via Discord (fix approval ✅ or rejection ❌ embeds).
sudo apt install tmux
sudo cp oncall/oncall-watcher.service /etc/systemd/system/
sudo cp dashboard/oncall-dashboard.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now oncall-watcher.service
sudo systemctl enable --now oncall-dashboard.service
Manage with:
systemctl start | stop | restart | status oncall-watcher
▫️ Step 5: Check if the service and Vector are running:
sudo systemctl status vector
sudo systemctl status oncall-watcher.service
sudo systemctl status oncall-dashboard.service
▫️ Network diagram:
▫️ Router configurations:
- Please find my test lab's config files under the lab_configs directory
- They are the network's fallback configs for
containerlab redeploy -t AINOC-TOPOLOGY.yml - Default credentials: see .env file at .env.example
aiNOC runs as an on-call watcher that monitors Vector's /var/log/network.json for SLA path failures and automatically invokes a Claude agent to diagnose the issue and propose a fix.
- Network devices track connectivity paths (Cisco IP SLA — extensible to Arista Connectivity Monitor, Juniper RPM probes, MikroTik Netwatch etc.)
- Failures are logged remotely to Syslog → Vector records, parses, and writes to
/var/log/network.json oncall-watcherservice detects the SLA failure, opens a Jira ticket, and invokes the aiNOC agent session- Web dashboard is activated and displays agent's work in real time. User is notified and kept in the loop via Discord.
- Agent follows structured troubleshooting methodology:
CLAUDE.md+/skills+MCP tools→ identifies root cause(s) → proposes fix - Only upon human operator approval via Discord, the agent applies and verifies the fix, otherwise issue is documented and the case stays open
- Case resolution is logged to Jira and Discord, and the watcher resumes monitoring
- aiNOC agent learns a new lesson about network troubleshooting and documents to
lessons.md
See Installation & Usage for instructions.
- New protocols supported
- Performance-based SLAs
New features are being added periodically (protocols, integrations, optimizations).
Stay up-to-date:
- Watch and Star this repository
Current version:
- aiNOC v5.5
You are responsible for defining your own troubleshooting methodologies and context files, as well as building your own test environment and meeting the necessary conditions (e.g., RAM/CPU, Claude subscription/API key, etc.).
Licensed under the GNU General Public License v3.0.
Interested in collaborating?
- Email:
- Reach out at hello@ainoc.dev
- LinkedIn:
- Let's discuss via LinkedIn