Onboarding Devices for OmniVista Terra Management

This section describes the required prerequisites and general workflow to onboard OmniSwitch and Access Point devices for OmniVista Terra Management, as well as troubleshooting information.

Switch Onboarding Workflow

The process to onboard AOS Switches for OmniVista management is described in this section. It is important to verify and configure the required prerequisites before attempting to onboard and provision a switch.

When a switch powers on, it contacts the DHCP Server and gets the location of the OmniVista Activation Server. The Cloud Agent on the switch then makes an HTTPS call to the OmniVista Activation Server and is matched to a Device Catalog entry containing the Management User and Provisioning Templates for that switch/switch model. OmniVista then uses SSH to log into the switch using the credentials specified in the Management User Template and configures/provisions the switch. Once provisioning is complete, the switch is manageable by OmniVista.

Verify the Required Prerequisites for Onboarding Switches

The prerequisite configurations below must be completed to ensure a successful onboarding process. Once the prerequisites are met, switches can be deployed as described in the Basic Deployment Workflow section.

Verify Network Prerequisites are configured. For example: DHCP, Firewall, DNS settings.
Verify Device Prerequisites for the switch are configured. For example: Minimum AOS software supported; license info; models supported
CLI-Based Provisioning
- At a minimum, the Management User Template is pushed to the switch. This template provides the login credentials that OmniVista will use to communicate with the switch. A Default Management User template is used, unless you select another template. The Default Management User Template uses the “admin/switch” login credentials to connect with the Switch.
- Configure any additional configuration to append to the switch configuration through CLI commands in a Provisioning Template.
- Configure CLI-Based Provisioning Settings to specify the onboarding process for switches with no initial configuration (no initial template, no value mapping).
To implement a global redirect configuration for Captive Portal authentication on an OmniSwitch, you have to manually configure the redirect settings through the switch CLI. This step is required until OmniVista supports Global Configuration in a future release. To configure a redirect for Captive Portal authentication, use one of the following methods:
- Configure the redirect on the switch using the redirect server IP address (use nslookup to find the IP address). For example:
  CODE
```
nslookup <server domain name>
unp redirect pause-timer 60
unp redirect proxy-server-port 1024
unp redirect server <server IP>
```
- Configure the redirect on the switch with the redirect server domain name (no need to use nslookup). For example:
  CODE
```
unp redirect pause-timer 60
unp redirect proxy-server-port 1024
unp redirect server us.manage.ovcirrus.com
```
  - Note that the server domain name should match the FQDN for the OmniVista cluster. Refer to the Creating a Guest Access Strategy screen to obtain the cluster FQDN.

Basic Deployment Workflow

The basic deployment workflow is slightly different for new "out-of-the-box" switches or currently-deployed switches.

New Switches

OmniVista Terra uses SSH to log into the switch using the credentials specified in the Default Management User Template and configures/provisions the switch. It is recommended that you change the login credentials contained in this template or create a new Management User Template.
Note: After switches are successfully onboarded and provisioned, it is highly recommended that you change the default "admin" password on the switches.
Make sure the switch has Internet access and is running from the Working directory.
Declare the switch(es) in the Device Catalog List and specify the Management User Template and the required Provisioning Template (see Prerequisites above) to assign to the switch.
Connect the switch(es) to the network.
New “out-of-the-box” switches automatically call the OmniVista Activation Server when first connected to the network. OmniVista verifies the call home request is from an AOS switch, then checks if the switch serial number is already declared in the Device Catalog List for an Organization. If found, OmniVista returns the required certificates that the switch needs to initiate a VPN connection to OmniVista.
The switch initiates the VPN connection. Once the connection is made, OmniVista downloads, installs, and starts the OmniVista Terra Agent on the switch. The OmniVista Terra Agent package consists of a monitoring and configuration agent that interacts on a push-pull, on demand basis with OmniVista to manage switches.
OmniVista then delivers the provisioning configuration (Management User Template and Provisioning Template) assigned to the switch when you added the switch to the Device Catalog List. When the provisioning configuration is sent, OmniVista applies the following CLI commands to the switch to set up Event Configuration:

Once the switch is onboarded in OmniVista, the switch running configuration will become unsaved. OmniVista will automatically save the configuration if "Certify" was enabled (the default) when you added the switch to the Device Catalog List. If the “Certify” option was disabled, then the switch configuration remains unsaved and you should perform a "Save to Running" action from the Device Catalog.
When the switch is successfully onboarded and managed, the Activation Status and Management Connectivity for the switch is updated in the Device Catalog.

Currently Deployed Switches

A switch should be running from the Working Directory for provisioning. If a switch is running from the Certified Directory, reload the switch from the Working Directory before beginning the steps below.

Note that a switch running from the Certified Directory can be provisioned, however, the configuration is temporary and will not be persisted. The switch will lose its configuration if it reboots. If a switch is provisioned from the Certified Directory, reload the switch from the Working Directory and "Force Provision" the configuration to the switch from the Results screen. When you "Force Provision" a switch, the configuration is pushed to the switch the next time the switch contacts OmniVista Terra. See the Results Screen online help for more information on manually pushing ("Force Provisioning") a configuration to a provisioned switch.

If the switch is currently managed by OmniVista Cirrus 10 or OmniVista Cirrus 4, you must remove certificates from the switch before adding the switch to OmniVista Terra. Otherwise, go to Step 2. Use the following CLI command to remove the listed certificates:
CODE
```
-> cd switch/cloud
-> rm -f client.crt cloudCAchain.pem csr.crt private.key public.key
```
Go to the CLI-Based Provisioning Management User Templates screen to view/configure the Default Management User Template or the template you want to assign to the switch when the switch is added to the Device Catalog List. The Management User Template is initially applied to a switch that is successfully provisioned and enables OmniVista management of the switch.
1. Select "Use existing credentials" and enter the current CLI/FTP Username and Password for the switch. OmniVista will expect these credentials to already exist on the switch. See the Management User Templates online help for more information on configuring the Management User Template.
  Note: If the switch username/password is different than the one defined in the Management User Template, OmniVista will be unable to connect to the switch and provisioning will fail. The switch will be displayed on the Results screen with a Provisioning Status of "Failed". If this happens, configure the "Use existing credentials" option on the Management User Template, and "Force Provision" the switch. See the Results screen online help for more information on "Force Provisioning".
Declare the switch(es) in the Device Catalog List and specify the Management User Template and the required Provisioning Template (see Prerequisites above) to assign to the switch. When the switch(es) contacts OmniVista, it will be matched to a corresponding Device Catalog List entry and the configuration in the templates will be pushed to the switch(es). The CLI-based configuration in the Provisioning Template is appended to the existing switch configuration file.
To enable a currently-deployed switch to contact the OmniVista Server, you must telnet to the switch and modify the cloudagent.cfg file and enable the Cloud Agent:
1. Modify the cloudagent.cfg file - Configure the "Activation Server URL" field in the cloudagent.cfg file and enter the FQDN - activation.myovterra.com.
2. Enable the Cloud Agent - Telnet to the switch and issue the following command: cloud-agent admin-state enable.
Once the connection is made, OmniVista downloads, installs, and starts the OmniVista Terra Agent on the switch. The OmniVista Terra Agent package consists of a monitoring and configuration agent that interacts on a push-pull, on demand basis with OmniVista to manage switches.
OmniVista delivers the provisioning configuration (Management User Template and Provisioning Template) assigned to the switch when you added the switch to the Device Catalog List.
When the switch is successfully onboarded and managed, the Activation Status and Management Connectivity for the switch is updated in the Device Catalog.

When a Provisioning Template is pushed to the switch, the configuration in the template is appended to the existing switch configuration file. If the Provisioning Template configuration conflicts with the current switch configuration, provisioning will fail and the device will not be manageable by OmniVista. If provisioning fails, go to the Results screen and check the "Last Provision Message" column for more information. If the Provisioning Template is the problem, make any necessary updates to the Provisioning Template then “Force Provision” the configuration to the switch from the Results screen. The next time the switch contacts OmniVista, provisioning should be successful. See the Results screen online help for more information on manually pushing ("Force Provisioning") a Rule to a switch.

Access Point Onboarding Workflow

The process to onboard Stellar AP devices for OmniVista management is described below. It is important to verify and configure the required prerequisites before attempting to onboard and provision Access Points.

The following is the basic deployment workflow for onboarding Stellar AP Series devices for OmniVista Terra management.

If the AP is currently managed by OmniVista Cirrus 10 or OmniVista Cirrus 4, you must remove certificates from the AP before adding the AP to OmniVista Terra. Otherwise, go to Step 2. Use the following commands to remove the listed certificates:
CODE
```
rm -rf /.ocloud/callhome_hash.json /.ocloud/certificateFile.cert
/.ocloud/cloudCaChain.pem /.ocloud/privateKey.key /.ocloud/csr.csr
/.ocloud/publicKey.key ./privateKey.key.dec
```

Configure option 43 for the AP in your DHCP server:

CODE

option 43
[010C616C656E7465727072697365801F687474703A2F2F61637469766174696F6E2E6D796F7674657272612E636F6D];

For example, if you want to configure the dhcpd.conf file in the core switch to which the AP is connected: (Note that the following is a sample configuration only. Use IP addresses, domain name server, and NTP server information specific to your deployment.).

CODE

manual-dhcp dc:08:56:3c:2f:20 10.95.171.178 {
option subnet-mask 255.255.255.0;
option routers 10.95.171.1;
option domain-name "myovterra.com";
option domain-name-servers 10.95.163.213;
option ntp-servers 112.111.111.108;
option 43
[010C616C656E7465727072697365801F687474703A2F2F61637469766174696F6E2E6D796F7674657272612E636F6D]
;
option 43 activation.myovterra.com;
}

The option 43 hexadecimal string is equivalent to the following: alenterprisehttp://activation.myovterra.com.

Enter the dhcp-server restart command on the switch.
Enter first boot and reboot commands on the AP.
Declare the AP device(s) in the Device Catalog List.
Make sure the AP has Internet access.
Connect the AP to the network and power it on.
The AP will automatically call the OmniVista Activation Server.
OmniVista verifies the call home request is from an AWOS AP device, then checks if the AP serial number is already declared in the Device Catalog List for an Organization. If found, OmniVista returns the required certificates that the AP needs to initiate a VPN connection to OmniVista Cirrus.
The AP will then connect with OmniVista Terra.
If the AP is unable to connect with OmniVista Terra, the AP will operate in Express Mode and periodically call home until the AP is able to connect with OmniVista Terra.
The AP is registered and licensed once it successfully connects with OmniVista Terra.
When the AP is successfully onboarded and managed, the Activation Status and Management Connectivity for the AP is updated in the Device Catalog.

Troubleshooting the Onboarding Process

Provisioning Fails

If provisioning fails, go to the Results screen and check the "Last Provisioning Message" column for the reason. The most common cause of failure is that OmniVista does not know the correct credentials to SSH/SFTP the switch. The credentials that OmniVista uses to connect to the switch are specified in the Default Management User Template or in a Custom Management Template. If the Provisioning Template is the problem, make any necessary updates to the Provisioning Template, and save it. The next time the switch contacts OmniVista, provisioning should be successful.
For additional troubleshooting information, refer to the Device Onboarding - FAQs/Troubleshooting online help page.

Verify the OmniVista Terra Agent Installation On the Switch

In addition to the OmniVista Terra Agent options available through the OmniVista Cirrus UI, you can also perform the following CLI commands on the switch.

To verify the Agent was successfully downloaded and installed on the switch, use the show pkgmgr CLI command:

To verify that the two components of the OmniVista Terra Agent package (Config Agent and Monitoring Agent) were started, use the show appmgr CLI command:

23 Sep 2025