Для чего предназначен SNMP: руководство по NMS, MIB, OID, ловушкам и агентам
SNMP (Simple Network Management Protocol) представляет собой коммуникационный протокол, который позволяет отслеживать управляемые сетевые устройства, включая маршрутизаторы, коммутаторы, серверы, принтеры и другие устройства, которые включены через IP через единую систему управления / программное обеспечение.
Если сетевое устройство поддерживает протокол SNMP, вы можете включить и настроить его для начала сбора информации и мониторинга количества сетевых устройств, как вы хотите, из одной точки.
Менеджер (NMS)
Компонент Manager — это просто часть программного обеспечения, которое установлено на компьютере (которое при объединении называется Network Management System), которое проверяет устройства в вашей сети, как часто вы указываете информацию.
Менеджер имеет правильные учетные данные для доступа к информации, хранящейся агентами (что объясняется в следующем разделе), а затем компилирует их в читаемом формате для сетевого инженера или администратора для мониторинга или диагностики проблем или узких мест. Некоторые программные пакеты NMS более сложны, чем другие, что позволяет настраивать сообщения электронной почты или SMS, чтобы предупредить вас о неисправных устройствах в вашей сети, в то время как другие просто опросили устройства для получения более общей информации.
Агенты
SNMP Agent — это часть программного обеспечения, которое поставляется вместе с сетевым устройством (маршрутизатором, коммутатором, сервером, Wi-Fi и т. Д.), Которое при включении и настройке выполняет всю тяжелую работу для Менеджера путем компиляции и хранения всех данных из своего данное устройство в базу данных (MIB).
Эта база данных правильно структурирована, чтобы программное обеспечение менеджера могло легко опросить информацию и даже отправить информацию Менеджеру, если произошла ошибка.
Какие номера портов используют SNMP?
Управляемые сетевые устройства
Управляемые сетевые устройства, в том числе маршрутизаторы, коммутаторы, Wi-Fi, серверы (Windows и другие), настольные ПК, ноутбуки, принтеры, UPS и т. Д., Имеют встроенное в них программное обеспечение агента, которое должно быть либо включено, либо настроено, либо просто настроено правильно для того, чтобы быть опрошены NMS.
MIB-файлы представляют собой набор вопросов, которые SNMP-менеджер может задать агенту. Агент собирает эти данные локально и сохраняет их, как определено в MIB. Таким образом, диспетчер SNMP должен знать эти стандартные и частные вопросы для каждого типа агента.
MIB содержат набор значений, как статистических, так и контрольных, которые определяются сетевым устройством. Во многих случаях расширения стандартных значений определяются с помощью Private MIB разными поставщиками сетевых устройств.
Чтобы упростить MIB, подумайте об этом так: MIB-файлы — это набор Вопросов, которые Менеджер может спросить у агента. Агент просто собирает эти вопросы и сохраняет их локально и обслуживает их по NMS по запросу.
Упрощенный пример работы MIB: NMS спросит у сетевого устройства вопрос, в данном случае, что такое ответ на вопрос 2?
Агент управляемых сетевых устройств затем отвечает с ответом на вопрос 2. Чтобы еще больше разбить это, давайте построим еще один пример.
Скажем, мы хотим знать системное время работы устройства.
Распределение номера OID
| MIB | Объект интереса | Пример |
| 1.3.6.1.2.1.1 | 3 | 0 |
| MIB | Объект SysUptime | Образец |
OID, Object Identifier — это просто номер, составленный MIB, объектом интереса и экземпляром. Каждый идентификатор является уникальным для устройства, и при запросе будет предоставлена информация о том, что было запрошено OID.
Существует два типа OID:
Скаляр — это экземпляр одного объекта — например, имя поставщика устройства. Может быть только одно имя поставщика, так что это будет скалярный OID.
С другой стороны, Tabular может иметь несколько результатов для своего OID — например, процессор Quad Core приведет к 4 различным значениям ЦП.
Ловушки
Ловушки используются, когда устройству необходимо предупредить программное обеспечение сетевого управления о событии без опроса. Ловушки гарантируют, что NMS получает информацию, если определенное событие происходит на устройстве, которое должно быть записано без предварительного опроса NMS.
Управляемые сетевые устройства будут иметь MIB Trap с заранее определенными условиями, встроенными в них. Крайне важно, чтобы система управления сетью объединяла эти MIB, чтобы получать любые ловушки, отправленные данным устройством.
MIB — это номер, который идентифицирует определенные характеристики или значения устройства, но если в системе управления сетью нет определенной MIB, которую отправляет ловушка сетевого устройства, нет способа интерпретировать, что такое MIB, и не будет записывать событие.
Версии (v1, v2c, v3)
Этот протокол прошел несколько пересмотров на протяжении многих лет, начиная с 1988 года, начиная с версии 1. Теперь мы до версии 3, но большинство систем управления сетью поддерживают все версии протокола.
Версия 1
Версия 1 была первой версией протокола, определенного в RFC 1155 и 1157. Эта версия является самой простой из 3-х версий протокола и является самой небезопасной из-за ее простой текстовой аутентификации.
Версия 2 (или 2c)
Версия 2 протокола была введена в 1993 году с большими улучшениями по сравнению с первой версией, включая транспортные сопоставления, элементы структуры MIB и, что самое важное, улучшенные обновления для проверки подлинности и безопасности.
Тем не менее, версии 1 и 2 / 2c имели встроенные риски безопасности, как упоминалось выше, — строки сообщества, которые эквивалентны паролям, где передается по проводу в виде прозрачного / обычного текста, позволяя любому, кто нюхает сеть, получить доступ к строке и могут компрометировать сетевые устройства и, возможно, перенастроить их с помощью SNMP.
Версия 3
Версия 3 протокола, дебютировавшая в 1998 году, сделала большие шаги для обеспечения безопасности набора протоколов, реализовав так называемую «пользовательскую безопасность». Эта функция безопасности позволяет вам устанавливать аутентификацию на основе требований пользователя. 3 уровня аутентификации:
Версия 3 протокола является наиболее безопасной из группы, но с добавленной безопасностью и шифрованием добавлена конфигурация и сложность настройки и конфигурации. Но при работе с сетевыми устройствами более высокого уровня, которые содержат конфиденциальную информацию, вознаграждение перевешивает головную боль при правильной настройке.
Понимание SNMP
Howard
Купить FS коммутаторы для компаний
SNMP (Simple Network Management Protocol) представляет собой стандартный интернет-протокол для управления устройствами в IP-сетях на основе архитектур TCP/UDP, который позволяет отслеживать управляемые сетевые устройства, включая маршрутизаторы, сетевые коммутаторы, серверы, принтеры и другие устройства, которые включены через IP через единую систему управления/программное обеспечение.
Как работает SNMP?
Чтобы понять принципы работы SNMP, важно сначала узнать модель управления SNMP.
Компоненты SNMP
В модели управления протокола SNMP всегда присутствуют три компонента:
Базы данных MIB представляют собой набор вопросов, которые SNMP-менеджер может задать агенту. Агент собирает эти данные локально и сохраняет их, как определено в MIB. Таким образом, диспетчер SNMP должен знать эти стандартные и частные вопросы для каждого типа агента;
SNMP-агент (то, что в других сетевых системах называется сервером) — это часть программного обеспечения, которое поставляется вместе с сетевым устройством (маршрутизатором, коммутатором, сервером, Wi-Fi и т. д.), Которое при включении и настройке выполняет всю тяжелую работу для Менеджера путем компиляции и хранения всех данных из своего данное устройство в базу данных (MIB);
MIB относится к базе данных, которая содержит переменные, поддерживаемые управляемыми устройствами (информация может запрашиваться и устанавливаться агентом).
Менеджер (NMS) — это просто часть программного обеспечения, которое установлено на компьютере (которое при объединении называется Network Management System), которое проверяет устройства в вашей сети, как часто вы указываете информацию.
SNMP принципы работы
Здесь используется SNMPv2c для объяснения принципов работы SNMP. Он выполняет следующие операции для извлечения данных, изменения переменных объекта SNMP и отправки уведомлений.
| Get | GetNext | GetBulk | Set | Response | Trap | Inform |
|---|---|---|---|---|---|---|
| Это запрос, отправленный NMS на управляемое устройство. И это выполняется для получения одного или нескольких значений из MIB. | Это похоже на GET. Но обычно он получает значение следующего OID (Идентификатор объекта) в дереве MIB. | Он используется для получения массы данных из большой таблицы MIB. | Он выполняется NMS для изменения значения управляемого устройства. | Он выполняется NMS для изменения значения управляемого устройства. Он выполняется агентом в ответ на операции GetRequest, GetNextRequest, GetBulkRequest и SetRequest. | Эта операция инициируется агентом. Он используется для уведомления NMS о ошибке или событии, которое происходит на управляемом устройстве. | Эта операция инициируется агентом. Это похоже на TRAP, но после того, как агент отправит запрос на информирование, NMS должна отправить пакет InformResponse в качестве ответа агенту. |
Обратите внимание, что SNMPv1 не поддерживает операции GetBulk и Inform.
На рисунке 2 показан процесс Get/GetNext/GetBulk/Set приложения SNMPv2c.
Когда NMS отправляет агенту пакет запроса Get/GetNext/GetBulk/Set, агент сначала аутентифицирует версию SNMP и имя сообщества. Затем, когда аутентификация успешна, агент отправляет соответствующее значение в NMS как пакет ответа. Если агент не может получить соответствующее значение, он возвращает сообщение об ошибке в NMS. Обратите внимание, что операция GetBulk эквивалентна последовательным операциям GetNext. Пользователь может установить количество операций GetNext, включенных в операцию GetBulk, без повторного выполнения операции GetNext.
На рисунке 3 показан процесс Trap/Inform приложения SNMPv2c.
Общие ЧАВО и решения
1. Как настроить SNMP?
SNMP использует центральный компьютер с программным обеспечением SNMP для управления сетевыми коммутаторами. Сегодня большинство сетевых коммутаторов на рынке, будь то гигабитные коммутаторы или коммутаторы 40G, поддерживают SNMP. SNMP предоставляет унифицированный и простой способ управления этими коммутаторами. Взяв в качестве примера конфигурацию SNMPv2c, процесс включает:
A) Настроить IP-адреса на компьютерах и управляемых коммутаторах.
C) Настроить права доступа, чтобы компьютеры могли управлять назначенными коммутаторами..
D) Проверить результат конфигурации.
Для получения более подробной информации о конфигурации SNMP, посетите Конфигурация SNMP на коммутаторах серии FS 3900, пожалуйста..
2. NMS не удалось получить Trap.
В конфигурации по умолчанию не все Trap включены. В системном представлении пользователи могут:
Сайт ARNY.RU
Настройка SNMP — достаточно интересная тема, так как протокол SNMP является мощным инструментом в руках системного администратора и критически необходимым в большой сети. Сетевым устройством будет выступать маршрутизатор CISCO.
Немного теории
Общие понятия
База заполняется автоматически сетевым устройством. Нужно только выбирать оттуда необходимые данные.
Взаимодействие между диспетчером и агентом происходит 2 разными способами:
Это если на устройстве для диспетчера выдано право только на чтение (RO) базы MIB, если же выдано право на запись (RW), то есть дополнительная возможность:
Последнее, что тут нужно сказать, важный момент: агент и диспетчер используют разные порты. Агент принимает запросы на 161/UDP порту, отправляет информацию диспетчеру на 162/UDP порт.
Версии SNMP
Существует 3 версии SNMP:
В плане реализации работы между версиями разница небольшая, но поскольку только версия 3 безопасна, то именно она является актуальной, а версии 1 и 2c хотя всё ещё боевые, но считаются устаревшими. Хотя на практике из-за простоты настройки повсеместно используется SNMP v2c.
База MIB
Диспетчер SNMP (программа) имеет стандартную базу MIB, чтобы программа узнала о специфичных ветках и параметрах конкретного производителя, нужно подгрузить MIB этого производителя.
Почитать о MIB CISCO. OIDs полезных параметров придётся искать в интернете/документации.
Проприетарные ветки производителей всегда располагаются по строго заданному пути iso.org.dod.internet.private.enterprises или в цифровом выражении 1.3.6.1.4.1.
Пример. Для CISCO путь будет 1.3.6.1.4.1.9, а для D-Link 1.3.6.1.4.1.171
Для загрузки MIB CISCO нужно использовать
CISCO IOS MIB Locator.
Подробнее о SNMP можно прочитать в 4 части курса CCNA.
Тестовая среда
На этом этапе считается, что все предварительные настройки уже выполнены.
SNMPv1/SNMPv2c
Версии настраиваются одинаково, так как версия не указывается при создании SNMP агента (строки сообщества), а лишь при создании ловушек. При создании строки сообщества задаётся лишь или право на чтение (RO), или право на запись (RW).
Пример. В маршрутизаторе настроен пока только интерфейс F0/0, ведущий к облаку (и VM). Введём команду создания агента (строки сообщества):
Теперь создадим сообщество с правом на запись:
Снова введём команду:
На диспетчере SNMP для работы можно будет выбрать или 1, или 2 версию агента.
Настройка маршрутизатора
Полная настройка версий 1 и 2:
В параметр snmp входят следующие ловушки:
Просмотреть полный перечень возможных ловушек можно командой:
Их там огромное количество:
Настройка VM
Нажатие кнопки Find покажет отсутствие доступных агентов в сети и срабатывание ловушки authentication:
Теперь погасим интерфейс F0/0 и снова включим:
С небольшой задержкой, ведь связанный интерфейс выключался, прилетают сообщения ловушек, смотрим:
Теперь пробуем добавить этот параметр для мониторинга:
Параметр успешно добавился. Выставляем интервал опроса параметра и триггер: если значение параметра не равно up, то отправить сообщение на e-mail:
SNMPv3
Настройка маршрутизатора
Удаляем всё что относится к предыдущей настройке кроме списка доступа. Далее, разбил настройку на 2 части, потом будет понятно почему.
Общие шаги
Часть 1
Агент SNMPv3 настраивается по-другому нежели SNMPv1/SNMPv2:
Предварительно для пользователя создаётся группа, а ещё ранее вид. Вид определяет с какой частью дерева MIB предстоит работать.
Ещё раз по командам:
Тут надо вспомнить 3 уровня безопасности SNMPv3:
Для использования authPriv требуется прошивка с поддержкой криптографии (k9).
Теперь проверим что получилось:
По соображениям безопасности пользователи SNMP не показываются в конфигурации.
Часть 2
Подробная настройка получателя ловушек SNMPv3:
Проверяем, пользователь как был так и остался, а вот в группах SNMP и в конфигурации интересные изменения:
Появилась новая группа TEST, хотя команды на её создание не было.
И вот такая занятная строка в конфиге:
Понять что это такое можно выполнив команду:
Помимо группы для ловушек были автоматически созданы дополнительные виды: //blog.ine.com/2008/07/19/snmpv3-tutorial/
Настройка VM
Для начала погасим и включим интерфейс S0/0 (один из дополнительных интерфейсов, интерфейсы по умолчанию на маршрутизаторе выключены), прилетают сообщения ловушек, диспетчер определяет ловушки как версию 2+:
Как видно из рисунка у пользователя ADMIN для ловушек нет шифрования и пароля.
Дальше добавляем агента с указанием версии и атрибутов:
Состояние интерфейса отображается корректно. С агентом версии 3 всё.
Настройка ловушек v3 с паролем и шифрованием
Удаляем получателя ловушек :
И заново всё проверяем. Автоматически создались виды, пользователь на месте с теми же параметрами, нет новой группы TEST, так как параметры аутентификации и шифрования совпадают с созданной ранее, исходной группой TEST. В конфигурации параметр для автоматически созданных видов дописался к строке группы:
Если теперь погасить/поднять интерфейс, то ловушки не приходят диспетчеру.
Пробуем добавить пользователя для ловушек версии 3, в программе есть такая возможность. Для этого нужно ввести помимо прочего Engine ID. Его можно найти просмотрев пользователя SNMP либо выполнив команду:
Программа ожидает ввода Engine ID в виде 80-00-00-09-03-00-C2-01-25-D0-00-00, автоматического преобразования нет. Вносим реквизиты пользователя, снова гасим/поднимаем интерфейс S0/0, ловушки приходят:
Открываем сообщение ловушки и видим, что пароль и шифрование задействованы:
Индексы интерфейсов
NMS записывает пропускную способность и другую статистику по интерфейсам устройства опрашивая SNMP агента. При этом для каждого интрефейса используется номер индекса. Уникальный номер индекса присваивается динамически при каждой загрузке устройства.
Хорошая практика держать индексы интерфейсов постоянными. Для этого нужно выполнить команду:
После выполнения команды индексы сохраняются в NVRAM и не зависят от перезагрузок устройства.
Установка Net-SNMP
А как же быть со средой Linux? Для Centos:
Далее, если выполнить:
Соответственно запросы не подпадающие под эти ветви будут возвращаться с ошибкой как выше. Комментируем и оставляем:
Затем рестартуем сервис:
Самые основные и нужные команды пакета:
На этом рассмотрение базовой работы SNMP завершено.
Если тема заинтересовала, то предлагаю выполнить лабу по SNMP.
Почему SNMP это не очень просто?
Читаем документацию
The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and
minimizing the amount of traffic generated by the network management function.
Для тех, у кого сложности с английским языком, имеется русский перевод:
Стратегия SNMP заключается в том, что мониторинг состояния сети с любым значимым уровнем детализации выполняется главным образом путем опроса из центра мониторинга. Ограниченное число незапрашиваемых сообщений (trap — прерывание) обеспечивает синхронизацию и активизирует опросы. Ограничение числа незапрашиваемых сообщений согласуется с задачами обеспечения простоты и минимизации трафика, создаваемого системой сетевого управления.
Из этих цитат, вполне понятно, что запросы с типами TRAP и INFORM это не наиболее часто используемая часть SNMP. Статью для начинающих было бы более уместно иллюстрировать примерами использования гораздо более ходовых GET-запросов.
Вообще я настоятельно рекомендую ознакомиться со всеми RFC, связанными с SNMP перед началом работы. Некоторые аспекты SNMP не очевидны и имеет смысл получить о них представление из первоисточника. Начать ознакомление с материалом можно с wiki.
Первые шаги
Помимо обязательного ознакомления с документацией, важно понимать, для чего мы все это делаем. В практике телекома, наиболее часто встречаются следующие задачи:
Задача SNMP-мониторинга выделяется на общем фоне требованием того, что опрашиваемого оборудования много или очень много. Предположим, что именно эту задачу нам и предстоит решать.
Начнем писать код. В тестовом примере мы обратимся по SNMP к собственному хосту и прочитаем значение переменной, заданной OID-ом 1.3.6.1.2.1.1.3.0 и содержащей значение uptime-а хоста:
Предварительно убедившись, что служба SNMP на нашем хосте работает и запустив код на выполнение, получим искомое значение uptime-а (времени безостановочной работы хоста с момента последней загрузки):
Используя это значение, можно осуществлять мониторинг. Если мы обнаруживаем, что значением уменьшилось — значит хост успел перезагрузиться с момента очередного опроса. Если хост не ответил в течение заданного таймаута (после нескольких автоматически сделанных попыток) это, скорее всего, означает, что хост не работает. Все просто?
Подсчитали — прослезились
Не совсем. Вспоминаем о том, что нам предстоит выполнять много запросов. Давайте промеряем, сколько запросов мы можем выполнить в секунду? Внесем небольшое исправление в код:
И запустим его на выполнение:
Почти две с половиной тысячи запросов в секунду! Неплохо?
Не будем торопиться. Мы отправляем запросы на Loopback интерфейс, а он работает несколько быстрее локальной сети. Посмотрим, сколько запросов в секунду мы успеем выполнить к другому хосту в нашей сети:
Не дотягиваем даже до двухсот. Вообще говоря, возможно, этого будет достаточно. Все зависит от задачи. Но мы проводили измерения при условии, что опрашиваемый хост доступен. Что будет если хост не ответит?
Будет несколько попыток доступа (в нашем коде мы задали 3) разделенных таймаутом (1000 мсек). Это означает, что за секунду мы не успеем выполнить ни одного запроса. Поскольку не отвечающий хост является не такой уж большой редкостью, это может стать большой проблемой в реальном проекте.
Идем на рекорд
Что с этим можно сделать? Если бы мы имели дело с каким либо синхронным протоколом (например telnet), особого выбора бы у нас не было. Для того, чтобы увеличить производительность, нам пришлось бы одновременно выполнять много потоков. Но SNMP асинхронен по своей природе! Не надо насильственно втискивать его в синхронные рамки.
Как перейти к асинхронному варианту? В нашем случае, довольно просто:
Запросы все равно что проваливаются в бездонную бочку! Разумеется, ответы будут приходить с задержкой, но приходить они будут тоже довольно быстро. Но как мы узнаем, что хост не ответил?
Очень просто, по истечении заданного количества попыток и таймаутов, SNMP4J вернет нам event, response в котором будет равен null:
Проанализируем результат выполнения:
Мы успеваем сформировать 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 вместе с соответствующим значением. Это дает возможность запрашивать скалярные значения вместе с значениями столбцов таблиц, в одном запросе.
Запустив этот код на выполнение, мы получим следующий response:
Мы получили значение uptime-а, индекс первого интерфейса и его имя, закодированное строкой октетов в шестнадцатеричном представлении. Чтобы получить следующие строки, мы должны выполнять последовательные запросы, передавая ранее полученные OID-ы.
С учетом необходимости поддержки возможности асинхронной обработки, это может стать нетривиальной (но вполне решаемой) задачей. К счастью, во 2-ой версии SNMP были добавлены bulk-запросы, автоматизирующие получение табличных данных и минимизирующие количество отсылаемых при этом запросов. Внесем необходимые изменения в код:
Выполнив этот запрос, мы получаем все строки таблицы одним запросом:
Разумеется, если таблица содержит более затребованных 50-ти строк, вновь (как и для 1-ой версии SNMP) потребуется формировать запросы для получения последующих строк, передавая в них OID-ыполученные для последней строки.
О чем я не рассказал?
В этой статье я не рассказал о многом. Я не рассказал о том, как изменять значения некоторых (не всех) переменных SET-запросами. Я не рассказал о том, что такое TRAP-ы и для чего они нужны. Я ни сказал ни слова о том, как разрабатывать SNMP-агенты. И я ни одним словом не обмолвился о 3-ей версии SNMP и привнесенных ей изменениях.
Но даже того о чем я сказал вполне достаточно, чтобы понять, что SNMP — это не просто.
