Description

Discover how to auto-populate your CMDB from NetApp storage arrays, Arista switch stacks, and Aruba network infrastructure using SNMP and SSH discovery protocols, and why network topology relationships in CMDB matter for change management and incident response.

NetApp, Arista, and Aruba Discovery: Auto-Populate Your CMDB from Network and Storage Infrastructure

TLDR

Network switches and storage arrays are the most common CMDB gaps in enterprise IT. NetApp ONTAP supports SNMP and SSH discovery; Arista EOS supports SNMP and its eAPI; Aruba switches support SNMP-based discovery and AirWave integration. This article explains per-vendor discovery approaches and why capturing network topology relationships in your CMDB improves change management and incident response.

Table of Contents

• Introduction
• Why Network and Storage Infrastructure Is Hardest to Discover
• NetApp Discovery
• Arista Switch Discovery
• Aruba Switch Discovery
• The CI Relationship Mapping Opportunity
• Conclusion

Introduction

Enterprise IT infrastructure is multi-vendor by necessity. No single vendor builds every piece of the stack from storage to network edge. Most organizations run NetApp ONTAP for their NAS and SAN workloads, Arista or Aruba switches at the core and distribution layers, and a mix of compute platforms on top. Managing this heterogeneous environment requires a CMDB that reflects the actual topology — not just the servers.

Yet in most enterprise CMDBs, network switches and storage arrays are invisible. Servers, virtual machines, and cloud instances are well-represented. The physical and logical infrastructure that connects and stores data for those servers is largely absent.

This gap has real consequences. Change managers approve switch firmware upgrades without knowing which servers and applications depend on those switches. Incident responders trace service outages to a flapping switch port without a topology map to identify which services are affected. Capacity planners make storage procurement decisions with no visibility into how existing NetApp volumes are distributed across the environment. The Uptime Institute 2024 Annual Outage Analysis confirms that network equipment failures and configuration errors remain top contributors to significant data center outages — a direct consequence of operating network infrastructure that goes unmodeled in the CMDB.

Why Network and Storage Infrastructure Is Hardest to Discover

Standard IT discovery tools are built around agented or agentless server discovery. A server runs an operating system that exposes WMI, SSH, or an agent endpoint. Network devices and storage arrays do not.

Storage arrays require protocol-specific discovery — SNMP for basic device identification, SSH or vendor API for volume and configuration data. Network switches require SNMP for topology data and CDP/LLDP for neighbor discovery. Neither fits the standard server-discovery workflow.

Add to this the organizational reality: network teams and storage teams often do not report to the same IT manager. Each team runs its own management tools, tracks its own asset inventory, and has little incentive to integrate with a CMDB managed by a different team. The result is CMDB data that covers only the top layer of the infrastructure stack.

NetApp Discovery: Capturing Storage and NAS Infrastructure

NetApp ONTAP is the operating system powering NetApp’s AFF (All-Flash FAS), FAS, and ONTAP Select platforms. It supports multiple discovery protocols.

SNMP Discovery for NetApp

NetApp ONTAP implements standard SNMP MIBs as well as NetApp-specific MIBs. SNMP v2c and v3 discovery can identify:

• Storage system hostname and management IP
• System serial number and model
• Overall health status (OK, warning, critical)
• Basic capacity metrics

SNMP-based discovery is suitable for populating the base storage system CI, but is not sufficient for capturing volume, LUN, or aggregate-level data.

SSH-Based Discovery for NetApp

ONTAP supports SSH access to its CLI. Authenticated SSH sessions can retrieve:

• Storage virtual machine (SVM) names and configuration
• Volume names, sizes, and qtree structures
• Aggregate and disk shelf inventory
• Network interface (LIF) configuration
• Cluster node hardware details

For CMDB purposes, SSH-based discovery provides the data needed to populate volume CIs and their relationships to storage virtual machines and cluster nodes.

NetApp REST API

ONTAP 9.6 and later includes a REST API that provides comprehensive access to configuration data. The REST API is the preferred method for purpose-built discovery tools because it returns structured JSON data that maps cleanly to CI attributes.

What to capture in your CMDB from NetApp:

CI Type	Key Attributes
NetApp Cluster	Cluster name, management LIF, ONTAP version, node count
Cluster Node	Serial number, model, status
SVM (Storage VM)	Name, protocol (NFS, CIFS, iSCSI, FCP)
Volume	Name, SVM, size, aggregate, junction path

Arista Switch Discovery: Modern Stacking and EOS

Arista Networks builds data center and campus switches running the Extensible Operating System (EOS). Arista is common in high-performance data center environments, and increasingly in campus deployments following Arista’s introduction of SWAG (Switch Aggregation Group) stacking in 2024. Source: Arista Networks Press Release, 2024

SNMP Discovery for Arista

Arista EOS implements standard SNMP MIBs including MIB-II, IF-MIB, ENTITY-MIB, and Arista-specific extensions. SNMP v2c and v3 are supported. SNMP discovery can identify:

• Switch hostname and management IP
• System model and serial number
• Interface inventory (physical and logical)
• CDP/LLDP neighbor table (for topology discovery)
• VLAN configuration

LLDP neighbor data is particularly valuable because it reveals how Arista switches connect to other switches, servers, and storage arrays. When this topology data populates the CMDB, change managers can trace the impact of a switch failure through the connected infrastructure.

SSH / eAPI Discovery for Arista

Arista EOS supports SSH access and an HTTP/HTTPS-based eAPI (Extensible API) that accepts JSON-formatted commands. The eAPI is the most efficient way to retrieve structured switch configuration data:

• show version — Platform model, serial number, EOS version
• show interfaces — All interface names, statuses, and MAC addresses
• show lldp neighbors detail — Neighbor discovery data for topology mapping
• show vlan — VLAN database
• show stack-ports (for SWAG stacks) — Stack member connectivity

CMDB value for Arista: In campus environments using SWAG stacking, Arista represents a group of physical switches as a single logical entity. Capturing the stack-level CI alongside individual member switch CIs gives your CMDB an accurate representation of how the physical infrastructure is grouped.

Aruba Switch Discovery: Campus Network Visibility

HPE Aruba Networks produces wired and wireless networking equipment widely deployed at the campus edge and distribution layers. Aruba switches are common in enterprise environments running VMware or Microsoft server infrastructure.

SNMP Discovery for Aruba

Aruba switches support SNMP v2c and v3. SNMP discovery identifies:

• Switch hostname, model, and serial number
• Interface inventory and operational status
• CDP/LLDP neighbor relationships
• VLAN membership

AirWave Integration

For environments running Aruba AirWave (HPE Aruba Networking Management Software), an AirWave integration provides richer device inventory including device type classification (switch, access point, controller), connected client visibility, and network segment and location data.

AirWave organizes devices into networks and groups, which can be used to structure CMDB groupings aligned to physical locations or network segments.

What to capture in your CMDB from Aruba:

CI Type	Key Attributes
Aruba Switch	Hostname, model, serial number, firmware, management IP
Physical Interfaces	Name, MAC, connected device (from LLDP)
VLAN	VLAN ID, name, associated interfaces
Stack Member (if stacked)	Member ID, serial, role (primary/secondary)

The CI Relationship Mapping Opportunity

Capturing network switches and storage arrays in isolation provides asset inventory. The real CMDB value comes from relationship mapping.

Network topology relationships:

• Arista Core Switch connects to Arista Distribution Switch
• Aruba Distribution Switch connects to Server NIC
• Server NIC is component of Physical Server
• Physical Server runs Virtual Machine

When these relationships exist in the CMDB, a planned Arista core switch upgrade has an automatic impact scope: every distribution switch, server, and service in the dependency chain is visible in the change record.

Storage topology relationships:

• NetApp Volume is hosted on NetApp Node
• Server uses NetApp Volume (via NFS mount or iSCSI LUN)
• NetApp Node connects to Arista Switch (via Ethernet)

These cross-domain relationships — connecting storage and network infrastructure to the compute layer — are what makes a CMDB genuinely useful for enterprise change and incident management. Without them, the CMDB is an asset list. With them, it becomes an infrastructure topology map.

Virima 6.1.1 and Multi-Vendor Network and Storage Discovery

Virima 6.1.1 introduced native discovery support for NetApp, Arista, and Aruba infrastructure. Using SNMP and SSH-based discovery protocols, Virima enumerates devices from all three vendors and populates them as CIs in the Virima CMDB with their associated attributes and relationships.

Discovery schedules are configurable per credential set, allowing network and storage discovery to run on a cadence appropriate for your change rate — daily for dynamic environments, weekly for more stable infrastructure. Discovered CIs are automatically related to existing server and cloud CIs in the CMDB, building the cross-layer topology map that change managers and incident responders need.

Conclusion

Network switches and storage arrays are the CMDB’s most common blind spots. NetApp, Arista, and Aruba all expose management data through SNMP and SSH protocols that purpose-built discovery tools can consume. Capturing this data — and mapping the relationships between network, storage, and compute CIs — transforms the CMDB from a server inventory into a genuine infrastructure topology map.

The investment pays off every time a change manager needs to understand who is affected by a switch upgrade, or a storage team needs to validate which servers depend on a specific NetApp volume before a maintenance window.

Want to see how Virima discovers NetApp, Arista, Aruba, and your full IT infrastructure automatically? Schedule a demo at virima.com.