By Default Slurp’it has his own OID database which it will use to recognize your device vendor, type and driver. 90% of the times this works perfectly, but there are vendors who use the same OID for different device types. Cisco is a good example, The Nexus & ACI line are physically the same, but also the Cisco C1000 series gave us some challenges.
To solve this we implemented Transform Rules. With a Transform rule you can write small Jinja2 template to manipulate data before it’s being stored in the database.
* note: Free version of Slurp’it only allows 3 transform rules
1. Enable the rule Set PhysicalModelName as Product
From experience we learned that overwriting the Device Type with the SNMP variable: PhysicalModelName will fix most of the issues with Cisco devices. To help you out, we already created a rule for this, you only have to apply it.
Search for: Set PhysicalModelName as Product and enable it.
In the following example I use a payload from a Cisco C100 devices.
Before enabling the Transform rule the Device was discovered as:
{
“ip”: “10.59.99.3”,
“hostname”: “C1000.slurpit.local”,
“fqdn”: “10.4.1.1”,
“vendor”: “CISCO”,
“device_type”: “cisco_ios”,
“product”: “CATALYST 1000”
}
After we enabled the Rule the device was discovered as
{
“ip”: “10.59.99.3”,
“hostname”: “C1000.slurpit.local”,
“fqdn”: “10.4.1.1”,
“vendor”: “CISCO”,
“device_type”: “cisco_ios”,
“product”: “C1000-24T-4G-L“
}
How does this work?
So the original payload of the discovered device looks like this:
{
“ip”: “10.59.99.3”,
“hostname”: “C1000.slurpit.local”,
“fqdn”: “10.4.1.1”,
“vendor”: “CISCO”,
“device_type”: “cisco_ios”,
“product”: “CATALYST 1000“,
“batch_id”: -1,
“timestamp”: “2025-05-21T16:47:33.246275Z”,
“snmp_state”: “VALID”,
“snmp_vars”: {
“ENTITY-MIB::entPhysicalAlias”: “”,
“ENTITY-MIB::entPhysicalDescr”: “C1000-24T-4G-L”,
“ENTITY-MIB::entPhysicalFirmwareRev”: “15.2(7)E11”,
“ENTITY-MIB::entPhysicalHardwareRev”: “V02”,
“ENTITY-MIB::entPhysicalModelName”: “C1000-24T-4G-L”,
“ENTITY-MIB::entPhysicalName”: “1”,
“ENTITY-MIB::entPhysicalSerialNum”: “FOC2317Y5HL”,
“ENTITY-MIB::entPhysicalSoftwareRev”: “15.2(7)E11”,
“SNMPv2-MIB::sysContact”: “”,
“SNMPv2-MIB::sysDescr”: “Cisco IOS Software, C1000 Software”,
“SNMPv2-MIB::sysLocation”: “Test location”,
“SNMPv2-MIB::sysName”: “C1000.slurpit.local”,
“SNMPv2-MIB::sysORLastChange”: “6”,
“SNMPv2-MIB::sysObjectID”: “1.3.6.1.4.1.9.1.2959”,
“SNMPv2-MIB::sysServices”: “6”,
“SNMPv2-MIB::sysUpTime”: “726470530”
}
}
The Slurpit OID database can’t detect this Device Type properly because the OID is used for multiple different hardware types (1.3.6.1.4.1.9.1.2959). But in this case Cisco provided the right Phyisical Name as different SNMP object. So what this rule will do is, it will always use the object entPhysicalModelName when it is available.
Jinj2 rule
{% set entPhysicalModelName = data[“snmp_vars”][“ENTITY-MIB::entPhysicalModelName”] %}
{% if entPhysicalModelName %}
{% do data.update({‘product’: entPhysicalModelName}) %}
{% endif %}
as a result, The C1000 device are now detected by their correct Physical Name.
Better supported by the Netbox Device Type library
By default SSOTs like Netbox & Nautobot are using a Device Type library which does not always match our discovered Device Types, but by using the Transform rules you can tailer it in such a way that it will match the used Device Types in your organisation.
