Documentation
Supported platforms
Documents the current release. We keep improving the platform, so some details may change. Ask support if anything looks off.
How support works
NetEnds is multi-vendor, but “supported” is not one flag per device — it is a separate answer for each thing you want to do with a node. (A managed device is a node: switches, routers, firewalls, load balancers and access points.) A node NetEnds monitors fully may have no configuration-backup path, and one it backs up may not be one it can push configuration to. This page answers each capability separately.
Three core capabilities are scored per platform in the tables below:
- Discover — find the node, identify its vendor, model and OS, and read its inventory: interfaces, VLANs, switchports, ARP and MAC tables, routes, VRFs, virtual contexts and hardware.
- Monitor — recurring polling for CPU and memory, interface utilization, hardware health, power, routing-protocol state and firewall state.
- Back up — retrieve the running configuration (and the startup configuration, where the platform keeps one) on a schedule, version it and diff it.
Three further capabilities — pushing configuration, upgrading the OS, and rendering the device-side configuration that turns telemetry on — cover a narrower set of platforms and have their own sections below.
Discover, monitor and back up
Every platform in the tables below is discovered and monitored, and backed up except where a dash says otherwise. Markers:
- Yes — a dedicated code path that speaks the vendor’s own API or CLI (eAPI, NX-API, NETCONF, the AOS-CX, FortiOS, PAN-OS, iControl and NITRO REST APIs, or vendor SSH).
- SNMP — identified and inventoried by the standard-MIB baseline that applies to any SNMP-reachable node, rather than a vendor-specific discovery collector.
- Ctrl — handled through the controller that manages the node.
- — — No path; the product shows the reason on the node rather than failing quietly.
Switching and routing
| Platform | Discover | Monitor | Back up |
|---|---|---|---|
| Arista EOS | Yes | Yes | Yes |
| Cisco NX-OS (Nexus) | Yes | Yes | Yes |
| Cisco IOS / IOS-XE | Yes | Yes | Yes |
| Juniper Junos | Yes | Yes | Yes |
| Aruba AOS-CX | Yes | Yes | Yes |
| Extreme EXOS | Yes | Yes | Yes |
| Nokia SR Linux | Yes | Yes | Yes |
| HPE / H3C Comware | Yes | Yes | Yes |
| Huawei VRP | Yes | Yes | Yes |
| SONiC | Yes | Yes | Yes |
| Dell SmartFabric OS10 | SNMP | Yes | Yes |
Firewalls and security
| Platform | Discover | Monitor | Back up |
|---|---|---|---|
| Cisco ASA | Yes | Yes | Yes |
| Fortinet FortiGate (FortiOS) | Yes | Yes | Yes |
| Palo Alto PAN-OS | Yes | Yes | Yes |
| Check Point Gaia | Yes | Yes | — |
| SonicWall SonicOS | Yes | Yes | — |
| OPNsense / pfSense | Yes | Yes | Yes |
Load balancers and application delivery
| Platform | Discover | Monitor | Back up |
|---|---|---|---|
| F5 BIG-IP | Yes | Yes | — |
| Citrix NetScaler (ADC) | Yes | Yes | — |
Edge and small-office routers
| Platform | Discover | Monitor | Back up |
|---|---|---|---|
| MikroTik RouterOS | SNMP | Yes | Yes |
| VyOS | SNMP | Yes | Yes |
| OpenWrt | SNMP | Yes | Yes |
Wireless (controller-managed)
| Platform | Discover | Monitor | Back up |
|---|---|---|---|
| Ubiquiti UniFi | Ctrl | Ctrl | — |
| FortiAP (FortiGate-managed) | Ctrl | Ctrl | — |
Wireless configuration is backed up on the controller, not the access point — see Wireless.
Anything else over SNMP
Any node NetEnds can reach over SNMP is inventoried and monitored against the standard RFC and ENTITY-MIB paths: system identity, interfaces, VLANs, ARP and MAC tables, routes, hardware components, CPU and memory, interface utilization, hardware health, and BGP and OSPF session state. The platform rows above add the vendor’s own API and the write-side capabilities on top of that baseline. Polling uses SNMPv2c or SNMPv3.
Where a platform exposes a richer API or CLI, NetEnds uses it for what SNMP cannot give — firewall session and VPN state on the firewalls, MLAG and VSX peer state and BGP prefix tables on the switching platforms, per-radio telemetry through the wireless controllers. On Aruba AOS-CX, REST is the monitoring path.
Virtual constructs are read where the platform has them: VDOMs (FortiGate), vsys (PAN-OS), security contexts (ASA), VSX systems (Check Point), route domains (F5) and traffic domains (NetScaler) with their administrative partitions, routing instances and logical systems (Junos), and network instances (SR Linux).
Reading configuration
Configuration backup covers more platforms than configuration push. A few details worth knowing:
- Startup configuration is captured where the platform keeps one separate from the running configuration (Cisco NX-OS, IOS / IOS-XE and ASA, Arista EOS and Aruba AOS-CX). Junos, FortiOS, PAN-OS and the SSH-only routers keep a single committed or running configuration, which is what NetEnds stores.
- Cisco ASA configuration is retrieved over SSH, which needs
aaa authentication ssh console LOCALon the device for SSH logins to authenticate. The product shows that note on the node. - Check Point Gaia, SonicWall SonicOS, F5 BIG-IP and Citrix NetScaler are discovered and monitored without a configuration backup; the product shows the reason on the node rather than returning an empty backup.
Configuration push
Configuration push sends a change an engineer has prepared to one or more nodes:
- General-purpose push covers Arista EOS, Cisco NX-OS, Cisco IOS / IOS-XE, Juniper Junos, Aruba AOS-CX and Extreme EXOS. FortiGate and SonicWall take changes only through the guided telemetry and API-enable flows.
- Every change is rendered and shown for review first and waits for approval before it runs. By default the approver must be someone other than its author, unless they hold the Administrator role.
- A backup is taken just before the push, and each change carries a rollback path — a native device checkpoint or config-replace where the platform has one, an inverse-command replay otherwise — shown before you approve.
- Configuration push, Autopilot, rollback, restore, console sessions and OS upgrades all refuse nodes on the Protection list.
Autopilot applies the telemetry configuration described under Telemetry enablement. It is off until an operator turns it on, and its mode decides whether it only drafts changes for review or applies them. It leaves protected and read-only nodes alone, and every change it makes gets a backup and a rollback.
OS upgrades
NetEnds stages a network OS image, plans the install, reload and post-upgrade checks against a pre-upgrade baseline, and presents that plan for review. OS upgrades are staged and proposed; an operator applies them.
- Upgrade drivers cover Cisco NX-OS, IOS-XE and ASA, Juniper Junos, Arista EOS, Fortinet FortiGate, Palo Alto PAN-OS and Aruba AOS-CX. Other platforms show the reason on the node.
- Each platform’s revert path is shown on the upgrade, and a revert is itself proposed as a draft that an operator approves before anything rolls back.
- Each driver records how far its upgrade path has been proven. Confirm your platform and path with support before you plan a production upgrade.
Telemetry enablement
Separately from collecting data, NetEnds renders the device-side configuration that makes a node send telemetry — syslog forwarding, flow export and SNMP traps — and that turns on the vendor management API the collectors use (NX-API, eAPI, NETCONF, RESTCONF, gNMI, REST).
- Where the platform offers a way to, the management-API configuration it renders admits only the collector’s source address; where it does not, the review says so. NX-API, eAPI, NETCONF, RESTCONF and REST are rendered over HTTPS or SSH only. gNMI is TLS only on Cisco NX-OS and Aruba AOS-CX. On Arista EOS and Cisco IOS-XE it is rendered as plaintext gRPC by default, because that is what the collector reads; on Arista EOS each request is still authorized.
- Protocol Enablement shows each rendered change for review; configuration push or Autopilot applies it.
Two specifics worth knowing: on Cisco NX-OS the flow export is sFlow, not NetFlow — NX-OS NetFlow depends on the line card and is rejected on Tomahawk-ASIC Nexus, so sFlow is the floor across the family. FortiGate flow export is also sFlow, so the exporter’s identity survives source NAT.
Flow ingest
Whether or not NetEnds configured the exporter, the flow collector accepts:
| Protocol | UDP port |
|---|---|
| sFlow | 6343 |
| NetFlow v5 / v9 | 2055 |
| IPFIX | 4739 |
So a node NetEnds does not enable flow export on can still be pointed at the collector by hand and have its flows ingested.
Wireless
Wireless is controller-based: NetEnds reads access points through the controller that manages them. Two controller families are supported:
- Ubiquiti UniFi controller — onboard the controller, and the access points, switches and gateways it manages are discovered from it and linked back to it. Newly discovered devices start as pending, for an operator to confirm.
- FortiGate acting as the wireless controller for FortiAPs — each managed access point is discovered from its parent FortiGate. NetEnds reads access point status, CPU and memory, uptime, per-radio channel, band and utilization, wired uplink and temperature from the FortiGate, and directs you to back up the controller rather than the access point.
Other wireless controllers, including cloud-managed ones, are not integrated.
License tiers
Discover, monitor and back up are part of the Base tier and every license includes them. The tiers gate the other product areas:
- Base — inventory, monitoring and alerting, topology, and configuration.
- Events & flows — log search and analytics, and flow analysis.
- Gia — Gia, your network assistant, and the Lab.
Areas outside your license stay visible with a padlock, not hidden, so the product looks the same on every tier. License files verify fully offline. See Licenses & entitlements.