The problem: it grew past “I just know”

For a while, the mental model of the network lived entirely in my head. That works until a switch port flaps, a VM migrates, or a device gets a new IP, and you find out about it by symptom rather than by signal — the “why is the Wi-Fi pod offline” question that turns into twenty minutes of SSHing into things to check link status one port at a time.

The fix was to stop treating the network as a black box and start treating it like the rest of my infrastructure: observable, documented, and — where it’s safe to do so — automatable.

A small internal webapp

The centerpiece is a small internal dashboard with a handful of tabs:

• Topology — a live, auto-generated map of the LAN: router, switches, and every device, drawn from an actual scan rather than a diagram someone has to remember to update.
• Graph — the same topology, but as an actual graph database (Neo4j) rebuilt from scratch every 15 minutes. It’s deliberately current-state only, not a history store — every sync wipes and rebuilds the graph, so a query always reflects what’s plugged in right now. The tab embeds the real Neo4j Browser so I can run ad-hoc Cypher queries against my own LAN (“what’s connected to this switch port,” “show me every device with no hostname”) instead of grepping through ARP tables.
• Monitoring — Grafana/Prometheus, for the metrics side of things.
• Switch — port status and traffic for the managed switches, without opening their web UIs.
• Syslog — the one that ended up mattering most in practice.

Syslog: making the logs actually watch something

Every host on the network already ships logs to a central syslog collector — hundreds of sources’ worth. The problem was that nothing was reading them. The answer to “why did the WiFi pod drop” was sitting in a switch’s log the whole time (a port link-down event), completely unwatched.

The Syslog tab adds two things on top of the raw collector: a searchable, multi-host log viewer (term/regex filters, time ranges — with hundreds of sources and a lot of history, filtering has to happen server-side, not in the browser), and user-defined notification rules. A small engine runs every minute, tails only the new bytes each watched log has grown by, matches them against the rules, and — on a match, respecting a per-rule cooldown so one flapping port doesn’t turn into a hundred pages — fires a webhook into Home Assistant, which turns it into a phone notification.

It’s a small feature, but it’s the difference between “the network told me something broke” and “I noticed something was broken.”

Giving Claude Code supervised hands on the network

The more interesting piece, for me, was building an MCP (Model Context Protocol) layer so Claude Code can act on the network directly instead of me relaying show command output back and forth by hand. There’s a small set of MCP servers, each scoped to one thing:

• One that talks to the router — reads configuration and running state, and can apply changes (like adding a static host mapping) over SSH.
• One that reads switch port status and traffic over SNMP.
• One that lists and controls VMs/containers on the Proxmox cluster via its API.
• One that reads the centralized logs.
• A generic SSH connector for anything else on the LAN.

The point isn’t “let an AI reconfigure my network unsupervised” — it’s narrowing the interface. Each server exposes a specific, reviewable set of actions instead of a raw shell, so when I’m working through something like a VLAN migration or a switch swap with Claude Code, it can genuinely read the live state of the router and switches and reason about port assignments and firewall rules against what’s actually deployed — not against my possibly-stale mental model of it — while every actual change still goes through review before it’s applied.

The VLAN problem consumer mesh WiFi can’t solve

The most concrete recent project this stack enabled: putting IoT devices and IP cameras on their own isolated VLAN, firewalled off from the trusted network, while leaving everything else alone.

The obvious approach — tag a dedicated SSID to a VLAN on the existing mesh WiFi — turned out to be a dead end. Consumer-tier mesh systems generally don’t support mapping individual SSIDs to VLANs; that’s an enterprise-AP feature. Rather than replace a perfectly good mesh system, the fix was to add a couple of cheap, dedicated access points running OpenWrt, configured as dumb bridges rather than routers: no DHCP, no routing, no firewall of their own, just WiFi bridged straight onto a switch port that’s hard-set to the IoT VLAN. The switch does all the VLAN tagging; the access point doesn’t need to know VLANs exist at all.

On the router side, that VLAN gets its own subnet, its own DHCP scope, and a firewall policy that defaults to drop everything inbound except:

• established/related traffic (so replies to connections IoT devices themselves initiated still work),
• a narrow allow rule for the one thing that has to reach in — MQTT traffic to the home-automation host, so IoT devices can publish to it,
• and outbound internet access, since these devices still need it for NTP, firmware updates, and cloud features.

Everything else from the IoT VLAN toward the trusted network is dropped by default. Traffic in the other direction (trusted → IoT) stays unrestricted, since it’s the automation/monitoring hosts polling into the IoT VLAN, not the reverse, that needs to keep working.

The one wrinkle worth calling out for anyone doing this themselves: mDNS and similar local-discovery protocols don’t cross VLAN boundaries. Anything that relies on discovery (some smart-home integrations) needs a static IP/reservation instead of “just works” auto-discovery once it’s segmented.

Naming things like infrastructure, not like guesses

A smaller but satisfying piece of this: formalizing a DNS naming standard. Some of my hostnames dated back to a previous job’s naming convention (CLLI codes, if you know, you know) and had long since stopped meaning anything to anyone but me. The new standard is boring on purpose — a short role code plus a number for physical hosts (router, switch, storage, etc.), the purpose itself as the name for single-role VMs, and a separate tier of service aliases that point at whichever host currently provides a service and move with it if that ever changes. It’s a small thing, but “the name tells you what it is” pays for itself every time you’re debugging at 11pm.

Where this leaves things

None of this is exotic — a graph database, a syslog watcher, some MCP servers, and a VLAN. What made it worth doing was treating a home network like it deserves the same basic care as any other system I run: know what’s on it, get told when it breaks, and keep the blast radius of any one compromised device small. The AI-copilot layer is the part I’d call genuinely new — not because it does anything a human couldn’t, but because it turns “let me SSH into six things to check” into a conversation grounded in what the network actually looks like right now.