VCF SD-WAN Insight: Introduction

Version: 2026.1.1.0

What it is

VCF SD-WAN Insight is a VMware Aria Operations Management Pack that monitors SD-WAN infrastructure. It is built as a single multi-vendor product: one adapter kind and one shared object model, in which the producer of a device is expressed only through the endpoint property. Two vendors are supported today: Cisco Catalyst SD-WAN (SD-WAN Manager, formerly vManage, with vSmart / vBond controllers and vEdge / cEdge edge routers) and Fortinet SD-WAN (FortiManager as the single point of integration, with FortiGate devices reached through it). One adapter instance collects exactly one vendor, selected with the SD-WAN Vendor instance parameter, so a Cisco estate and a Fortinet estate are monitored through the same dashboards, groups, reports and alerts.

The Management Pack covers the overlay end to end: the management and control plane appliances, the edge routers at every site, the transport links that carry the traffic out of each site, and the tunnel quality those links deliver. Where the deployment is organised into sites, the adapter also derives an SD-WAN Location object per site, so an operator navigates Site -> Node -> Link instead of starting from the manager.

How does it work?

Authentication: the adapter signs in to the vendor management platform over HTTPS. On Cisco it opens a session against the SD-WAN Manager with the Basic credential kind. On Fortinet it authenticates to FortiManager either with an API token (Authorization: Bearer <key>, the Fortinet API key credential kind) or with a username/password session (exec sys/login/user, the Basic credential kind).
Controller inventory: the management and control plane appliances are read first. On Cisco the SD-WAN Manager, the vSmart controllers and the vBond validators are distinguished by the role property; the device with the vmanage role is the API entry point. On Fortinet the single FortiManager is the controller and the API entry point, and its HA role is published as role.
Device inventory: the edge routers are read from the management platform - /dataservice/device on Cisco, /dvmdb/device on Fortinet - and each one becomes an SD-WAN Node.
Site derivation: on Cisco the site-id / site-name pair carried by every device record is grouped into one SD-WAN Location object per site. SD-WAN Manager publishes no site inventory of its own, so the sites are derived from the inventory. The Fortinet path has no site identifier in /dvmdb/device, so a Fortinet instance creates no Location object and its nodes hang directly under the controller.
Transport links: the interfaces that carry traffic out of a site are read as WAN Links. On Cisco these are the transport interfaces (TLOCs) exposed by /dataservice/device/interface; on Fortinet they are the SD-WAN members read through the FortiManager proxy. An overlay tunnel interface is deliberately not turned into a WAN Link - its measurements are aggregated onto the physical WAN Link that carries it.
Tunnel measurement: the per-tunnel figures - latency, jitter, packet loss - are read from the vendor and aggregated onto the WAN Link. On Cisco they come from the app-route records; on Fortinet from the real-time monitor (sd-wan-sla-log) plus the performance-SLA health-checks and IPsec entries, with a health-check and an IPsec entry that describe the same remote gateway merged into one leg.
Mapping and emission: every value is mapped onto the shared object model. A value that the target does not expose or the account may not read produces no data point, never a zero.
Relationships: the topology is rebuilt on every collection cycle. Where an SD-WAN device runs as a virtual machine, the adapter matches it against the virtual machines already known to Aria Operations and relates the two.

Features

Two supported vendors under one adapter kind: Cisco Catalyst SD-WAN and Fortinet SD-WAN, selected per adapter instance.
One adapter instance per management address, covering the controller, every edge router, every transport link and the tunnel quality behind each link.
Four object kinds under one shared model: SD-WAN Device, SD-WAN Node, SD-WAN Link and SD-WAN Location. The first three are populated by both vendors; the Location is declared for both but created only by the Cisco path, because only the vManage inventory carries a site identifier.
Two-level hierarchy with an optional site layer: Adapter Instance -> SD-WAN Device -> SD-WAN Node -> SD-WAN Link, plus SD-WAN Location as a second parent of the node on a Cisco deployment that carries sites.
Tunnel quality aggregated onto the WAN Link: ping, jitter and packet loss are means over the live legs of the link, so a degraded link is judged on the object an operator acts on instead of on thousands of per-tunnel objects.
Path inventory as first-class counters: path_count, path_up_count and paths_sla_violated say how many overlay paths a link carries, how many of them are up and how many breach their SLA class. They drive the dashboards and the link reports because they are facts of the topology, not periodically measured samples.
Availability as a pair: the binary availability sample that alerting matches on, and availability_pct, the 0 / 100 projection the reports render.
Configurable SLA budget: sla_level, the derived sla_availability_threshold and sla_allowed_downtime_hours per object, from the SLA default level, SLA level overrides, the two downtime budget parameters and the SLA monitoring window.
Backup-aware alerting: a member the SD-WAN policy declares a standby carries link_role = backup and is excluded from the down alerting, so a link that is down by design never pages anybody.
Events for informational state changes: ten conditions that describe what a link or a node is doing right now are emitted as INFO events rather than alarms, so the alert list stays actionable.
External topology: virtual machines are related to the SD-WAN devices and nodes they host, and an installed phpIPAM Management Pack can relate its IP Address objects to the node's management_ip.
Honest data: a value that could not be measured or read is omitted, so alerts never fire on a value that does not exist.

Benefits

The Management Pack answers three operational questions for an SD-WAN estate: is each device healthy, is the traffic leaving each site over a usable transport, and are the service levels still met. It replaces a per-site tour of the SD-WAN Manager or FortiManager UI with one Aria Operations inventory and one set of dashboards, and it makes the overlay visible next to the virtual infrastructure that hosts it.

Centralised monitoring. Controllers, edge routers, transport links and sites from every location - across Cisco and Fortinet estates alike - are collected into one Aria Operations inventory.
One model, two vendors. Cisco and Fortinet objects use the same kinds, identifiers, metrics and relationships, so dashboards, reports, custom groups and alert definitions are written once and work for both. No duplicate content, no vendor-specific tooling.
Proactive alerting that stays actionable. Reachability, resource exhaustion, certificate expiry and sustained unavailability raise alerts; transient quality and error conditions raise INFO events instead. Backup links are excluded from down alerting, so the alert list describes faults rather than the normal state of a standby path.
SLA evidence and reporting. Availability and transport quality per device, node, link and location over 24 hours, 7 days, 30 days and 365 days provide the figures needed for service reviews and transport provider escalations.
Faster troubleshooting. The relationship tree and the cross-adapter link to the hosting virtual machines make it immediately clear which sites, transports and links are affected by a given problem.
Capacity and cost insight. Utilization and throughput per transport show which carrier circuits are saturated and which are under-used, supporting bandwidth right-sizing decisions.
Scales to a real fleet. Removing the per-tunnel object and aggregating its measurements onto the link reduced the collection cost of a live fleet from an oversized object graph to the objects an operator actually uses.