SNMPv2 Discovery Status missing Serial number

[benjaminayo]

Hello,

I am working on ingesting VTC devices into our CMDB using a snmpv2 community credentials. When ran I got an Failing Exploring CI pattern, HorizontalDiscoveryProbe error, Pattern name: Network Router. I was told I should add the OID to the classifiers and in doing so the device was classified but no CI's available to be selected. When I drive into the horizontal Discovery Log, there is a payload error about missing the mandatory field:serial number. What would be the next step in resolving such as issue?

[kmohammed]

Hi benjaminayo,

You have already cleared classification - the remaining failure is at identification. The Network Router pattern ran and built a payload, but for that CI class the Identification and Reconciliation Engine (IRE) treats serial_number as a mandatory identification attribute. The payload contained no serial number, so IRE rejected the CI ("missing mandatory field: serial_number"), which is why the device classifies successfully yet no CI becomes available to select.

Why the serial is empty: the out-of-box network patterns read the serial from the ENTITY-MIB value entPhysicalSerialNum (OID 1.3.6.1.2.1.47.1.1.1.1.11). Most VTC/codec endpoints either do not expose ENTITY-MIB at all, expose the serial only in a vendor-private MIB, or the SNMPv2 community string is bound to a restricted MIB view on the device that excludes the 1.3.6.1.2.1.47 branch. In all three cases classification (driven by sysObjectID, 1.3.6.1.2.1.1.2) still works while the serial step returns nothing.

Next steps, in order:

1. Confirm what the device actually returns. Walk OID 1.3.6.1.2.1.47.1.1.1.1.11 against one VTC using the same community string (from the MID Server host or an SNMP walk tool), and in the Discovery Status open the ECC queue input payload for the horizontal probe to see the serial step's raw result. This separates a device/view problem from a pattern problem.

2. If the walk returns a serial but the pattern payload does not, fix the community string's MIB view on the device so it includes the entity branch, then re-run Discovery.

3. If the serial only exists in a vendor-specific OID, do not edit the OOTB Network Router pattern - extend it instead: add a pattern extension section with an SNMP query for that vendor OID mapped to the CI serial_number attribute (the normal serial-number processing will also write the cmdb_ci_serial_number record), and make sure your classifier points at the extended pattern.

4. Validate with the Pattern Debugger / test run against the device IP first - you should see serial_number populated in the test payload before running a full Discovery.

One caution about the shortcut of removing serial_number from the class identification rule: it does let these CIs in, but serial is the de-duplication key for hardware, so without it you tend to get duplicate CIs when IPs change. Only relax the rule for this specific device class if the endpoints genuinely expose no serial over SNMP, and pair it with another strong identifier (for example MAC address or name) in the same rule.

Regards,

Karimuddin