Multi vendor, and the matrix says where the gaps are

• Cisco
• Huawei
• Juniper
• Aruba
• Arista
• Nokia
• Dell
• Fortinet
• F5
• Palo Alto Networks
• Infoblox
• Forcepoint

CoveredPartialNot covered

Platform	Inventory	Topology	Compliance	CVE	Spanning tree	MPLS and L2VPN
Cisco IOS 12 and 15	Covered	Covered	Covered	Covered	Covered	Covered
Cisco IOS XE 16 and 17	Covered	Covered	Covered	Covered	Covered	Covered
Cisco ASA	Covered	Partial	Covered	Covered	Not covered	Not covered
Cisco NX-OS	Covered	Covered	Covered	Covered	Covered	Partial
Cisco IOS XR	Covered	Covered	Covered	Covered	Not covered	Covered
Huawei VRP	Covered	Covered	Covered	Covered	Covered	Covered
Juniper Junos	by import	by import	by import	by import	Not covered	Not covered
Aruba AOS-CX	Covered	Covered	Covered	Covered	Not covered	Not covered
Aruba AOS	Covered	Covered	Covered	Covered	Not covered	Not covered
Dell OS10	Covered	Covered	Covered	Covered	Not covered	Not covered
Arista EOS	by import	by import	by import	by import	Not covered	Not covered
Nokia SR OS	by import	by import	by import	by import	Not covered	Not covered
Fortinet FortiOS	Covered	Partial	Covered	Covered	Not covered	Not covered
F5 TMOS	Covered	Partial	Covered	Covered	Not covered	Not covered
Palo Alto PAN-OS	Covered	Partial	Covered	Covered	Not covered	Not covered
Infoblox NIOS	Covered	Not covered	Covered	Partial	Not covered	Not covered
Forcepoint NGFW	Covered	Partial	Not covered	Covered	Not covered	Not covered

Compliance rule sets ship per platform, and most have a reference configuration set that tests them on every build. Forcepoint NGFW is collected but has no rule set yet: we would rather say so than evaluate it against another vendor's rules. Spanning tree is captured on Cisco and Huawei switches, MPLS and L2VPN on Cisco IOS, IOS XE, IOS XR and Huawei. Firewalls and load balancers appear in the topology through their addressing rather than a reported neighbour, since those platforms do not run LLDP or CDP. Juniper Junos, Arista EOS and Nokia SR OS are marked by import: you supply the configurations and command outputs, NacTrack parses them and shows them alongside the rest of the estate. Automatic SSH collection does not support these three platforms, and we would rather say so here than at deployment.

Platform	What is read from it
Cisco ISE	Network access devices, live sessions with the 802.1X and MAB split, profiled endpoints, identity and endpoint groups, authorisation profiles, TrustSec with its SGTs, SGACLs and egress matrix, identity sources, TACACS profiles and command sets.
Cisco Catalyst 9800, on IOS XE	The controller, its access points, its WLANs, the radios and the associated clients. The controller is itself an IOS XE device, so the inventory, compliance and CVE of the IOS XE row already apply to it.

Both of these surfaces are in the lab, and the product says so on screen on every one of their pages. The controller was validated against a real CW9800M; AireOS, the previous generation, is not supported and we would rather write that here.

• You open a ticket. That is all we ask of you: the platform enters the support flow like any other request, and we carry it from there.
• The rest is our work. The parsing runs on text from a real device, and that text is gathered while the ticket is handled. There is no vendor API to obtain, no partnership to sign and no third party release to wait for.
• A platform comes in through import first, which gives inventory, compliance and CVE immediately, then moves to SSH collection once the command set has settled.
• Specific architectures take the same route: an inherited addressing plan, a hand built VPLS, a naming convention peculiar to your house get described in a ticket, then correlated like everything else.