Wireless

Forward models wireless infrastructure — WLAN controllers (WLCs) and their access points (APs) — as part of the network digital twin, so wired and wireless paths trace end to end. Modeling is at the forwarding layer: SSID-to-VLAN mappings, CAPWAP tunnels between a controller and its APs, wireless clients as connected hosts, and the ACLs applied to wireless traffic. Forward does not model the RF layer — signal strength, channel planning, roaming, or mobility domains.

This section covers what Forward supports, how to collect it, how wireless appears in the model, how APs are licensed, and how to resolve the common collection and modeling problems.

• Collection — set up each vendor's WLC or cloud dashboard.
• How wireless is modeled — WLCs, APs, SSIDs, CAPWAP, FlexConnect, and path analysis.
• Licensing — how Cisco, Meraki, and Mist APs consume peripheral licenses.
• Troubleshooting & FAQ — common failures and frequent questions.

Supported vendors and platforms

Vendor	Controller / dashboard	Access points	AP modeling	Collection	OS
Cisco (enterprise)	Catalyst 9800 WLC	Cisco APs	Individual devices	Cisco IOS-XE (over SSH)	IOS-XE 17.x+ for APs
Cisco Meraki	Meraki Dashboard	Meraki MR	Individual devices	Meraki Dashboard (HTTPS)	—
HPE Aruba	WLAN controller 7000/7200 Series; Mobility Access Control Switch	Aruba APs	Not separate; tunnel to controller	Aruba Controller SSH	ArubaOS (tested from 6.5)
Juniper Mist (Tech Preview)	Mist cloud dashboard	Mist Wireless Access Points	Individual devices	Mist (HTTPS)	—

For the exact platform models and tested OS versions, see Supported Devices and Tested Devices. For per-feature support, see the Wireless section of the Feature Matrix.

note

Cisco WLC OS version. AP collection from a Catalyst 9800 WLC requires IOS-XE 17.x or later. On IOS-XE 16.x the collector skips all AP-related commands, so the WLC is collected but its APs are not.

note

"Not separate; tunnel to controller" (Aruba). Forward models the Aruba WLAN controller, but not the APs it manages as their own devices. Each ESSID is modeled as a tunnel interface that terminates on the controller, and wireless clients attach there as hosts. A path from an Aruba wireless client therefore starts at the controller — there is no AP device for it to originate from. For how this compares to Cisco and Meraki, see How wireless is modeled.

note

Meraki requires a non-2FA account. Meraki collection uses the private Dashboard APIs, which need an interactive login with two-factor authentication disabled — an API key alone is not sufficient. See Cisco Meraki collection.

Not supported

• Cisco AireOS WLCs (for example 5520, 8540, 5500) — end-of-life, with no planned support. APs managed by an IOS-XE WLC are supported; APs on an AireOS controller are not, and their CAPWAP tunnels cannot be traced.
• Cisco Catalyst Center / DNA Center — not a collection source for wireless.
• Arista CV-CUE — cloud management platform, not a forwarding device.
• Fortinet FortiAP — not modeled.

Wireless data in NQE

On a Cisco IOS-XE WLC, NQE surfaces AP-level data from the collected AP command output — per-AP fields such as SSID/BSSID, AP mode, channel, transmit power, and CAPWAP path MTU — at per-AP granularity, not per-client. Per-client and per-user data is not queryable directly; retrieve it by re-running the relevant show commands as custom commands. The AP_USERS data model is populated for Aruba only and returns blank on a Cisco IOS-XE WLC.

For an example, see the NQE query Find all hosts that are Aruba wireless access points.