---
title: SNMP discovery maps to an unexpected profile
source: https://docs.newrelic.com/docs/network-performance-monitoring/troubleshooting/snmp-discovery-unexpected-profile
---

## Problem [#problem]

After running an SNMP discovery, your device is mapping to an unexpected profile in the `mib_profile` key of the device configuration.

## Background [#background]

The SNMP discovery process will attempt to automatically map devices to an existing profile from the [kentik/snmp-profiles](https://github.com/kentik/snmp-profiles) repository using the following process:

-   First, an attempt is made to match the value of the device's [sysObjectID](http://oid-info.com/get/1.3.6.1.2.1.1.2) with either a literal or wildcard match for the values in the `systemobjectid` key for a profile.
-   In cases where a device's sysObjectID is one of the [Net-SNMP agent OIDs](http://oid-info.com/get/1.3.6.1.4.1.8072.3.2), there is a best-effort attempt to further isolate the device profile through a regex match against the device's [sysDescr](http://oid-info.com/get/1.3.6.1.2.1.1.1) value. You can see the current options in the `matches` key of the [net-snmp.yml profile](https://github.com/kentik/snmp-profiles/blob/main/profiles/kentik_snmp/_general/net-snmp.yml).

There are two distinct scenarios that can exist after this process:

1.  Device is matched to an expected profile and collects metrics without issue.
2.  Device is unexpectedly matched to the wrong profile and is collecting the wrong metrics or is missing metrics.

## Solution [#solution]

### Kentik Default devices [#kentik-default]

For the second scenario, the most common situation is that your device maps to the following:

```yaml
# Snippet from device config
  mib_profile: base.yml
  provider: kentik-default
```

Follow the steps in the [SNMP discovery results in 'Kentik Default' entities](https://docs.newrelic.com/docs/network-performance-monitoring/troubleshooting/snmp-discovery-kentik-default) troubleshooting guide to resolve this.

### Net-SNMP devices [#net-snmp]

You may also see situations where the best-effort matching against the `sysDescr` value for a device either doesn't work or isn't available due to a lack of uniquely identifying information available in the value.

In this case, you can manually override the matching from the discovery job using the **bang (!)** syntax: `"!profile-name.yml"`, which allows you to force any profile you desire:

```yaml
# Snippet from device config
  mib_profile: "!sonicwall-sma.yml"
  provider: kentik-firewall
```

As mentioned in the [device configuration documentation](https://docs.newrelic.com/docs/network-performance-monitoring/advanced/advanced-config/#devices), the value of the `provider` key also needs to be set to ensure a proper UI experience in New Relic.

Make sure you add any new MIBs for your config file into the global `mibs_enabled` key. This tells the running container to actively collect metrics for those MIBs.

Here's a Sonicwall firewall example:

```yaml
# Snippet from global config
  mibs_enabled:
  - HOST-RESOURCES-MIB
  - IF-MIB
  - SONICWALL-SMA-APPLIANCE-SYSTEM-HEALTH-MIB
  - SONICWALL-SMA-APPLIANCE-SERVICE-HEALTH-MIB
  - SONICWALL-SMA-APPLIANCE-SECURITY-HISTORY-MIB
  - SONICWALL-SMA-APPLIANCE-TUNNEL-SERVER-MIB
```

> #### 💡 TIP
>
> You should also set the discovery configuration key: "[replace_devices](https://docs.newrelic.com/docs/network-performance-monitoring/advanced/advanced-config/#discovery)" to `false` to prevent accidentally overwriting these edits on a future discovery job.