Troubleshooting

If the version of the OmniVista Terra Agent is old (for example, switch was onboarded in a previous release) or the agent is stuck (not sending updates or accepting requests from OmniVista Terra), you may encounter the following switch management problems:

• Management connectivity turns on and off.

• Switch configuration and statistics are not updated in some of the UI screens.

• Configuration is not delivered to the switch.

If you do encounter any of the above switch management problems, consider the following troubleshooting tips:

• Check the OmniVista Terra Agent version, status, and supported actions here:
  https://docs.ovcirrus.com/ovtx/omnivista-cirrus-agent

• Update the OmniVista Terra Agent version by setting the Force Provisioning Flag (Device Catalog > CLI Based Provisioning > Results > Select a switch > Actions). Once this flag is set, OmniVista Terra will automatically update the version the next time the switch calls home. It can take approximately 5-10 minutes to update. To check if the switch has called home and the call home sequence has completed, check the timestamps in the Activation Server log (Device Catalog > Devices List > Select Switch > Diagnostic Tools > View Activation log).

• Ping the switch from the Device Catalog List (Device Catalog > Devices List > Select Switch > Actions > Diagnostic Tools > Ping). This can bring back the Management Connectivity in about 10-15 seconds.

• If management connectivity is “On”, you can Collect Switch Logs (Monitor > Diagnostic Tools > Collect Support Info). In the tar file and inside techsupport archive, you will see ovng-monitoring and ovng-config logs. Check for any errors.
  Tip: You can search a UI page quickly by using the Search bar at the top right of any page, near your Profile icon, left of Bell icon.

• If OmniVista Terra cannot reach the switch and you have access to the switch, try the following:
  Use the show pkmgr CLI command to verify the Agent was successfully downloaded and installed on the switch.
  LabSwitch-> show pkgmgr
Legend: (+) indicates package is not saved across reboot
(*) indicates packages will be installed or removed after reload
Name Version Status Install Script
---------------+---------------------+------------------+---------------------------------
ams default installed default
ams-apps default installed default
ovng-agent 3.5 installed /flash/working/pkg/ovng-agent/install.sh
  Use the show appmgr CLI command to verify the two components of the Agent package (Config Agent and Monitoring Agent) were started.

  LabSwitch-> show appmgr
Legend: (+) indicates application is not saved across reboot
Application Status Package Name User Status Time Stamp
----------------+---------+-------------------+---------------------+-------------------------
config-agent started ovng-agent snmpRW Fri Nov 22 02:25:37 2024
monitoring-agent started ovng-agent snmpRW Fri Nov 22 02:25:45 2024
  Use the appmgr start/restart commands if the status is stopped. For example:
  LabSwitch-> appmgr start ovng-agent config-agent
LabSwitch-> appmgr start ovng-agent monitoring-agent

• Check if the switch is connected to OmniVista Terra. The following command should report status as Connected:
  debug ams show

• Check ovng-agent log files for errors:
  LabSwitch-> ls -ltr /flash/ovng*

You can try to reconnect after 10 minutes; then OmniVista Terra will send a new verification email. If still no email is received, give the email address associated with the account to the OmniVista Terra Super Admin. The Super Admin will provide you with the confirmation URL to verify your account.

To see data in the OmniVista Terra UI, please check that the following main steps have been completed:

• Access Points are upgraded to the supported build number. More information.

• The correct Ports in your Firewall are open and devices are not behind a proxy. More information.

• Devices are declared in your organization. More information.

• The date set in your Access Points is correctly configured for your Timezone.

When your Access Points are correctly configured and connected to the OmniVista Terra platform, you can see the date on which they issued data for the last time in the Last Seen column of the Device Catalog screen.

If you don’t see any date in this column, it means that the configuration of your Access Points has not been done properly. Please check this page for further details.

The problem may be caused by a compliment proxy or firewall tool (Endpoint). Please contact your IT department to verify.

Try one of the following options to enable the Save button:

• Check to see if there are any fields on the screen that are required but they weren’t configured. If so, configure the required fields.

• Try changing another attribute/field with a current value or change a check box selection, then change it back.

• Try to refresh the updated page.

To enable the Save button on the main screen, complete other edits on that screen. When you only make changes to the related configuration screen in a new browser tab, the main screen does not reflect that any edits were made. For example, if you wanted to edit an Access Policy related to an SSID from the Customize SSID screen, you would click Edit and select "Edit Access Policy Page in a new browser tab". The Edit Access Policy screen will then open in another browser tab. After you make any changes in the Edit Access Policy screen, if you have not made any other changes in the Customize SSID screen, the Save button for the Customize SSID screen is disabled.

There is a delay to open a connection to the device shell, as the console is waiting for the device's message. If it takes more than one minute and there is still nothing, please check the Internet connection, then close the console and restart a new SSH session.

If the data doesn't reflect the changes after seeing the success notification message, click on the refresh button in the table or refresh the page to get the updated data.

1. Make sure the Access Point or OmniSwitch is running the minimum software required.

   1. AWOS 5.0.3 for an Access Point.

   2. 8.9R1 minimum (8.9R4 recommended) for an OmniSwitch.

2. Wait 1 to 2 minutes for the device to reflect the new threshold value.

To customize the WiFi4EU captive portal template, you have to upload another photo for the template’s banner as there is no button to edit the default template. However, you can edit the Login Background color and Login Button.

There is an SSH connection issue between OmniVista Terra and the Switches. Please verify that SSH is enabled through the Switch CLI before performing an instant backup or scheduling a backup for the switch.

Try to zoom out to have larger screen resolution.

Try to refresh the page. If the error still persists, please inform the Tech Support team.

Try to refresh the page.

Go to the Device layers drop-down list. First, check the Channel Utilization option, then uncheck the Devices option and check it again. Now, both the Channel Utilization and Devices icons will display together.

You can manually copy the Golden configuration content from the screen and use another user interface to duplicate it.

1. Make sure the AP model is an AP-1321 or AP-1361 with AWOS >= 5.0.3.13. Check the AP release notes for additional models that may support MACSEC.

2. Login to OVNG Org:

   1. To Create Provisioning Configuration - Navigate to Wireless->Profile->Provisioning Configuration. Click on Create Provisioning Configuration.

      1. Enable the options as shown below.

3. Create Access Points Groups - Navigate to Wireless->Profile->Access Points Groups and click on Create Access Points Groups and select the provisioning configuration created in the above step.

4. Add the Access point under inventory and select Access Points group created in above step. 

5. Connect the specified model of APs to the switch which has minimum AOS version of 8.10.93.R03 or above and MACsec license installed. Check the AOS release notes to get the list of switches and ports that support MACsec.

6.  Configure AAA and UNP with 802.1x enabled on the port the AP is connected to as shown below.

AAA Configuration. Configure AAA Profile with the desired AAA Server as 802.1X Authentication Server.

UNP Port Template Configuration. Configure UNP Port Template with 802.1X Authentication enabled and AAA Profile above

7. Enable MACsec with Dynamic RADIUS mode on the interface port of the OmniSwitch where the AP is connected by navigating to Device Catalog-> Wired Ports, select the switch and under Actions choose Enable MACsec.

8. Verification steps:

Check the UNP user details

ACC-31-> show unp user details mac-address dc:08:56:34:74:a0
Port: 2/1/13
MAC-Address: dc:08:56:34:74:a0
SAP                            = -,
Service ID                      = -,
VNID                            = -,
VPNID                          = -,
ISID                            = -,
VPLSID                          = -,
Access Timestamp                 = 10/30/2025 17:22:53,
User Name                       = DC08563474A0,
IP-Address                      = 10.110.0.52,
Vlan                            = 1100,
Authentication Type             = 802.1x,
Authentication Status           = Authenticated,
Authentication Failure Reason = -,
Authentication Retry Count      = 0,
Authentication Server IP Used = 143.209.0.2,
Authentication Server Used      = UPAMRadiusServer,
Server Reply-Message            = -,
Profile                         = defaultWLANProfile,
Profile Source                  = Auth Pass - LLDP Rule UNP,
Profile From Auth Server        = -,
Implict Trust-Tag Source        = -,
RADIUS Alcatel-trust-tag-vlans = -,
Session Timeout                  = 0,
Classification Profile Rule     = -,
Role                            = -,
Role Source                     = -,
User Role Rule                  = -,
Restricted Access               = No,
Location Policy Status          = -,
Time Policy Status              = -,
QMR Status                      = Passed,
Redirect Url                    = -,
SIP Call Type                   = Not in a call,
SIP Media Type                  = None,
Applications                     = None,
Encap Value                     = -, 
Rule ID                         = 7, 
Total users : 1 

Check the MACsec configuration.

ACC-31-> show interfaces macsec dynamic 2/1/13
                                                               Server     Transmit        Key      Operation
Chas/Slot/Port  Admin-State   Mode       Keychain  Encryption  Priority   Interval(Sec)   Server   Status
--------------+-----------+---------+------------+-----------+----------+--------------+---------+-----------
2/1/13           Enabled       radius      NA        Enabled       10          2             YES      UP

Ping between AOS and AP to confirm connectivity.

ACC-31-> ping 10.110.0.52
PING 10.110.0.52 (10.110.0.52) 56(84) bytes of data.
64 bytes from 10.110.0.52: icmp_seq=1 ttl=63 time=1.76 ms 
64 bytes from 10.110.0.52: icmp_seq=2 ttl=63 time=1.51 ms 
64 bytes from 10.110.0.52: icmp_seq=3 ttl=63 time=4.22 ms 
64 bytes from 10.110.0.52: icmp_seq=4 ttl=63 time=9.16 ms 
64 bytes from 10.110.0.52: icmp_seq=5 ttl=63 time=23.5 ms 
64 bytes from 10.110.0.52: icmp_seq=6 ttl=63 time=1.78 ms

In this condition, users may observe:

• APs or devices showing Management Connectivity = OFF

• The state may persist until administrative recovery actions are performed

Viewing Kafka Connect Logs

Administrators can verify this condition by reviewing the kafka-co pod logs:

1. Access the Web Admin UI

2. Open the Dashboard

3. Search for “kafka-co” pods

4. Select the relevant pod

5. Click Download Pod Logs

Logs may contain multiple entries similar to:

WARN Connection lost. Re-connecting is set to true
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
Caused by: java.net.SocketException: Connection reset

Workaround

To restore Management Connectivity:

1. Access the Web Admin UI

2. Open the Dashboard

3. Search for “kafka-co” pods

4. Select the affected pod

5. Click Recreate Pod

After the kafka-co pod is recreated, devices should return to Management Connectivity = ON.

Check the current date and time configuration of each OVTX node. They should be consistent otherwise it could cause issues for Kafka consumers/producers. It’s recommended to configure NTP to keep date and time synchronized.