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.

When you edit a Management User Template, the changes only affect new switches during onboarding. Switches already managed in your Organization will not get the updates, even if they're using this template. To change credentials for switches that are already managed, you need to update them in the Discovery Manager Entry instead.

Use Case	Protocol (SSH/HTTP)	Mgmt Template	Discovery Manager Entry	Prompt User for Credentials	Comments
Initial CLI template	SSH	Yes	Yes	No	If a previously managed switch is forced provisioned, OV will use the Management User Template information to apply the Initial CLI template. If the switch has NOT been managed before: The credential type of Management user template is “Create new credentials”: OV will use the default username/password of the switch (admin/**) to apply the Initial CLI template. The credential type of Management user template is “Use existing credentials”: OV will use the username/password in the Management user template to apply the Initial CLI template. Username/password** in the Management user template will be updated to the Discovery Manager Entry after the device finishes pre-provisioning successfully.
Incremental CLI template	SSH	No	Yes	No	OV uses the CLI/FTP User Name and Password in the Discovery Manager Entry to apply the Incremental CLI template.
Terminal launch	WebSocket -> SSH	No	No	Yes (support remember password)	User can choose to remember the credentials for reuse. Credentials not accessible to any other user.
Actions under Diagnostic Tools -> OV Cirrus Agent	SSH	No	Yes	No	Agent is started as part of provisioning flow. User input may not be feasible.
Send configuration commands to Config Agent (VLAN, Save to running, etc.)	MQTT	No	No	No	OV sends configuration commands to the config agent through VerneMQ. No credentials of the switch are used.
Rediscovery (OV Monitoring Agent)	MQTT	No	No	No	OV sends poll commands to the Config Agent and receives poll information from the Monitoring Agent through VerneMQ.
Backup/Restore	SSH	No	Yes	No	LAN Support MS retrieved the credentials from the Discovery Manager Entry Kafka topic: pub_ov_networkconfig_discovery_manager_entry
Golden Config - Setup - Restore - Get Drift	SSH	No	Yes	No	LAN Support MS retrieved the credentials from the Discovery Manager Entry Kafka topic: pub_ov_networkconfig_discovery_manager_entry An improvement is planned for initial setup and drift detection to use MQTT once some features are supported by AOS team. For restore we will see if we can support without SSH in the future, but there is no guarantee yet.
Golden Config - Audit	MQTT	No	No	No	Periodic and manual Golden Config Audit are done through MQTT config-agent
Collect Support Info	SSH	No	Yes	No	Credentials are taken from kafka topic pub_ov_networkconfig_discovery_manager_entry

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:
- To enable switches to contact the OmniVista Server and receive the Provisioning configuration, the DHCP Server must point to the local OmniVista Server as the Activation Server for provisioning.
- The DNS server is configured to resolve activation.myovterra.com, as.myovterra.com, vpn.myovterra.com to point to the local OmniVista Server. Once the activation server is set to activation.myovterra.com, the switch will “call home”. The activation.myovterra.com domain must be resolved to OmniVista’s IP address using the DNS server that was set through DHCP.
- Devices have access to at least one NTP Server (local or external) for Certificate verification (start date and duration) and all related encryption functions.
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, see the Global Configuration online help.

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 contact OmniVista to get the Activation Server FQDN (activation.myovterra.com) from DHCP 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 OVC 4, OVE 4, or OVC 10, refer to Moving Devices from OVC/OVE 4 or OVC 10 to OmniVista Terra. Otherwise, go to Step 2.
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 OVC 4, OVE 4, or OVC 10, refer to Moving Devices from OVC/OVE 4 or OVC 10 to OmniVista Terra. Otherwise, go to Step 2.
Configure option 43 for the AP on your DHCP server. For example, if you want to configure the dhcpd.conf file on 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 Terra.
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.

Moving Devices from OVC/OVE 4 or OVC 10 to OmniVista Terra

If an AP or Switch is currently managed by OmniVista Cirrus 4 or OmniVista Cirrus 10, you need to remove Certificates and have the device Call Home with hash to OmniVista Terra.
- Removing Certificates from Switch Devices
  - Switch Calls Home With Hash
- Removing Certificates from AP Devices
  - AP Calls Home With Hash
If an AP or Switch is not managed by OmniVista or only managed by OmniVista 2500 (OVE 4), the devices will not have any certificates to remove. You can simply have the device Call Home with hash to immediately onboard to OmniVista Terra.
- Switch Calls Home With Hash
- AP Calls Home With Hash

Removing Certificates from Switch Devices

You can use one of the following methods to remove Certificates:

Use the following CLI command to remove the listed Certificates:

CODE

-> cd switch/cloud
-> rm -f client.crt csr.crt private.key public.key

Clear Certificates on the devices by assigning the “clearCertificateAndPrivateKey” troubleshooting command to the device before moving the device to OmniVista Terra.

Once the Certificates are removed, the device must call home with hash to get new Certificates for OmniVista Terra management.

Switch Calls Home With Hash

Configure the following for switch devices that do not have call home Certificates in /.ocloud or /flash/switch/cloud:

Add the switch serial number to the OmniVista Terra Device Catalog.
SSH to the switch and edit the working/cloudagent.cfg file to configure activation.myovterra.com as the Activation Server URL.
Restart the Cloud Agent: cloud-agent admin-state restart
Verify the Call Home log: cat libcurl_log
Verify the Call Home status: show cloud-agent status

Removing Certificates from AP Devices

You can use one of the following methods to remove Certificates:

Use the following command to remove the listed Certificates:

CODE

rm -f callhome_hash.json certificateFile.cert csr.csr privateKey.key publicKey.key

Clear Certificates on the devices by assigning the “clearCertificateAndPrivateKey” troubleshooting command to the device before moving the device to OmniVista Terra.

Once the Certificates are removed, the device must call home with hash to get new Certificates for OmniVista Terra management.

AP Calls Home With Hash

Configure the following for switch devices that do not have call home Certificates in /.ocloud or /flash/switch/cloud:

Configure option 43 for the AP in your DHCP server:

CODE

option 43
[010C616C656E7465727072697365801F687474703A2F2F61637469766174696F6E2E6D796F7674657272612E636F6D];

Edit the /tmp/dhcp_cloud_info (skip if set in DHCP opt43) to configure activation.myovterra.com as the Activation Server URL.
Add the AP serial number to the OmniVista Terra Device Catalog.
Restart the Call Home: callhome.sh
Verify the Call Home log: cat /var/log/activation_client.log
Verify the Call Home status: ocloud_show
Verify the Call Home Certificate: cd /.ocloud

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 Terra 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: