/ 01
Mixed EXOS / VOSS session recording
Both platforms supported with appropriate CLI parsing. Searchable text across the mixed fleet — useful as Extreme customers consolidate onto Fabric Engine over time.
Extreme Networks operates across campus, data centre, and edge with EXOS as the historical platform, VOSS (Virtual Services Platform) for fabric-attached deployments, and the Fabric Engine successor unifying both. Innovexus brokers SSH sessions to every Extreme CLI-accessible platform — no agent, no ExtremeCloud IQ dependency, no MOS plugin. Vault, rotation, session recording, and drift detection work consistently.
Innovexus is agentless from the Extreme device perspective. Connection via SSH (preferred) and console. Authentication via TACACS+, RADIUS, or local users.
Most Extreme Networks fleets are running through Innovexus within 1–2 business days. The mix of EXOS and VOSS platforms is handled cleanly because both expose standard SSH-based AAA.
Pull existing local admin credentials from each platform class (EXOS and VOSS use slightly different config syntax; Innovexus handles the difference). Vault them. Rotation runs on schedule.
Add the Innovexus pod's outbound IP to your management ACLs. Existing TACACS+/RADIUS continues at the device level.
Map Extreme role profiles to Innovexus role definitions. EXOS uses default `admin` / `user` accounts; VOSS uses CLI access levels (rwa, ro, layer-2-admin, etc.).
Session recording captures the full CLI experience across both EXOS and VOSS. Configuration drift collection uses the appropriate `show configuration` syntax per platform.
Engineers log into Innovexus with their FIDO2 hardware key, click into an Extreme device, and the brokered SSH session opens with the assigned role. Recording, audit, and credential lifecycle operate automatically.
Both platforms supported with appropriate CLI parsing. Searchable text across the mixed fleet — useful as Extreme customers consolidate onto Fabric Engine over time.
Local admin credentials, TACACS+ shared secrets, and RADIUS keys rotate on schedule. Rotation handles the syntactic differences between EXOS and VOSS automatically.
Extreme devices accept management connections only from the Innovexus pod IP. Out-of-band emergency access via vaulted credentials remains available.
Continuous baseline collection across EXOS, VOSS, and Fabric Engine fleets. Drift detected outside approved sessions fires an alert.
Innovexus supports both legacy EXOS and VOSS plus the unified Fabric Engine successor, so PAM operations don't need to change as you migrate. Audit continuity is preserved across the platform transition.
Network monitoring and security operations alongside PAM. Same console, one audit trail, one tier price.
Direct, sourced answers about how Innovexus integrates with this vendor's platforms.
No. The integration is direct via SSH using each platform's standard AAA primitives. ExtremeCloud IQ, ExtremeCloud A3 (formerly Aerohive), and ExtremeManagement are not dependencies. If you run XIQ for orchestration, Innovexus runs alongside it — we handle privileged human and vendor access; XIQ handles cloud management.
Cleanly. Innovexus supports EXOS, VOSS, and Fabric Engine in the same fleet. As you migrate devices to Fabric Engine, Innovexus continues to broker sessions, vault credentials, and detect drift through the transition. The audit trail remains continuous — you can search a single device's session history across the platform migration boundary.
Aerohive APs and the Extreme Wireless platform are typically managed via ExtremeCloud IQ rather than direct CLI. Innovexus integrates with XIQ via SAML SSO for tenant administration. CLI access to APs is supported for diagnostic purposes but not the primary administrative path.
Yes. VOSS-side TACACS+ and RADIUS shared secrets are vaulted and rotated on schedule. The rotation uses VOSS's configuration syntax for shared-key updates and respects the platform's commit model.
Innovexus is fabric-topology agnostic — we connect via SSH to whichever VOSS or Fabric Engine devices you put in scope, regardless of fabric role. The integration doesn't depend on or interfere with the fabric (SPB, VXLAN) control plane. Configuration drift detection works across the entire fabric.
Yes, with normal SSH overhead. The brokered SSH session adds typically 5–20 ms of latency at the protocol layer beyond direct access. For campus and branch deployments where the device is reached over a WAN link, total round-trip latency depends on the WAN — not Innovexus. The broker model imposes no additional latency penalty beyond the SSH layer.
Vault credentials for one device class, allowlist the pod IP, point engineers at it. EXOS, VOSS, and Fabric Engine all supported in the same trial. 5-day trial, no card required.