Troubleshooting Topics

Edit online

This guide helps users identify, diagnose, and resolve problems. It describes common symptoms, explains likely causes, and provides step-by-step instructions to fix issues and restore normal operation.

The following are some common issues that you might encounter when you integrate Fortinet SD-WAN with SevOne NMS:

Check Connection fails when testing

Symptom

In the Integration Manager, when you click Check Connection to verify the connection status, the connection fails.

Cause
This problem can occur for any of the following reasons:
  • The FortiManager URL, user name, or password is not valid or does not have the required permissions.
  • The selected peer cannot connect to the Fortinet API endpoint.
  • No network connectivity to the Fortinet SD-WAN API endpoint from the selected peer.
Solution

To identify and resolve the root cause of a connectivity failure, run the connectivity test again from Integration Manager. Click Check Connection to verify the connection status. For more information, see Fortinet Integration.

If you need detailed debugging, perform the following tests:
  1. Verify Fortinet API credentials.
    • Ensure that the Fortinet URL, user name, and password that are configured in the Integration Manager are valid, active, and have the required permissions.
  2. Check DNS resolution from the NMS peer.
    • DNS resolution is required to translate the Fortinet URL to an IP address.
    • From the relevant NMS peer, run the following command: 
      nslookup <Fortinet URL>
    • Verify that the domain resolves successfully.
    • If DNS resolution fails, check the DNS server configuration on the peer.
    Make sure that the domain resolves. If DNS resolution fails, verify the DNS server configuration on the peer.
  3. Test API connectivity from the NMS peer.
  • Validate direct API access using the configured FortiManager URL.
  • Run the following command from the peer: 

    • 

$echo '{
  "id": 1,
  "method": "exec",
  "params": [
    {
      "data": {
        "user": "<<abc>>",
        "passwd": "<<pwd>>"
      },
      "url": "/sys/login/user"
    }
  ]
}' > data.json

curl --location --globoff --insecure 'https://<<FortiManager URL>>/jsonrpc' \
  --header 'Content-Type: application/json' \
  --data @data.json

      Output will be as shown below:

      {
  "cid": 195,
  "id": 1,
  "result": [
    {
      "status": {
        "code": 0,
        "message": "OK"
      },
      "url": "/sys/login/user"
    }
  ],
  "session": "<session-token>"
}
      A successful HTTP response (for example, HTTP 200) confirms that the Fortinet API endpoint is reachable and that authentication is working.
  • Run a network connectivity (Traceroute) check.

    To verify HTTPS connectivity and identify where traffic is blocked, run the following command:

    traceroute -p 443 <Fortinet_URL>

    This command determines whether HTTPS connectivity to the Fortinet endpoint is available and identifies the network hop where traffic is blocked.

  • Verify HTTPS and proxy configuration.
    • Ensure that outbound HTTPS traffic (TCP port 443) from the peer to the Fortinet (vManage) server is allowed.
    • If a proxy is required, verify that the proxy settings are correctly configured on the SevOne collector.

Integration status shows Suceeded but device do not populate

Symptom

After you add the integration device, the integration status displays Succeeded, but the devices do not populate.

CauseThis problem can occur for any of the following reasons:
  • The integration account does not have access to any devices.
  • API response returned empty data.
  • Filters or configuration settings exclude all devices.
Solution
To resolve this issue, complete the following steps:
  1. Log in to the NMS collector by using SSH. Run the following command to enter the NMS container: 
    podman exec -it nms-nms-nms bash
  2. Trigger verbose discovery for the integration device:
    • Navigate to the writable directory: 
      cd /var/support
    • Run the discovery command: 
      ID=<integration_device_id>;SevOne-discover-devices discover-now ${ID} --verbose-discovery 2>&1 | tee /tmp/disco_${ID}_$(date +%s).log
  3. Review the discovery log to identify the cause of the issue.

Device or Orchestrator populated with Partial Object synchronization

If the Device Onboarding process is not functioning, check the spk import status in the MySQL database.

  1. Navigate to SevOne NMS container. 
    nms
  2. Execute the command to perform database validation. 
    mysqlconfig
  3. Execute the SQL command. 
    
SELECT vendor, spk_file_name,
    CAST(processed_status AS INT) AS processed_status,
    CAST(active AS INT) AS active_int,
    processed_at
FROM net.spk_data
WHERE vendor = 'Fortinet';
  4. Verify the import status for the .spk files.

    Example

    
+----------+----------------------------------------------+------------------+------------+---------------------+
| vendor   | spk_file_name                                | processed_status | active_int | processed_at        |
+----------+----------------------------------------------+------------------+------------+---------------------+
| Fortinet | Fortigate_Alerts_v1-1_v1.0.0.spk             |                1 |          1 | 2025-05-13 11:52:23 |
| Fortinet | Fortigate_Certification_v1.0.0.spk           |                1 |          1 | 2025-05-13 11:52:22 |
| Fortinet | Fortigate_Interface_SubType_Rules_v1.0.0.spk |                1 |          1 | 2025-05-13 11:52:22 |
| Fortinet | Fortigate_MIBs_v1.0.0.spk                    |                1 |          1 | 2025-05-13 11:52:14 |
| Fortinet | Fortigate_ObjectGroups_v1.0.0.spk            |                1 |          1 | 2025-05-13 11:52:22 |
| Fortinet | Fortigate_TopN_v1.0.0.spk                    |                1 |          1 | 2025-05-13 11:52:30 |
+----------+----------------------------------------------+------------------+------------+---------------------+
6 rows in set (0.001 sec)

    Note: The processed_status should be set to 1, and the processed_at field should record the UTC timestamp when the device was first discovered.
    Note: For Fortigate_* .spk files where processed_at is 0 or null, manually import them using the following command. 
    
cd /config/sdwan/Fortinet

SevOne-import --allow-overwrite --file <spk_name>

Integration status shows Failed

Symptom

After you add the integration device, the integration status displays Failed.

Cause
This problem can occur for any of the following reasons:
  • The API URL, user name, or password is not valid, or the credentials do not have the required permissions.
  • The selected peer cannot connect to the Fortinet API endpoint.
  • The integration plugin encountered errors during discovery.
Solution
To resolve this issue, perform the following workaround steps:
  1. Log in to the NMS collector by SSH into the NMS box. Run a command like this to enter the NMS container: 
    podman exec -it nms-nms-nms bash
  2. Perform verbose discovery for the integration device:
    1. Navigate to the writable directory: 
      cd /var/support

    2. Run the discovery command:

      ID=<integration_device_id>; SevOne-discover-devices discover-now ${ID} --verbose-discovery 2>&1 | tee /tmp/disco_${ID}_$(date +%s).log

      The following sample output is displayed:

      

2026-04-12T11:42:08.719000+0000 SevOne\plugins\SDWANDiscovery::getSdwanVendorFromMetadata(): Failed to find mapping for attribute: Orchestrator Name in namespace: Cisco SDWAN2026-04-12T11:42:08.720361+0000 SevOne\plugins\SDWANDiscovery::atDiscoveryFinish():139 SPK Import class initialised2026-04-12T11:42:08.740705+0000 SDWAN\BaseSDWANPlugin\BaseSDWANPlugin::__construct(): Constructor called with 2 parameters2026-04-12T11:42:08.743995+0000 SDWAN\Fortinet\FortiManager::__construct(): Proxy Id:2026-04-12T11:42:08.744037+0000 SevOne\plugins\SDWANDiscovery::atDiscoveryFinish():156 SPK Import processing for Fortinet2026-04-12T11:42:08.744048+0000 Processing of SPK files started for the vendor: Fortinet and for the import stage 0 ; 0 = before discovery, 1 = after discovery2026-04-12T11:42:08.744809+0000 Fetched 0 SPK files for vendor: Fortinet2026-04-12T11:42:08.754309+0000 SDWAN\Fortinet\FortiManager::Run(): Device type is fortigate2026-04-12T11:42:08.755901+0000 SDWAN\Fortinet\FortiManager::Run(): calling get device by name for: Lisbon-FW2026-04-12T11:42:21.761191+0000 SDWAN\Fortinet\FortiManager::Run(): Fetching session new session key2026-04-12T11:42:21.761703+0000 SDWAN\Fortinet\FortiManager::sendHttpRequest(): Exception occurred while making the API call url = /jsonrpc for device #13 Error executing HTTP Request -- URL using bad/illegal format or missing URL2026-04-12T11:42:21.761761+0000 SDWAN\Fortinet\FortiManager::getSessionKey(): Login to FortiManager failed for device: Lisbon-FW2026-04-12T11:42:21.762377+0000 SDWAN\BaseSDWANPlugin\BaseSDWANPlugin::updateSDWANIntegrationStatus(): Updating integration status to INTEGRATION_STATUS_FAILED for Orchestrator ID 132026-04-12T11:42:21.762422+0000 SDWAN\Fortinet\FortiManager::setSessionKey(): Failed to obtain session key. Exiting.2026-04-12T11:42:21.762440+0000 SDWAN\Fortinet\FortiManager::Run(): Failed to set session key. Aborting.2026-04-12T11:42:21.762466+0000 !!! Failing discovery for plugin 'SDWAN'.  Reason: !!! Fortinet vendor discovery failed for device Id = 132026-04-12T11:42:21.762685+0000 !!! Discovery of plugin 'SDWAN' failed in some way (the Plugin should have already listed the reason earlier).2026-04-12T11:42:21.762714+0000 --- About to acknowledge alerts for disabled objects for Plugin #25 'SDWAN'.
  3. Review the discovery log to identify the cause of the issue.

SNMP objects fail to appear after adding valid SNMP credentials

Symptom

SNMP objects, such as interfaces, do not appear in the SNMP plug-in after you add valid SNMP credentials to a device.

Cause
This problem can occur for any of the following reasons:
  • The device is not reachable over the network.
  • SNMP port (UDP 161) is blocked by a firewall or routing configuration.
  • Firewall rules between the host and the device are preventing SNMP traffic.
  • Incorrect SNMP settings on the device, such as version, port, or credentials.
  • Device is manually added but not valid IP address is entered.
Solution
To resolve this issue, perform the following workaround steps:
  1. Verify the basic network connectivity by running a command like this: 
    ping <device_ip>

    If the device does not respond, SNMP communication can't occur.

  2. Verify the SNMP port reachability by running a command like this: 
    nmap -sU -p 161 <device_ip>

    If the scan fails, check for firewall or routing issues.

  3. Check for firewalls. Make sure that no firewall between your host and the device is blocking UDP port 161 or other required SNMP ports.
  4. Log in to the Fortinet SD-WAN dashboard and verify the SNMP settings for your device. For more information, see SNMP Overview and Configuration.

OOTB reports do not show any data

Symptom

When you view the out-of-the-box (OOTB) reports, you do not see any data in the widgets.

Cause

This issue occurs when the OOTB report can't link TopN views in the selected data source. In Fortinet SD-WAN, the Fortinet SD-WAN Integration Device discovery process imports TopN views into the NMS data source. If this process fails or the TopN views are not imported correctly, the reports remain empty.

Solution
To resolve this issue, perform the following workaround steps:
  1. Verify the processed_status and the active values.
    1. Log in to the nms container.
    2. Access the database by running a command like this: 
      mysql -A
    3. Run the following command: 
      
SELECT
    vendor,
    spk_file_name,
    CAST(processed_status AS INT) AS processed_status,
    CAST(active AS INT) AS active_int,
    processed_at
FROM
    net.spk_data
WHERE
    vendor = 'Fortinet';

      In the command output, if the processed_status is set to 1 and the processed_at field records the UTC timestamp of when the device is first discovered, then the TopN views are already imported.

      If the processed_status is 0, then the TopN views are not imported. Run SevOne-import with the --allow-overwrite option and specify the Fortigate_TopN_v1.0.0.spk file: 
      
SevOne-import --allow-overwrite --file Fortigate_TopN_v1.0.0.spk\

    4. Delete all the onboarded devices and rerun the discovery process.

  2. If the processed_status shows 1 but the TopN views are still not visible in NMS, try importing them manually.
    1. Log in to the nms container.
    2. Navigate to the Cisco SD-WAN directory and verify that the TopN view file exists. Run these commands: 
      
cd /config/sdwan/Fortinet/
ls -l
      The following sample output is displayed: 
      total 108
-rw-r--r--. 1 root root  3098 Jun 19  2025 Fortigate_Alerts_v1-1_v1.0.0.spk
-rw-r--r--. 1 root root 28182 Jun 19  2025 Fortigate_Certification_v1.0.0.spk
-rw-r--r--. 1 root root  2703 Jun 19  2025 Fortigate_Interface_SubType_Rules_v1.0.0.spk
-rw-r--r--. 1 root root 55612 Jun 19  2025 Fortigate_MIBs_v1.0.0.spk
-rw-r--r--. 1 root root  1063 Jun 19  2025 Fortigate_ObjectGroups_v1.0.0.spk
-rw-r--r--. 1 root root  8579 Jul  2  2025 Fortigate_TopN_v1.0.0.spk
    3. To import the TopN view file, run a command like this: 
      
SevOne-import --allow-overwrite --file Fortigate_TopN_v1.0.0.spk
    4. Verify that data appears in OOTB report widgets.