Networkops Platform
AI-powered network automation via Model Context Protocol (MCP). 178 tools for multi-vendor infrastructure management, self-healing agents, drift detection, and a real-time web dashboard.
Installation
npx networkops-platformAsk AI about Networkops Platform
Powered by Claude Β· Grounded in docs
I know everything about Networkops Platform. Ask me about installation, configuration, usage, or troubleshooting.
0/500
Reviews
Documentation
NetworkOps
AI-Powered Network Automation Platform
Natural language commands to manage multi-vendor infrastructure
NetworkOps is a network automation platform built on the Model Context Protocol (MCP). It enables AI-assisted management of Cisco, Juniper, Nokia, Arista, and Linux devices through natural language β no scripting required.
Screenshots
Topology Dashboard
Interactive force-directed network topology with device health indicators, legend, and network stats.

Device Details
Click any device to view its properties, interface status, and remediation controls.

OSPF Adjacencies Overlay
Visualize OSPF adjacencies with area labels directly on topology links.

BGP Sessions Overlay
BGP session status with AS number annotations on peering links.

DMVPN Fabric Status
DMVPN hub-and-spoke overlay with peer state table showing tunnel IPs, NBMA addresses, and uptime.

Ping Sweep with Latency Heatmap
Bulk ping results visualized as a color-coded latency heatmap across the topology.

Command Terminal
Execute show commands on any device with full output display.

AI Documentation Assistant
RAG-powered chat with live network queries β ask questions in natural language and get answers with source citations.

Real-time Telemetry (MDT)
Live CPU, memory, interface traffic, and counters streamed via gRPC at 5-second intervals.

Impact Analysis
Predict the blast radius of a configuration change before executing it.

Intent Drift Engine
YAML-defined expected state validation with per-item compliance checks and violation alerts.

Subnet Calculator
Built-in subnet calculator with VLSM split and quick reference tables.

Quick Start
Demo Mode (no network devices needed)
Try NetworkOps without any hardware. Demo mode simulates a multi-device network with routers, switches, and an FRR edge device.
git clone https://github.com/E-Conners-Lab/NetworkOps_Platform.git && cd NetworkOps_Platform
./scripts/quickstart.sh --demo
# Follow the prompts, then open http://localhost:5001 β Login: admin/admin
Or manually:
git clone https://github.com/E-Conners-Lab/NetworkOps_Platform.git && cd NetworkOps_Platform
uv venv --python 3.11 # downloads Python 3.11 if needed
source .venv/bin/activate
uv pip install -r requirements.txt
cd dashboard && npm install && npm run build && cd ..
JWT_SECRET=$(python3 -c "import secrets; print(secrets.token_hex(32))")
DEMO_MODE=true JWT_SECRET=$JWT_SECRET python dashboard/api_server.py
Don't have uv? Install it with
curl -LsSf https://astral.sh/uv/install.sh | sh. You can also usepython3.11 -m venv .venvandpip install -r requirements.txtinstead.
With Real Devices
git clone https://github.com/E-Conners-Lab/NetworkOps_Platform.git && cd NetworkOps_Platform
./scripts/quickstart.sh
# Edit .env with your device IPs and credentials
# Edit config/devices.py with your device inventory
python dashboard/api_server.py
Docker
git clone https://github.com/E-Conners-Lab/NetworkOps_Platform.git && cd NetworkOps_Platform
./scripts/docker-init.sh
# Edit .env with your credentials (or add DEMO_MODE=true for demo)
docker compose up
Demo Mode
Demo mode provides a fully functional dashboard experience using simulated network data. No real devices, SSH connections, or lab infrastructure required.
What Works in Demo Mode
| Feature | Status | Details |
|---|---|---|
| Topology visualization | Full | 7-node network with routers, switches, and FRR edge device |
| BGP overlay | Full | Simulated iBGP (AS 65000) and eBGP (AS 65100) peering |
| OSPF overlay | Full | Area 0 adjacencies across all routers |
| DMVPN overlay | Full | Hub-and-spoke topology with 3 spokes |
| Switch fabric overlay | Full | 2 switches with uplink status and port counts |
| Ping sweep | Full | Simulated 100% reachability with realistic latencies |
| Interface list | Full | Per-device interface display with status |
| Show commands | Partial | show ip interface brief, show version, show ip route return simulated output; other commands return a placeholder message |
| Login / RBAC | Full | JWT auth, role-based permissions, all dashboard features unlocked |
| Health endpoints | Full | /healthz and /health/detailed work without Redis |
What Does Not Work in Demo Mode
| Feature | Reason |
|---|---|
| Configuration changes | No real devices to push config to |
| NETCONF/YANG queries | Requires live device connections |
| pyATS baselines/diffs | Requires SSH to real devices |
| RAG chatbot | Requires ANTHROPIC_API_KEY and ChromaDB index |
| Streaming telemetry | Requires gRPC streams from real devices |
| Terminal (arbitrary commands) | Most commands return placeholder output |
| NetBox integration | Requires a running NetBox instance |
| MCP tools via Claude | Tools that SSH to devices will fail; read-only tools work |
Demo Topology
R1 ββββ R2
β β
Switch-R1 Switch-R2
β
R3 ββββ R4
β
edge1 (FRR, AS 65100)
- R1βR4: Cisco C8000V routers (IOS-XE) β OSPF Area 0, iBGP AS 65000, DMVPN hub/spoke
- Switch-R1, Switch-R2: Cisco Cat9kv switches
- edge1: FRRouting device β eBGP peering with R3
Features
React Dashboard
- Interactive force-directed topology with drag-and-drop positioning
- Real-time device health monitoring (healthy / degraded / critical)
- Role-based access control (Admin / Operator / Viewer)
- Command terminal with output display
- AI chat panel (RAG-powered, requires Anthropic API key)
- Device detail panels:
- Cisco devices: Interface list with admin/line protocol status, remediation buttons
- Linux hosts: Uptime, memory, disk, gateway reachability
- Containerlab devices: Container status, uptime, memory
- Visualization overlays:
- BGP session status with AS numbers
- OSPF adjacencies with area mapping
- DMVPN hub/spoke fabric
- Switch fabric with EIGRP status
- Ping sweep with latency heatmap
- Intent Drift Engine:
- YAML-defined expected state validation
- Force-directed dependency graph
- Forward/backward/blast-radius impact analysis
- Cross-subsystem event correlation
- Hierarchical site view (Region β Site β Rack β Device)
- Position persistence via localStorage
- Change management workflow
MCP Tools (178 tools, 24 categories)
Integrate with Claude Code or Claude Desktop for natural language network management.
Health & Monitoring
| Tool | Description |
|---|---|
health_check | Check single device connectivity |
health_check_all | Parallel health check across all devices |
full_network_test | Validate OSPF, BGP, DMVPN, and reachability |
linux_health_check | Linux host status (uptime, memory, disk) |
get_cpu_memory | CPU and memory utilization |
ping_sweep | Bulk ping from a device to all targets |
Device Operations
| Tool | Description |
|---|---|
get_devices | List available devices |
send_command | Execute show commands |
send_config | Send configuration commands |
discover_topology | Discover topology via CDP/LLDP |
get_interface_status | Detailed interface status |
remediate_interface | Fix interfaces (no shutdown, bounce) |
bulk_command | Execute command on multiple devices in parallel |
Configuration Management
| Tool | Description |
|---|---|
backup_config | Save running config to timestamped file |
compare_configs | Diff two configs or backup files |
list_backups | List saved configuration backups |
Routing & Troubleshooting
| Tool | Description |
|---|---|
get_routing_table | Parsed routing table with protocol filtering |
traceroute | Hop-by-hop path analysis |
get_arp_table | Parsed ARP table with VRF support |
get_mac_table | MAC address table from switches |
get_neighbors | Structured CDP/LLDP neighbor data |
get_logs | Syslog buffer with severity filtering |
NETCONF
| Tool | Description |
|---|---|
get_interfaces_netconf | Interface info via NETCONF/YANG |
get_netconf_capabilities | Device NETCONF capabilities |
get_bgp_neighbors_netconf | BGP neighbors via NETCONF |
pyATS Integration
| Tool | Description |
|---|---|
pyats_learn_feature | Learn device feature state |
pyats_snapshot_state | Capture device state baseline |
pyats_diff_state | Compare against baseline |
pyats_check_compliance | Check config against golden templates |
pyats_list_baselines | List saved baselines |
pyats_list_templates | List golden config templates |
NetBox Integration
| Tool | Description |
|---|---|
netbox_get_devices | List devices from NetBox |
netbox_get_interfaces | Device interfaces from NetBox |
netbox_get_prefixes | IP prefixes from NetBox |
netbox_generate_configs | Generate FRR configs from NetBox via Jinja2 |
netbox_generate_iosxe_config | Generate IOS-XE configs from NetBox |
netbox_allocate_ip | Allocate next available IP from a prefix |
Memory & Context System
| Tool | Description |
|---|---|
memory_search | Semantic search across conversation history |
memory_save | Save notes for later retrieval |
memory_recall_device | Recent events for a device |
memory_stats | Memory system statistics |
Event Logging & Cache
| Tool | Description |
|---|---|
get_event_log | Audit log events (filterable) |
clear_event_log | Clear audit log |
cache_status | Redis cache statistics |
Streaming Telemetry (MDT)
- Real-time CPU, memory, and interface counters via gRPC (5-second intervals)
- WebSocket push to dashboard via Socket.IO
- Configured on C8000V routers and Cat9kv switches
RAG Documentation Chatbot
- Indexed CCIE/Cisco documentation with semantic search
- ChromaDB + sentence-transformers embeddings
- Live network queries via SSH during chat
- Claude-powered responses with source citations
Discord Bot (ChatOps)
- Commands:
!devices,!health,!bgp,!ping,!events,!topology,!run - RBAC: Admin commands require "Network Admin" role
Enterprise Features
| Category | Feature |
|---|---|
| Authentication | JWT tokens, MFA/TOTP with recovery codes |
| Authorization | Role-based access control (Admin/Operator/Viewer) |
| Caching | Redis-backed response caching |
| Rate Limiting | Configurable per-endpoint rate limits |
| Async Jobs | Celery task queue with PostgreSQL persistence |
| Health Probes | /healthz, /readyz, /health/detailed, /metrics |
| TLS/HTTPS | Nginx reverse proxy with TLS 1.2/1.3 |
| Logging | Structured JSON logs for aggregation |
| SIEM Forwarding | Splunk, Elasticsearch, Syslog, Webhook |
| Kubernetes | Full manifests with HPA, PDB, rolling deployments |
| Graceful Shutdown | SIGTERM handling with request draining |
Architecture
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β NetworkOps Platform β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β ββββββββββββββββ ββββββββββββββββ ββββββββββββββββββββββ β
β β Frontend β β API Server β β MCP Server β β
β β (React) βββββΊβ (Flask) β β (Claude Tools) β β
β β Port 3000 β β Port 5001 β β β β
β β β β β β 178 tools across β β
β β β’ Topology β β β’ REST API β β 24 categories β β
β β β’ Terminal β β β’ WebSocket β β β’ NETCONF/YANG β β
β β β’ RAG Chat β β β’ Auth/RBAC β β β’ pyATS β β
β ββββββββββββββββ ββββββββ¬ββββββββ ββββββββββββ¬ββββββββββ β
β β β β
β ββββββββββββββ΄ββββββββββββββββββββββββ΄βββββββββββ β
β β Shared Data Layer β β
β β β’ networkops.db (Alembic-managed) β β
β β β’ chromadb/ (RAG) β’ baselines/ (pyATS) β β
β βββββββββββββββββββββββββ¬ββββββββββββββββββββββββ β
β β β
βββββββββββββββββββββββββββββββββββββββββββΌβββββββββββββββββββββββββββ€
β β β
β Network Devices (SSH / NETCONF) β
β βββββββββββ βββββββββββ βββββββββββ βββββββββββ βββββββββ β
β β Cisco β β Juniper β β Nokia β β Arista β β Linux β β
β β IOS-XE β β Junos β β SR Linuxβ β EOS β β FRR β β
β βββββββββββ βββββββββββ βββββββββββ βββββββββββ βββββββββ β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Setting Up Your Own Lab
Use the quickstart script to configure NetworkOps for your own network devices:
# Interactive setup (recommended)
./scripts/quickstart.sh
# Demo mode (no devices needed)
./scripts/quickstart.sh --demo
# Non-interactive (CI/CD, Docker)
./scripts/quickstart.sh --headless
# Setup and auto-start
./scripts/quickstart.sh --headless --auto-start
The script detects uv automatically for faster dependency installation.
Deploying on a Linux VM (Proxmox, bare metal, etc.)
You can run the entire platform and containerlab on a single Linux host β no Multipass needed.
1. Install prerequisites:
# Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER && newgrp docker
# Containerlab
sudo bash -c "$(curl -sL https://get.containerlab.dev)"
# uv (Python version manager + package installer)
curl -LsSf https://astral.sh/uv/install.sh | sh
source ~/.bashrc
# Node.js (for building the React frontend)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
2. Clone and set up the project:
git clone https://github.com/E-Conners-Lab/NetworkOps_Platform.git && cd NetworkOps_Platform
uv venv --python 3.11
source .venv/bin/activate
uv pip install -r requirements.txt
3. Configure .env:
cp .env.example .env
Set these values in .env:
CONTAINERLAB_LOCAL=true
CONTAINERLAB_ONLY=true
CONTAINERLAB_TOPOLOGY_PATH=/path/to/NetworkOps_Platform/containerlab/datacenter.clab.yml
DEMO_MODE=false
JWT_SECRET=<generate with: python -c "import secrets; print(secrets.token_hex(32))">
4. Pull images and deploy the lab:
docker pull frrouting/frr:v8.4.1
docker pull ghcr.io/nokia/srlinux:24.10.1
docker pull alpine:3.19
cd containerlab
sudo containerlab deploy -t datacenter.clab.yml
cd ..
5. Build the frontend, run migrations, and start:
cd dashboard && npm install && npm run build && cd ..
alembic upgrade head
python dashboard/api_server.py
6. Change the default password:
TOKEN=$(curl -s http://localhost:5001/api/auth/login -H "Content-Type: application/json" -d '{"username":"admin","password":"admin"}' | python3 -c "import sys,json;print(json.load(sys.stdin)['token'])")
curl -X POST http://localhost:5001/api/auth/change-password -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d '{"old_password":"admin","new_password":"YourNewPassword"}'
7. Access the dashboard at http://<your-vm-ip>:5001 and log in with admin and your new password.
Note:
CONTAINERLAB_LOCAL=trueruns Docker commands directly instead of routing through Multipass.CONTAINERLAB_ONLY=truehides EVE-NG/physical devices that aren't present, showing only containerlab devices in the dashboard.
Containerlab via Multipass (macOS)
If you're on macOS and prefer to use Multipass to host the containerlab VM, leave CONTAINERLAB_LOCAL=false (the default) and set CONTAINERLAB_VM to your VM name. See core/containerlab.py for details.
Supported Device Types
| Platform | device_type | Features |
|---|---|---|
| Cisco IOS-XE | cisco_xe | SSH, NETCONF, pyATS |
| Cisco IOS | cisco_ios | SSH only |
| Linux | linux | SSH |
| FRRouting | containerlab_frr | SSH (via Containerlab) |
| Nokia SR Linux | containerlab_srlinux | SSH (via Containerlab) |
Example Device Entry
DEVICES = {
"core-router": {
"host": "192.168.1.10",
"device_type": "cisco_xe",
"username": "admin",
"password": "secret",
"netconf_port": 830,
},
"linux-server": {
"host": "192.168.1.100",
"device_type": "linux",
"username": "root",
"password": "password",
},
}
Example Claude Commands
"Show me the interfaces on R1"
"What's the OSPF neighbor status across all routers?"
"Run a health check on all devices"
"Take a baseline snapshot of R2 and check for drift"
"Ping from R1 to all router loopbacks"
"Compare the running config of R1 and R2"
"Show me the PIM neighbors and RP mapping"
Project Structure
.
βββ network_mcp_async.py # MCP server entry point
βββ mcp_tools/ # 178 MCP tools (24 categories)
βββ config/
β βββ devices.py # Device inventory (static or NetBox)
βββ core/ # Core engines
β βββ intent_engine.py # Intent-based validation
β βββ impact_analyzer.py # Impact analysis
β βββ demo/ # Demo mode fixtures
β βββ unified_db.py # Unified SQLite database
βββ dashboard/ # React dashboard + Flask API
β βββ api_server.py # Flask API backend (port 5001)
β βββ routes/ # Modular route blueprints
β βββ auth/ # JWT, MFA/TOTP, RBAC
β βββ src/ # React frontend
β βββ Dockerfile.api # API container
β βββ Dockerfile.frontend # React + nginx container
βββ templates/ # Jinja2 config templates (FRR, IOS-XE)
βββ alembic/ # Database migrations
βββ ansible/ # Playbooks and inventory
βββ containerlab/ # Topology and device configs
βββ docker/ # Production Dockerfiles
βββ helm/ # Helm chart for Kubernetes
βββ k8s/ # Kubernetes manifests
βββ nginx/ # TLS reverse proxy config
βββ netbox/ # NetBox integration
βββ scripts/ # Quickstart, benchmarks, utilities
βββ services/ # Discord bot, background services
βββ tests/ # Test suite
βββ docs/ # Documentation
Requirements
- Python 3.11+ (recommended; pyATS doesn't support 3.14 yet)
- Node.js 18+ (for dashboard)
- Network devices accessible via SSH (for non-demo usage)
- Claude Code or Claude Desktop with MCP support (for AI tools)
Optional
- Redis (caching and rate limiting)
- PostgreSQL (job persistence)
- Anthropic API key (RAG chatbot)
- NetBox instance (IPAM integration)
Using a Local LLM
The RAG chatbot uses Claude by default, but you can swap in a local LLM if you prefer to keep everything on-prem.
What already runs locally
- Embeddings β
sentence-transformers(all-MiniLM-L6-v2) runs locally for all vector search and document indexing. No external API calls. - MCP tools β The 178 MCP tools use the standard MCP protocol over SSH/NETCONF. Any MCP-compatible client can consume them, and the HTTP proxy (
mcp_http_proxy.py) exposes them as REST endpoints for any LLM or script.
What requires changes for a local LLM
The RAG chat panel (rag/query.py) is wired to the Anthropic SDK. To point it at a local model (Ollama, vLLM, LM Studio, llama.cpp, etc.), you need to modify three files:
1. rag/query.py β Replace the Anthropic client with an OpenAI-compatible client:
# Before (Anthropic)
import anthropic
client = anthropic.Anthropic(api_key=api_key)
response = client.messages.create(
model=model,
max_tokens=1024,
system=self.SYSTEM_PROMPT,
messages=[{"role": "user", "content": user_message}]
)
# After (OpenAI-compatible β works with Ollama, vLLM, LM Studio)
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="unused")
response = client.chat.completions.create(
model="llama model here",
max_tokens=1024,
messages=[
{"role": "system", "content": self.SYSTEM_PROMPT},
{"role": "user", "content": user_message}
]
)
2. rag/sanitizer.py β Update the model allowlist (lines 15β22) to include your local model names, or remove the allowlist check entirely.
3. dashboard/routes/chat.py β Change the default model from claude-sonnet-4-20250514 to your local model name.
Tool-calling (live device queries)
The RAG chat can execute live SSH commands against your devices mid-conversation (e.g., "run a health check"). This uses Anthropic's tool_use block format. If you want this working with a local LLM:
- The tool-calling loop in
rag/query.py(around line 406) needs to be adapted to the OpenAI function-calling schema - You'll need a model with solid function-calling support β Llama 3.1 70B+, Qwen 2.5 72B, or Mistral Large work well
- Smaller models (7B/8B) will struggle with multi-step tool chains
If you only need RAG Q&A (ask questions about indexed documentation) without live device queries, you can skip the tool-calling refactor entirely. Any local model that handles basic chat completions will work.
Recommended local setups
| Setup | Model | VRAM Required | Tool-calling |
|---|---|---|---|
| Ollama | llama3.1:70b | ~40 GB | Yes |
| Ollama | qwen2.5:32b | ~20 GB | Yes |
| Ollama | llama3.1:8b | ~5 GB | RAG only (no tools) |
| vLLM | Any HuggingFace model | Varies | Yes (with OpenAI server) |
| LM Studio | Any GGUF model | Varies | Yes (OpenAI-compatible API) |
Performance
Tested on MacBook Pro M4, Gunicorn with 4 workers:
| Concurrency | Requests/sec | Avg Latency |
|---|---|---|
| 100 | 5,376 | 24ms |
| 500 | 5,100+ | slight increase |
| 1,000 | 4,800+ | near saturation |
Zero errors at all concurrency levels. See scripts/wrk_benchmark.sh for full benchmark suite.
Security Notes
- Never commit
.envβ it contains credentials and secrets - Generate a unique
JWT_SECRETfor every deployment - The dashboard uses RBAC to limit command access by role
- Dangerous commands (
reload,write erase, etc.) are blocked - Review commands before execution in production
