Home Getting Started Status Community Help
Alcatel-Lucent OmniVista Cirrus

Network Management as a Service

Home
/
Production Notes
/
OmniVista Cirrus Production Notes 4.9.2
OmniVista Cirrus Production Notes 4.9.2

OmniVista Cirrus Production Notes 4.9.2

OmniVista® Cirrus is a cloud-based Network Management System (NMS). This cloud-based approach eliminates the need for purchasing and maintaining a physical server and installing the NMS onsite, since everything resides in the cloud. Network Operators can access OmniVista Cirrus from anywhere, using any approved browser and device (e.g., workstation, tablet).

Access to OmniVista Cirrus is supported on the following browsers: Chrome 68+ (on Windows and Redhat/SuSE Linux client PCs), and Firefox 62+ (on Windows and Redhat/SuSE Linux client PCs).

These Production Notes detail new features and functions, network/device configuration prerequisites, supported devices, and known issues/workarounds in OmniVista Cirrus. Please read the Production Notes in their entirety as they contain important operational information that may impact successful use of the application.

New Features and Functions

An overview of new features and functions is provided below.

Devices

AOS Switches

The following new switch models are now supported:

  • OS6870

Stellar APs

There were no new OmniAccess Stellar AP models introduced with this release.

Software

OmniVista Cirrus now supports the following OS Software Versions:

  • AOS 5.2R7 – OmniVista 2500 NMS now supports AOS 5.2R7 for the OS2260 and OS2360 Series Switches.
  • AOS 8.9R4 MR – OmniVista 2500 NMS now supports AOS 8.9R4 MR on all previously supported AOS Switches.
  • AOS 8.10R2 – OmniVista 2500 NMS now supports AOS 8.10R2 on all previously supported AOS Switches.
  • AWOS 5.0.2 – OmniVista 2500 NMS now supports AWOS 5.0.2 on all previously supported Stellar APs.

New Features

The following section details new applications introduced in this release.

OmniSwitch 6870 Support

The OmniSwitch 6870 (OS6870) is supported with this release. Consider the following guidelines for supporting this platform:

  • OmniVista does not support performing CPLD upgrades. To upgrade the CPLD version, refer to the AOS Release Notes for the CPLD procedure on ONIE-based switches.
  • The Application Visibility feature is currently not supported. It will be supported in an upcoming OmniVista release that supports AOS 8.10R3 or higher.

Application Updates/Enhancements

The following section details updates and enhancements to existing OmniVista Cirrus applications.

  • Password Enhancements for OmniVista User Logins
    • Enforce Strong Password Setting – New Password Expiry policy now configurable. You can specify the number of days during which a password remains valid. By default, Password Expiry is set to "Never". Changes to this setting apply immediately to new users, but do not affect existing users until they change their password on or after the current password expires.
  • Provisioning Encryption Strengthening – Support added for all Auth & Priv protocols when configuring SNMPv3 access in the default or custom Management Users Template.

MD5
SHA
MD5+DES
SHA+DES
SHA+AES

SHA+AES192
SHA+AES256
SHA+3DES
SHA224
SHA224+AES

SHA224+AES192
SHA224+AES256
SHA224+3DES
SHA256
SHA256+AES

SHA256+AES192
SHA256+AES256
SHA256+3DES
SHA384
SHA384+AES

  • 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.

  • UPAM Check for Message-Authenticator RADIUS Attribute – A new Request 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):
    • 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.

OmniVista Cirrus Framework Improvements

  • Ubuntu version upgrade from 20.04 to 22.04.
  • OpenSSL upgrade from 1.1.1f to 3.0.2 15
  • Docker upgrade from 23.0.4 to 27.4.1

Framework Enhancements

The following CVEs were fixed in this release:

  • CVE-2024-52046
  • CVE-2024-52316
  • CVE-2025-24813
  • CVE-2018-1270
  • CVE-2018-1275
  • CVE-2024-45337
  • CVE-2024-24790
  • CVE-2024-41110

Network and Device Prerequisites

The following prerequisites must be verified/configured before using OmniVista Cirrus.

Customer Network Prerequisites

The following Network Deployment, Bandwidth, Proxy, Firewall, and NTP Server configurations must be verified/configured on your local network before using OmniVista Cirrus.

Network Deployment

The following sections detail DHCP Network and Static Network deployment prerequisites.

DHCP Deployment Requirements

Standard Requirements

  • IP Address - DHCP Server IP address.
  • Option 1 - Subnet Mask.
  • Option 2 - Gateway.
  • Option 6 - Domain Name Servers - Required for FQDN resolution of OmniVista Cirrus connection points.
  • Option 28 - Broadcast Address. This option is only recommended, not required.
  • Option 42 - NTP Server(s) - Required for Certificate validation (start date and duration), and all related encryption functions. This option is not required on devices running AOS 6.7.2 R04 / AOS 8.5R2 / AWOS 3.0.4.1036 or higher. It is however, recommended.

ALE Specific Requirements

  • Option 43
    • Sub-Option 1 - Vendor ID. Validate the DHCP response (must be set with the value alenterprise). This sub-option is only required if you specify any of the sub-options listed below, or any devices on your network are running AOS 6.7.2 R03.

The following Sub-Options are only required if you are using a Proxy to connect to the Internet.

    • Sub-Option 129 - Proxy URL. It can be either an IP address or a URL (e.g., "IP-address=4.4.4.4", "URL=http://server.name").
    • Sub-Option 130 - Proxy Port.
    • Sub-Option 131 - Proxy User Name. If the customer proxy access requires authentication, both 131 and 132 can be supplied via these sub-options.
    • Sub-Option 132 - Proxy Password.
    • Sub-Option 133 - Network ID.
  • Option 138 - Remove any existing configuration (required for all ALE Devices).

Static Deployment Requirements

The following switch configuration prerequisites must be met for a Static Network Deployment.

1. Execute the following CLI commands on each switch. The commands can be contained in a CLI Script and pushed to network switches. See the CLI Scripting online help for more information.

ip name-server <dns_ip>
ip domain-lookup
ntp server <ntp_ip>
ntp client enable

2. (If you are using a Proxy), modify the <running directory>/cloudagent.cfg file on each switch as follows:

  • Activation Server URL: Enter the Activation Server FQDN.
  • HTTP Proxy Server: Enter the Proxy IP address.
  • HTTP Proxy Port: Enter the Proxy IP port.
  • HTTP Proxy User Name: Enter the Proxy username.
  • HTTP Proxy Password: Enter the Proxy password.

3. Enable the Cloud Agent on each switch with the following CLI Command:

cloud-agent admin-state enable

Bandwidth Requirements

Onboarding
For basic onboarding of devices and connection to the OmniVista Cirrus Server, a minimum of 10 kbps end-to-end network throughput is required between the device and OmniVista Cirrus.

Advanced Management
To enable statistics data transfer, status queries, configuration commands, and other requests/responses between devices and OmniVista Cirrus, a minimum of 2Mbps without latency end-to-end network throughput is required between the device and OmniVista Cirrus. APs must be running the latest AWOS software version.

Proxy Requirements

If a device is accessing the Internet via an HTTP/HTTPs proxy, the proxy server must be specified in DHCP Option 43, Sub-option 129 (Server) and Sub-Option 130 (Port). The server may be specified in 1 of 2 formats: 1) “URL=http://server.domain”, or 2) “IP-address=x.x.x.x”. The port is specified as a number (8080).

Firewall Requirements

The following ports must be configured to allow outbound traffic from your local network:

  • 443 - If you are not using a Proxy to connect to the Internet, your firewall must allow outbound access to this port; if you are using a Proxy, you need to be able to access this port via your local proxy. The following FQDNs should be allowed on this port:
    • images.myovcloud.com
    • images.prod.myovcloud.com
    • activation.prod.myovcloud.com
    • activation.myovcloud.com
    • registration.prod.ovcirrus.com
    • registration.ovcirrus.com
    • multi.prod.ovcirrus.com
    • multi.ovcirrus.com
    • {tenant-friendly-name}.ov.ovcirrus.com (e.g., acme.ov.ovcirrus.com)
    • {tenant-friendly-name}.upam.ovcirrus.com (e.g., acmeorg.upam.com)
    • {tenant-friendly-name}.vpn.ovcirrus.com (e.g., acmeorg.vpn.ovcirrus.com)
    • {tenant-ID}.tenant.vpn.myovcloud.com (please contact Alcatel-Lucent Enterprise Technical Support to obtain your tenant ID)
    • {tenant-ID}.tenant.ovd.myovcloud.com (please contact Alcatel-Lucent Enterprise Technical Support to obtain your tenant ID)
    • debug.prod.myovcloud.com
  • 80 - Relevant only if you are accessing UPAM Guest/BYOD Captive portal via insecure HTTP.  If you are not using a Proxy to connect to the Internet, your firewall must allow outbound access to this port; if you are using a proxy, you need to be able to access this port via your local proxy.
  • 123 - Relevant if you are using an NTP Server that is outside of your network. You must ensure that your firewall allows outbound access to port 123 UDP. This access cannot be mediated by a proxy, it must be direct (NAT is allowed). The following FQDNs should be allowed on this port:
    • clock1.ovcirrus.com
    • clock2.ovcirrus.com
    • clock0.ovcirrus.com
    • clock3.ovcirrus.com.
  • 53 - Relevant if you are using a DNS Server that is outside of your network. You must ensure that your firewall allows outbound access to both port 53 tcp and port 53 UDP. This access cannot be mediated by a proxy, it must be direct (NAT is allowed).

Deep Packet Inspection Requirements

OpenVPN is used to secure traffic from OmniVista Cirrus managed devices to the cloud on port 443.

NTP Server Requirements

An NTP Server(s) is required for Certificate validation (start date and duration), and all related encryption functions. Devices must have access to at least one NTP Server, whether local or external. Note that if a device's System Time is not correct, it may take several attempts to synchronize with the NTP Server before the device connects to the OmniVista Cirrus Server.

Device Prerequisites

The minimum device software versions for onboarding and management can be found here.

When licensed devices call home, OmniVista Cirrus checks the software versions the devices are running and, if necessary, triggers an update of the device to the software required to support OmniVista Cirrus 4.9.1. In addition, a software update for a device can be manually triggered from the device list.

Supported Devices

A full list of ALE supported devices/AOS releases can be found here.

Countries of Service and Hosting

A list of countries where Alcatel-Lucent complies with local regulations and hosts OmniVista Cirrus cloud-based service can be found here.

Scalability

The maximum number of devices supported per OmnniVista Cirrus single instance is 5000 devices in total ( up to 4000 Stellar APs). For single instances with a larger device deployment, consider the Managed Service Provider (MSP) dashboard for Multi-tenancy which offers deployment flexibility for very large organizations. Please contact your Alcatel-Lucent Enterprise representative for an overview of deployment solutions.

REST API Management

You can use REST APIs for scripting or integration with any third-party systems in your management network. Available OmniVista REST APIs can be found here https://ovc4x.ovcirrus.com/api

Issues/Workarounds

AP Registration

Cannot Re-Upload a New Upload Key File When Creating an 802.1X Certificate (OVE-12732)
Summary: When you re-load an “Upload Key File” with the same name as the existing key file, the “Import” button is disabled. Files with the same name cannot be uploaded again.
Workaround: Upload a file with a different name.

Application Visibility

The OAW-AP1511 and OAW-1521 Do Not Support Application Visibility
Summary: The Application Visibility (DPI) feature is not supported on the AP1511 and AP1521 in this release.
Workaround: N/A - Informational.

Device Catalog

OV Managed Device Automatically Deleted and License Unassigned (OVC-4683)
Summary: A currently managed device can be automatically deleted, its license unassigned, and the device moved to “Registered” if the IP address assignments of devices are changed.

For example, suppose there are two devices discovered and managed by OmniVista: Device1 with IP address "IP1", and Device2 with IP address "IP2". At some point, the IP Address assignment for these devices are changed as follows: Device1 IP address is changed from "IP1" to "IP2"; and Device2 IP address is changed from "IP2" to something else. This scenario could happen, for example, if the DHCP Server is restarted and does not attempt to give the same IP address as before to the DHCP clients.

If Device1 is then rediscovered (as part of periodic polling or by a manual user action), Device2 will be deleted from OmniVista when OmniVista discovers that Device1 now has the "IP2" IP address to avoid the situation where two devices have the same IP address in OmniVista.
Workaround: NA - Informational.

Upgrades Are Triggered Differently for 6x and 8x Switches (OVC-435)
Summary: The Activation Server checks the "current software version" from the switches to determine whether a switch should upgrade or not. Because of the different behaviors of 6x and 8x Switches, there may be some inconsistencies about when a switch will be triggered to upgrade.

  • AOS 8x switches send current software version of the current running directory.
  • AOS 6x switches send current software version of WORKING directory when in sync.

Example AOS 6x:
Assume switch comes up in the Certified Directory.
Assume /flash/working has the same image version as "desired software version" set in Device Catalog, whereas /flash/certified has a lower version. Since AOS 6x sends current software version of /flash/working, upgrade will NOT be triggered on the switch.

Example AOS 8x:
Assume switch comes up in the Certified Directory.
Assume /flash/cloud has the same image version as "desired software version" set in Device Catalog, whereas /flash/certified has a lower version. Since AOS 8x sends current software version of current running directory which is /flash/certified. there will be an upgrade. The switch will download the desired software version to /flash/cloud and reboots from /flash/cloud.

Workaround: NA - Informational.

Auto-Upgrade for Switches Running Lower Than AOS 6.7.2.R7 (OVC-8103)
Summary: Switches running an AOS version lower than 6.7.2.R7 will be automatically upgraded to AOS 6.7.2.R7 even if you select the "Do Not Upgrade" option when adding the device to the Device Catalog.
Workaround: N/A - Informational.

Provisioning Fails for 8.10R1 Default Factory Switch (OVC-9884)
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.

Inventory

Upgrade Workflow Should Be Changed When Device Is Loaded From Certified Directory (OVC-435)
Summary: When an AOS 6.x Switch with "Set to Software Version" set to "Latest Version" contacts the OmniVista Server, the server checks the Working Directory to see if it is running the latest AOS software. If the Working Directory contains the latest software version, an upgrade will not be triggered, even if the Certified Directory is running on an older software version. To upgrade the Certified Directory to the latest software, reboot the switch from the Working Directory.
Workaround: NA - Informational.

OmniVista does not Indicate Failure Reason when NaaS Device is in Degraded Mode (OVE-11475)
Summary: OmniVista does not indicate the reason for a failure when a configuration or software upgrade through Managed Devices fails because the NaaS license has expired on the device.
Workaround: No workaround at this time.

mDNS

mDNS Server and Client Policy: UI Offers Policy Lists in "Access Role Profile" Drop-Down (OVE-10559)
Summary: When creating or editing an mDNS Server or Client Policy, the Access Role Profile drop-down is populated with Unified Policy Lists, not Access Role Profiles.
Workaround: Do not use the drop-down list suggestions. Manually enter the Access Role Profile Name in the field and click on the Add icon (+) to configure an Access Role Profile for the policy.

Unified Access

Switch Client Passes MAC Authentication Then Fails, but the Client is Assigned to the ARP from the Successful Authentication (OVE-13317)
Summary: If a client connected to a switch successfully authenticates but later fails authentication, the switch retains the Access Role Profile (ARP) from the successful authentication and continues to assign that ARP to the client. Note that switch clients that have never successfully authenticated receive the correct ARP after failed MAC authentication. This issue is resolved in AWOS 5.0.1 and later, so clients connected to APs running AWOS 5.0.1 or above are not affected.
Workaround: No workaround for switches. For APs, upgrade AWOS to 5.0.1.

Unified Policy Switch Picker Does Not Display All VC Devices (OVC-9896)
Summary: If you remove a switch from a Virtual Chassis (VC) configuration to operate as a standalone unit, the switch still maintains the same VC ID. The Unified Policy Switch Picker then sees more than one switch with the same ID and will not display all the switches with duplicate IDs for selection.  

  • When a VC is created, the vcpolicy.cfg file is duplicated across all the members of the VC. This file contains the LDAP ID, which is used to identify the VC switches as a single system. When you add a switch to the VC, the vcpolicy.cfg ID on the new switch is overwritten to match the vcpolicy.cfg ID of the VC.
  • If you remove a switch from the VC, it still has the same vcpolicy.cfg file containing the VC LDAP ID. As a result, the switch continues to operate in VC mode.
  • QoS has no way of knowing if removing a switch from the VC was user-intended or if it was just a temporary issue with the VC. The ID is not regenerated because if it was a temporary VC split, there’s no way to know which ID is the original VC LDAP ID.  
  • Removing a switch from a VC configuration results in switches with the same VC LDAP ID that do not belong to the same VC configuration. This causes confusion when determining which switches to include in the Unified Policy Switch Picker, thus not all the switches are displayed.

Workaround: Delete the “/flash/network/vcpolicy.cfg” file from the standalone switch and reboot the switch to generate a new switch ID.

UPAM

HTTPs Traffic is Not redirected to Portal Page for an HSTS Website (OVC-1777)
Summary: The first time a user opens an HSTS website, they are redirected to the portal page, as expected. The second time a user opens an HSTS website, the redirection will not work. If the user clears browser cache and retries connecting to the HSTS website, it will work. The behavior depends on the browser used. Chrome is very strict, so the problem is always seen, Firefox is not as strict; the problem will still happen but not as frequently.
Workaround: There is no workaround at this time.

Delay in UPAM Interactions After Subscriber Gets a Paid Account (OVC-6806)
Summary: After a subscriber gets a paid account, UPAM related interactions will not work until free radius server is restarted (at 00:00 AM the subsequent day).
Workaround: There will be a delay in realizing any expected changes in UPAM function when any of the following occurs:

  • Creation of a new tenant
  • Activation of a different RADIUS Server Certificate
  • Synchronization of RADIUS Attribute Dictionary at OmniVista with RADIUS Server
  • Edit of NAS Client details.

After any of the above actions, expected UPAM changes will take effect after the following midnight (00:01 a.m. PST), as these require a restart of the OmniVista internal RADIUS Server. The OmniVista internal RADIUS Server is restarted periodically at midnight PST. All tenants sharing the same OmniVista VM will experience a brief period of interruption of UPAM RADIUS functionality during this periodic restart.

WiFi4EU not Connected to Captive Portal (OVE-11164)
Summary: The validity period for Captive Portal authentication defaults to 30 days, but WiFi4EU requirement is maximum 24 hours.
Workaround: There is no workaround.

The UI Does Not Offer a TLS Port Field When TLS is Enabled for RADIUS Server (OVE-12747)
Summary: When creating a TLS-enabled Radius server, the Create RADIUS Server screen (Security – Authentication Servers – Radius) does not offer a field to specify the TLS Port value.
Workaround; Specify the TLS Port value in the “Authentication Port” field, which is 2083 by default.

Web Content Filtering

If an AP Client is using a Mobile Application, WCF does not Work (OVE-10205)
Summary: When client access uses a mobile application (e.g., Facebook, Twitter, YouTube, etc.), there are no restrictions; the application is not blocked and will load properly, as if WCF is disabled on the AP.
Workaround: No workaround at this time.

WCF Limitation when a Client Accesses the Internet through an HTTP/HTTPS Proxy (OVE-11466)
Summary: When a client is behind a proxy, the client doesn’t request the AP to resolve the DNS query but directly requests the proxy server. As a result, the AP does not get the opportunity to perform the WCF function, so the accept/reject of a website does not work as configured/expected by the user on OmniVista.
Workaround: No workaround at this time.

WLAN

RF Profile Not Supported on AP1201BG (OVE-10781)
Summary: Stellar OAW-AP1201BG does not support RF profiles, as it is a BLE gateway.
Workaround: No workaround at this time.

Other

If You Remove a Master from a Virtual Chassis Slave Devices Lose Connectivity
Summary: If You Remove a Master from a Virtual Chassis (VC), Slave devices Lose Connectivity Due to stale certificates. Devices use a certificate to communicate with OmniVista Cirrus. This certificate is given to the devices by the OmniVista Cirrus on their first Activation attempt. In a VC, the Master chassis is issued a certificate for its Serial Number and this certificate is copied over to all the Slaves. If the owner of the certificate (Master) is removed permanently from the VC, the remaining chassis will form a VC and attempt activation using the certificate of the old Master but will be unable to activate using this certificate. Customers should raise a ticket with ALE Customer Support to overcome this issue. After understanding the VC topology, ALE Customer Support might take a decision to remove the certificate from the VC and enable the remaining chassis in the VC to attempt Cloud Activation afresh.
Workaround: Raise a ticket with ALE Customer Support. After investigating the VC topology, ALE Customer Support may decide to remove the certificate from the VC and enable the remaining chassis in the VC to re-attempt activation.

The AOS 8.9R4 U-Boot Accepts Signed Images Only for OS6750M (OVE-13356)
Summary: If the U-Boot and AOS version is 8.9R4 or above and you downgrade the AOS version to 8.9R3 and reboot the switch, the switch cannot reboot. The 8.9R4 U-Boot only accepts signed images.

  • OS6570M has a signed image; there is no unsigned image. All other switches have unsigned images.
  • If the OS6570M running with the 8.9R4 U-Boot version is upgraded to AOS 8.9R4 or 8.10R1 (these versions offer signed images only for the OS6570M), then you cannot downgrade the switch to AOS 8.9R3 or below.
  • If the OS6570M runs with an older U-Boot (that does not enforce signature validation), then you can upgrade the AOS version to 8.9R4 or 8.10R1 and downgrade to 8.9R3 or below without any limitations.

Workaround: Informational.

Cannot upgrade U-Boot with File Name "u-boot.5.2R03.3.tar.gz" (OVE-13346)
Summary: If the U-Boot file name is “u-boot.5.2R03.3.tar.gz”, the upgrade will fail.
Workaround: Rename the U-Boot file to “u-boot.5.2.R03.3.tar.gz”.

OmniSwitch 9912 and 9907 U-Boot Upgrade Fails (OVE-13040, OVE-13032)
Summary: Upgrading the OmniSwitch 9912 and OmniSwitch 9907 U-Boot from OmniVista does not work.
Workaround: Informational. When performing a U-Boot upgrade on OS9907 and OS9912 switches, there are two U-Boot files involved: one regular and one Denverton. If the switch contains different types of NI modules, you need to perform the U-Boot upgrade twice with each of the applicable U-Boot files:

  • The CMM2 and CNI-U20 modules have Denverton CPUs, so the Denverton coreboot Zip file is used (coreboot-uboot.denverton).
  • The CMM1 and all the rest of the NI models have Rangeley CPUs, so the non-Denverton coreboot Zip file is used (coreboot-uboot).

The upgrade is successful on the NI modules for which the U-Boot Zip file is applicable.

Enforce Strong Password Enabled After Upgrade (OVE-13859)
Summary: If you disable the Enforce Strong Password setting in OmniVista 4.9R1, then upgrade to release 4.9R2, the following occurs when you access the Enforce Strong Password screen (Home > Administration > Preferences > System Settings > Enforce Strong Password):

  • The Enforce Strong Password setting is automatically enabled.
  • OmniVista logs you out and requires you to change your password.

Workaround: Change the password and log in again with the new password.

Issues Fixed

Issues Fixed Since Release 4.9.2

Issues Fixed Since Release 4.8.2

  • Management IP of a Device Is Not Updated in OmniVista Cirrus When the Management IP Is Changed on the Device (OVC-9737)
  • Statistics Collection May Stop if SNMP Credentials are Changed (OVE-13114)
  • The Days Left for Expiry is Incorrect for an AP NaaS License (OVC-9151)
  • Device Does Not Display When Editing a Scheduler Job (OVC-9798)

Issues Fixed Since Release 4.8.1

  • Roaming and RSSI history of the client device displayed for only 24 hours (OVC-9754)
  • SNMPv3 Username/Password Must Not Contain Certain Special Characters (OVE-12152)
  • The 6GHz SSID Interface Will Not Function if PMF State Is Not Set to “Required” (OVE-12727)
  • After Editing an SSID With PPSK Entries, Access Guardian Service Does Not Respond to Any Requests Until Restarted Manually (OVE-12818)
  • Network Analytics Statistics Port-Based Statistics Counters are Fixed (OVE-13109).
  • Syslog Over TLS Certificate Name Must Not Contain a Space (OVE-12702)
  • OmniVista ClearPass Integration Fails When Adding APs to AP Group (OVE-12378)

Issues Fixed Since Release 4.7.1

  • CSA Limitation on 6GHz (OVC-9306)
  • User should not set AP to RAP twice in GOV (OVC-9627)

Issues Fixed Since Release 4.6.2

  • "Export VPN Settings" with Shorthand Mask Option does not Show the List Peer IP Address (OVE-11444)
  • Editing an AP Group to Add a New Profile Resets the Timezone to the UTC-8 Default Value (OVE-11531)
  • Cannot Work Simultaneously on Two SSH Tabs Opened Inside CLI Scripting (OVC-9022)
  • OVC Tenant cannot load any data, error “communication failure with OV Cirrus” displayed on the Dashboard. Reason was ActiveMQ Service was reaching the memory limit (OVC-9072)
  • OVC Default Radius server was not created because of scheduler service got stuck (OVC-9002)
  • OVC SSH Incompatibility with Stellar AP when doing SSH Terminal. Removal of weak SSH algorithms (OVC-9230)
  • The OmniVista Topology Map does not Display the LLDP Link Between an AOS 8.8R1 OmniSwitch and an AWOS 4.0.4 AP (CRAOS8X-31942)
  • The alaNaasLicenseInstalledAlert Trap Shows the Wrong Value (OVE-11374)
  • The NaaS VC Device Sends the alaNaasInconsistentModeAlert Trap Multiple Times (OVE-11414)
  • The NaaS License Expiry Time is Reported in the Number of Whole Days Remaining until the License Expires (OVE-11415)
  • Can't Display Running Directory Information for NaaS Device in Degraded Mode (OVE-11416)
  • Stellar AP Connectivity to OS22x60 does not Work (OVE-11467)

Issues Fixed Since Release 4.6.1

  • IoT Exception List Does Not Work for iOS Devices (OVC-7843)
  • Unable to find the RAP in the OV2500 (OVC-8302)
  • Trap Configuration Fails when the Switch Name Contains the “#” Character (OVE-10558)
  • HTTPS Captive Portal Redirection with Proxy Reduces Performance (OVE-11482)
  • Deleting a Responder Device Fails (OVC-8876)
  • Social Login Fail with Google Account (OVC-8901)

Issues Fixed Since Release 4.5.3

  • MTS-Managed Tenant Local Users Cannot Use "View SSIDs on an AP Group" Feature (OVC-6321)
  • Cannot Onboard a Switch Running AOS 6.7.2.R05 (OVC-6879)
  • Device Address Column Sorted Incorrectly in Device Backup/Restore Table (OVE-1861)
  • Cannot Download Radius Server Certificates (OVC-8405)
  • Must Wait 1 Day Before Using Web Content Filtering (WCF) Feature (OVC-8508)
  • User Is Not Notified When User Role Is Configured for Two-Factor Authentication (OVC-8540)
  • Client Blacklisting Does Not Work on AP1320/AP1360 (OVE-9544)
  • mDNS Server and Client Policy: UI Offers Policy Lists in "Access Role Profile" Drop-Down (OVE-10559)
  • Unified Policies Are Lost on Certain Switches After Reboot (CRAOS8X-26272)
  • Client Name Field Blank for Clients Running iOS 14 (OVC-8287)

Issues Fixed Since Release 4.5.2

  • APs Are Displayed as IOT Devices in IoT Inventory (OVE-5542)

Issues Fixed Since Release 4.5.1

  • ALE-BYOD Users and ALE-Corp Users Disassociated from SSIDs (OVE-6759)
  • Delete Map Cannot Complete in Topology (OVC-7412)
  • Problem Connecting to Switch with OV Assistant When Multiple Bluetooth Dongles Present (OVC-7240)

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 Home Page. An overview of OV Cirrus as well as Getting Started Guides for Freemium and Paid Accounts is available here.

 

Help

About Getting Started Customer Support

Info

Community Twitter Legal

Brought to you by

v1.2