OmniVista Cirrus Production Notes 10.5.1 (August 2025)
This release of OmniVista Cirrus is available as a free trial or paid version of the full OmniVista Cirrus Solution. The trial version extends for 90 days and can be used to monitor up to 20 Access Point and Switch devices combined (additional time and number of devices can be requested). You can then upgrade from the free trial version to a paid licensed version of OmniVista Cirrus.
OmniVista Cirrus 10.5.1 (OVC 10.5.1) provides an elastic cloud scale platform supporting dynamic expansion, ensuring high availability and resilience. You can access OVC 10.5.1 from anywhere using any approved browser and device (e.g., workstation, tablet). Access to OmniVista Cirrus is supported on the following browsers: Chrome 79+ (on Windows and Redhat/SuSE Linux client PCs), and Firefox 62+ (on Windows and Redhat/SuSE Linux client PCs).
These Production Notes detail features and enhancements, network/device configuration prerequisites, supported devices, and known issues/workarounds in OmniVista Cirrus 10.4.3. Please read the Production Notes in their entirety as they contain important operational information that may impact successful use of the application.
New in This Release
The following sections provide an overview of the features and enhancements introduced with this release.
Devices Supported
Stellar Access Points
There were no new OmniAccess Stellar AP models introduced with this release.
AOS Switches
The following AOS switch models are now supported:
OS9900 (CAPEX license mode only; Flex Pay license not supported)
See the Supported Devices section below for a list of all devices currently supported in OmniVista Cirrus 10.5.1.
Software Supported
AWOS 5.0.3 - OmniVista Cirrus 10.5.1 supports AWOS 5.0.3 on all supported Access Points.
AOS 8.9R4 is the minimum software version supported by OmniVista Cirrus 10. AOS software versions below 8.9R4 are not supported.
AOS 8.10R3 - OmniVista Cirrus 10.5.1 now supports AOS 8.10R3 on all supported AOS Switches.
New Features and Functions
This section details new features introduced in this release.
Important Note: Analytics Only Mode No Longer Supported
This release of OVC 10 no longer supports monitoring Access Point devices in Analytics Only mode.
Existing Analytics Only Access Points are automatically removed from the Device Catalog, as well as any statistics collected.
Management Mode field no longer included in the Device List table, as only Full Management devices are supported. However, field remains in API response.
Application Visibility
Application Visibility is now supported on Access Point models (OmniSwitch support is not yet available).
Application Visibility identifies application/protocol flows based on Application Signatures that identify an associated application or protocol. To enable Application Visibility, you create a Signature Profile that includes all of the signatures for applications/protocols that you want to monitor/control, and apply that profile to network Access Points. Once Application Visibility is enabled, OmniVista Cirrus can identify traffic flows included in the profile across all supported Access Point models.
Signature Profiles are created from a Signature File, which contains Application Signature information for individual applications/protocols as well as application groups (pre-configured groups of related applications/protocols).
UPAM Check for Message-Authenticator RADIUS Attribute
A new Require Message Authenticator flag is now available to specify whether to check RADIUS packets for the Message-Authenticator attribute. This flag is configurable for the following use cases and resolves CVE-2024-3596 (#Blast-RADIUS):
UPAM as RADIUS Server for AP/OmniSwitch – UPAM RADIUS server accepts RADIUS requests from clients within a specified IP range.
Access Points always include the Message-Authenticator attribute in RADIUS request packets.
The OmniSwitch does not include the Message-Authenticator attribute in RADIUS requests or checks for that attribute in RADIUS responses. To ensure that the OmniSwitch includes that attribute in all RADIUS packets sent and also enforces validation of the attribute in all RADIUS server responses, use the aaa radius message-authenticator CLI command on the switch. This CLI command is a global command supported on AOS 8.10R2 or higher.
External Radius server for AP/OmniSwitch (No UPAM) – An Access Point or OmniSwitch sends RADIUS AAA requests directly to a RADIUS server (on-premises or hosted elsewhere); UPAM is not involved. OmniVista configures the AAA RADIUS settings on the AP or OmniSwitch through the AAA Server Profile.
The Require Message Authenticator flag in the AAA Server configuration on Access Points running AWOS >= 5.0.2 enforces that the RADIUS response packets from the RADIUS server contain the Message-Authenticator attribute. Access Points running AWOS < 5.0.2 do not verify the attribute in RADIUS server response packets.
The OmniSwitch does not include the Message-Authenticator attribute in RADIUS requests or checks for that attribute in RADIUS responses. To ensure that the OmniSwitch includes that attribute in all RADIUS packets sent and also enforces validation of the attribute in all responses received from any RADIUS server, use the aaa radius message-authenticator CLI command on the switch. This CLI command is a global command supported on AOS 8.10R2 or higher.
UPAM as Proxy between AP/OmniSwitch and External Radius – UPAM proxies incoming RADIUS requests from an Access Point or OmniSwitch to an external RADIUS server.
When the Require Message Authenticator flag is enabled for the external RADIUS server, UPAM checks for the Message-Authenticator attribute in response packets received from the external RADIUS server. UPAM will then drop any response packets that do not contain the attribute but will continue to send RADIUS request packets to the external RADIUS Server for the specified number of Retries.
When the Require Message Authenticator flag is disabled for the external RADIUS server, UPAM does not check for the Message-Authenticator attribute in RADIUS response packets.
Dynamic Access to Multiple MSPs and Organizations
Users can be declared in two different Organizations.
MSP user can be declared in another MSP/Organization.
MSP administrator can detach an Organization from an MSP. Once detached, all the users within the MSP will no longer have access to the detached Organization.
MSP administrator can also move an Organization to another MSP.
Device Catalog Views
The following Device List views are now available for the Device Catalog:
Basic - Displays the overall configuration for each device, as shown above.
Configuration - Displays configuration information for your OmniSwitch devices and allows you to manage Golden Configuration settings and perform auditing functions.
Connectivity - Displays specific management connectivity information for each device.
License - Displays license information, such as license type and status, for each device.
Model & Firmware - Displays the model number and firmware version for each device.
The user can decide which Device List view they want to use to drill down to any data of interest and key analytic metrics. By default, the Connectivity view is displayed.
License Management
When you create an Organization, you now have two options when requesting access to that Organization:
Request a free Teaser Period.
Skip applying for a Teaser Period and directly apply a CAPEX Subscription license to the Organization.
When the Trial License for a Teaser Period subscription has expired, you now have two options:
Renew the Trial License subscription.
Apply a CAPEX Subscription license to the Organization.
If you attempt to import licenses and the number of selected devices exceeds the number of available licenses, a warning message appears. When this occurs:
The “Next” button on the Import License screen is disabled.
The warning message indicates the number of selected devices that exceeds the number of available licenses. You can the modify the number of devices selected, as needed.
OmniVista Cirrus 10.5.1 Applications Supporting AP and/or LAN Management
Feature | Stellar AP | OmniSwitch |
Inventory | ||
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | Not Supported | |
Does Not Apply | ✔️ | |
Does Not Apply | ✔️ | |
✔️ | Does Not Apply | |
Does Not Apply | ✔️ | |
Network Access | ||
✔️ | ✔️ (except Location Policies, Access Classification, Period Policies) | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
Not Supported | ||
✔️ | Not Supported | |
✔️ | Not Supported | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
Application Visibility Signatures | ✔️ | Not Supported |
Network | ||
✔️ | ✔️ (except Client Blocklist, WIPs, Application Visibility Analytics) | |
✔️ | ✔️ (except IoT Devices) | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | Not Supported | |
✔️ | ✔️ | |
Diagnostic Tools | ||
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ | |
✔️ | ✔️ |
Application Updates/Enhancements
AP Management
New Device Catalog “Neighbor APs” option - Displays a list of neighboring APs to which the connected wireless client might roam. The Neighbor APs List includes the following:
Manually added (static) and automatically-discovered neighbors for the selected AP.
A “Manage Neighbors” option lets you manually add AP neighbors for the selected switch.
Bridge APs can now be configured as Root - In a point-to-multipoint bridge setup, all far-end bridge APs using the same SSID and keys are expected to connect to a single root AP. Without a designated root, these APs could form peer-to-peer links instead of connecting to the intended root bridge. This new feature lets administrators explicitly configure a root AP, ensuring proper topology and eliminating this limitation.
Auditing the Switch Golden Configuration - Drift Detection
When a drift occurs between the Running Configuration and the saved Golden Configuration, you can now view both configurations to compare the differences. In addition, you can restore the Golden Configuration and/or copy the Running and Golden Configuration contents.
A “Drift Detected” counter is listed under the “Global Configuration” section of the Summary panel located on the right side of the Configuration Device List view. You can click on the “Drift Detected” link to display only those switches with a Running Configuration that is different from the Golden Configuration in the Device List.
A new “View Device Configuration” action redirects you to the “Golden Configuration” tab on the Device Detail screen for the selected device. You can perform any of the following actions from the “Golden Configuration” tab:
View the differences between the saved Golden Configuration and the Running Configuration.
Copy the Golden and/or Running Configuration to the clipboard.
Determine the date and time the Drift was detected.
Perform an immediate audit of the switch configuration.
Click on the “Restore the Golden Configuration” option to copy the Golden Configuration to the Running Configuration. Any changes to the Running Configuration are overwritten. You can also specify whether the switch will automatically reboot after the Golden Configuration is restored.
Notifications - Rainbow Bubble Alerts
Integration with Rainbow allows you to send notifications from OmniVista Cirrus to an existing and/or new Rainbow Bubble. For each Organization, Admin users can enable the sending of alerts to the specified Rainbow Bubble.
OmniVista Cirrus Agent
Each new release of OmniVista Cirrus 10 includes the latest version of the OmniVista Cirrus Agent. During the switch onboarding process, the Agent is downloaded to the switch. If a new Agent is released before the next version of OmniVista Cirrus 10 is released, OmniVista Cirrus is updated with this new version; however, previously managed switches are still running the older Agent version.
You can now use the new “Download/Install Latest Version” option to update the OmniVista Cirrus Agent running on managed switches with the new version of the Agent. The next time the managed switch calls home, the new Agent is downloaded to the switch.
Countries of Service for OmniVista Cirrus
You can now select the countries of Argentina, Costa Rica, Columbia, Dominican Republic, Guatemala, Hong Kong, and Vietnam when preforming the following functions:
Signing up for an OmniVista account (Trial or Paid).
Creating a 6GHz band RF Profile.
Creating an Organization.
QoE UI Enhancements
The QoE screens were enhanced to improve the user experience when analyzing key network metrics. Enhanced presentation of widget information includes the following:
Connections over time presented as a stacked bar chart.
Average Connection Time widget added.
The following widget information is presented as a horizontal bar chart.
Failed phases classifiers.
Failures by roam type classifiers.
Causes of low capacity failures.
Causes of low coverage failures.
Reports Application Improvements
This release provides the following improvements for generating Analytics Reports:
Can now generate reports using default built-in templates or admin can customize and add specific data, widgets for report generation.
New report templates available: Inventory Summary, Client Health, Client Summary, Site Summary, Floor Summary, and Building Summary.
Reports include the Switch/AP Friendly Name.
Preview widgets when creating a Regular report.
Client Session Distribution report supports complex “Group By” condition. You can group sessions by any of the two parameters: “site”, “building”, “floor”, “ssid”, “connectionMode”, “vlanId”, “arp”, “health”,”apModel”.
Client count distribution per AP supports query by Top N APs.
Reports are now shared with other users in the Organization.
SSID
Wi-Fi Enhanced Open Transition Mode – Support added to enable Enhanced Open Transition Mode for an SSID.
When this mode is enabled, the AP broadcasts two different types of BSSID: one legacy Open SSID on 2.4GHz/5.0GHz band and one Enhanced Open SSID on 2.4GHz/5.0GHz/6.0GHz band. This allows both Enhanced Open and Non-Enhanced Open clients to connect to the same open SSID without adversely impacting the end user experience.
The Enhanced Open setting is available when the SSID usage is set to Guest Network (Open or Captive Portal) or Employee BYOD Network.
Note that the Enhanced Open Transition Mode is supported only on APs running AWOS 4.0.8 or above. Enabling this mode for APs running older AWOS versions may cause the SSID to revert to an open SSID after a reboot. Upgrading your network is highly recommended.
Backward Compatibility – Support for 2.4/5GHz devices when 6GHz band is selected.
Enables/disables using WPA3_PSK_SAE_AES encryption on 2.4GHz and 5.0GHz bands when encryption is automatically set to WPA3_SAE_AES for the 6.0GHz band.
When the 6.0GHz band is selected for the SSID, the other bands inherit using WPA3_SAE_AES encryption, which some legacy devices cannot use to connect to the SSID.
When Backward Compatibility is enabled, the WPA3_PSK_SAE_AES Encryption Type is automatically used for the 2.4GHz and 5.0GHz bands, and the 6.0GHz band continues to use WPA3_SAE_AES.
The Backward Compatibility setting is available when the SSID usage is set to Protected Network (Pre-Shared Key & an Optional Captive Portal) or Protected Network for Employees (Pre-Shared Key & BYOD Registration Portal) and the Allowed Band is 6.0GHz.
Note that if the MLO Band setting includes 6.0GHz, then the Backward Compatibility option is automatically disabled.
Topology Enhancements
Icon Size - The size of a device icon is adjustable to make the icon smaller or larger on the Topology Map.
Device Name - A new filtering option to show or hide the device name on the Topology Map.
Unmanaged Devices - By default, are not displayed, but may still appear grayed out in the Topology Map if the device is an intermediate node.
Circle Topology Layout - Circular layout changes to a spiral layout to accommodate large networks.
Device Status Dot - The status of a device is indicated by the color of the dot displayed on the device. The dot color to use for the device status is based on the specified color theme for trap severity levels configured in the User Preference settings for Appearance.
Unified Access
Assigned Switch Configuration Details - You can now view the current profile configuration for each Switch that is assigned to an Access Authentication Profile, AAA Server Profile, Access Role Profile, and Unified Policies.
Click on a profile name to view the switches to which the profile is applied.
View and edit the profile configuration applied to the switch.
Access Authentication Profile - Attributes now supported on AOS Switches:
Port Bounce - When enabled, the port is administratively shut down when a client is switched from one VLAN to another after a Change of Authorization (COA). This is to trigger DHCP renewal and re-authentication, if necessary.
AP Mode - The Switch device automatically detects, learns, and manages a Stellar AP that is connected to the port. Wireless Client traffic is then forwarded from the AP to the Switch device onto the wired network.
Advanced 802.1X Settings - Additional 802.1X authentication settings.
Access Role Profile - Attributes now supported on AOS Switches:
Auth Flag - Enables/Disables authentication (not supported on APs).
Mobile Tag Status - Enables/Disables classification of tagged packets received on UNP ports (not supported on APs).
Redirect Status - Enables/Disables Captive Portal Redirect. When enabled, the Access Role Profile can only map to a VLAN when applying the profile to a device.
QoS/ACL - Define a QoS Policy for the Access Role Profile.
Inactivity Interval - Defines the amount of time, in seconds, before an authenticated device is automatically logged out of the network due to inactivity (MAC address for the device has aged out).
VLAN/Tunnel Mapping - Map the Access Role Profile to a VLAN or a Guest Tunnel ID.
Unified Policy/Policy List - Attributes now supported:
L3 IP Group and Group MAC address - Can now define an L3 IP Group and Group MAC address combination for a policy condition.
L4 Service Condition - Supports selecting the ICMP Protocol to create a condition for a Service Protocol only.
ICMP Policy Condition - Applies the policy to traffic with a specified ICMP Type or Code value. For Steller Access Points, ICMP configuration must be combined with Service protocol = ICMP in L4 Services.
L7 Application Visibility Condition - Applies the policy to traffic flowing to and from an Application Group or Application.
IoT Categorization
IoT Inventory now includes wired clients for AOS switches.
IoT Enforcement is now configurable for wired clients.
For MAC and 802.1x authentication, OmniVista Cirrus applies IoT enforcement only after successful authentication. The IoT-based profile is not applied if authentication fails.
Note: This does not apply to Captive Portal authentication.
GRE Tunnel Resiliency - Can now configure a backup GRE Tunnel Server to provide GRE tunnel redundancy between an AP and GRE Tunnel Server. When the primary GRE Tunnel Server IP address goes down, the backup Tunnel Server takes over.
AP Ethernet-Over-USB Support - New USB0 port selection is now available when configuring the AP Group port assignment for an Access Authentication profile. Selecting USB0 indicates that an Ethernet-over-USB dongle is connected to an AP USB host port.
UPAM
Captive Portal (Simple Persona) - You can now select “Simple Persona” as the Login Strategy when configuring Guest Access Strategy. The user is then requested to enter just an Email address for the Captive Portal Guest Access login.
Authentication Records - Improved information and UI presentation. You can now view the Authentication Record flow in a well-structured manner (NAS > UPAM > External Source and External Source > UPAM > NAS).
Accounts - Import templates for Company Property, Guest Account, and Employee Account, now include all attributes available on the form used to manually create account entries.
Framework Updates
This release included major updates to many third-party packages to address vulnerabilities.
Beta Features
The following Beta features are available in OmniVista Cirrus 10.5.1 and can be configured. However, they have not gone through the complete validation cycle and are therefore not officially supported.
IPv6 Support (Not at GA Level) - IPv6 options may appear for various features in the OmniVista Cirrus UI; however, IPv6 was not certified for release in 10.5.1. OmniVista Cirrus support for IPv6 is experimental at this time.
MACsec Encryption - MACsec Encryption for provisioning configurations assigned to Access Points Groups. This allows you to configure MACsec support for member devices of the associated Access Point Group.
MACsec functionality is supported in AWOS 5.0.3 GA only on the AP1321 and AP1361.
Only specific OmniSwitch models and ports support MACsec. Ensure your AP is connected to a port that supports MACsec. Refer to the AOS documentation for the OmniSwitch model you are using for more details.
Celona Private 5G Integration - UPAM integration with the Celona Private Wireless solution.
Celona Edge first performs authentication based on SIM, then users are authorized by validating the SIM card (IMSI) or the device (IMEI) with Enterprise NAC (UPAM).
NAS Clients are now configurable as third-party devices to accommodate Celona device integration.
New UPAM IMSI/IMSE database for UPAM authorization of Celona devices.
Regulatory Compliance
OmniVista Cirrus 10.5 compliance in US, EU, and abroad:
General Data Protection Regulation (GDPR)
California Consumer Privacy Act (CCPA)
Third-Party and Open-Source Contributions
Software Bill of Materials (SBOM) is available in CycloneDX format.
Network and Device Prerequisites
To ensure the necessary communication between devices (Access Point/Switch) and OmniVista Cirrus 10.5.1, verify/configure the following prerequisites on your local network:
Network Prerequisites - Network deployment, bandwidth, proxy, firewall, and NTP server requirements.
Device Prerequisites - Supported Access Point software and models.
If your fully managed Access Points are running AWOS 4.0.8, it is recommended that you upgrade to AWOS 5.0.3 by setting the Desired Software Version first before accessing OmniVista Cirrus 10.5.1.
It is also recommended that you upgrade your OmniSwitch AOS release to 8.10R3.
Onboarding Devices Workflow - The basic steps involved to onboard Switches and Access Points for management in OmniVista Cirrus.
Supported Devices
Click here for a list of supported Stellar Access Points and AOS Switch models, which includes the supported software releases and the license information based on the licensing model (Flexible Pay or CAPEX).
The following Access Point models are not supported:
OAW-AP1101
OAW-AP1201L
OAW-AP1201H
OAW-AP1201HL
OAW-AP1201BG
OAW-AP1261
REST API Management
You can use REST APIs for scripting or integration with any third-party systems in your management network. The complete API reference can be found at the following link based on your region (no login is required):
EU: https://eu.manage.ovcirrus.com/apidoc/apidoc.html
Americas: https://us.manage.ovcirrus.com/apidoc/apidoc.html
For more information, see Automation with APIs.
Known Issues/Workarounds
Inventory
Device Fails to Get Certificates (OVNG-21279)
Summary: When re-adding a device or moving a device between OmniVista 4 and OmniVista Cirrus 10, there are no issues as long as the device retains its certificates and calls home using the certificates. However, if the device certificate is lost and the device calls home using a hash, the device will receive a “FailedToGetCertificate” response. This occurs because the Certificate Server does not permit issuing new certificates to the same device more than once.
Workaround: Contact Alcatel-Lucent Technical Support to request manual certificate regeneration for the affected devices.
Schedule Upgrade Using Set Desired Software Version (OVNG-10325)
Summary: When an AP already follows a group schedule and the software version is changed using the “Set Desired Software Version” option from the Edit Device drop-down menu, note the following:
If the AP Group of the AP device is not part of a schedule upgrade, then the Desired Software Version is set to “Do Not Upgrade”.
If the AP Group of the AP device is part of a schedule upgrade, the AP device will be upgraded to the Desired Software Version based on the schedule upgrade for the group.
Workaround: Use the “Information” or “Schedule Software Upgrade” options from the Edit Device drop-down menu to have an AP already following a group schedule upgraded to the specified software version on the next call home.
Cannot Enter Another Username/Password in Terminal Session Modal (OVNG-14678)
Summary: If you enter an incorrect Username/Password when establishing an SSH Terminal Session with a device, an error message is displayed and the Device Credentials modal re-opens. Entering another Username/Password in the modal does not correct the problem, so the SSH connection still fails.
Workaround: Close the Device Credentials modal and the Terminal Session window, then select the device and start a new session.
Auto-Group VLANs Fails to Apply a New Profile to an AP (OVNG-15351)
Summary: The Management VLAN-Based Automatic Grouping option does not work as expected. When you add an AP deice and select the “Mgmt VLAN Based Automatic Grouping” option for the Access Group, the Provisioning Configuration and all existing configurations linked to the matching group are successfully pushed to the AP. However, if any changes are made to the configuration after the AP has onboarded are not pushed to the AP.
Workaround: Edit the AP configuration to manually set an AP Group for the AP.
Cannot Onboard a Virtual Chassis if Adding Two Slave Devices into Device Catalog (OVNG-15331)
Summary: When onboarding a Virtual Chassis (VC) with two Slave switches, provisioning fails if the switches do not use the default Admin account for login credentials. This occurs if the default password for the Admin account was already changed before the VC was onboarded.
Workaround: Set the Initial Configuration again (either the Management User Template or Provisioning Template/Value Mapping). Note that after provisioning fails, only one record shows in the Device Catalog. Search for the device by Serial Number and update the Initial Configuration.
Set Desired Software Version May Fail for Switch VC if Primary Switch Serial Number Doesn’t Match VC Serial Number (OVNG-13619)
Summary: When adding a switch Virtual Chassis (VC) to OmniVista Cirrus, you can enter any Master or Slave serial number that belongs to the VC into the Device Catalog. After the switch sends a Call Home request to OmniVista Cirrus, the record in the Device Catalog is updated to the VC Serial Number (vcSerialNumber). Usually, the serial number of the current Master equals the vcSerialNumber. However, if a VC split, takeover, etc., occurs, the serial number of the current master may not match the vcSerialNumber. This discrepancy may cause problems when attempting to set the Desired Software Version for the VC.
As soon as the VC Switch is added to OmniVista Cirrus (before the device sends a Call Home request) or after the VC Switch becomes managed, you can set the Desired Software Version.
If the VC Switch has been added to OmniVista Cirrus but not yet managed, the Desired Software Version changes to 'Do not upgrade' when you add the Master/Slave serial number (not vcSerialNumber).
If the VC Switch is managed on OmniVista Cirrus, the Desired Software Version may not display correctly when the Virtual Chassis switches are split or broken.
Workaround: Check the Call Home request sent from the switch Virtual Chassis (VC) in the “/flash/libcurl_log” file. You can access this file by running Collect Support Info on the Switch and downloading it to your computer to examine the contents. Here’s an example Call Home request found in the “/flash/libcurl.log” file showing the VC serial number:
Request data: {"data": {"devices": [{"serialNumber": "V3981563", "deviceMacAddress": "2c:fa:a2:a2:ea:71", "modelName": "OS6560-P24Z8", "partNumber": "903953-90", "role": "master", "hash": "5e9275478352a44861dedbb659523f46b1046eb80eb78e43ecc30c141395e221", "vcSerialNumber": "ALE203981575", "vcMacAddress": "2c:fa:a2:a2:fb:01", "currentSoftwareVersion": "8.9.92.R04", "currentCertifiedSoftwareVersion": "8.9.92.R04", "currentRunningDirectory": "working", "deviceCloudGroup": "-", "authMethod": "certificate", "thinClient": 0, "typeCallHome": "periodic", "deviceMode": "CAPEX", "naasLicenses": []}, {"serialNumber": "JSZ203981575", "deviceMacAddress": "2c:fa:a2:a2:fb:01", "modelName": "OS6560-P24Z8", "partNumber": "903953-90", "role": "slave", "deviceMode": "CAPEX"}]}}
When the issue occurs:
If the VC Switch has been added to OmniVista Cirrus but not yet managed, manually reset the Desired Software Version for the VC Switch.
If the VC Switch is managed on OmniVista Cirrus and is split or broken, complete the following steps:
Remove all Chassis entries belonging to the Virtual Chassis switches.
Completely reset the Virtual Chassis switches.
Add the switch again using the VC serial number from the request (recommendation).
Adding a Switch to a Virtual Chassis May Cause the Primary Switch to Return to the Register State (OVNG-17750)
Summary: When adding another switch to a Virtual Chassis configuration, the new switch does not consume a license and the VC primary switch moves to “Registered” status.
Workaround: Release the license for the primary switch, then assign the license again. The license count is then updated on the next periodic or manual rediscovery.
Provisioning Fails for 8.10R1 Default Factory Switch (OVNG-17310)
Summary: When a switch running AOS 8.10.R1 GA boots up without a vcboot.cfg file for auto-configuration, the SSH is disabled by default, causing provisioning to fail. Only the console is enabled. This is not limited to a particular platform and can be seen on any switch running AOS 8.10.R1.
Workaround: Enable AAA authentication SSH on the 8.10R1 switch via the CLI. Problem is fixed in the AOS 8.10R1 MR1 release.
Force Provisioning Required for Switches Managed on a Previous Release of OmniVista Cirrus 10 (OVNG-18116)
Summary: When a new switch is onboarded in the current OmniVista Cirrus 10.4.3 release, the latest version of the OmniVista Cirrus Agent is pushed to the switch. However, If the device was already managed in a previous release of OmniVista Cirrus 10, the latest version of the OmniVista Cirrus Agent is not pushed to the switch.
Workaround: Force Provision the switch device to install the latest version of the OmniVista Cirrus Agent.
Manual Rediscovery Does Not Update All Objects Changed on Switch (OVNG-17911)
Summary: When you do a manual Rediscover action, OmniVista Cirrus does not update the following objects with any changes configured through the Switch CLI:
Access Role Profile,
Access Authentication Profile
Unified Policy
Unified Policy List
Manual Rediscover only updates the following objects with any changes configured through the Switch CLI:
Device hardware information
Device system information
Device status information
IP Interface
Port information
UNP Ports
VLAN Members
Poll link
Workaround: Wait for automatic rediscovery that occurs once an hour for updates to the Access Role Profile, Access Authentication Profile, Unified Policy, and Unified Policy List.
ISSU
Cloud Agent Status “Unknown” After ISSU Upgrade on AOS 8.9Rx Switch (OVNG-14310)
Summary: After an ISSU upgrade on an OmniVista Cirrus 10 managed switch, the Cloud Agent Status on the switch is “Unknown”.
Workaround: Manually copy the cloudagent.cfg file from "/flash/working/cloudagent.cfg" to "/flash/issu/cloudagent.cfg" on every managed switch after the ISSU upgrade. This will be fixed in the next AOS 8 release.
LAN Management
OmniVista Cirrus 10 Does Not Correctly Process More Than 2000 VLANs From a Switch (OVNG-18228)
Summary: If VLANs are created, updated, or deleted through the switch CLI and there are more than 2000 VLANs configured on the switch, OmniVista Cirrus does not correctly process the switch changes when the switch is next polled. As a result, OmniVista Cirrus UI does not reflect the updated switch VLAN configuration.
Workaround: To get the latest OmniVista Cirrus Agent and switch configuration, Force Provisioning is required for existing managed switches.
License Management
Cannot Import a Flexible Pay License (OVNG-21421)
Summary: When you attempt to import a Flexible Pay license, the license is imported into OmniVista Cirrus, but you are unable to complete the upgrade from a Teaser to a Flexible Pay license.
Workaround: Contact your Alcatel-Lucent Enterprise Technical Support representative for assistance.
Need to Wait One Day After License Renewal to Add Devices (OVNG-14988)
Summary: If all licenses are used up, you cannot add new devices to the Device Catalog until new licenses take effect.
Workaround: Wait one day after license renewal to add devices to the Device Catalog.
Network Monitoring
It Takes More Than 45 Minutes for a Client to Appear on the Application Visibility Widgets Page (OVNG-19911)
Summary: When Daylight Savings Time is configured, new records do not appear for one hour, and old records display with a one-hour delay.
Workaround: There is no workaround at this time.
Collect Support Info Feature Does Not Work on NaaS APs that have an expired Management License (OVNG-5850)
Summary: If the NaaS management license expires for an AP in NaaS mode, the Collect Support Info operation will fail.
Workaround: Make sure the NaaS Management License is active when the AP is functioning in the NaaS mode.
Error Message When Filtering Auth Resource Column in Authentication Records List (OVNG-15414)
Summary: When you enter a search value to filter the “Auth Resource” column in the Authentication Records List, an error message is displayed instead of search results.
Workaround: There is no workaround at this time. A fix will be provided in the next release.
Incorrect Event Responder Information When Device is Moved to a Different Site (OVNG-15663)
Summary: When the location of a device is changed to a different Site, the Event Responder page still shows the old site for the device-specific Event Responder.
Workaround: Edit the Event Responder page for the specific device to update the site information.
Final Access Role Profile in Authentication Record Does Not Update Immediately After Captive Portal Authentication on Switch (OVNG-14892)
Summary: The "Final Access Role Profile" field displayed in the Authentication Record is the Access Role Profile (ARP) that the Switch actually applies to the device after successful Captive Portal authentication, but it is not the ARP that you would expect to apply to the device.
Workaround: Disconnect the client, then connect the client again to update the final ARP as expected.
LLDP Link Information On Device Detail Page Incorrect Between Managed and Unmanaged Switches (OVNG-14208)
Summary: When you click on the “LLDP” tab on the Device Detail screen for a switch, the LLDP link port information may not be correct and some fields blank. This occurs only with an unmanaged switch and a managed switch.
Workaround: There is no workaround at this time.
Link on the Topology Map Is Lost When the Switch Goes Down (OVNG-14922)
Summary: When the switch that an Access Point or another switch is connected to goes down, the link between the two devices disappears from the Topology Map instead of turning red. The Access Point will be linked to Cloud node.
Workaround: There is no workaround at this time.
CSV Analytics Report File Displays More Fields Than the Created Report (OVNG-15429)
Summary: When generating a report in CSV file format, you can select the fields to include in the report. However, the resulting generated CSV report does not include all of the selected fields.
Workaround: There is no workaround at this time.
Completed Wired Client Sessions Not Shown After Device is Deleted (OVNG-15250)
Summary: After deleting a device, wired clients connected to that device are removed from the “Live Wired Clients” list but are still shown as a complete sessions in the “Wired Client Sessions” list. However, you are unable to view additional information for these sessions.
Workaround: There is no workaround at this time.
Unified Access
Unified Access Profiles in Pending Status After Upgrade to OmniVista Cirrus 10.5.1 (OVNG-21343)
Summary: After upgrading to OmniVista Cirrus 10.5.1, the configuration status of existing Unified Access profile templates is “Pending”.
Workaround: The configuration status will return to a normal state when you try to edit the template and apply it to devices again. Another workaround is to navigate to the device view of the template (by clicking on the template name), select all Device Config entries and perform a multi-edit action.
When Applying Two Policies With the Same Condition Group Simultaneously, the Latest Data on the AP Is Not Updated (OVNG-19125)
Summary: OmniVista Cirrus pushes the correct data to the AP when two Unified Policies with the same Condition Group are applied simultaneously. However, the latest policy data is not updated on the AP.
Workaround: Restore policy data synchronization to ensure APs will successfully receive and apply the most current policy configurations. This requires completing the following steps to re-establish policy associations:
Navigate to Policy Management
Access the Unified Policies screen (Configure > Network Access > Unified Access > Unified Policies).
Locate the two affected policies that share the same Condition Group.Unlink policies from the AP group
Access the assignment settings for each affected policy.
Remove the AP group association from both policies.
Confirm the AP group is no longer listed under either policy's applied groups.Re-apply policies sequentially
Return to the first policy's assignment page.
Re-add the AP group to this policy's applied groups.
Wait for the assignment to complete and propagate.
Repeat the process for the second policy.Validation through Unified Policies Screen
Verify both policies now show the AP group in their applied assignments.
Confirm the shared condition group is properly configured in both policies.
Monitor AP status to ensure the latest policy data has been synchronized.
Limitation When Selecting an Existing Group for a Unified Policy Condition (OVNG-10669)
Summary: When using the “Choose Existing Group” option for an L2 MAC or L3 IP Policy Condition, if you modify the Group after the Policy is saved and applied to APs, your changes to the Group will not be applied to the APs. This limitation does not occur when using the “Create a New Group” option.
Workaround: After you modify the Group on the Group screen, go to the Unified Policy and select the “Not defined” option (or make any other change to the Policy) and save it. Then edit the Unified Policy again and select the “Choose Existing Group” option.
All of the Special Characters Not Allowed in Unified Policy List Name are Not Specified (OVNG-15404)
Summary: When creating a Unified Policy List with special characters that are not allowed, the “Name” field value prompt does not include all of the special characters that are not allowed. For example, if you enter “PolicyList1&TP1” as the list name, the error message below the “Name” field does not include the “&”.
Workaround: Do not use any special characters in the Unified Policy List Name.
Redirect URL Not Working After Successful BYOD Portal Authentication (OVNG-10674)
Summary: After BYOD Portal Authentication passes, the Success Portal Page displays but the user is not redirected to the “Go to initial URL” specified in the BYOD Access Strategy. This issue occurs only when the initial URL begins with “HTTPS”.
Workaround: No workaround at this time.
Limitations for Deleting Unified Access Profiles on AOS Switches (OVNG-18331)
Summary: When you delete single or multiple unified profiles, such as Access Auth Profile, Access Role Profile, AAA Profile, or AAA Servers, OmniVista Cirrus will remove the profiles from the OmniVista Cirrus database and send a delete message to the switch. However, if the switch is unreachable, the delete message is not received; therefore, not removed from the switch configuration. OmniVista Cirrus will then create the profiles the next time the switch is polled.
Workaround: No workaround at this time.
UPAM-NAC
Errors Occur When the Client Continuously Connects and Reconnects to SSID Portal (OVNG-9735)
Summary: When a user logs into the network, then logs out, and then logs in again, the user may see error messages on the login portal and won’t be able to access the network.
Workaround: User should try to avoid continuously logging in and logging out of the network.
After Upgrading to Android 11 or 12, EAP-TLS Protected Wi-Fi No Longer Works (OVNG-9786)
Summary: In 2021, Android (Google) made a change in their OS to enforce "Validate Server Certificate" option for a 802.1X authentication. This means that, Android 11 and 12 will validate the server's device certificate. Hence users need to specify server's device certificate chain (Root And/Or Intermediate CA's) on their Android devices. If not the authentication will fail. Android 10 and below still works.
Workaround: An alternative is to upgrade the devices to Android 13. Android 13 offers "Trust on First Use" (TOFU) feature. TOFU enables installing the Root CA certificate received from the server during initial connection to a new network. The user must approve installing the Root CA certificate.
Client Unable to Join 802.1X SSID When All EAP = NO and Allowed Method = EAP-TLS for the Access Policy (OVNG-10155)
Summary: When you create an SSID and select an Access Policy with All EAP set to “No” and Allowed Method set to “EAP-TLS” for the SSID Authentication Strategy, the client is unable to join an 802.1X SSID.
Workaround: There is no workaround at this time.
Delay in Seeing BYOD IPv4 Client in the List of BYOD Device Records (OVNG-10759)
Summary: Once a client connects to a BYOD SSID, there is a delay before seeing the Client IPv4 address in BYOD device records. The AP to which the Client is connected will send the client IPv4 with the second accounting packet.
Workaround: No workaround at this time. Problem will be fixed in the next release.
Service Temporarily Unavailable Message With External RadSec Server (OVNG-11277)
Summary: When attempting to authenticate with an External RADIUS Server that is using RadSec ((RADIUS-over-TLS), you may receive a “Service Temporarily Unavailable” message from OmniVista Cirrus.
Workaround: Configure a new External RadSec Server to replace the old one.
Captive Portal Screen Displayed on Microsoft Edge (OVNG-13528)
Summary: When a guest device using a Microsoft Edge browser opens the Captive Portal Template after connecting to an SSID, the sign in/sign up form may not display (no username, password input shown). If this happens, there may be a mismatch between the hostname the Web browser is attempting to reach and the hostname sent by the Web server in a digital certificate.
Workaround: Click the Lock → Connection is Secure → Certificate Icon on the browser to check if the certificate is correct. For example:

Wireless
Each AP Group Can Only Support Up to Seven SSIDs (OVNG-9610)
Summary: When you try to assign a new SSID into an existing AP Group that already has seven SSIDs, that AP group will not be included into the new SSID.
Workaround: Enable the Extended SSID Scale attribute for the AP Group. When enabled, only AP models that support up to 14 SSIDs can join the AP Group. When disabled, any AP model can join the group, but the limit is 7 SSIDs per AP Group. Note that 6GHz networks do not support the Extended SSID Scale attribute and support only 4 SSIDs per AP Group.
Data VPN Setting With Shorthand Mask IP Address Ending in Zero Fails (OVNG-15394)
Summary: If you create a Data VPN Setting profile and specify a Network IP Address for the Shorthand Mask option that ends in zero (10.2.2.0), editing VPN Setting profiles will fail.
Workaround: Avoid specifying a Network IP Address for the Shorthand Mask option that ends in zero. As an alternative, you can use an IP address that ends in .1 (10.2.2.1) to specify a similar IP range.
Other
AP does not Send “portal.report” Event when Wrong Username/Password Entered (OVNG-2811)
Summary: When a user logs in to UPAM Captive Portal with an incorrect username/password, the login will fail but the failure is not immediately indicated on the QoE Analytics UI. Only after 15 minutes will QoE report the failure and the failure is reported as a “Timeout”. Two consequences of this are: Users won’t find out about the failures to login to UPAM Captive Portal until after 15 minutes, and the user will not be able to differentiate between a true “Timeout” with UPAM Captive Portal versus wrong credentials entered at UPAM Captive Portal login.
Workaround: No workaround at this time.
"HostName" Information Lost in “user.report” After the Client Roams to Another AP (OVNG-7792)
Summary: The Client Name (aka “HostName”) information in WLAN Client List is lost after the client roams to another AP.
Workaround: No workaround at this time.
AP Client is Assigned to Untagged VLAN Instead of Tunnel ID Configured in Access Role Profile (OVNG-11683)
Summary: When an Access Role Profile (ARP) with Tunnel only mapping is applied to an AP client, the client is assigned an IP Address in the Untagged VLAN network, not an IP address in the Tunnel network.
Workaround: No workaround at this time.
Rogue AP Cleared Alert Is Not Generated if Organization Status Is Update Requested (OVNG-14906)
Summary: If an Organization is waiting for a requested subscription update, “Rogue AP Cleared” alerts are not generated for APs within that Organization.
Workaround: When the Organization update request is approved, “Rogue AP Cleared” alerts are generated.
Issues Fixed
Issues Fixed Since Release 10.4.3
Customer PRs Fixed
Management connectivity status is OFF for AOS switch (SR # 00807386 CRNOV-7152).
OV Cirrus Account Activation Failure due to time zone mismatch (SR # 00810183 CRNOV-7191/OVNG-19901).
AP stuck in calling home in hash mode with FailedToGetCertificate status when onboarding to OmniVista Cirrus (SR # 00816825 CRNOV-7318/OVNG-14879).
AP Friendly Names Reverting to Default (AP-XX:XX) (SR # 00820756, 00821852 CRNOV-7334/OVNG-21004)
Release Note Issues Fixed
If the SSID Name in a “aproqueinfo.report” Contains a Semicolon, WIPs Alerts and Analytics are Not Generated (OVNG-14205)
Issues Fixed Since Release 10.4.2
Start/End Date Values Not Shown When Editing a Report with a Custom Date Range (OVNG-14672)
Cannot Edit a Tunnel Profile with “%” or “+” in the Profile Name (OVNG-15410)
Creating/Editing Unified Policy With Allowed Special Character Does Not Always Work (OVNG-15415)
Save Disabled When Editing the Responder Status (OVNG-15530).
Issues Fixed Since Release 10.4.1
Current Client Density Screen Displays Incorrect Session Start Time for AP Clients (OVNG-11243)
AP Location is Empty in Live Wireless Client Additional Information (OVNG-12164)
Editing the AP Device Location Disrupts Connectivity With the AP (OVNG-12252)
Mismatch Between Time Filters on the Client Analytics Screen and the Clients Screen (OVNG-12257)
Issues Fixed Since Release 10.3
PKSC8 private key is not supported for LDAP cert and AP Web Cert (OVNG-7726)
False Portal Authentication Failure Alert Messages Received (OVNG-11239)
Current Client Density Screen Displays Incorrect Session Start Time for AP Clients (OVNG-11243)
Additional Documentation
Online help is available in OmniVista Cirrus and can be accessed by clicking on the Help Link (?) in the upper-right corner of any screen. You can also search through the online help on the OmniVista Cirrus Documentation home page and/or use the following links to familiarize yourself with OmniVista Cirrus 10.4.3 features and functionality:
Getting Started – What you need to know to get up and running.
Configure Organizations for Network Management - How to create and manage Organizations, including creating/modifying sites, adding devices, and adding users.
Configure and Manage Device Inventory - Add, edit, or remove Access Point devices from the device inventory. The Device Inventory is also where devices obtain their provisioning configuration when they are added to the inventory.
Configure WLAN Network Management- Configure wireless networks, policies to prevent attacks on Stellar AP Series Wireless Devices, and Radio Frequency (RF) profiles for devices. It is also used to configure External Engines and UPAM server certificates.
Configure Network Access Control - Configure security functions (authentication, classification) to provide network access controls that are applied to devices attempting to access the network.
Monitoring Network Device Activity – Monitor, evaluate, and troubleshoot network components and device activity.
Automation with APIs – Develop applications to integrate with OmniVista Cirrus 10.4.3.
Troubleshooting - Review general troubleshooting questions and actions for using OmniVista Cirrus. You can also find links to troubleshooting information for specific features.
Technical Support
Alcatel-Lucent Enterprise technical support is committed to resolving our customer’s technical issues in a timely manner. Customers with inquiries should contact us at:
Region Phone Number
North America 1-800-995-2696
Latin America 1-877-919-9526
Europe Union +800 00200100 (Toll Free) or +1(650)385-2193
Asia Pacific +65 6240 8484
Email:ale.welcomecenter@al-enterprise.com
Internet: Customers with Alcatel-Lucent service agreements may open cases 24 hours a day via Alcatel-Lucent’s support web page at: https://myportal.al-enterprise.com/.
Upon opening a case, customers will receive a case number and may review, update, or escalate support cases on-line. Please specify the severity level of the issue per the definitions below. For fastest resolution, please have telnet or dial-in access, hardware configuration—module type and revision by slot, software revision, and configuration file available for each switch.
Severity 1 - Production network is down resulting in critical impact on business—no workaround available.
Severity 2 - Segment or Ring is down or intermittent loss of connectivity across network.
Severity 3 - Network performance is slow or impaired—no loss of connectivity or data.
Severity 4 - Information or assistance on product feature, functionality, configuration, or installation.