Fabric AIops

Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by Cisco, Meraki, Arista, Ubiquiti, or any network-controller vendor. "Cisco", "Meraki", "Catalyst", "DNA Center", "Arista", "CloudVision", "Ubiquiti", "UniFi", "ACI", "APIC" and all product/trademark names belong to their respective owners. MIT licensed.

Governed AI-ops for network fabrics managed through a controller — the Cisco Meraki Dashboard API (the reference platform, full read + write), Cisco Catalyst Center (formerly DNA Center; read subset), Arista CloudVision Portal (CVP) (read subset), and UniFi Network (self-hosted controller or UniFi OS console; read subset + device restart), plus read-only Cisco ACI (APIC) endpoint path reconstruction and faults — with a built-in governance harness: unified audit log, token/runaway budget guard, undo-token recording, and descriptive risk tiers. Multi-platform by construction: a registry keyed by platform maps every canonical operation onto each controller's REST API (path templates + response adapters), so adding a controller is a registry entry, never new ops/CLI/MCP surface. An operation a platform doesn't map returns a clear teaching error ("not supported on X yet — open an issue"), never a silent no-op. No platform has yet been exercised against a live controller by this tool; the ACI reads are the one part built from real controller responses (anonymized APIC payloads a production user supplied) — see docs/VERIFICATION.md.

What it does

Three flagship signature analyses, plus the guarded reads and writes around them:

• Uplink loss & latency RCA — pull MX WAN uplink loss + latency across an org, rank the worst uplinks by a composite of average loss and latency, and map each degraded uplink to a likely cause + recommended action. Every ranking carries its numbers, not a black-box verdict.
• Network health score — a composite 0-100 score per network from device online %, uplink health %, and an alert-severity penalty (weighted 0.5/0.3/0.2), with every component returned so the number is explainable.
• Config template drift — for networks bound to a config template, list the settings that have drifted from the template (expected vs actual).

What works

• CLI (fabric-aiops ...): init, overview, org, network, device, client, health, aci, remediate, secret, doctor, mcp.
• MCP server (fabric-aiops mcp or fabric-aiops-mcp): 37 tools (28 read, 9 write), every one wrapped with the bundled @governed_tool harness.
• Encrypted credentials: the controller secret (Meraki API key / Catalyst Center or APIC username:password / CVP service-account token / UniFi API key) lives in an encrypted store ~/.fabric-aiops/secrets.enc (Fernet + scrypt) — never plaintext on disk. Unlock with a master password from FABRIC_AIOPS_MASTER_PASSWORD (MCP/CI) or an interactive prompt (CLI).
• Reversibility: mutating writes fetch the real before-state first and record a faithful inverse (update_device/update_network_vlan restore prior values; claim↔remove; bind↔unbind/rebind). Irreversible ops (reboot_device, blink_device_leds) record the prior state for audit but declare no undo.
• Safety: every state-changing CLI op supports --dry-run and requires double confirmation; every write MCP tool takes a dry_run preview.

Capability matrix (37 MCP tools)

Domain	Tools	Count	R/W
Overview	overview	1	read
Organizations	org_list, org_get, org_licensing, org_admins, org_device_statuses, org_api_requests	6	read
Networks	network_list, network_get, network_vlans, network_alerts, network_traffic	5	read
Devices	device_inventory, device_status, device_uplinks, switch_ports, wireless_ssids	5	read
Clients	client_list, client_get, client_usage, client_connectivity	4	read
Health (flagship)	uplink_loss_and_latency_rca, network_health_score, config_template_drift	3	read
Cisco ACI (APIC only)	aci_endpoint_trace, aci_epg_segment, aci_faults_list	3	read
Remediation	reboot_device, claim_devices_into_network, remove_device_from_network, bind_network_to_template, unbind_network_from_template	5	write (high)
	update_device, update_network_vlan	2	write (medium)
	blink_device_leds	1	write (low)
Undo	undo_list	1	read
	undo_apply	1	write (medium)

network_health_score and config_template_drift are injected-only (they score data you already hold); uplink_loss_and_latency_rca accepts injected records for offline analysis or pulls live from a configured target. Device models carry a product-type prefix: MX appliance, MS switch, MR wireless AP, MV camera, MG cellular gateway.

Platform support matrix

One tool, five controller platforms. For the four in the table below the ops/CLI/MCP surface is identical everywhere; each platform maps the canonical operations it supports and raises a teaching error for the rest ("not supported on <platform> yet — open an issue or PR"). ACI maps none of these — see Cisco ACI below.

Canonical operation	meraki	catalyst	cvp	unifi
overview (org/site/container rollup)	✅	✅	✅	✅
org_list / org_get	✅	✅ sites	✅ containers	✅ sites (list; get ❌)
org_licensing, org_api_requests	✅	❌	❌	❌
org_admins	✅	❌	✅ users	❌
org_device_statuses	✅	✅ device-health	✅ inventory + streaming status	✅ stat/device (state, uptime, firmware)
network_list / network_get	✅	✅ site-health / site	✅ containers	✅ sites / stat/health (subsystem rollup)
network_vlans, network_traffic	✅	❌	❌	❌
network_alerts	✅	✅ issues (P1→critical, P2→warning)	✅ events	✅ alarms (*_Lost_Contact→critical)
device_inventory, device_status	✅	✅ network-device	✅ inventory (+ complianceCode drift signal)	✅ stat/device (id = device MAC)
device_uplinks	✅	❌	❌	❌
switch_ports	✅	✅ interface stats (pass the device uuid)	❌	✅ device port_table (pass the device MAC)
wireless_ssids	✅	❌	❌	❌
client_list / client_get	✅	✅ client-health (aggregate) / client-detail (by MAC)	❌	✅ stat/sta (connected) / stat/user (by MAC)
client_usage, client_connectivity	✅	❌	❌	❌
uplink_loss_and_latency_rca (live pull)	✅	❌ (injected records still work)	❌ (injected records still work)	❌ (injected records still work)
network_health_score, config_template_drift (injected-only)	✅	✅	✅	✅
reboot_device	✅	❌ teaching error	❌ teaching error	✅ cmd/devmgr restart-device
The other 7 writes (blink/update/claim/remove/bind/unbind/VLAN)	✅	❌ teaching error	❌ teaching error	❌ teaching error

Concept mapping: canonical organizations/networks are Catalyst Center sites, CVP containers, and UniFi sites (the canonical id is the site's short name — the /api/s/{site}/ path segment); all have one global tree, so the org scope does not filter their lists. On unifi, device-scoped calls (device get / switch_ports / reboot) fill the site from the target's default org_id — set it in config.yaml (or the init wizard). Writes are Meraki-only except UniFi device restart — Catalyst Center and CVP change models (task/configlet workflows) don't map cleanly onto these canonical writes, so each write fails fast with a teaching error before any controller call (never a silent no-op). CVP config-drift surfaces through device_inventory (complianceCode/complianceIndication per device) and network_alerts (events); configlet-content retrieval and deep pagination on catalyst/cvp/unifi are known deferrals.

Cisco ACI (APIC)

ACI has two axes — tenant → VRF → bridge domain → EPG, and pod → node → interface — and neither is an organization → network → device tree. Rather than make every network_id mean something different per call, an aci target answers the canonical tools with a teaching error and gets three read-only ACI-native tools that take ACI references (MAC/IP, tenant/app/EPG names, DNs):

Tool (CLI)	What it answers
aci_endpoint_trace (aci trace --mac/--ip)	Where is this endpoint and what carries it: attachment (pod / leaf / interface or vPC) → EPG → bridge domain → VRF → the EPG's contracts → filter entries, plus faults whose DN names the EPG or the attachment interface
aci_epg_segment (aci segment TENANT APP EPG)	The same EPG → BD → VRF → contracts chain from an EPG name
aci_faults_list (aci faults)	Fabric faults, worst severity first

How to read them: