Протокол SNMP. Простой протокол управления сетью Состояние snmp разрешено что значит
SNMP работает на прикладном уровне TCP/IP (седьмой уровень модели OSI). Агент SNMP получает запросы по UDP-порту 161. Менеджер может посылать запросы с любого доступного порта источника на порт агента. Ответ агента будет отправлен назад на порт источника на менеджере. Менеджер получает уведомления (Traps и InformRequests) по порту 162. Агент может генерировать уведомления с любого доступного порта. При использовании TLS или DTLS запросы получаются по порту 10161, а ловушки отправляются на порт 10162.
В SNMPv1 указано пять основных протокольных единиц обмена (protocol data units - PDU). Еще две PDU, GetBulkRequest и InformRequest, были введены в SNMPv2 и перенесены в SNMPv3.
Все PDU протокола SNMP построены следующим образом:
Ниже перечислены семь протокольных единиц обмена SNMP:
GetRequest
Запрос от менеджера к объекту для получения значения переменной или списка переменных. Требуемые переменные указываются в поле variable bindings (раздел поля values при этом не используется). Получение значений указанной переменной должно быть выполнено агентом как Атомарная операция . Менеджеру будет возвращён Response (ответ) с текущими значениями.
SetRequest
Запрос от менеджера к объекту для изменения переменной или списка переменных. Связанные переменные указываются в теле запроса. Изменения всех указанных переменных должны быть выполнены агентом как атомарная операция. Менеджеру будет возвращён Response с (текущими) новыми значениями переменных.
GetNextRequest
Запрос от менеджера к объекту для обнаружения доступных переменных и их значений. Менеджеру будет возвращён Response со связанными переменными для переменной, которая является следующей в базе MIB в лексиграфическом порядке. Обход всей базы MIB агента может быть произведён итерационным использованием GetNextRequest, начиная с OID 0. Строки таблицы могут быть прочтены, если указать в запросе OID-ы колонок в связанных переменных.
GetBulkRequest
Улучшенная версия GetNextRequest. Запрос от менеджера к объекту для многочисленных итераций GetNextRequest. Менеджеру будет возвращён Response с несколькими связанными переменными, обойдёнными начиная со связанной переменной (переменных) в запросе. Специфичные для PDU поля non-repeaters и max-repetitions используются для контроля за поведением ответа. GetBulkRequest был введён в SNMPv2.
Response
Возвращает связанные переменные и значения от агента менеджеру для GetRequest, SetRequest, GetNextRequest, GetBulkRequest и InformRequest. Уведомления об ошибках обеспечиваются полями статуса ошибки и индекса ошибки.
Эта единица используется как ответ и на Get-, и на Set-запросы, в SNMPv1 называется GetResponse .
Trap
Асинхронное уведомление от агента - менеджеру. Включает в себя текущее значение sysUpTime, OID, определяющий тип trap (ловушки), и необязательные связанные переменные. Адресация получателя для ловушек определяется с помощью переменных trap-конфигурации в базе MIB. Формат trap-сообщения был изменён в SNMPv2 и PDU переименовали в SNMPv2-Trap.
InformRequest
Асинхронное уведомление от менеджера менеджеру или от агента менеджеру. Уведомления от менеджера менеджеру были возможны уже в SNMPv1 (с помощью Trap), но SNMP обычно работает на протоколе UDP, в котором доставка сообщений не гарантирована, и не сообщается о потерянных пакетах. InformRequest исправляет это обратным отправлением подтверждения о получении. Получатель отвечает Response-ом, повторяющим всю информацию из InformRequest. Этот PDU был введён в SNMPv2.
Разработка и использование
Версия 1
SNMP, версия 1 (SNMPv1) - изначальная реализация протокола SNMP. SNMPv1 работает с такими протоколами, как UDP, IP, CLNS, DDP и IPX. SNMPv1 широко используется и де-факто является протоколом сетевого управления в Интернет-сообществе.
Первые RFC для SNMP, сейчас известные как SNMPv1, появились в 1988г:
- RFC 1065
- RFC 1066
- RFC 1067
Эти протоколы были пересмотрены в следующих RFC:
- RFC 1155 - Структура и идентификация управляющей информации в сетях на основе стека протоколов TCP/IP
- RFC 1156 - База управляющей информации для сетевого управления в сетях на основе стека протоколов TCP/IP
- RFC 1157 - Простой протокол сетевого управления
- Настройка SNMP на Cisco as53xx
Enter configuration commands, one per line. End with CNTL/Z.
Список № 1: Разрешить доступ из сети 10.26.95.224/27 или 255.255.255.224
as5350(config)#access-list 1 permit 10.26.95.224 0.0.0.31
Список № 2: Разрешить доступ с IP 10.26.95.254 и 10.26.95.251
as5350(config)#access-list 2 permit host 10.26.95.254
as5350(config)#access-list 2 permit host 10.26.95.251
Настройка snmp-server для чтения и записи со строкой сообщества xxas5300xx. SNMP-доступ разрешён только для access-list 2 (для 2-х IP, для остальных IP неявно запрещён)
as5350(config)#snmp-server community xxas5300xx rw 2
Разрешаем reload циски по SNMP.
as5350(config)#snmp-server system-shutdown
Стратегия SNMP заключается в том, что мониторинг состояния сети с любым значимым уровнем детализации выполняется главным образом путем опроса из центра мониторинга. Ограниченное число незапрашиваемых сообщений (trap - прерывание) обеспечивает синхронизацию и активизирует опросы. Ограничение числа незапрашиваемых сообщений согласуется с задачами обеспечения простоты и минимизации трафика, создаваемого системой сетевого управления.
Из этих цитат, вполне понятно, что запросы с типами TRAP и INFORM это не наиболее часто используемая часть SNMP. Статью для начинающих было бы более уместно иллюстрировать примерами использования гораздо более ходовых GET-запросов.
Вообще я настоятельно рекомендую ознакомиться со всеми RFC, связанными с SNMP перед началом работы. Некоторые аспекты SNMP не очевидны и имеет смысл получить о них представление из первоисточника. Начать ознакомление с материалом можно с wiki .
Первые шаги
Помимо обязательного ознакомления с документацией, важно понимать, для чего мы все это делаем. В практике телекома, наиболее часто встречаются следующие задачи:- Опрос оборудования по SNMP (аккаунтинг, мониторинг)
- Управление оборудованием по SNMP (активация)
Задача SNMP-мониторинга выделяется на общем фоне требованием того, что опрашиваемого оборудования много или очень много. Предположим, что именно эту задачу нам и предстоит решать.
Начнем писать код. В тестовом примере мы обратимся по SNMP к собственному хосту и прочитаем значение переменной, заданной OID-ом 1.3.6.1.2.1.1.3.0 и содержащей значение uptime-а хоста:
Одиночный GET-запрос
package com.acme.ae.tests.snmp;
import java.io.IOException;
import org.snmp4j.CommunityTarget;
import org.snmp4j.PDU;
import org.snmp4j.Snmp;
import org.snmp4j.Target;
import org.snmp4j.TransportMapping;
import org.snmp4j.event.ResponseEvent;
import org.snmp4j.mp.SnmpConstants;
import org.snmp4j.smi.Address;
import org.snmp4j.smi.GenericAddress;
import org.snmp4j.smi.OID;
import org.snmp4j.smi.OctetString;
import org.snmp4j.smi.VariableBinding;
import org.snmp4j.transport.DefaultUdpTransportMapping;
public class Test {
private final static String SNMP_COMMUNITY = "public";
private final static int SNMP_RETRIES = 3;
private final static long SNMP_TIMEOUT = 1000L;
private Snmp snmp = null;
private TransportMapping transport = null;
private void test() throws IOException {
Target t = getTarget("udp:127.0.0.1/161");
String r = send(t, "1.3.6.1.2.1.1.3.0");
System.out.println(r);
}
private String send(Target target, String oid) throws IOException {
PDU pdu = new PDU();
pdu.add(new VariableBinding(new OID(oid)));
pdu.setType(PDU.GET);
ResponseEvent event = snmp.send(pdu, target, null);
if (event != null) {
return event.getResponse().get(0).toString();
} else {
return "Timeout exceeded";
}
}
private Target getTarget(String address) {
Address targetAddress = GenericAddress.parse(address);
CommunityTarget target = new CommunityTarget();
target.setCommunity(new OctetString(SNMP_COMMUNITY));
target.setAddress(targetAddress);
target.setRetries(SNMP_RETRIES);
target.setTimeout(SNMP_TIMEOUT);
target.setVersion(SnmpConstants.version1);
return target;
}
private void start() throws IOException {
transport = new DefaultUdpTransportMapping();
snmp = new Snmp(transport);
transport.listen();
}
private void stop() throws IOException {
try {
if (transport != null) {
transport.close();
transport = null;
}
} finally {
if (snmp != null) {
snmp.close();
snmp = null;
}
}
}
public static void main(String args) {
Test t = new Test();
try {
try {
t.start();
t.test();
} finally {
t.stop();
}
} catch (IOException e) {
System.out.println(e.toString());
}
}
}
Предварительно убедившись, что служба SNMP на нашем хосте работает и запустив код на выполнение, получим искомое значение uptime-а (времени безостановочной работы хоста с момента последней загрузки):
1.3.6.1.2.1.1.3.0 = 2:28:55.06
Используя это значение, можно осуществлять мониторинг. Если мы обнаруживаем, что значением уменьшилось - значит хост успел перезагрузиться с момента очередного опроса. Если хост не ответил в течение заданного таймаута (после нескольких автоматически сделанных попыток) это, скорее всего, означает, что хост не работает. Все просто?
Подсчитали - прослезились
Не совсем. Вспоминаем о том, что нам предстоит выполнять много запросов. Давайте промеряем, сколько запросов мы можем выполнить в секунду? Внесем небольшое исправление в код:Private void test() throws IOException {
Target t = getTarget("udp:127.0.0.1/161");
Long timestamp = System.currentTimeMillis();
for (int i = 0; i < 1000; i++) {
send(t, "1.3.6.1.2.1.1.3.0");
}
System.out.println(1000000L /(System.currentTimeMillis() - timestamp));
}
И запустим его на выполнение:
2463
Почти две с половиной тысячи запросов в секунду! Неплохо?
Не будем торопиться. Мы отправляем запросы на Loopback интерфейс, а он работает несколько быстрее локальной сети. Посмотрим, сколько запросов в секунду мы успеем выполнить к другому хосту в нашей сети:
182
Не дотягиваем даже до двухсот. Вообще говоря, возможно, этого будет достаточно. Все зависит от задачи. Но мы проводили измерения при условии, что опрашиваемый хост доступен. Что будет если хост не ответит?
Будет несколько попыток доступа (в нашем коде мы задали 3) разделенных таймаутом (1000 мсек). Это означает, что за секунду мы не успеем выполнить ни одного запроса. Поскольку не отвечающий хост является не такой уж большой редкостью, это может стать большой проблемой в реальном проекте.
Идем на рекорд
Что с этим можно сделать? Если бы мы имели дело с каким либо синхронным протоколом (например telnet), особого выбора бы у нас не было. Для того, чтобы увеличить производительность, нам пришлось бы одновременно выполнять много потоков. Но SNMP асинхронен по своей природе! Не надо насильственно втискивать его в синхронные рамки.Как перейти к асинхронному варианту? В нашем случае, довольно просто:
Асинхронные запросы
package com.acme.ae.tests.snmp;
import java.io.IOException;
import org.snmp4j.CommunityTarget;
import org.snmp4j.PDU;
import org.snmp4j.Snmp;
import org.snmp4j.Target;
import org.snmp4j.TransportMapping;
import org.snmp4j.event.ResponseEvent;
import org.snmp4j.event.ResponseListener;
import org.snmp4j.mp.SnmpConstants;
import org.snmp4j.smi.Address;
import org.snmp4j.smi.GenericAddress;
import org.snmp4j.smi.OID;
import org.snmp4j.smi.OctetString;
import org.snmp4j.smi.VariableBinding;
import org.snmp4j.transport.DefaultUdpTransportMapping;
public class Test implements ResponseListener {
private final static String SNMP_COMMUNITY = "public";
private final static int SNMP_RETRIES = 3;
private final static long SNMP_TIMEOUT = 1000L;
private Snmp snmp = null;
private TransportMapping transport = null;
public void onResponse(ResponseEvent event) {
PDU response = event.getResponse();
if (response != null) {
System.out.println(response.get(0).toString());
return;
}
}
private void test() throws IOException {
Target t = getTarget("udp:192.168.131.253/161");
Long timestamp = System.currentTimeMillis();
for (int i = 0; i < 1000; i++) {
send(t, "1.3.6.1.2.1.1.3.0");
}
System.out.println(1000000L /(System.currentTimeMillis() - timestamp));
}
private void send(Target target, String oid) throws IOException {
PDU pdu = new PDU();
pdu.add(new VariableBinding(new OID(oid)));
pdu.setType(PDU.GET);
snmp.send(pdu, target, null, this);
}
private Target getTarget(String address) {
Address targetAddress = GenericAddress.parse(address);
CommunityTarget target = new CommunityTarget();
target.setCommunity(new OctetString(SNMP_COMMUNITY));
target.setAddress(targetAddress);
target.setRetries(SNMP_RETRIES);
target.setTimeout(SNMP_TIMEOUT);
target.setVersion(SnmpConstants.version1);
return target;
}
private void start() throws IOException {
transport = new DefaultUdpTransportMapping();
snmp = new Snmp(transport);
transport.listen();
}
private void stop() throws IOException {
try {
if (transport != null) {
transport.close();
transport = null;
}
} finally {
if (snmp != null) {
snmp.close();
snmp = null;
}
}
}
public static void main(String args) {
Test t = new Test();
try {
try {
t.start();
t.test();
} finally {
t.stop();
}
} catch (IOException e) {
System.out.println(e.toString());
}
}
}
7142
Запросы все равно что проваливаются в бездонную бочку! Разумеется, ответы будут приходить с задержкой, но приходить они будут тоже довольно быстро. Но как мы узнаем, что хост не ответил?
Очень просто, по истечении заданного количества попыток и таймаутов, SNMP4J вернет нам event, response в котором будет равен null:
Исправленный вариант
Проанализируем результат выполнения:
9174
283
Мы успеваем сформировать 9174 запросов в секунду, а опрашиваемое устройство успевает обрабатывать запросы со скоростью 283 запроса в секунду. На большую часть запросов оно ответить не успевает (соответственно в логе остаются сообщения «Timeout exceeded»). Разумеется, это не будет проблемой когда мы начнем опрашивать большое количество устройств с разумным интервалом между запросами.
Идем далее
Мы научились получать по SNMP значения скалярных переменных. Но, помимо них, в SNMP есть еще и таблицы (например таблица интерфейсов на устройстве). Как они устроены? Посмотрим MIB-browser:
В OID mgmt.interfaces (1.3.6.1.2.1.2) мы видим скалярную переменную ifNumber (1.3.6.1.2.1.2.1), содержащую количество интерфейсов в таблице, а также набор столбцов. Каждый из столбцов имеет собственный OID. Например столбец содержащий числовой индекс ifIndex интерфейса имеет OID = 1.3.6.1.2.1.2.2.1.1.
Для того, чтобы получить значение этой переменной, необходимо добавить к OID-у индекс интерфейса (например для интерфейса с индексом 123 OID = 1.3.6.1.2.1.2.2.1.1.123). Но как нам получить индексы интерфейсов? Они совсем не обязательно идут по порядку! Например, на моей машине, таблица интерфейсов выглядит так:
Именно для этой цели был придуман запрос GETNEXT. Передавая в этот запрос префикс OID-а, мы получаем OID и значение следующей (в лексикографическом порядке) за этим префиксом переменной. Это означает, что передав префиксы OID-ов столбцов таблицы, мы получим OID-ы и значения первой ее строки. Чтобы получить следующую строку, надо выполнить еще один запрос, передав в него OID-ы, полученные предыдущим запросом. И так до тех пор, пока мы не просмотрим всю таблицу.
Разумеется, с учетом всего сказанного выше, нам следует минимизировать количество запросов (это также необходимо с учетом того, что в рамках одного запроса, согласно RFC, предоставляются консистентные данные, если мы запросим индекс и имя интерфейса двумя последовательными запросами, они возможно не будут соответствовать друг-другу). В рамках 1-ой версии SNMP, мы должны читать всю строку таблицы одним запросом.
Следует заметить, что довольно удобно то, что OID-ы скалярных переменных также представляют собой префиксы. Например, для переменной sysUpTime OID, на самом деле равен 1.3.6.1.2.1.1.3. Мы можем передать его в GETNEXT запрос и получить OID = 1.3.6.1.2.1.1.3.0 вместе с соответствующим значением. Это дает возможность запрашивать скалярные значения вместе с значениями столбцов таблиц, в одном запросе.
Просмотр первой строки таблицы
package com.acme.ae.tests.snmp;
import java.io.IOException;
import java.util.HashSet;
import java.util.Set;
import org.snmp4j.CommunityTarget;
import org.snmp4j.PDU;
import org.snmp4j.Snmp;
import org.snmp4j.Target;
import org.snmp4j.TransportMapping;
import org.snmp4j.event.ResponseEvent;
import org.snmp4j.event.ResponseListener;
import org.snmp4j.mp.SnmpConstants;
import org.snmp4j.smi.Address;
import org.snmp4j.smi.GenericAddress;
import org.snmp4j.smi.Integer32;
import org.snmp4j.smi.OID;
import org.snmp4j.smi.OctetString;
import org.snmp4j.smi.VariableBinding;
import org.snmp4j.transport.DefaultUdpTransportMapping;
public class Test implements ResponseListener {
private final static String SNMP_COMMUNITY = "public";
private final static int SNMP_RETRIES = 3;
private final static long SNMP_TIMEOUT = 1000L;
private Snmp snmp = null;
private TransportMapping transport = null;
private Set
Запустив этот код на выполнение, мы получим следующий response:
RESPONSE]
Мы получили значение uptime-а, индекс первого интерфейса и его имя, закодированное строкой октетов в шестнадцатеричном представлении. Чтобы получить следующие строки, мы должны выполнять последовательные запросы, передавая ранее полученные OID-ы.
С учетом необходимости поддержки возможности асинхронной обработки, это может стать нетривиальной (но вполне решаемой) задачей. К счастью, во 2-ой версии SNMP были добавлены bulk-запросы, автоматизирующие получение табличных данных и минимизирующие количество отсылаемых при этом запросов. Внесем необходимые изменения в код:
BULK-запрос
package com.acme.ae.tests.snmp;
import java.io.IOException;
import java.util.HashSet;
import java.util.Set;
import org.snmp4j.CommunityTarget;
import org.snmp4j.PDU;
import org.snmp4j.Snmp;
import org.snmp4j.Target;
import org.snmp4j.TransportMapping;
import org.snmp4j.event.ResponseEvent;
import org.snmp4j.event.ResponseListener;
import org.snmp4j.mp.SnmpConstants;
import org.snmp4j.smi.Address;
import org.snmp4j.smi.GenericAddress;
import org.snmp4j.smi.Integer32;
import org.snmp4j.smi.OID;
import org.snmp4j.smi.OctetString;
import org.snmp4j.smi.VariableBinding;
import org.snmp4j.transport.DefaultUdpTransportMapping;
public class Test implements ResponseListener {
private final static String SNMP_COMMUNITY = "public";
private final static int SNMP_RETRIES = 3;
private final static long SNMP_TIMEOUT = 1000L;
private final static int BULK_SIZE = 50;
private Snmp snmp = null;
private TransportMapping transport = null;
private Set
Выполнив этот запрос, мы получаем все строки таблицы одним запросом:
Много данных
RESPONSE]
Разумеется, если таблица содержит более затребованных 50-ти строк, вновь (как и для 1-ой версии SNMP) потребуется формировать запросы для получения последующих строк, передавая в них OID-ыполученные для последней строки.
О чем я не рассказал?
В этой статье я не рассказал о многом. Я не рассказал о том, как изменять значения некоторых (не всех) переменных SET-запросами. Я не рассказал о том, что такое TRAP-ы и для чего они нужны. Я ни сказал ни слова о том, как разрабатывать SNMP-агенты. И я ни одним словом не обмолвился о 3-ей версии SNMP и привнесенных ей изменениях.Но даже того о чем я сказал вполне достаточно, чтобы понять, что SNMP - это не просто.
SNMP - это протокол прикладного уровня, разработанный для стека TCP/IP, хотя имеются его реализации и для других стеков, например IPX/SPX. Протокол SNMP используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в базе данных управляющей информации MIB (Management Information Base). Простота SNMP во многом определяется простотой MIB SNMP, особенно их первых версий MIB I и MIB II. Кроме того, сам протокол SNMP также весьма несложен.
Агент в протоколе SNMP - это обрабатывающий элемент, который обеспечивает менеджерам, размещенным на управляющих станциях сети, доступ к значениям переменных MIB и тем самым дает им возможность реализовывать функции по управлению и наблюдению за устройством.
Основные операции по управлению вынесены в менеджер, а агент SNMP выполняет чаще всего пассивную роль, передавая в менеджер по его запросу значения накопленных статистических переменных. При этом устройство работает с минимальными издержками на поддержание управляющего протокола. Оно использует почти всю свою вычислительную мощность для выполнения своих основных функций маршрутизатора, моста или концентратора, а агент занимается сбором статистики и значений переменных состояния устройства и передачей их менеджеру системы управления.
SNMP - это протокол типа «запрос-ответ» , то есть на каждый запрос, поступивший от менеджера, агент должен передать ответ. Особенностью протокола является его чрезвычайная простота - он включает в себя всего несколько команд.
Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.
Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.
С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.
Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие - отключить порт, приписать порт определенной VLAN и т. п. Команда Set пригодна также для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.
Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.
Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько значений переменных за один запрос.
Уже немало написано о том, что в названии Simple Network Management Protocol слово Simple можно смело писать в кавычках. Протокол SNMP является достаточно простым с точки зрения создания SNMP-агентов, однако на стороне управляющего ПО (SNMP manager) грамотная обработка сложных по структуре данных обычно является нетривиальной задачей.
Мы попытались упростить процесс настройки сбора данных и событий SNMP и позволить пользователям во время этого процесса:
- Никогда не заглядывать внутрь MIB-файлов
- Не знать, что такое OID-ы и никогда не оперировать с ними
- Не пользоваться отдельной SNMP-утилитой для предварительного просмотра данных во время настройки
Шаг 1: добавляем MIB-файлы
Прежде всего необходимо разобраться с MIB-файлами. Описание логики связей между элементами данных и их синтаксиса было в SNMP реализовано при помощи этих файлов с целью уменьшения нагрузки на сеть и упрощения реализации агентов. Пользователи, однако, далеко не всегда хотят разбираться с их внутреннем устройстве.Модуль SNMP нашей системы AggreGate Network Manager при старте загружает все MIB-файлы, находящиеся в специальной папке сервера, после чего позволяет добавлять новые при помощи простого диалога:
Во время загрузки файлов происходит их автоматическая компиляция. Встроенный редактор MIB-ов с подсветкой синтаксиса имеется лишь на случай появления MIBов, не соответствующих спецификации. Пользоваться им нужно крайне редко.
Редактор MIB-ов
На этом работа с MIB-файлами заканчивается, дальше их названия используются только для логической группировки уже собранных данных. При необходимости, загруженные файлы можно посмотреть и поискать в таблице MIBов, но при обычной работе это также не требуется.
Таблица MIB-ов
Шаг 2: подключаем SNMP-устройство
В случае построения классической системы мониторинга этот шаг обычно не требуется, так как все устройства добавляются в систему автоматически во время периодического обнаружения устройств (network discovery). Тем не менее, во время добавления обнаруженных сканированием сети устройств выполняются примерно те же шаги:
Шаг 3: изучаем снимок устройства
После завершения этапа подключения устройства системе требуется от нескольких секунд до нескольких минут на завершение опроса устройства в рамках выбранных MIB-ов. Когда пиктограмма устройства становится зеленой, можно открывать и изучать так называемый «снимок устройства»:
В этом снимке сосредоточена практически вся суть нашего подхода к работе с данными SNMP. Прежде всего, он всегда содержит «под рукой» все реальные данные устройства. При этом все данные считываются только один раз, последующий опрос идет только по важным метрикам. Полное перечитывание снимка устройства производится раз в сутки, для снижения нагрузки на сеть его можно вообще отключить. Снимок устройства опционально сохраняется в БД при перезапуске системы мониторинга.
Обычно не требуется прибегать к помощи каких-либо внешних утилит когда требуется найти подходящие данные для мониторинга по их описаниям в MIB-файле или значениям. Все данные уже сгруппированы по MIB-файлам, однако можно сгруппировать их и по иерархии OID-ов:
Чтобы посмотреть подробное описание любой метрики или таблицы, содержащееся в MIB-файле, достаточно навести мышкой на описание или значение метрики. Во всплывающей подсказке также виден тип данных SNMP и полный OID:
Если метрика может принимать одно из нескольких числовых значений, описанных в MIB-файле текстовыми константами, в снимке устройства сразу показывается соответствующая текущему значению константа. Полный список констант и их числовых значений доступен через контекстное меню:
При этом текущее числовое значение всегда можно посмотреть во всплывающей подсказке. Для редактируемых метрик все еще проще, можно выбрать константу и посмотреть ее значение прямо в выпадающем списке:
Но наибольшую пользу наш метод работы с данными SNMP приносит при обработке таблиц. Каждая SNMP-таблица показывается в снимке устройств как отдельная метрика табличного типа:
Редактирование данных в таблицах можно производить прямо по время просмотра, например для отключения сетевого интерфейса достаточно поменять значение поля ifAdminStatus в соответствующей строке.
При наведении на заголовок столбца во всплывающей подсказке видно описание поля, полученное из MIB-файла, а также его тип и OID:
Если имеется несколько связанных друг с другом таблиц, например использующих внешние индексы или расширение (augmentation), система автоматически обрабатывает все внутренние связи и сводит данные связанных таблиц в одно целое. В большинстве случаев пользователи даже не подозревают о существовании таких сложностей. Вот, например, как выглядит таблица hrSWRunPerfTable :
На уровне MIB файла эта таблица представляет из себя два столбца (hrSWRunPerfCPU и hrSWRunPerfMem ), расширяющие таблицу hrSWRunTable . В снимке устройства эти таблицы уже объединены, что облегчает анализ данных, построение отчетности и диаграмм, настройку хранения и т.д.
Поскольку единая модель данных платформы AggreGate ориентирована на работу с таблицами, таблицы данных SNMP являются идеальным кандидатом на обработку встроенными средствами. При помощи них реализуется построение топологии L2/L3, анализ данных MPLS TE и MPLS VPN, мониторинг и создание тестов IP SLA, а также сотни более простых задач.
Шаг 4: настраиваем периоды опроса и сроки хранения
AggreGate Network Manager является , поэтому в большинстве случаев после автоматического или ручного добавления устройства периоды опроса и сроки хранения метрик уже преднастроены для всех метрик и таблиц, которые система «понимает», т.е. показывает на инструментальных панелях и анализирует на предмет необходимости генерации тревожных сообщений.Откорректировать настройки опроса (синхронизации) и хранения метрики можно через ее контекстное меню, либо через настройки аккаунта (для всех метрик сразу).
Настройки опроса и хранения
В диалоге настроек хранения показывается только срок хранения «сырых» данных в обычной базе данных (реляционной или NoSQL, в зависимости от настроек сервера). В большинстве случаев данные SNMP хранятся в кольцевой базе данных (Round-Robin Database, RRD), которая встроена в платформу AggreGate. На тему создания каналов статистики , которые перекладывают метрики и части таблиц в кольцевую БД, будет отдельная статья.
Шаг 5: переходим к обработке и визуализации данных
Когда данные собираются и сохраняются в БД сервера, можно приступать к их использованию для дела, то есть для мониторинга и управления ИТ инфраструктурой. Контекстное меню любой метрики в снимке устройства предоставляет доступ к визардам, позволяющим начать настройку тревог, отчетов, графиков, запросов, инструментальных панелей, и других средств анализа и визуализации.
При помощи этих средств настраивается влияние метрик и таблиц на общесистемные операции поиска причин отказов, анализа производительности, планирования и инвентаризации, управления конфигурациями, и других функций системы. Попутно «рисуются» различные интерфейсы:
В результате
Описанный выше процесс может показаться сложным из-за множества упомянутых подробностей, однако на практике от момента подключения абсолютно нового устройства до появления его специфических данных на стандартных инструментальных панелях проходит всего несколько минут. За это время выход из нашей системы требуется лишь на время поиска специфических MIB-файлов на сайте производителя подключаемого оборудования.При настройке мониторинга не требуется ручное указание названий MIB-ов, ввод OID-ов и других низкоуровневых идентификаторов. Это делает настройку SNMP-мониторинга достаточно быстрой и легкой.
Безусловно, нам еще есть над чем поработать. Требуется улучшение механизмов выбора индивидуальных метрик, чтобы избежать даже единократного опроса целых MIBов. Есть необходимость исключения из опроса индивидуальных строк и столбцов SNMP-таблиц. Нам интересно было бы услышать и о других недостатках процесса настройки SNMP-мониторинга в нашей системе.
А поподробнее?
Эта статья вообще не касается получения, обработки и отправки ловушек SNMP, работы по SNMP v3, и многих других аспектов.Для более подробного рассказа мы приглашаем всех хабражителей на вебинар Мониторинг и управление по SNMP , который состоится 26 мая 2015 года в 11:00 по московскому времени. На этом вебинаре мы «вживую» продемонстрируем весь вышеописанный процесс, а также многие другие способы мониторинга сетевого, серверного и нестандартного оборудования при помощи SNMP.
Введение
Одной из проблем большинства сегодняшних сетей - быстрорастущих, больших по количеству узлов и зачастую широко раскинутых географически - является управление и получение информации о состоянии всей сети или отдельных ее участков.
Целью данной курсовой работы является изучение протокола SNMP, предназначенного для удаленного управления и сбора информации с удаленных систем. К настоящему времени данный протокол достаточно хорошо развит и используется во многих областях сетевых технологий.
SNMP Framework
Simple Network Management Protocol (SNMP) - протокол, предназначенный для сетевого управления удаленных систем. С его помощью можно управлять и получать информацию о состоянии сетевого оборудования или сетевого протокола, реализованного на удаленной системе.
SNMP является не просто протоколом для обмена управляющей информацией между объектами сети. Чаще всего под SNMP понимают Internet-Standard Management Framework или SNMP Framework , т.е. совокупность стандартов описывающих модели и средства использующиеся при сетевом управлении.
SNMP Framework состоит из нескольких частей:
Язык описания информации
Описание протокола
При развитии стандарта от версии к версии, обновляется содержание этих модулей, но основные принципы строения SNMP остаются неизменны.
Причиной модульного строения было желание упростить предполагаемый в скором времени переход от протокола SNMP к протоколам ISO. По этому были созданы протоколо-независимые SMI и MIB. В результате, планы по переходу к OSI не осуществились, но модульное строение SNMP Framework все же сыграло свою роль упростив переход от SNMPv1 к SNMPv2, и от SNMPv2 к SNMPv3.
База данных управляемых элементов
Для управления тем или иным сетевым протоколом или устройством с помощью SNMP, выделяются основные объекты этого протокола или устройства, которые могут предоставлять (для чтения или для изменения) какую-либо информацию о протоколе или устройстве. Все эти объекты являются управляемыми элементами этого протокола или оборудования. Управляемые элементы рассматриваются как объекты виртуального хранилища информации, называемого Management Information Base (MIB). В MIB все эти объекты рассматриваются как переменные, содержащие информацию о представляемом ими объекте. Например, для протокола IP, существует переменная ipDefaultTTL, которая содержит значение по умолчанию для поля TTL в заголовке датаграммы протокола IP, или переменная ipInHdrErrors, предоставляющая информацию о том, какое количество ip-пакетов было отсеено по причине ошибок в их заголовке. Наборы этих переменных определяются в MIB-модулях.
Вообще, MIB имеет структуру дерева, каждый узел которого является переменной MIB. Для нужд сетевого управления сети Internet выделена отдельное поддерево, в котором могут быть определены все требуемые элементы. В одном из поддеревьев этого дерева содержатся все управляемые элементы сети Internet. Раньше вся эта ветка определялась одним MIB-модулем.
Позже, после публикации второй версии этого MIB-модуля, был принят другой подход к созданию базы управляемых элементов. До этого существовал единственный комитет, работающий над документом, описывающим Стандартный MIB для Internet. Теперь же принято разделение на группы, каждая из которых специализируется в одной из областей сетевых технологий. Небольшие MIB-модули разработанные каждой группой, составляют единый Internet MIB. Т.о. теперь поддерево сетевого управления Internet описывается не единой спецификацией, входящей в состав SNMP, а набором отдельных документов, выпускаемых отдельно от Стандартов SNMP.
Язык описания информации
Вся База Управляемых Элементов описывается с помощью упрощенного подмножества стандартного языка OSI, Abstract Syntax Notation One (ASN.1). Это подмножество описывается в документе называемом Structure of Management Information, по этому и весь язык описания информации для SNMP называется SMI. По мимо языка определения данных этот документ описывает также и древовидную структуру MIB и все стандартные поддеревья, которые должны присутствовать во всех реализациях MIB.
Протокол
Эта часть Стандартной Модели описывает протокол, посредством которого происходит обмен информацией между управляемым объектом (называемым агентом ) и управляющей системой (называемой менеджером ). PDU (protocol data unit) протокола SNMP содержит операцию, выполняемую протоколом и список переменных и их значений, участвующих в данной транзакции.
Во всех версиях SNMP определены следующие операции: get, get-next, get-response, set-request. Более поздние версии определяют еще несколько операций. Этот модуль также содержит рекомендации о том, какой транспортных протокол может использоваться для доставки сообщений SNMP. Все версии SNMP, используемые на сегодняшний день содержат рекомендации об использовании транспортных протоколов без установки соединения (UDP).
Безопасность и администрирование
Система сетевого управления SNMP предоставляет достаточно большие возможности для непосредственного управления удаленными системами. По средствам SNMP можно получить доступ к достаточно критическим параметрам системы. Таким образом, проблемы безопасности должны учитываться на каждом этапе проектирования SNMP. В то же время безопасность любого открытого протокола всегда является очень спорным вопросом.
В первой версии SNMP проблемы безопасности практически не учитывались. Этот недостаток SNMPv1 предполагался уже на стадии разработки, т.к. на тот момент основной задачей был скорейший выпуск стандартной модели сетевого управления, в которой нуждалось интернет-сообщество, а обсуждение спорных вопросов безопасности еще на долго затянуло бы разработку стандарта.
Именно тогда проблемы безопасности и администрирования были вынесены в отдельный блок общей модели, рассмотрение которого было оставлено на будущие версии SNMP.
Развитие SNMP
В настоящее время существует три версии SNMP Framework. В следующих трех частях будут кратко описаны изменения произошедшие в каждой версии SNMP и ссылки на документы описывающие компоненты каждой версии SNMP.
SNMPv1
Первоначальным Internet-Standard Management Framework стал SNMPv1, история его развития описана в первой части. Стандарт SNMPv1 содержится в следующих документах:
SNMPv2c - Развитие SNMPv2p, кроме системы безопасности. Содержит дополнение к протоколу и типам данных, определенным ранее. Использует community string-based систему безопасности из первой версии SNMPv1. (RFC-1901 , RFC-1905 , RFC-1906).
SNMPv2u - Отличается от SNMPv2c только подсистемой безопасности. В этой модификации используется user-based подход. (RFC-1905 , RFC-1906 , RFC-1909 , and RFC-1910)
SNMPv2* - сочетает в себе лучшие стороны SNMPv2p и SNMPv2u. (Эта спецификация никогда не издавалась как официальный документ RFC)
Существовали также SNMPv1+, SNMPv1.5, SNMP++
Наибольшую поддержку IETF получил SNMPv2c, не использующий никаких нововведений в области безопасности. Он стал наиболее распространенным и используемым в интернет-сообществе. Описание этой вариации SNMPv2 Framework содержится в следующих документах:
На данный момент большинство из вышеперечисленных документов заменено их более новыми версиями и издано со статусом Стандарта. Документы, представляющие SNMPv2c на сегодняшний день, приведены в таблице в заключительной части данной.
SNMPv3
Итак, проект SNMPv2 не выполнил поставленных перед ним целей. Не было разработано стандартоного средства сетевого управления, удовлетворявшего интернет-сообщество в плане безопасности. Теперь, все эти проблемы должна была решить рабочая группа SNMPv3 (SNMPv3 WG), созданная IETF. Ей предстояло разработать единый стандарт для нового поколения SNMP. Единственной критической неразрешенной проблемой оставалась система безопасности и администрирования, по этому все силы рабочей группы были брошены на разрешение этой проблемы.
В руках SNMPv3 WG имелись предыдущие разработки и результаты работ других проектов, посвященных безопасности в SNMP:
От рабочей группы SNMPv3 требовалось найти точки соприкосновения всех концепций безопасности и администрирования представленных ранее. Также в ее задачи входило:
соответствие требованиям широкого спектра существующих сетевых окружений, имеющих различные потребности в управлении.
простота перехода от предыдущих версий SNMP к использованию SNMPv3.
простота установки и сопровождения
Части нового стандарта, не связанные с проблемами безопасности, такие как SMI, MIB, протокол, были заимствованы из SNMPv2. Таким образом, многие документы из спецификации SNMPv2 Framework получили статус стандарта и перешли в SNMPv3 Framework.
Спецификация SNMPv3 Management Framework была разделена на множество частей, каждая из которых представлена отдельным документом. Таким образом, в любой документ могли быть внесены поправки и обновления не затрагивая при этом другие элементы Модели.
В конечном счете, все документы спецификации SNMPv3 могут быть разделены на те же категории, на которые делились документы всех предыдущих версий SNMP:
Язык описания информации
База данных управляемых элементов
Описание протокола
Решение проблем безопасности и администрирования
Первые три части взяты из SNMPv2, а последняя часть является результатом основной работы проекта SNMPv3 и других проектов, разработавших концепции безопасности SNMP.
SNMPv3 WG был представлен следующий набор документов, описывающих третью версию стандартную модель сетевого управления:
Рисунок 1. Средний входящий трафик на машине iota.cs.prv
Заключение
Итак, описание любой версии SNMP Framework разделено на четыре части. Их взаимодействие определяется следующим образом.
Доступ к управляемым объектам осуществляется через виртуальное хранилище информации, называемое Management Information Base (MIB). В качестве протокола для доступа к объектам MIB используется Simple Network Management Protocol (SNMP). Объекты в MIB описываются с помощью механизмов определяемых спецификацией Structure of Management Information (SMI), предоставляющей свой язык определения информации. При любом взаимодействии объектов SNMP Framework учитывается система безопасности и администрирования принятая в данной версии SNMP.
Следующая таблица представляет свод всех документов, определяющих все три версии SNMP. Все документы разделены на вышеупомянутые группы. Также почти все версии SNMP предоставляют некоторое количество докуметов информационного характера. В них описаны общие концепции данной версии Стандарта или его совместимость с предыдущими версиями.
Как уже говорилось ранее, ситуация с описанием MIB несколько изменилась после выхода первой версии SNMP. Следующие версии уже не включали в себя единый стандартный MIB, описывающий все, требуемые для управления, объекты сети. Последние две версии Стандарта включают в себя только модуль MIB, содержащий описание переменных для работы с объектами протокола SNMP, а также переменные, описывающие состояние системы, на котором расположен агент SNMP. Остальное содержимое документа RFC-1213 , описывавшего MIB-II первой версии SNMPv1 разделено на несколько частей, каждая из которых содержится в отдельном документе. Теперь совокупность этих модулей образует MIB-II. В свою очередь MIB-II это модуль описывающий сетевые объекты используемые в Internet.
После перехода к модульному описанию MIB, База Данных Управляемых элементов несколько отделилась от общей модели SNMP. Естественно, MIB все еще остается частью SNMP, но теперь весь Internet MIB не описывается спецификацией SNMP, а документы, описывающие отдельные элементы Internet MIB, выходят отдельно.
Основным языком описания модулей MIB на сегодняшний день является SMIv2, который является рекомендованным стандартом IETF. Более того, IETF требует, чтобы все новые MIB модули были описаны с помощью SMIv2. Одновременно с этим все еще используется SMIv1, который также является стандартом, но без статуса рекомендации. Стандарт SMIv1 не был объявлен устаревшим, т.к. существует большое количество документов опирающихся на спецификацию SMIv1 и многие коммерческие организации еще долгое время после выпуска стандарта SMIv2 пользовались SMIv1. По этому объявление SMIv1 устаревшим потребовало бы изменения и пересмотра очень большого количества спецификаций. Тем более, что одновременное использование SMIv1 и SMIv2 не вносит особых проблем в систему сетевого управления, т.к. SMIv2 совместим со SMIv1. SNMPv2 и SNMPv3, работающие со SMIv2 могут корректно обрабатывать модули описанные с помощью SMI. SNMPv1 воспринимает только SMIv1 и не может полноценно работать с модулями описанными с помощью SMIv2, т.к. SMIv2 содержит новые типы данных. Проблемы совместной работы нескольких версий SNMP, в том числе и проблемы SMIv1/SMIv2 рассматриваются в документах RFC-2576 и RFC-3584 .
Таким образом, на сегодняшний день SMIv2 является рекомендованным стандартом IETF, а SMI является стандартом без статуса рекомендации.
На данный момент существует большое количество (около 10000) MIB-модулей, описывающих объекты для управления почти всеми известными сетевыми протоколами и устройствами. Информацию обо всех MIB-модулях можно найти на сайте http://www.mibdepot.com .
