RTFM.WIKI

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Рецепт блюда из SNMP ======

Лучшая вводная статья про SNMP, OID и MIB. Вовремя её не сохранил, поэтому пришлось доставать из веб архива - http://web.archive.org/web/20150705153434/http://blog.svarog63.ru/index.php?controller=post&action=view&id_post=20

Сегодня немного поговорим об SNMP и его пользе для системного, сетевого, или какого-либо еще ИТ администратора. На самом деле, SNMP для меня долгое время оставался тайной за семью печатями. Несмотря на то, что это простой (Simple NMP) протокол, я весьма долго не мог понять, как же это работает и с чем это вообще едят. Но, рано или поздно, со всем приходится разбираться впервые, и поэтому своим небольшим опытом я хочу здесь поделиться.

Перед началом хочется отметить, что статей по различного рода настройкам SNMP в Интернете великое множество, однако все они обходят различные мелочи, без понимания которых вы не сможете сложить у себя полную картину, а значит – не сможете понять, как работает данный протокол и зачем он нужен. И поэтому, здесь не будет особо много конфигурации, но я постараюсь уделить внимание всем мелочам, которые помогут просто понять схему. Как только вы поймете принцип, конфигурация того или иного устройства сразу же станет второстепенной незначительной задачей.

Итак, SNMP расшифровывается как Simple Network Management Protocol, или Простой Протокол Сетевого Управления. И в названии, на самом деле, заключена почти вся суть протокола, с тем лишь исключением, что в большинстве случаев SNMP используется не для управления, а для наблюдения за сетью и различными устройствами. Причем, устройством может быть практически все, что угодно: маршрутизатор (причем, практически любой, от навороченных монстров Cisco до домашних «мыльниц» D-Link или Zyxel), компьютер, сервер, источник бесперебойного питания и т.д. Собственно говоря, SNMP сегодня поддерживают даже устройства, напрямую не относящиеся к обработке и передаче данных, такие, как кондиционеры, стиральные машины, микроволновые печи и так далее.

Что бы лучше представить схему работы протокола, я воспользуюсь примером от Джереми Чара, сетевого инструктора из CBTNuggets. Есть некое устройство, которое используя специальные цифровые значения (коды, если угодно) может сообщать о своем состоянии. Сообщать кому? Устройству, которое будет эти коды принимать и обрабатывать. Собирать информацию. Под «состоянием» устройства понимается множество вещей. Запутал? Смотрите.

Представим, что есть кофе-машина. Она готовит вам кофе. Но она находится на другом конце офиса, и будет не удобно каждый раз идти через длинный коридор что бы узнать, есть ли в ней кофе, остыл ли он, есть ли ингредиенты для приготовления или нужно добавить, и так далее. Тем более, будет еще неудобнее, если, к примеру, закончилась вода, и что бы вызвать обслуживающий кофе-машину персонал, вам нужно возвращаться к своему столу (через длинный коридор), потому что там, на стикере, приклеенном к вашему монитору, есть памятка – кофе-мастер! И номер телефона.

А теперь представим, что кофе-машина поддерживает SNMP. И что она, используя различные коды, может сообщать некому устройству в сети свои состояния: температуру напитка, количество воды, количество кофе, сливок и так далее. И как только что-либо из этих вещей заканчивается, или приходит в «ненадлежащее» состояние (например, температура кофе упала ниже определенной отметки), кофе-машина либо сама моментально оповещает об этом наблюдающее устройство, либо устройство фиксирует изменения показателей, и сообщает об этом куда надо, в нашем примере – вам, сидящему за своим компьютером, посредством, например, e-mail.

Представили? Теперь, более подробно. У SNMP есть несколько ключевых элементов, назначение которых нужно понимать.

**OID - object identifier.** Идентификатор объекта. Это как раз тот самый цифровой код, который наша кофе-машина передает куда-либо. Подавляющее большинство OID выглядят примерно так: 1.3.6.1.2.1.2.2.1.16.8 или 1.3.6.1.2.1.4.24.4.1.1.0. И практически для каждого объекта в системе существует такой вот уникальный object ID. Причем, важно понимать, что «объект» в данном случае подразумевает под собой массу элементов: это может быть состояние интерфейса, процент загруженности процессора, количество используемой памяти, состояние службы и так далее.

**MIB – management information base.** База управляющей информации. Замечательное название, не правда ли? Из названия не понятно ровным счетом ничего! На самом деле это – описание уникальных идентификаторов, и не более того. Вернемся к нашему примеру, что бы сразу стало яснее.

Ваше устройство слежения (ваш сервер, принимающий SNMP-сообщения) имеет представление о целом ряде OID-ов, которые чаще всего общие для любых схожих устройств. Скажем, тип сетевых интерфейсов на устройстве. Вы можете не знать производителя сетевого оборудования, но при этом успешно выяснить, какие интерфейсы на нем присутствуют. Однако, устройство может содержать в себе сотни и даже тысячи OID-ов, на все случаи жизни, и естественно, что ваш сервер всего этого знать не может (да и не должен, иначе просто для хранения такого объема данных потребуется масса места). И вот для этого нужны MIB-ы.

Предположим, что у кофе-машины что-то случилось, и вы получаете сообщение а-ля: 1.3.6.1.4.1.2.6.7.4.3.1.5.6.8.13=1. И что с этим делать? Это означает, что ваш сервер не знает, как обработать данный код что бы подать вам его в более читабельном виде. Но, вы же не промах! Вы идете на официальный сайт производителя кофе-машины, находите соответствующий раздел по SNMP, и смотрите, что для загрузки доступен MIB. Вы скачиваете его, загружаете на свой сервер наблюдения и теперь сообщение от кофе-машины выглядит уже совсем иначе: waterTankLevelLow=1. И теперь уже более понятно, что кофе-машина сообщает вам, что у нее мало воды! Т.е. MIB – это база данных, где хранится расшифровка для OID-ов.

**Community.** Прямой перевод этого слова – сообщество, но в контексте SNMP это скорее просто пароль. Согласитесь, что кофе-машина и ваш сервер наблюдения должны как то друг друга узнать. Для этого и существует community. Есть два стандартных community – public и private, а так же два их возможных состояния - RO (read only) и RW (read/write). Так как из трех (1,2,3) версий протокола SNMP у двух (1 и 2) плохо с безопасностью, то возьмите себе за правило никогда не использовать стандартные значения community. Ну, или хотя бы, определите, кто может обращаться к данным устройствам (используя, к примеру, список доступа). Третья версия поддерживает аутентификацию по логин/паролю, но она далеко не так распространена, как первые две и вы вполне можете столкнуться с устройством, которое SNMPv3 не умеет вовсе.

Т.е. еще раз – community это значение, которое должно быть одинаковым на наблюдателе и наблюдаемом.

Едем дальше. Теперь, отвлечемся от кофе-машины, и обратимся к реальному оборудованию, что бы можно было показывать примеры. Мы тут все говорили – сервер наблюдения. На самом деле, для простой проверки работы SNMP вам не нужно будет устанавливать отдельный сервер и что-то долго настраивать. Вполне подойдет любая linux-машина.

Есть замечательная утилита, которая называется snmpwalk. К сожалению, большинство авторов статей об SNMP считают, что она у вас присутствует по умолчанию, и поэтому когда ваша командная строка сообщит вам, что не знает подобной команды – не удивляйтесь. Особенно, если вы новичок в Linux, и можете подумать, что у вас неправильный дистрибутив, битая версия и кривое ядро. Нет, все куда проще.

Snmpwalk, как и ряд других «snmp-что-то» команд, входят в состав утилиты Net-SNMP, которой по дефолту в вашем Linux скорее всего нет. Исправить это элементарно – apt-get install snmp snmpd. После этого можно начинать щупать устройства по протоколу SNMP. Попробуем?

Для начала, можете воспользоваться командой snmpstatus. При успешном срабатывании, она вернет вам общие данные об устройстве. Например:

<code>
root@linux:~# snmpstatus -c public -v2c 192.168.100.1

[UDP: [192.168.100.1]:161->[0.0.0.0]]=>[Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.1(3)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Mon 15-Nov-10 22:51 by prod_rel_team] Up: 171 days, 3:50:59.78
Interfaces: 0, Recv/Trans packets: -1110388726/581359510 | IP: -1859574297/65805750
</code>

Snmpstatus – это основная команда. Ключ –c означает не что иное, как community (и в нашем примере, оно стандартное) – public. Дальше идет указание версии протокола SNMP. Они маркируются как v1, v2c и v3 – у нас вторая версия. И последним идет IP-адрес устройства, у которого мы запрашиваем SNMP статус.

Теперь, уделим внимание ситуации, когда ответ вам не приходит. Даете команду, а в ответ получаете Timeout: No Response from 192.168.100.1. Это может означать, что ваш сервер: либо не может достучаться до устройства вовсе (отсутствует пинг – возможно, устройство выключено, либо что-то не так с настройками сети либо у вас, либо на устройстве); либо закрыт 161 UDP порт. SNMP использует два порта UDP – 161 и 162 (о 162 чуть позже), и поэтому данный порт должен быть открыт. Еще два варианта: на устройстве выключена служба SNMP (т.е. устройство работает, но просто игнорирует ваши запросы, т.к. не понимает их), либо указаны разные community. Скажем, вы указали в команде public, а на устройстве community – thermopasta. При таком раскладе вы тоже не получите информации. Поэтому, если нет ответа, все эти моменты нужно проверить. Помните так же, что отсутствие пинга вовсе не означает, что устройство не работает или не слушает 161-й порт. Могут быть просто закрыты ICMP. Ладно, не в ту степь уже немножко.

Ответ пришел. Отлично. Теперь мы знаем, что SNMP работает, и мы можем делать уже более детальные запросы. Здесь нам уже пригодится snmpwalk.

<code>
root@linux:~# snmpwalk -c public -v2c 192.168.100.1 1.3.6.1.2.1.2.2.1.2
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "FastEthernet0"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "FastEthernet1"
iso.3.6.1.2.1.2.2.1.2.3 = STRING: "FastEthernet2"
iso.3.6.1.2.1.2.2.1.2.4 = STRING: "FastEthernet3"
iso.3.6.1.2.1.2.2.1.2.5 = STRING: "FastEthernet4"
iso.3.6.1.2.1.2.2.1.2.6 = STRING: "Null0"
iso.3.6.1.2.1.2.2.1.2.7 = STRING: "Vlan1"
iso.3.6.1.2.1.2.2.1.2.8 = STRING: "Tunnel1"
iso.3.6.1.2.1.2.2.1.2.9 = STRING: "NVI0"
iso.3.6.1.2.1.2.2.1.2.10 = STRING: "Dialer1"
iso.3.6.1.2.1.2.2.1.2.11 = STRING: "Virtual-Access1"
iso.3.6.1.2.1.2.2.1.2.12 = STRING: "Virtual-Access2"
</code>

Структура команды такая же, однако в конце мы указали OID того объекта, который нам нужен. В данном примере мы запросили текстовые идентификатор сетевых интерфейсов. Как видите, код каждого интерфейса отличается лишь последним значением. Выберем интерфейс, возьмем к примеру, Dialer1. Предположим, следующим шагом мы хотим узнать количество пакетов, попадающих на этот интерфейс (т.е. download).

Сначала смотрим нужный нам OID. Для входящих пакетов он будет называться ifInOctets и код его будет 1.3.6.1.2.1.2.2.1.10. Теперь прикрутим это к нашей команде, только в конце OID-а еще подставим 10 – укажем, что нам нужен именно Dialer1:

<code>
root@linux:~# snmpwalk -c public -v2c 192.168.100.1 1.3.6.1.2.1.2.2.1.10.10
iso.3.6.1.2.1.2.2.1.10.10 = Counter32: 2128584759
</code>

Работает! «И что мне делать с этим трехэтажным числом?» можете спросить вы. А вот здесь вам уже пригодится какая-нибудь система мониторинга, которая будет собирать информацию и превращать ее в удобный для вас вид. Вот например:

//Здесь должна быть картинка, но web.archive её не сохранил//

Теперь пару слов о портах и директивах SNMP. Когда система мониторинга собирает данные с устройства, то важно понимать, что она именно «собирает» данные. Т.е. это не наблюдаемое устройство сообщает что-либо наблюдателю, а сам наблюдатель (сервер) периодически спрашивает устройство о состоянии данных и записывает у себя их изменения. Однако, есть ситуации, когда сервер запросто может проспать какое-либо важное событие, произошедшее на наблюдаемом устройстве. Скажем, сервер опрашивает устройство каждые 30 секунд. И в этот промежуток происходит скачок напряжения, которые вырубает пару предохранителей (пример с потолка). Но, есть еще два, и устройство работает. И когда сервер спрашивает вновь – ему отвечают, что все хорошо. А предположим, об общем состоянии устройства сервер спрашивает не раз в 30 секунд, а раз в час! И значит, о том, что два предохранителя вышли из строя, станет известно только через час.

Пример не очень правдоподобный, но суть вы поняли я надеюсь. Так вот, наблюдаемое устройство может само информировать наблюдателя о каких-либо событиях. Это называется snmp-trap, и эта «ловушка» использует 162-й порт UDP. Т.е., запрос от сервера к устройству идет по 161 порту, а наоборот – по 162-му.

Так же стоит упомянуть о двух основных директивах SNMP – GET и SET. GET – это запрос на получение данных. Т.е., когда мы с вами делали команды snmpwalk и snmpstatus, мы на самом деле отправляли устройству get-запросы. SET позволяет изменять определенные значения. Для этого должна быть сконфигурирована read/write community. После этого, вы можете послать устройству команду с определенным OID-ом. Что-нибудь вроде:

<code>root@linux:~# snmpset -v2c -c ‘thermopasta’ 192.168.1.100 .1.3.6.1.4.1.9.2.9.9.0</code>

Данная команда например, позволит вам удаленно, даже не подключаясь, перезагрузить устройство.

Вот в целом и все. Дальше, для обработки информации, полученной по SNMP можно использовать любую удобную вам утилиту: Cacti, MRTG, PRTG, Zabbix. Последний – вообще очень мощный инструмент, и сбор данных по SNMP это лишь малая доля того, что дает данный open-source продукт.

Как всегда, несколько полезных ссылок:

  * https://ru.wikipedia.org/wiki/SNMP
  * https://www.zabbix.com/documentation/1.8/ru/manual/advanced_snmp/special_mibs
  * http://www.opennet.ru/base/cisco/cisco_snmp.txt.html