Guide
GuidesMulti-vendor LAN faults under one model
Multi-vendor LAN faults under one model
Most networks are not pure-vendor. There is Meraki at the HQ, a UniFi closet in the other office, sometimes a third vendor at the warehouse you inherited. The standard answer is two dashboards and a Slack channel for the third. NetMender takes a different approach: one fault model, one board, swappable per-vendor adapters underneath.
~3 min read
What is actually the same across vendors
The shape of a network fault is vendor-agnostic. There is an affected device or link, a class of failure (connectivity, DHCP or DNS, Wi-Fi signal), evidence (events, metrics, samples) that justifies the diagnosis, a severity, and a status. What differs between Meraki and UniFi is the wire format of the telemetry and the exact API call that runs the fix. The fault model and the operator’s mental model do not need to change with the vendor.
Vendor-neutral core, swappable adapters
The canonical fault model and the orchestrator live in a core that knows nothing about Meraki or UniFi. Each adapter does two specific jobs: it normalizes the vendor’s telemetry into the canonical fault model on the way in, and it provides a per-vendor playbook library that translates an approved fix into the vendor’s API calls on the way out. Adding a vendor means adding an adapter, not building a new dashboard. The RCA engine, the confidence gate, the kill switch, and the audit trail all sit above the adapters and see the same fault shape regardless of where it came from.
Why the host probe is its own adapter
Controller-vendor APIs sometimes lie or go silent. The on-LAN host probe is its own adapter, watching the network from a real device on it: uplink reachability via ping, DNS health, Wi-Fi signal where applicable. It catches consumer-router and last-mile faults the controllers cannot see, and it stays running when the controller is unreachable. From the orchestrator’s perspective the probe is just another telemetry source feeding the same fault model, with one specific difference: the only safe fix on a host with no control API is a DNS-cache flush, so other classes surface as evidence-rich triage with manual steps, not as pre-formed playbooks.
One board, one approval surface
With one model, every fault renders the same way (severity-ranked, evidence-cited), and every approval flows through the same orchestrator under the same confidence gate, kill switch, and audit trail. Operators learn one workflow no matter what their vendor mix looks like. For the autonomy split and the guardrails that gate each fix, see autonomous detection, human-approved fixes, or the NetMender product page for the live demo.
Related guides
Keep reading
Networks
Autonomous detection, human-approved fixes
Splitting autonomous LAN fault detection from one-tap, human-approved remediation behind a confidence gate, kill switch, and append-only audit trail.
Governance
IT governance, run by agents
How Paragon turns governance from a dashboard of problems into an assess, generate, remediate loop across twelve modules.
Run it across your mix
Tell us the vendors in scope and we will get you into the demo against a fleet that matches.
Subscribe
Get new guides when they drop. One email when there is something to read; never spam.