✨ aiNOC

	Core Version
Vendors
Management
Integrations
	On-Request
Vendors
Management
Integrations
	Stats
Performance

📖 Table of Contents

• 📜 aiNOC
  • 🔭 Overview
  • 🍀 Here's a Quick Demo
  • ⭐ What's New in v5.5
  • ⚒️ Current Tech Stack
  • 📋 Supported Vendors
  • 🚛 Supported Transports
  • 🎓 Troubleshooting Scope
  • 🛠️ Installation & Usage
  • 🔄 Test Network Topology
  • 📞 aiNOC Service Mode
  • ⬆️ Planned Upgrades
  • ♻️ Repository Lifecycle
  • 📄 Disclaimer
  • 📜 License
  • 📧 Collaborations

🔭 Overview

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+:

• See aiNOC Service Mode

▫️ 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)

⚠️ NOTE: Due to the intermittent nature of troubleshooting, it's worth using an advanced model by default. Costs won't become unsustainable even if addressing and fixing several issues per day.

▫️ Set your default model: Create settings.json under .claude/:

{
  "model":"opus",
  "effortLevel":"medium"
}

▫️ High-level architecture:

🍀 Here's a Quick Demo

• See a DEMO of aiNOC v5.5

⭐ What's New in v5.5

• See changelog.md

⚒️ Core Tech Stack

📋 Supported Vendors

🚛 Supported Transports

🎓 Troubleshooting Scope

🛠️ Installation & Usage

▫️ 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.json file 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

🔄 Test Network Topology

▫️ 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 Service Mode

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.

How It Works

1. Network devices track connectivity paths (Cisco IP SLA — extensible to Arista Connectivity Monitor, Juniper RPM probes, MikroTik Netwatch etc.)
2. Failures are logged remotely to Syslog → Vector records, parses, and writes to /var/log/network.json
3. oncall-watcher service detects the SLA failure, opens a Jira ticket, and invokes the aiNOC agent session
4. Web dashboard is activated and displays agent's work in real time. User is notified and kept in the loop via Discord.
5. Agent follows structured troubleshooting methodology: CLAUDE.md + /skills + MCP tools → identifies root cause(s) → proposes fix
6. Only upon human operator approval via Discord, the agent applies and verifies the fix, otherwise issue is documented and the case stays open
7. Case resolution is logged to Jira and Discord, and the watcher resumes monitoring
8. aiNOC agent learns a new lesson about network troubleshooting and documents to lessons.md

See Installation & Usage for instructions.

⬆️ Planned Upgrades

• New protocols supported
• Performance-based SLAs

♻️ Repository Lifecycle

New features are being added periodically (protocols, integrations, optimizations).

Stay up-to-date:

• Watch and Star this repository

Current version:

• aiNOC v5.5

📄 Disclaimer

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.).

📜 License

Licensed under the GNU General Public License v3.0.

📧 Collaborations

Interested in collaborating?

• Email:
  • Reach out at hello@ainoc.dev
• LinkedIn:
  • Let's discuss via LinkedIn