To be successful with modelling a device you need a few things before you start.
You can model a device without having one, but it is REALLY HARD, having SNMP readonly access to a device is vital for success.
You will need to have all the necessary standard (IETF/IEEE) MIBs and the vendor specific MIBs for the device to be modelled.
Once you have the MIBs the best way to interpret the MIBs is to complete an SNMP WALK of the device, first verify that you can use SNMP to access the device see the following article: Testing SNMP Connectivity from the NMIS Server with snmpwalk
Then you need to do a full SNMP WALK, you will need to create a directory to store the MIBs in, for example ~/mibs, then copy the MIBs you obtained for the product and copy them to that folder, you will also need the standard MIBs, which are included in the NMIS distribution in /usr/local/nmis8/mibs/traps, copy these to the same folder, now verify that everything is working, you may get some errors from SNMP WALK about mib compiling, but you can usually ignore those if you get a good output.
For devices with proprietary MIB's or Enterprise MIBS, you should obtain them from the vendor, Google is very helpful and add them to your MIB's in ~/mibs, before doing the SNMP walk.
Commands to run:
mkdir ~/mibs cp <vendor mib file(s)> ~/mibs cp /usr/local/nmis8/mibs/traps/* ~/mibs snmpwalk -m ALL -M ~/mibs -v 2c -c GOODCOMMUNITY <HOSTNAME or IP ADDRESS> system |
Expected output:
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: Intel64 Family 6 Model 15 Stepping 6 AT/AT COMPATIBLE - Software: Windows Version 6.1 (Build 7601 Multiprocessor Free)SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.311.1.1.3.1.1 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (40604629) 4 days, 16:47:26.29 SNMPv2-MIB::sysContact.0 = STRING: dc_admin@opmantek.com SNMPv2-MIB::sysName.0 = STRING: kaos SNMPv2-MIB::sysLocation.0 = STRING: Head Office SNMPv2-MIB::sysServices.0 = INTEGER: 79 |
Run a full walk and redirect to a file
snmpwalk -m ALL -M ~/mibs -v 2c -c GOODCOMMUNITY <HOSTNAME or IP ADDRESS> .1 > ~/VENDOR-Product.mib |
Now you have an SNMP Dump.
What is the goal for the modelling? Just standard type support, or more advanced collection, do you want to collect some performance data about how a protocol is operating, or verify the number of sessions a firewall is running.
Sometimes you can find the source MIB in the documentation or a whitepaper, but sometimes it is very difficult to determine where the needed data is stored. If possible ask a product expert who is familiar with that specific product.
Many times, people want to graph CPU and Memory, but not all devices support the collection of this information, you can only ask NMIS to collect something which the device has the instrumentation for, the MIBs should tell you if it is possible.
For Cisco routers, it is very handy to monitor CPU load, it is an excellent metric for how the device is performing, however on some newer Cisco devices, the processing is distributed and performed in hardware, so the CPU load is still handy but it may not be providing the information you need.
Now you know what you want to collect and monitor, verify that the MIB operates the way the documentation says it does and verify that it works they way you think it does.
Now you know what you want to model, you will need to decide to use the system or systemHealth techniques for having NMIS collect and store the data, you will also want to decide if you want any custom alarms configured.
This page has great information about Modelling MIBS that use Indexes using the systemHealth section.
Main collection is /systemHealth/rrd/hrProcessorLoad
Common-database entry called hrProcessorLoad
Common-heading entry for the /systemHealth/rrd/hrProcessorLoad/graphtype => hrprocload
To create a threshold, statistical data is needed, this is extracted using Common-stats and this is based on the rrd name, so for this hrProcessorLoad collection, the Common-stats entry would be hrProcessorLoad
To compare the data to the threshold, there needs to be a Common-threshold section, this is named after the /systemHealth/rrd/hrProcessorLoad/threshold => arCpuLoad
So that the threshold system can match data from the stats results, we use the item to match the data, so NMIS is going to look for the item in the resulting stats data, in this case the item name is hrProcessorLoad, which matches the print statement: 'PRINT:hrProcessorLoad:AVERAGE:hrProcessorLoad=%1.0f' in the Common-stats section.
### Model-AristaSwich.nmis
%hash = (
'systemHealth' => {
'rrd' => {
'hrProcessorLoad' => {
'graphtype' => 'hrprocload',
'indexed' => 'true',
'threshold' => 'arCpuLoad'
'snmp' => {
'hrProcessorLoad' => {
'oid' => 'hrProcessorLoad',
'option' => 'gauge,0:U'
}
}
}
### Common-database.nmis
'hrProcessorLoad' => '/nodes/$node/health/hrProcessorLoad-$index.rrd',
### Common-heading.nmis
'hrprocload' => 'Processor Load',
### Common-stats.nmis
%hash = (
'stats' => {
'type' => {
'hrProcessorLoad' => [
'DEF:hrProcessorLoad=$database:hrProcessorLoad:AVERAGE',
'PRINT:hrProcessorLoad:AVERAGE:hrProcessorLoad=%1.0f',
]
### Common-threshold.nmis
%hash = (
'threshold' => {
'name' => {
'arCpuLoad' => {
'item' => 'hrProcessorLoad',
'event' => 'Proactive CPU Utilisation',
'select' => {
'default => {
'value' => {
'fatal' => '90',
'critical' => '80',
'major' => '70',
'minor' => '60',
'warning' => '50'
}
}
}
},
|