Addon manufacturer inserted to network CIs

Dave Holdcraft
Tera Contributor

3 weeks ago

Discovery will insert the value “ADDON” in the manufacturer, Asset, and Model ID fields of a network switch or router.

Do I need to modify the pattern to fix this?
If so, do I edit the OOB step or create step(s) before it to find & correct manufacturer names containing "ADDON" ?

0 Helpfuls
  • 257 Views
1 REPLY 1

Matthew_13
Mega Sage

3 weeks ago

Hi Buddy,

I would say don’t change the OOB pattern first. In most cases, you don’t need to touch the pattern at all.

What you’re seeing with “ADDON” usually means Discovery couldn’t confidently identify the real manufacturer/model from SNMP, so it falls back to a generic placeholder. That value is typically coming from an OID-to-model/manufacturer mapping, not from a random step in the pattern.

Here’s how to think about it:

  1. Discovery isn’t inventing “ADDON” on its own
    It’s almost always coming from how the device’s SNMP sysObjectID is being resolved. If the OID maps to a generic or bad entry, Discovery populates Manufacturer, Model, and sometimes Asset fields with “ADDON”.

  2. First thing to check (recommended)
    Pick one affected switch/router and:

    • Open the Discovery run

    • Look at the pattern logs or context

    • Identify the device’s sysObjectID
      Then check the SNMP/OID mapping records and see if that OID is mapped to an “ADDON” model or manufacturer. If it is, fixing or clearing that mapping usually solves the problem permanently.

  3. Only touch patterns if you must
    If the device genuinely doesn’t expose usable vendor/model data via SNMP, then:

    • Do not edit the OOB pattern directly

    • Use a pattern extension or a copied pattern

    • Add logic after identification that says:
      “If manufacturer/model = ADDON, derive it from sysDescr or other SNMP fields and overwrite it”

  4. What not to do

    • Don’t edit OOB steps directly (upgrades will overwrite them)

    • Don’t blindly replace “ADDON” in every case without understanding why it’s set

So the right order is:

  1. Verify and fix the OID → model/manufacturer mapping

  2. Only if that fails, add a small override step in a pattern extension

That keeps Discovery clean, upgrade-safe, and predictable.

 

@Dave Holdcraft - Please mark as Accepted Solution and Thumbs Up if you found helpful 🙂

MJG
0 Helpfuls