OmniVista Cirrus Production Notes 4.9.1

Standard Requirements

The following switch configuration prerequisites must be met for a Static Network Deployment. < /p>

1. Execute the following CLI commands on each switch. The commands can be cont ained 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/r esponses between devices and OmniVista Cirrus, a minimum of 2Mbps without latency end-to-end netw ork throughput is required between the device and OmniVista Cirrus. APs must be running the lates t AWOS software version.

Proxy Requirements

If a device is accessing the Internet via an HTTP/HTTPs proxy, the proxy server must be speci fied in DHCP Option 43, Sub-option 129 (Server) and Sub-Option 130 (Port). The server may be speci fied 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 th is 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, you r 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 outsid e 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 tc p 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 4 43.

NTP Server Requirements

An NTP Server(s) is required for Certificate validation (start date and duration), and all re lated 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 sync hronize 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.< /p>

When licensed devices call home, OmniVista Cirrus checks the software versions the devices ar e 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 i n 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 manag ement 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-1273 2)
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 ca nnot 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 AP15 11 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 dev ices are changed.

For example, suppose there are two devices discovered and managed by OmniVista: Device1 with I P address "IP1", and Device2 with IP address "IP2". At some point, the IP Add ress 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 attem pt 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), Devi ce2 will be deleted from OmniVista when OmniVista discovers that Device1 now has the "IP2&qu ot; 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 sw itches to determine whether a switch should upgrade or not. Because of the different behaviors of 6 x and 8x Switches, there may be some inconsistencies about when a switch will be triggered to upg rade.

• 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 Catalo g, whereas /flash/certified has a lower version. Since AOS 6x sends current software version of /fl ash/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 Cata log, whereas /flash/certified has a lower version. Since AOS 8x sends current software version of c urrent running directory which is /flash/certified. there will be an upgrade. The switch will downl oad 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 automatic ally 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 fi le 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 run ning AOS 8.10.R1.
Workaround: Enable AAA authentication SSH on the 8.10R1 switch via the CLI. Pro blem will be fixed in the AOS 8.10R1 MR/8.10R2 release.

Inventory

Upgrade Workflow Should Be Changed When Device Is Loaded From Certified Directory (OV C-435)
Summary: When an AOS 6.x Switch with "Set to Software Version" set t o "Latest Version" contacts the OmniVista Server, the server checks the Working Directo ry to see if it is running the latest AOS software. If the Working Directory contains the latest s oftware version, an upgrade will not be triggered, even if the Certified Directory is running on a n older software version. To upgrade the Certified Directory to the latest software, reboot the s witch 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 s oftware upgrade through Managed Devices fails because the NaaS license has expired on the device.< br> Workaround: No workaround at this time.

mDNS

mDNS Server and Client Policy: UI Offers Policy Lists in "Access Role Profile&quo t; 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 Acce ss Role Profile for the policy.

Unified Access

Switch Client Passes MAC Authentication Then Fails, but the Client is Assigned to the A RP from the Successful Authentication (OVE-13317)
Summary: If a client connected to a switch successfully authenticates but later fails au thentication, the switch retains the Access Role Profile (ARP) from the successful authentication a nd continues to assign that ARP to the client. Note that switch clients that have never successfull y 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.