Issue with Network Stacked Switch Discovery

[AnkitaA66249150]

Currently, network stacked switch discovery is not populating the correct model id. We want to use OID 1.3.6.1.2.1.47.1.1.1.1.13 to discover correct model id. We tried to discover switch with this OID but it failed with the following error - 

Post-sensor script \"Network Devices - Post Sensor\" failed due to: TypeError: Cannot convert null to an object.

We want to discovery stack switches model with following OIDs in the stack -

Stack switch 1 - 1.3.6.1.2.1.47.1.1.1.1.13.1000

Stack switch 2 - 1.3.6.1.2.1.47.1.1.1.1.13.2000

Stack switch 3 - 1.3.6.1.2.1.47.1.1.1.1.13.3000

Stack switch 4 - 1.3.6.1.2.1.47.1.1.1.1.13.4000  and so on

Our network team is able to do snmpget to the OID but we are not able to do snmp walk. Did anyone faced the same type of issue and if yes what solution was implemented to fix this?

@Neville Lee 

[AJ-TechTrek]

Hi @AnkitaA66249150 

This is a fairly common issue in ServiceNow Discovery when dealing with stacked switches and the entPhysicalModelName OID (1.3.6.1.2.1.47.1.1.1.1.13).
Your network team can run snmpget successfully, but ServiceNow Discovery patterns usually use snmpwalk or indexed retrieval — if the walk fails, you’ll end up with null values in the sensor output, which then breaks the Network Devices – Post Sensor script.

As per my understanding why You’re Getting the Error
* The Network Devices – Post Sensor script expects the OID value to exist and be returned as an array/object.
* If snmpwalk fails or the OID is not directly discoverable in the pattern step, the result is null, and when the script tries to loop or map over it, it throws:
TypeError: Cannot convert null to an object

This is often seen with stacked devices because:
* Some SNMP agents require explicit index calls (e.g., .13.1000, .13.2000, etc.).
* snmpwalk on the base OID .13 fails if indexing is inconsistent across stack members.
* Older OOB ServiceNow patterns aren’t built to handle indexed sub-OIDs for stacks.

Solution Approaches can be like this -

1. Confirm OID Indexing with SNMP Walk
On the MID Server host, test:

snmpwalk -v2c -c <community> <switch_ip> 1.3.6.1.2.1.47.1.1.1.1.13

You should see each stack member with its index:

...13.1000 = STRING: "Model_A"
...13.2000 = STRING: "Model_B"

If snmpwalk fails but snmpget works, it’s a device SNMP agent limitation — you’ll have to explicitly poll each indexed OID.

2. Modify the SNMP Pattern Step
In the Network Switch or Network Devices discovery pattern:
1. Clone the OOB pattern (never edit OOB).

2. Add an SNMP Get step for:
1.3.6.1.2.1.47.1.1.1.1.13.1000
 1.3.6.1.2.1.47.1.1.1.1.13.2000
 1.3.6.1.2.1.47.1.1.1.1.13.3000
1.3.6.1.2.1.47.1.1.1.1.13.4000

3. Loop through possible indexes (e.g., up to .5000) in a Script step to collect results dynamically instead of hardcoding each one:
var modelOids = [];

 var base = "1.3.6.1.2.1.47.1.1.1.1.13.";
var indexes = [1000, 2000, 3000, 4000];
 indexes.forEach(function(idx) {
var val = snmp.get(base + idx);
 if (val) modelOids.push(val);
});
payload.model_ids = modelOids;

4. Map these values to the CMDB field (model_id or model_number).

3. Adjust Post-Sensor Script
If you can’t get SNMP Walk to work, modify your Post-Sensor script to handle null values gracefully:
if (!data.model_ids || data.model_ids.length === 0) {
gs.log("No model IDs returned for stacked switch: " + current.name);
} else {
// proceed with population
}
This prevents the TypeError and allows partial results to still populate.

4. Alternative – Use LLDP/CDP Data
If SNMP limitations block the OID retrieval, you can:
* Enable LLDP or CDP on the switches.
* Use OOB LLDP/CDP patterns in ServiceNow to get model and neighbor info for each stack member.

Recommended Path for Your Case
1. Test snmpwalk vs snmpget for the OID indexes.
2. If snmpwalk fails:
* Modify the discovery pattern to explicitly SNMP get each indexed OID for the stack members.
3. Update Post-Sensor to handle missing/null results so the discovery doesn’t fail entirely.
4. Map each model to a separate cmdb_ci_network_adapter or stack member CI linked to the parent switch chassis.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[AJ-TechTrek]

Hi @AnkitaA66249150 

This is a fairly common issue in ServiceNow Discovery when dealing with stacked switches and the entPhysicalModelName OID (1.3.6.1.2.1.47.1.1.1.1.13).
Your network team can run snmpget successfully, but ServiceNow Discovery patterns usually use snmpwalk or indexed retrieval — if the walk fails, you’ll end up with null values in the sensor output, which then breaks the Network Devices – Post Sensor script.

As per my understanding why You’re Getting the Error
* The Network Devices – Post Sensor script expects the OID value to exist and be returned as an array/object.
* If snmpwalk fails or the OID is not directly discoverable in the pattern step, the result is null, and when the script tries to loop or map over it, it throws:
TypeError: Cannot convert null to an object

This is often seen with stacked devices because:
* Some SNMP agents require explicit index calls (e.g., .13.1000, .13.2000, etc.).
* snmpwalk on the base OID .13 fails if indexing is inconsistent across stack members.
* Older OOB ServiceNow patterns aren’t built to handle indexed sub-OIDs for stacks.

Solution Approaches can be like this -

1. Confirm OID Indexing with SNMP Walk
On the MID Server host, test:

snmpwalk -v2c -c <community> <switch_ip> 1.3.6.1.2.1.47.1.1.1.1.13

You should see each stack member with its index:

...13.1000 = STRING: "Model_A"
...13.2000 = STRING: "Model_B"

If snmpwalk fails but snmpget works, it’s a device SNMP agent limitation — you’ll have to explicitly poll each indexed OID.

2. Modify the SNMP Pattern Step
In the Network Switch or Network Devices discovery pattern:
1. Clone the OOB pattern (never edit OOB).

2. Add an SNMP Get step for:
1.3.6.1.2.1.47.1.1.1.1.13.1000
 1.3.6.1.2.1.47.1.1.1.1.13.2000
 1.3.6.1.2.1.47.1.1.1.1.13.3000
1.3.6.1.2.1.47.1.1.1.1.13.4000

3. Loop through possible indexes (e.g., up to .5000) in a Script step to collect results dynamically instead of hardcoding each one:
var modelOids = [];

 var base = "1.3.6.1.2.1.47.1.1.1.1.13.";
var indexes = [1000, 2000, 3000, 4000];
 indexes.forEach(function(idx) {
var val = snmp.get(base + idx);
 if (val) modelOids.push(val);
});
payload.model_ids = modelOids;

4. Map these values to the CMDB field (model_id or model_number).

3. Adjust Post-Sensor Script
If you can’t get SNMP Walk to work, modify your Post-Sensor script to handle null values gracefully:
if (!data.model_ids || data.model_ids.length === 0) {
gs.log("No model IDs returned for stacked switch: " + current.name);
} else {
// proceed with population
}
This prevents the TypeError and allows partial results to still populate.

4. Alternative – Use LLDP/CDP Data
If SNMP limitations block the OID retrieval, you can:
* Enable LLDP or CDP on the switches.
* Use OOB LLDP/CDP patterns in ServiceNow to get model and neighbor info for each stack member.

Recommended Path for Your Case
1. Test snmpwalk vs snmpget for the OID indexes.
2. If snmpwalk fails:
* Modify the discovery pattern to explicitly SNMP get each indexed OID for the stack members.
3. Update Post-Sensor to handle missing/null results so the discovery doesn’t fail entirely.
4. Map each model to a separate cmdb_ci_network_adapter or stack member CI linked to the parent switch chassis.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025