Хорошие доки про SNMP утилиты Linux
- http://net-snmp.sourceforge.net/ – source
- https://www.opennet.ru/docs/RUS/net-snmp/ – перевод
установка
UBUNTU
sudo apt-get install snmp – snmpget, snmpwalk, snmpset, snmptrap/snmpinform и еще куча snmp утилит относятся к пакету snmp.
sudo apt-get install snmp-mibs-downloader – ставим если нужно, чтобы OID разрешались в текстовое описание. Я добавлял только ради IF-MIB.
sudo download-mibs – обновляем текущие MIB скриптом download-mibs. Можно периодически запускать для актуализации.
CentOS
[root@localhost ~]# rpm -qf /usr/bin/snmpget net-snmp-utils-5.7.2-24.el7_2.1.x86_64 [root@localhost ~]# rpm -ql net-snmp-utils | grep bin /usr/bin/encode_keychange /usr/bin/snmpbulkget /usr/bin/snmpbulkwalk /usr/bin/snmpdelta /usr/bin/snmpdf /usr/bin/snmpget /usr/bin/snmpgetnext /usr/bin/snmpinform /usr/bin/snmpnetstat /usr/bin/snmpset /usr/bin/snmpstatus /usr/bin/snmptable /usr/bin/snmptest /usr/bin/snmptranslate /usr/bin/snmptrap /usr/bin/snmpusm /usr/bin/snmpvacm /usr/bin/snmpwalk
oid/запросы
sysObjectID.0 – глобальный неизменяемый параметр с помощью которого индифицируется устройство по snmp.Он должен быть уникален для устройств одной модели, но некоторые вендоры иногда умудряются его через менять для разных прошивок 🙂
~$ snmpwalk -v2c -c public 10.113.84.130 SNMPv2-MIB::sysObjectID.0
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.935.1.1.1
~$ snmpwalk -v2c -c public 10.10.104.254 SNMPv2-MIB::sysObjectID.0
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.935
sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The vendor's authoritative identification of the
network management subsystem contained in the
entity. This value is allocated within the SMI
enterprises subtree (1.3.6.1.4.1) and provides an
easy and unambiguous means for determining `what
kind of box' is being managed. For example, if
vendor `Flintstones, Inc.' was assigned the
subtree 1.3.6.1.4.1.4242, it could assign the
identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
Router'."
::= { system 2 }
Если WALK показывает результат, а GET говорит No Such Instance – значит OID не полный. Даже если строка в результате WALK одна.
$ snmpwalk -v 2c -c public 172.2.1.233 .1.3.6.1.4.1.89.2.13.1.1.2 SNMPv2-SMI::enterprises.89.2.13.1.1.2.1 = INTEGER: 1 $ snmpget -v 2c -c public 172.2.1.233 .1.3.6.1.4.1.89.2.13.1.1.2 SNMPv2-SMI::enterprises.89.2.13.1.1.2 = No Such Instance currently exists at this OID $ snmpget -v 2c -c public 172.2.1.233 .1.3.6.1.4.1.89.2.13.1.1.2.1 SNMPv2-SMI::enterprises.89.2.13.1.1.2.1 = INTEGER: 1
SNMPv3
snmpwalk -v3 -l authPriv -u <user> -a MD5 -A <pass> -x DES -X <des_pass> <ip> snmpwalk -v3 -l authPriv -u admin -a MD5 -A lsurpassH1fv -x DES -X Su243K1l 10.10.25.3
Snmptraps & Informs использование с примерами
snmptrapd – стандартная Linux утилита для сохранения трапов. Она используется даже известными NMS. Установка описана тут.
snmptrap – утилита для отправки трапов.
snmptrap -v 1 -c public 192.168.1.222 1.2.3.4.5.6 192.192.192.192 6 99 55 1.11.12.13.14.15 s teststring snmptrap -v 2c -c public 192.168.1.222 '1398650' .1.3.6.1.6.3.1.1.5.4 ifIndex i 1046 ifAdminStatus i 1 ifOperStatus i 1 snmptrap -v 2c -c public 192.168.1.222 .1.3.6.1.6.3.1.1.5.3 .1.3.6.1.6.3.1.1.5.3 sysUpTime timestamp 1398650 ifIndex i 1046 ifAdminStatus i 1 ifOperStatus i 1
[root@localhost ~]# tcpdump host 192.168.1.222 12:10:50.228838 IP 192.168.1.222.60957 > 192.168.1.22.snmptrap: Inform(102) system.sysUpTime.0=652283 S:1.1.4.1.0=S:1.1.5.3 interfaces.ifTable.ifEntry.ifIndex=1046 interfaces.ifTable.ifEntry.ifAdminStatus=2 interfaces.ifTable.ifEntry.ifOperStatus=2 12:11:05.221914 IP 192.168.1.222.60957 > 192.168.1.22.snmptrap: Inform(102) system.sysUpTime.0=652283 S:1.1.4.1.0=S:1.1.5.3 interfaces.ifTable.ifEntry.ifIndex=1046 interfaces.ifTable.ifEntry.ifAdminStatus=2 interfaces.ifTable.ifEntry.ifOperStatus=2 12:11:20.239959 IP 192.168.1.222.60957 > 192.168.1.22.snmptrap: Inform(102) system.sysUpTime.0=652283 S:1.1.4.1.0=S:1.1.5.3 interfaces.ifTable.ifEntry.ifIndex=1046 interfaces.ifTable.ifEntry.ifAdminStatus=2 interfaces.ifTable.ifEntry.ifOperStatus=2 12:11:35.269971 IP 192.168.1.222.60957 > 192.168.1.22.snmptrap: Inform(102) system.sysUpTime.0=652283 S:1.1.4.1.0=S:1.1.5.3 interfaces.ifTable.ifEntry.ifIndex=1046 interfaces.ifTable.ifEntry.ifAdminStatus=2 interfaces.ifTable.ifEntry.ifOperStatus=2 Из Wireshark (другое устройство): 6123 153.413740000 192.168.1.222 192.168.1.2 SNMP 161 informRequest 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0 1.3.6.1.2.1.2.2.1.1.28 1.3.6.1.2.1.2.2.1.7.28 1.3.6.1.2.1.2.2.1.8.28 6156 156.399012000 192.168.1.222 192.168.1.2 SNMP 161 informRequest 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0 1.3.6.1.2.1.2.2.1.1.28 1.3.6.1.2.1.2.2.1.7.28 1.3.6.1.2.1.2.2.1.8.28 6165 159.398664000 192.168.1.222 192.168.1.2 SNMP 161 informRequest 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0 1.3.6.1.2.1.2.2.1.1.28 1.3.6.1.2.1.2.2.1.7.28 1.3.6.1.2.1.2.2.1.8.28 6212 162.398451000 192.168.1.222 192.168.1.2 SNMP 161 informRequest 1.3.6.1.2.1.1.3.0 1.3.6.1.6.3.1.1.4.1.0 1.3.6.1.2.1.2.2.1.1.28 1.3.6.1.2.1.2.2.1.7.28 1.3.6.1.2.1.2.2.1.8.28
32-битные счетчики sysUpTime
C 497 дня (4-миллиарда timeticks) обновляется значение Uptime при опросе sysUpTime (DISMAN-EVENT-MIB::sysUpTimeInstance или .1.3.6.1.6.3.10.2.1.3). Такое поведение аналогично на всех устройствах, включая Cisco. 64-битного счетчика timeticks (1/100 секунды), по аналогии с Counter64, пока не существует. Для Cisco, Alcatel и многих других устройств (даже ZTE, но не D-Link) есть альтернатива – опрашивать количество секунд со старта (не epoch seconds) (SNMP-FRAMEWORK-MIB::snmpEngineTime или .1.3.6.1.2.1.1.3.0) и конвертировать во время самостоятельно скриптом.
$ snmpwalk -v 2c -Cc -c xxx 11.22.33.44 .1.3.6.1.6.3.10.2.1.3 SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 48842811 seconds $ snmpwalk -v 2c -Cc -c xxx 11.22.33.44 .1.3.6.1.2.1.1.3.0 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (589314318) 68 days, 4:59:03.18
В таком случае переполнение счетчика >4млрд произойдет только через 135 лет. Получается, точность немного хуже, но кейсов необходимости точности в 1/100 секунды (10 мс), имхо, не много. В целом Cisco рекомендует опрашивать и то, и то, а потом добивать в значение seconds значение последних двух цифр из timeticks.
Currently, IOS based devices rely on RFC1213's sysUpTime which is a 32 bit counter in 1/100 second and wraps around every 496 days. This makes it difficult to tell how long the device has been up if the counter has rolled over. Workarounds: The uptime value in the show version output is accurate even after 496 days. Routers running 12.0(3)T or higher can also use the snmpEngineTime object from the SNMP-FRAMEWORK-MIB. This object keeps track of seconds since the SNMP engine started. While not as granular as sysUpTime, it will not roll over for 135 years. By polling both sysUpTime and snmpEngineTime together, then taking the full value of sysUpTime and combining it with the additional two digits from snmpEngineTime, one can gain additional granularity. Note, if sysUpTime is polled right during roll-over, time will change +/- one year."
Для устройств без счетчика в секундах (привет, D-Link!) нужно придумывать костыли, например, выгружать дату загрузки через заход по telnet/ssh и чтобы получить аптайм вычитать из текущей даты выгруженную.
fun_uptime_days_exp ()
{
#static date=`date -d "24 Oct 2017" "+%s"`
date=$(exp_get_bootdate $1 | grep "Boot Time" | awk '{print $5,$6,$7}')
date=`date -d "$date" "+%s"`
curdate=`date "+%s"`
diff=$(($curdate-$date))
days=$(($diff/(60*60*24)))
echo "$days"
}