Home Getting Started Status Community Help
Alcatel-Lucent OmniVista Cirrus

Network Management as a Service

Home
/
Production Notes
/
OmniVista Cirrus Production Notes 4.5.3
OmniVista Cirrus Production Notes 4.5.3

OmniVista Cirrus Production Notes 4.5.3

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

OmniVista Cirrus now supports the following devices:

  • AOS Devices
    • OS6360 Series Switches - The new OS6360 Series Switch is now available. OS6360-10, OS6360-P10, OS6360-24, OS6360-P24, OS6360-PH24, OS6360-P24X, OS6360-P48X, OS6360-48, and OS6360-P48, Switches are now supported in all OmniVista applications, except for Application Visibility.
    • New OS6900 Switch Models - OS6900-V48C8 and OS6900-X48C4E Switches are now supported in all OmniVista applications.
  • APs
    • OAW-AP1301 - OAW-AP1301 is now supported in OmniVista.
    • OAW-AP1311 - OAW-AP1311 is now supported in OmniVista.

Software

OmniVista Cirrus now supports the following OS Software Versions:

  • AWOS 4.0.2 - OmniVista Cirrus now supports AWOS 4.0.2 on all supported APs.
  • AOS 8.7R2 - OmniVista 2500 NMS now supports AOS 8.7R2 on all previously supported AOS Switches, as well as the new OS6360 Series Switches. Application Visibility is now supported on OS6860N Switches running AOS 8.7R2 using a 6860N Signature Kit.

Application Updates/Enhancements

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

Analytics

  • Filter Analytics Reports by Profile
    • You can now filter and display Top N Ports, Top N Poe Ports, and Top N PoE Switches. Reports by Analytics Profiles. A user can set up different profiles for groups of switches and use the Profile Filter option of the Report Screen to display specific switches based on Profile.

AP Registration

  • Group Description Column Added to the Access Points List
    • A Group Description column had been added to the Access Points List. The column contains the optional AP Group Description configured by the user for the AP Group.

Authentication Servers

  • Longer RADIUS Server Password Supported
    • The RADIUS Server Shared Secret can now contain up to 64 characters.

License

  • Manual Polling for Immediate Subscription Update
    • A Check For Updates To Subscription button has been added to the top of the License Home Screen that the user can click on to immediately activate any subscription updates.

mDNS

  • Access Role Profile Condition for mDNS Client and Server Policies
    • You can now include an Access Role Profile Condition in mDNS Client Policies and mDNS Server Policies.

Notifications

  • Acknowledge/Clear All Traps
    • You can now acknowledge or clear all traps in the Notifications Table in a single step. Click on the new Actions button at the top of the Notifications Home Screen and select Ack All or Clear All. The Poll button to poll devices for traps, is now under the new Actions button.
  • Option to Ignore Stellar AP “Unsaved Changes” Traps
    • There is a new option under the Unsaved Device Notifications icon (Bell) at the top of the OmniVista UI. Unsaved changes on Stellar APs are generally not a problem since Stellar APs receive the latest configuration at reboot. To prevent notifications for unsaved changes on Stellar APs, click on the Bell icon, then click on Settings. Uncheck the "Unsaved Changes Notification for Stellar Access Points" checkbox, and click OK.

Preferences

  • Create Alarm Sounds for UI Inactivity and Notifications Traps
    • You can now set audible alarm sounds for UI Inactivity and Notifications Traps. For Notifications, you can set the same sound for all traps or set different sounds for different Severity Levels. The sounds are configured on the Preferences “ Sounds Screen (Administration “ Preferences “ User Settings “ Sounds).

Unified Access

  • Map Access Role Profiles to Dynamic VLANs
    • On 6.x Switches (running 6.7R08 and higher) and 8.x Switches (running 8.6R1 and higher) you can map an Access Role Profile to a dynamically-created VLAN. On 6.x Switches, you can map an Access Role Profile to a VLAN learned by a dynamic protocol (e.g., MVRP). On 8.x Switches you can map an Access Role Profile to any VLAN even if the VLAN does not yet exist on the switch. The switch will create a UNP Dynamic VLAN. In both cases, the switch will decide whether it will permit the mapping.
    • For dynamic VLAN mapping, you must first configure a Unified Access Global Configuration Setting with Global Dynamic UNP VLAN creation enabled, and assign that Global Configuration to network switches.
  • Assign an Access Auth Profile to an AP Downlink Port
    • You can now assign an Access Auth Profile to a Downlink Port on AP1201H, AP1201HL, and AP1311 Devices. When you assign the profile to an AP Group, you have the option of selecting up to three Downlink Ports. OmniVista will apply the profile to the selected port(s) on supported APs/ports in the AP Group. OmniVista will ignore unsupported APs/ports in the AP Group.
  • Map a UNP VLAN to UNP Port When Assigning an Access Authentication Profile
    • When assigning an Access Authentication Profile, you can map a UNP VLAN to a UNP Port. This configures a Tagged or Untagged VLAN Port Association between the specified UNP Bridge Port and the VLAN This feature is useful when connecting “Silent" devices (e.g., printers) to Bridge Ports. The feature is supported on 6.x Switches (running AOS 6.7.2.R07 and higher) and 8.x Switches (running AOS 8.6R1 and higher).
  • Bypass VLAN Feature for AP1201H and 1201HL APs
    • A Bypass VLAN attribute in now available when configuring Access Auth Profiles. The Bypass VLAN attribute is supported on Stellar AP1201H and AP1201HL Devices. The feature improves wired port forwarding performance by skipping the CPU process. When a Bypass VLAN is configured, traffic from the AP uplink port to the downlink port, or vice versa, is forwarded directly through the switch chipset without CPU intervention.
    • The Bypass VLAN has higher priority than Trust Tag. When a VLAN is configured as the Bypass VLAN and Trust Tag at the same time, the Bypass VLAN function is effective on that VLAN, while Trust Tag is not. Note that when Bypass VLAN is configured, Authentication/ACL/Policy etc. features cannot be applied to the traffic in the Bypass VLAN.
    • This attribute is supported on AP1201H and AP1201HL Devices. When an Access Auth Profile is applied to an AP Group, OmniVista will pass the Bypass VLAN attribute to all APs in the AP Group. 1201H and 1201HL APs will accept it, other APs in the group will silently ignore this attribute. Bypass VLAN is recommended for the use case of HD IPTV.

UPAM

  • New Web Content Filtering Feature
    • A new Web Content Filtering (WCF) Feature has been added to the UPAM application (UPAM – Web Content Filtering). WCF Profiles can be configured to allow/deny client access through Stellar APs to web sites based on specific security or content conditions (e.g., Malware Sites, Gambling). A single WCF profile can contain multiple filtering conditions. To configure Web Content Filtering on an AP, you create a WCF Profile, configure an Access Role Profile or SSID with the WCF Profile, and then apply the Access Role Profile or SSID to APs.
    • When a client tries to access a restricted website, the page will fail to load, and the browser will display an error. In a future release, if a client attempts to access a restricted site, OmniVista will redirect the client to a specific block page.
    • Web Content Filtering is supported on APs running AWOS 4.0.2 (except AP1101, AP1201H, AP1201L, and AP1201HL models).  
    • You must have a Web Content Filtering License installed to use this feature. Licenses are purchased for a set number of APs.
  • Configure Automatic Deletion of Expired UPAM Guest Accounts
    • You can now configure automatic deletion of UPAM Guest Accounts once their validity period expires. The “Guest Account Deletion Policy” field on the UPAM Global Configuration page (UPAM “ Guest Access “ Global Configuration) enables you to configure how long expired Guest Accounts are retained before they are automatically deleted. The following retention options are available: never accounts, delete accounts as soon as they expire, delete accounts after a certain number of days (1 “ 90).
  • Configure Guest Access Batch Account Access Code Length
    • You can now configure the Access Code Length for Guest Accounts when creating accounts using the Batch Account Creation Feature. The Access Code Length is configured on the UPAM Guest Account page (UPAM – Guest Access – Guest Account). The Access Code Length can be between 6 and 16.
  • Set the Validity Period Start Time for Guest Accounts
    • You can now configure a Guest Account Validity Period to start the first time a user logs in. This is set in the “Effective at First Login” field on the UPAM Guest Account page (UPAM “ Guest Access “ Guest Account).
  • EAP Option Available for UPAM Access Policy Configuration
    • A new EAP option is now available when configuring a UPAM Access Policy that enables the user to restrict authentication to specific EAP Protocols (EAP-PEAP, EAP-TLS). The option is available under the Advanced Attributes Mapping Conditions (Attribute = Service-Type, Value = Framed User). 
  • Guest Access User Password Reset Option
    • A “Reset Password” option is now available when configuring a Guest Access Strategy. If this option is enabled, a Guest User can change their login password without Administrator operation by receiving a Verification Code through e-mail or SMS. The user will be able to click on the "Forget Password?" link on the login screen for their account to request a Verification Code to change their password.

Users and User Groups

  • Two-Factor Authentication
    • You can now configure Two-Factor Authentication for user login based on User Role (Security " Users and User Groups “ Two Factor Authentication). Two-Factor Authentication requires a user to enter an authentication code after entering their login/password to access OmniVista Cirrus. The authentication code is a time-based, 6-digit code generated using the Google Authenticator App, a free App that the user downloads to their Smartphone. When Two-Factor Authentication is enabled/disabled, the configuration is applied to all users who are members of a User Group with a User Role configured for Two-Factor Authentication.

OmniVista Cirrus Framework Improvements

  • Improved Performance and Redundancy
    • OmniVista Cirrus is now more fault tolerant and offers better performance due to redundancy and load balancing on key components.
  • New Analytics AP Uptime/Downtime Report Display Options
    • The Analytics AP Uptime/Downtime Report now has the option to filter the display data by device or map; as well as displaying data by time range or displaying the most recent data.
  • Search Bar Added to Configuration Fields in UI
    • A Search Bar has been added to configuration fields throughout the UI to assist the user in locating information from drop-down menus during configuration.
  • IoT Device Classification Improvements
    • The IoT device classification process between the cloud-based Device Fingerprinting Service and OmniVista has been streamlined, speeding up the IoT device classification process.
  • Faster Loading of Application Visibility Screens
    • The Application Visibility Signature Profile Screen now loads more quickly regardless of the number of Signature Profiles.
  • VLAN Polling Improvements
    • VLAN Polling has been streamlined for faster updates of VLAN information.

Remote Access Points

  • Increased Scalability
    • OmniVista can now support up to 1,000 Remote Access Points. Required CPU and Memory configurations are detailed in the OmniVista 4.5R3 Remote Access Point and VPN VA Installation Guide.
  • Assign an Access Auth Profile to an AP Downlink Port
    • As described above, you can now assign an Access Auth Profile to an AP Downlink port on AP1201H, AP1201HL, and AP1311 Devices.
  • Tagged VLAN Traffic and VLAN Pool Supported
    • Remote Access Points now supports Tagged VLAN traffic via GRE Tunnel, as well as VLAN Pool.

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 64 kbps 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=8.8.8.8”. 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.
  • 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).
  • 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).

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 are detailed below. The minimum onboarding versions are required for the device to connect the to the OmniVista Cirrus Server. The specified management software versions are required to support all of the management features available in OmniVista Cirrus 4.5.3.

Onboarding

For onboarding (call home and connection to the OmniVista Cirrus Server), devices must be running the following minimum software versions:

  • AOS 6.7.2.R05
  • AOS 8.5R2
  • AWOS 3.0.5.xx.

Management

Devices must be running the software versions specified below to support all of the management features available in OmniVista Cirrus 4.5.3.

  • Essential Switch (E) - OS6350/OS6450 - (6.7.2.R08), OS6360 (8.7R2), OS6465 (8.7R2), OS6560 (8.7R2)
  • Core Switch (C) - OS6900 (8.7R2)  
  • Advanced Switch (A) - OS6860/OS6860E/OS6865 (8.6R1), OS6860N (8.7R2)
  • Stellar AP (SA) - OAW-AP1101, OAW-1201, OAW-1201H, OAW-1201L (available in Brazil only), OAW-AP1221, OAW-AP1222, OAW-AP1231, OAW-AP1232, OAW-AP1251, OAW-AP1201BG, OAW-AP1321, OAW-AP1322, OAW-AP1361, OAW-AP1362 (AWOS 4.0.2)

A link to the latest software images is included in the Verification E-Mail you receive when you create your account. If necessary, click on the link and download the required AOS software. Release Notes, containing detailed upgrade instructions for each device type, are available on the ALE Business Portal.

Supported Devices

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

REST API Management

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

Issues/Workarounds

Application Visibility

AV No Longer Supports OS6900 Switches (OVC-4434)
Summary: Application Visibility no longer supports OS6900 Switches. Any Application Visibility Policies or Policy Lists applied to these devices should be updated/deleted.
Workaround: NA - Informational.

Unified Policies Are Lost on Certain Switches After Reboot (CRAOS8X-26272)
Summary: If a Unified Policy List is applied to the following AOS Switches, the policies will be lost when the switch is rebooted: OS9900, OS6560, OS6465, OS6900, OS6860N, OS6360. This issue is only observed when a policy is pushed from OmniVista. If policy is applied by CLI commands there is no issue. The problem is not seen on OS6900 or OS6860 Switches.
Workaround: After switch reboot, reapply the policies from OmniVista. The problem is fixed in AOS 8.7R02. Upgrade switch to AOS 8.7R02.

Configuration Manager

Device Address Column Sorted Incorrectly in Device Backup/Restore Table (OVE-1861)
Summary: If you sort the Device Address Column in the Backup/Restore Table in ascending or descending order, the IP addresses are not sorted correctly. For example, a list of IP addresses will be incorrectly sorted as 10.1.3.1, 10.1.2.1, 10.1.11.1.
Workaround: No workaround at this time.

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.

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.

IoT

IoT Inventory Does Not Work if sFlow is Enabled on Switch (OVE-5544)
Summary: Devices are not displayed in the Inventory List if sFlow is enabled on a switch.
Workaround: The problem is fixed in AOS 8.6R2. Upgrade switch to AOS 8.6R2.

Device Start Time Is Incorrect in IoT Inventory List (OVE-5658)
Summary: If a device is moved to a different port on a switch, the Start Time displayed in the Inventory List will reflect the first time the device was connected to the switch.
Workaround: The problem is fixed in AOS 8.6R2. Upgrade switch to AOS 8.6R2.

IoT Inventory List Displays Active/Online Endpoints as Offline (OVC-6788)
Summary: The IoT Inventory List displays multiple Active/Online endpoints as offline for devices connected to switches running AOS 8.6R1.
Workaround: The problem is fixed in AOS 8.6R2. Upgrade switch to AOS 8.6R2.

IoT Client Continuously Re-Connects After Category Enforcement (OVE-7648)
Summary: If a client is authenticated over a RADIUS Server and classified into a UNP Profile, and then another UNP Profile is applied via IoT Category Enforcement (same or different profile), the client will continuously re-connect.
Workaround: No workaround at this time. The problem will be fixed AOS 8.7R1. Upgrade switch to AOS 8.7R1.

IoT Exception List Does Not Work for iOS Devices (OVC-7843)
Summary: An Exception List configuration that should be applied to iOS Devices fails if the Access Role Profile configured for Enforcement is changed. These devices continue to follow the IoT Enforcement configured for their category.
Workaround: No workaround at this time. This will be fixed in the next OmniVista Cirrus release.

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.

Provisioning

Cannot Onboard a Switch Running AOS 6.7.2.R05 (OVC-6879)
Summary: You cannot successfully onboard a 6.x switch in the Provisioning application that is running a AOS 6.7.2.R05.
Workaround: For 6.x Switches, Provisioning is only supported on AOS 6.7.2.R06 and higher. Upgrade the 6.x Switch to a supported build.

Remote Access Points

Unable to find the RAP in the OV2500 (OVC-8302)
Summary: RAP was not displayed in OmniVista when the Dual Stack Lite technology was used for Internet access in RAP/VPN VA configuration.
Workaround: Dual stack configuration is not supported in Remote Access Point/VPN VA deployment.

SSID

MTS-Managed Tenant Local Users Cannot Use "View SSIDs on an AP Group" Feature (OVC-6321)
Summary: When managed by MTS, local Tenant Users cannot use the "View SSIDs on an AP Group" button to quickly view SSIDs by AP Group.
Workaround: Users who want to view SSIDs associated with a specific AP Group need to go to each SSID and view its AP Group association. Click on the AP Group Assignment and Schedule button at the top of the SSIDs screen to bring up the “AP Group Assignment and Schedule” Screen. Select an SSID from the SSID Service Name drop-down. The AP Group(s) associated with the SSID are displayed.

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.

No IPv4 or IPv6 Value Displayed in UPAM Authentication Record (OVC-6061)
Summary: Client IP address is not displayed in UPAM Authentication Record.
Workaround: 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.

Cannot Download Radius Server Certificates (OVC-8405)
Summary: Unable to download RADIUS Server Certificates on the UPAM RADIUS Server Certificates Screen. When you select a Certificate in the RADIUS Server Certificates List and click on Download button, there is no response from OmniVista Cirrus.
Workaround: No workaround at this time.

Must Wait 1 Day Before Using Web Content Filtering (WCF) Feature (OVC-8508)
Summary: OmniVista Cirrus automatically syncs with the Web Content Filtering Service every 24 hours. The WCF feature was introduced in Release 4.5.3. If this is a new OmniVista Cirrus Account, it may take up to 24 hours before the feature is available for the user.
Workaround: Go to the License Screen and click on the Check For Updates To Subscription button at the top of the screen perform an immediate sync. If this is an existing OmniVista Cirrus Account that was upgraded to 4.5.3, this step is not necessary. You can begin using the feature immediately.

Users and User Groups

User Is Not Notified When User Role Is Configured for Two-Factor Authentication (OVC-8540)
Summary: Any time Two-Factor Authentication is enabled/disabled for a current Two-Factor Authentication user, an automatic e-mail is sent to the user informing them of the change. However, if a new user is created with Two-Factor Authentication enabled for their assigned User Role, or Two-Factor Authentication is enabled for a current user's User Role, the user is not notified. This may cause confusion for the user when they attempt to log into OmniVista Cirrus and see the Two-Factor Authentication Login Page for the first time.
Workaround: Administratively disable/enable Two-Factor Authentication at the Role level after creating a user or modifying a user. An e-mail will be sent. This will be addressed in the next OmniVista Cirrus release (OVC 4.6.1).

Web Content Filtering

End User Should be Notified When a Page Is Blocked by WCF (OVE-10205)
Summary: When a client tries to access a website restricted by Web Content Filtering (WCF), the page will fail to load, and the browser will display an error. However, the error message is a generic connection error message. It does not explain why the page failed to load (e.g., “Access to this Website is restricted”).
Workaround: Connect to a known unrestricted site to verify the reason the connection failed. In a future release, if a client attempts to access a restricted site, OmniVista will redirect the client to a specific block page.

WLAN

Client Blacklisting Does Not Work on AP1320/AP1360 (OVE-9544)
Summary: The “Add to Blacklist” function from WLAN - Client List in OmniVista does not work with clients connected to Stellar OAW-AP1320/AP1360 APs. The client is moved to the Blacklist on the OmniVista GUI, but remains connected to the network on the AP1320/AP1360.
Workaround: No workaround at this time.

Client Name Field Blank for Clients Running iOS 14 (OVC-8287)
Summary: The Client Name field in the “List of All Client on All APs” is not displayed for devices running iOS 14.
Workaround: No workaround at this time. The problem occurs on devices running iOS 14 as they do not send Option 12 in the DHCP message.

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.

Problem Connecting to Switch with OV Assistant When Multiple Bluetooth Dongles Present (OVC-7240)
Summary: The OmniVista Assistant uses the Bluetooth dongle MAC address to initiate a connection to a switch. If multiple Bluetooth dongles are active at the same time, OmniVista Assistant may initiate a connection to an unexpected dongle.
Workaround: Make sure there are no other active Bluetooth dongles in the area. And make sure the correct model and serial number appear under "Paired Devices" before initiating a connection to a switch.

Issues Fixed

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)

Issues Fixed Since Release 3.0

  • If Network ID Strict Mode Is Enabled Some Devices Will Be Unable to On-Board (OVC-4381)
  • Cannot Notify Policy List with Accept All | Deny All Policy on AOS 6x Devices (OVC-6133)
  • Unable to upload Captive Portal Certificate on UPAM (ALEISSUE-410)
  • Unable to change “Account Validity Period” While Creating Guest Access Code with Service Level (ALEISSUE-459)
  • APs were UP, however showed DOWN in OmniVista (ALEISSUE-383)

Issues Fixed Since Release 2.1.0

  • External LDAP Server Requires Direct Connection (OVCLOUD-2832)
  • BYOD Access Strategy "Go to initial URL" Option Does Not Work on AOS 6x Switches (OVC-421)
  • No CLI Command to Configure Network ID in Statically Configured Cloud Agents (OVC-4569)

Issues Fixed Since Release 2.0

  • Cannot Remove a BYOD/Guest Online Device From Device List on AOS 8x Switches (OVC-419)
  • Cannot Find Audit Logs in OmniVista Cirrus (OVC-456)
  • Error When Applying Access Role Profile with Policy List to 6x Device (OVC-459)
  • Cannot Apply Policy List from RADIUS Attribute "Alcatel-Policy-List" in UPAM on AOS 6.x Switches (OVC-463)
  • Captive Portal Page Is Not Kept After Upgrading From 1.0.2 (OVC-2467)
  • AP Image Upgrade From 3.0.2 to 3.0.4 Requires 2 Reboots (OVC-2957)
  • Device Status Color Does Not Change When a Trap is Sent From an AP (OVC-3220)
  • Minimum OS Versions Required for Full OmniVista Cirrus Functionality (OVC-3468)
  • OS6560 Device Loses VPN Connectivity and Remains in a DOWN State (OVC-3530)
  • Guidance for Users with ALE Business Store Based OmniVista Cirrus Subscriptions That Are Pending Activation (OVC-3776)
  • OS6560 Dumps ipcmmd pmds When Calling Home (OVC-3834)

Issues Fixed Since Release 1.0.2

  • Hide Top N clients and Top N App Charts (OVC-1565)
  • OS6560 Does Not Support Policy List on OS6560 Switch running AOS 8.4.1.R03 (OVCLOUD-1384)
  • Status of All AOS Devices Changed from “OV Managed” to “Pre-Provisioning" in Device Catalog (OVC-145)
  • Analytics Line Chart Does Not Display Date in X-Axis (OVC-461)

Issues Fixed Since Release 1.0.1

  • Device Added to Data Lake Is Not Added to Device Catalog Even Though "Call Home" Was Successful (OVC-146)
  • VC of 2 OS6900-X20 Disappeared from the List of Managed Devices (OVC-147)

Additional Documentation

Online help is available in OmniVista Cirrus and can be access 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