Alcatel-Lucent OmniVista Cirrus

Network Management as a Service

OmniVista Cirrus Production Notes 3.0

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 on premise, 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: Internet Explorer 11+ (on Windows client PCs), 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
    • OS6900-V72 and C32 are now supported in all OmniVista applications.

Software

OmniVista Cirrus now supports the following OS Software Versions:

  • AOS 6.7.2.R06
  • AOS 8.5R4
  • AWOS 3.0.6.27

Applications

Application Updates/Enhancements

  • AP Registration
    • AP Neighbor Table - You can click on the Static Neighbor AP field in the Access Points Detail Panel to view information about any neighbors for the AP.
  • Application Visibility
    • Additional Reports Supported on Stellar APs - "Top Users Per Application" and "Top Applications Per User Reports" are now supported on Stellar APs in addition to OS6860E Devices.
  • Audit
    • Collect Support Info - OmniVista now collects Support Information Logs for APs, in addition to AOS Devices. In addition, logs are now stored on the OmniVista Cirrus Server and can be downloaded to an OmniVista Client at any time. The logs are retained on the Server as configured in the new Preferences - Collect Support Info Screen.
  • Inventory
    • Device Catalog Support for Duplicate IP Addresses - OmniVista Cirrus supports duplicate IP addresses. For example, a Tenant may have multiple DHCP Servers. In this case, the same IP address may be given to multiple devices. You can identify devices with the same IP address by referring to the device Friendly Name or Device Name. If no Device Name was configured for a device, you can identify the device by clicking on the Device's Serial Number in the Device Catalog to highlight the device in a Topology Map.
  • Multi-Tenancy Service
    • A Managed Service Provider (MSP) can now use the same email for multiple Tenant accounts. This will enable a Service Provider to view notifications from all accounts they are supervising under one e-mail address.
  • Notifications
    • New Trap Name Filter - You can now filter traps from the OmniVista Database by Trap Name. Click on the "Filter" drop-down at the top of the table and enter a trap name(s) in the Trap Name field to display specific traps.
  • Preferences
    • New Device Naming Default - The Device Naming default setting is now IP Address (System Name). This is to help identify devices with duplicate IP addresses. The other naming conventions are still available.
  • Subscription
    • Reminder E-Mails for Subscription Renewal - When a Paid Account is 90 days from expiration, a "Renew Subscription" button is displayed at the top of the OmniVista Cirrus screen, and OmniVista automatically sends periodic renewal reminder e-mails to all account users. There is a 90-day Grace Period after a Paid account expires during which time the user has access to the account. If you renew a Paid Account within the Grace Period, all of your data will be available with your renewed/upgraded account. ​​Once the Account Access Grace Period expires there is no way to restore data, and there is no option to renew a Paid account. The only option is to obtain a new Subscription and OmniVista Tenant and re-configure it.
  • Topology
    • Map Status Indicator - A device status indicator is now displayed on the Globe icon in the Map drop-down in the upper left corner of the screen. The Globe icon in the drop-down displays the status of the highest-level notification of any device in the map (e.g., if all devices in a map are "Up", the icon is green, if a device in a map is a "Warning" state, the icon is orange, if a device in a map is "Down", the icon is Red).
    • Map Pin - You can click on the Pin icon in the Map drop-down keep the Topology Map drop-down open. Click the Pin icon again to close it.
    • AP Mesh Network View - AP Mesh networks are now displayed on Topology maps. APs in the Mesh Network are identified by Wi-Fi icons at endpoints between APs and a network symbol next to the Root AP in the network. A Mesh Link filter has also been added to Topology maps.
    • Geo Map Sub-Sites - You can now create Sub-Sites within a Site (e.g., buildings, floors) by creating child maps from the logical Site map that is automatically created when you create a Site. The new Sub-Site map will appear as a sub-map under the Site in the Map drop-down at the upper-left corner of the screen. When you go to the Geo Map view, the total number of devices at the Site will be displayed in the Site circle (the total number of devices at the Site including all Sub-Sites), along with the device status and notifications status for all devices at the Site.
  • Unified Access
    • DHCP Option 82 - A new DHCP Option 82 Feature has been added to the Global Configuration Template group to allow a DHCP Relay Agent to insert specific information into a request that is being forwarded to a DHCP Server by an AP. Once the feature is configured, it is enabled/disabled as part of an Access Role Profile.
  • UPAM
    • Machine Authentication for AD Servers - OmniVista now supports 802.1x authentication of existing users in a Microsoft Active Directory in cases where the NETBIOS is not the same as the Active Directory name.
  • WLAN
    • SSID Improvements - The following improvements have been made to the SSIDs application:
      • ESSID Renamed to SSID Service - The ESSID field has been renamed to SSID.
      • Multiple SSID Services - You can now configure multiple SSID Services using the same SSID (previously called ESSIDs). For example, you could define an SSID called "Student" and have two SSID Services at different locations - "School 1" and "School 2".
      • Implicit Access Policy - A default Access Policy is automatically created for an SSID using the SSID Name when UPAM is selected for authentication. You can customize the default Access Policy by creating the SSID and then editing it. You can also select an existing Access Policy when configuring the SSID.
      • Support for Multiple RADIUS Servers - Multiple External RADIUS Servers are now supported when configuring an SSID.
      • Improved AP Group Assignment Window -  The AP Group Assignment and Schedule window has been updated for easier configuration.
      • SSID Order Preference - The order of the SSIDs listed will persist if a user changes the order of the SSIDs displayed.
      • Horizontal Scroll Bar Visibility - The horizontal scroll bar is now visible at all times.
      • Expanded SSID Drop-Down List -  The SSID drop-down list at the top of each SSID column can now display up to 10 SSIDs.
    • WPA3 Encryption - WP3A Encryption is now supported in the WLAN application when configuring a wireless network.
    • Fixed Channel Width Setting in RF Profile - You can now specify a fixed Channel width if needed even when the Channel Setting is “Auto”. This ensures that all APs configured with the same RF profile are assigned channels that abide by the configured channel width.
    • Heat Map AP Neighbor Display - You can now highlight neighbor APs in a Heat Map. Select an AP and click on the “Display Neighbor AP” in the Survey Toggle Panel to highlight any static neighbor APs or automatic discovery neighbor APs.

Network and Device Prerequisites

The following Customer Network and Alcatel-Lucent Enterprise (ALE) Device prerequisites must be verified/configured before using OmniVista Cirrus.

Customer Network Prerequisites

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

DHCP Server 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).

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 if you are not using a Proxy to connect to the Internet, or if your DNS or NTP Servers are outside of your network:

  • 443 - If you are not using a Proxy to connect to the Internet. Either your firewall must allow outbound access to this port; or if you have one, you may access the port via your local proxy.
  • 80 - If you are not using a Proxy to connect to the Internet. Either your firewall must allow outbound access to this port; or if you have one, you may access the port via your local proxy.
  • 123 - If you are using an NTP Server that is outside of your network. If External, 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 - If you are using a DNS Server that is outside of your network. If External, 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 3.0.

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.112.R03
  • AOS 8.4.1.141.R03
  • AWOS 3.0.2.40.

Management

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

  • Essential Switch (E) - OS6350/OS6450 - (6.7.2.R06), OS6465 (8.5R4), OS6560 (8.5R4)
  • Core Switch (C) - OS6900 (8.5R4)  
  • Advanced Switch (A) - OS6860/OS6860E/OS6865 (8.5R4)
  • Stellar AP (SA) - OAW-AP1101, OAW-1201, OAW-1201H, OAW-AP1221, OAW-AP1222, OAW-AP1231, OAW-AP1232, OAW-AP1251 (AWOS 3.0.6.27)

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.

Issues/Workarounds

Application Visibility

AV No Longer Supports OS6900/OS10K Switches (OVC-4434)
Summary: Application Visibility no longer supports OS6900/OS10K Switches. Any Application Visibility Policies or Policy Lists applied to these devices should be updated/deleted.
Workaround: NA - 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.

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.

Preferences

If Network ID Strict Mode Is Enabled Some Devices Will Be Unable to On-Board (OVC-4381)
Summary: If Network ID Strict Mode is enabled, only devices running AOS 672.R05 and AWOS 3.0.5.30 will be able to onboard.
Workaround: NA - Informational.

Pre-Provisioning

Pre-Provisioning Fails When NTP Server Is Configured in a Pre-Provisioning Template (OVC-4682)
Summary: If you configure the NTP Server in a Pre-Provisioning Template and on your on-premise DHCP Server, pre-provisioning will fail.
Workaround: Do not configure the NTP Server on both the Pre-Provisioning Template and your on-premise DHCP Server. The on-premise DHCP server should not return the NTP Server IP address if the NTP IP is specified in the pre-provisioning configuration in OmniVista. Alternatively, if the DHCP Server is returning the NTP Server IP address to devices, do not specify the NTP Server IP address in the pre-provisioning configuration in OmniVista.

Unified Access

Unable to Map SSID to Different VLANs on Different AP Groups (OVC-4989)
Summary: You cannot Map an SSID to different VLANs on different AP Groups.
Workaround: There is no workaround at this time. Will be fixed in OmniVista Cirrus 3.1.0 release.

Cannot Notify Policy List with Accept All | Deny All Policy on AOS 6x Devices (OVC-6133)
Summary: A Policy List containing an "Accept All" or "Deny All" Policy cannot be applied to an AOS 6.x Device even though OmniVista message indicates "Success".
Workaround: This issue does not exist on AOS 8.x Devices, and will be fixed in AOS 6.7.2.R07. Until then, for AOS 6.x Devices, connect to the device and issue the following CLI commands to apply the configuration:

policy condition IPv6-Any  destination ipv6 Any
policy action [DenyAction/AcceptAction] disposition [drop/ accept]
policy validity-period AllTheTime days sunday monday tuesday wednesday thursday friday saturday months january february march april may june july august september october november december
policy rule [OV-L3-DenyAllPolicy-IPv6/ OV-L3-AcceptAllPolicy-IPv6] precedence 100 condition IPv6-Any action [DenyAction/ AcceptAction] validity-period AllTheTime log no default-list   
policy list [list1] rules [ OV-L3-DenyAllPolicy-IPv6/ OV-L3-AcceptAllPolicy-IPv6]
qos apply

UPAM

External LDAP Server Requires Direct Connection (OVCLOUD-2832)
Summary: If you are using an external LDAP Server, you must have a direct connection to the server using a public IP address.
Workaround: NA - Informational.

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.

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.

Issues Fixed

Issues Fixed Since Release 2.1.0

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