Preventing Duplicate or Conflicting FortiSwitch Data in Auvik (Ping Discovery vs FortiGate API)

Introduction

When monitoring FortiSwitches in Auvik, data can be collected through:

• Device discovery via ping (ICMP) and subsequent polling
• The FortiGate API (for switches managed via FortiLink)

Using both methods simultaneously can introduce duplicate devices, inconsistent topology, and conflicting device data. This article explains how to resolve these issues by standardizing your monitoring approach.

Problem

If both ping-based discovery and FortiGate API monitoring are enabled:

• Auvik may discover the same FortiSwitch more than once
• Device attributes (hostname, IP, interfaces) may not match
• Network topology may appear inconsistent
• Downstream devices may attach to different parent devices

This occurs because Auvik is ingesting two independent data sources describing the same infrastructure.

Recommended Approach

Use the FortiGate API as the authoritative data source for FortiSwitches and restrict direct discovery of those switches.

This ensures:

• A single source of truth
• Consistent device identification
• Stable topology mapping

Configuration Steps

Step 1: Exclude FortiSwitches from Discovery

1. In Auvik, go to Discovery > Manage Networks
2. Locate the IP ranges or specific IPs used by FortiSwitches
3. Add these to the exclusion list
4. Save changes

This prevents Auvik from discovering and polling the switches directly.

Step 2: Verify FortiGate API Integration

Ensure your FortiGate integration is functioning:

• API credentials are configured
• Connection tests succeed
• Device data is being populated in Auvik

(Refer to existing FortiGate/FortiSwitch API setup documentation if needed.)

When to Apply This Configuration

Use this approach when:

• FortiSwitches are managed via FortiLink
• Duplicate or mismatched devices appear in Auvik
• Topology inconsistencies are observed
• Stability and consistency are prioritized

Alternative Approach

You may choose to:

• Disable FortiGate API monitoring
• Use discovery and polling only

However, this is generally less effective in FortiLink environments and may reduce visibility into controller-managed relationships.

SNMP, FortiGate API, and avoiding duplicate data

Auvik can collect Fortinet information through SNMP, direct discovery, FortiGate CLI credentials, and the FortiOS REST API. Whether these sources conflict depends on which devices each source is discovering or representing.

For FortiLink-managed FortiSwitches:

• The FortiGate API can provide switch inventory, interfaces, statistics, and FortiLink relationships.
• FortiGate CLI credentials may provide additional topology information, including LLDP data.
• Direct discovery and polling of the same FortiSwitches can create duplicate or conflicting device records if the FortiGate API is also representing them.

FortiOS 6.0 and later is supported for FortiLink-managed FortiSwitch monitoring through the FortiOS REST API.

Recommended configuration

For FortiLink-managed FortiSwitches, use the FortiGate API as the primary source when it provides the required inventory, interface, and relationship data.

If additional topology or interface information is required, direct discovery may be used only when the FortiSwitches are independently reachable from the Auvik Collector and the discovery scope does not create duplicate representations.

When using direct discovery:

• Confirm that each FortiSwitch responds to ICMP from the Collector.
• Configure valid SNMP credentials in Auvik.
• Enable LLDP on the FortiSwitches and relevant uplink or downlink ports.
• Avoid overlapping discovery scopes that represent the same switch through both direct discovery and the FortiGate API.
• Review inventory and topology after making changes.

FortiLink-only discovery may provide less topology detail than direct discovery. Direct discovery can provide additional interface and neighbor information when the switches are reachable and correctly configured, but it should not be enabled in a way that creates a second device record for a switch already represented through the FortiGate API.

If duplicate or conflicting devices appear

1. Determine whether the affected FortiSwitch is represented through the FortiGate API, direct discovery, or both.
2. Decide which source should remain authoritative for that switch.
3. Restrict or remove the secondary discovery path so the same switch is not created twice.
4. Trigger a rediscovery and allow several polling cycles for inventory and topology to update.
5. If duplicates remain, provide Support with the affected device identifiers, intended discovery method, and screenshots of the conflicting records.

If duplicate or conflicting devices appear

Check the following:

• Whether the FortiSwitch is managed through FortiLink.
• Whether the same switch is visible through both direct discovery and the FortiGate API.
• Whether the FortiGate API is configured for the correct site and FortiGate.
• Whether the collector can reach the required management interfaces.
• Whether the API and SNMP credentials are assigned to overlapping devices.

Changes to discovery scopes, credentials, or FortiGate API configuration should be made by an authorized administrator. Before disabling a credential source or excluding devices from discovery, confirm which monitoring method is intended to remain authoritative.

If duplicate devices or conflicting topology remain, contact Auvik Support with screenshots of the affected devices, device identifiers, the intended monitoring scope, and the FortiOS version.

Summary

Running both direct discovery and FortiGate API monitoring for FortiSwitches can lead to duplicate and conflicting data in Auvik. By excluding switches from discovery and relying on the FortiGate API, you create a cleaner, more reliable network model with fewer inconsistencies.