Простой протокол управления сетью — SNMP
В современной комплексной сети из маршрутизаторов, коммутаторов и серверов задача управления всеми устройствами и обеспечение того, чтобы они не просто функционировали, а работали оптимально, может показаться обескураживающей. Вот где может помочь SNMP (Simple Network Management Protocol) — простой протокол управления сетью. SNMP был введен в 1988 году с целью удовлетворить растущую потребность в стандарте для управления устройствами, поддерживающими интернет-протокол IP (Internet Protocol). SNMP предоставляет пользователям «простой» набор операций, позволяющий управлять этими устройствами удаленно.
Основа SNMP — простой набор операций (и информации, собираемой посредством этих операций), который предоставляет администраторам возможность изменять состояние какого-либо устройства, поддерживающего SNMP. Например, вы можете использовать SNMP, чтобы отключить интерфейс на маршрутизаторе или проверить скорость, с которой работает интерфейс Ethernet. SNMP позволяет даже отслеживать температуру коммутатора и предупреждать вас, когда она слишком высока.
Обычно SNMP ассоциируется с управлением маршрутизаторами, но важно понимать, что его можно использовать для управления устройствами различных типов. Хотя предшественник SNMP, простой протокол управления маршрутизаторами SGMP (Simple Gateway Management Protocol), разрабатывался для управления интернет-маршрутизаторами. Можно управлять любым устройством, на котором запущено программное обеспечение, позволяющее получать информацию SNMP. Это справедливо не только для физических устройств, но и для программ, например веб-серверов и баз данных.
Другой аспект управления сетью — мониторинг сети, то есть мониторинг всей сети, а не отдельных маршрутизаторов, узлов и других устройств. Чтобы понять, как работает сама сеть, а также как отдельные ее устройства влияют на сеть в целом, был разработан модуль удаленного мониторинга (RMON — Remote Network Monitoring). Он может использоваться для мониторинга не только трафика в локальной сети (LAN — Local Area Network), но и интерфейсов WAN.
Версии SNMP
SNMP версии 1 (SNMPv1) — первоначальная версия протокола SNMP. Она определена в RFC 1157 и является историческим стандартом IETF. Безопасность SNMPv1 основана на строках community (поле «пароль»), которые представляют собой просто пароли. Они позволяют любому SNMP-приложению, которое их знает, получать доступ к информации об управлении устройством. Обычно в SNMPv1 используются три значения community: RO — read-only (только чтение), RW — read-write (чтение и запись) и trap (ловушка — уведомление). Следует отметить, что хотя SNMPv1 стал историческим стандартом, он все еще является основной реализацией SNMP, поддерживаемой многими производителями.
SNMP версии 2 (SNMPv2) часто называют SNMPv2 с поддержкой строк community. Технически эта версия SNMPv2 называется SNMPv2c, Она определена в RFC 3416, RFC 3417 и RFC 3418.
SNMP версии 3 (SNMPv3) — последняя версия SNMP. Ее главный вклад в управлении сетями заключается в безопасности. В ней добавлена поддержка сильной аутентификации и закрытой связи между управляемыми объектами. В 2002 году она наконец перешла из разряда временного стандарта в разряд полного стандарта. Этот стандарт определяется следующими документами: RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418 и RFC 2576.
За стандартные протоколы, регулирующие трафик Интернета, в том числе SNMP, отвечает Группа по стандартам для сети Интернет IETF (Internet Engineering Task Force).
IETF публикует документы RFC (Request for Comments), которые представляют собой спецификации для многих протоколов, существующих в мире IP.
Менеджеры и агенты SNMP
В мире SNMP существует два вида объектов: менеджеры и агенты. Менеджер — это сервер, на котором запущена какая-либо программная система, имеющая возможность выполнять задачи по управлению сетью. Менеджеры часто называют станциями управления сетью (NMS — Network Management Station). NMS отвечает за опрос и получение ловушек от агентов в сети. Опрос в контексте управления сетью — это действие по запросу у агента (маршрутизатора, коммутатора, Linux-сервера и т.п.) какой-либо информации. В дальнейшем эта информация может быть использована, чтобы определить, не произошло ли какое-нибудь катастрофическое событие. Ловушка — это способ для агента сообщить NMS о каком-то событии. Далее NMS отвечает за действие в соответствии с информацией, полученной от агента.
Вот некоторые NMS: Zabbix, Nagios, Spiceworks Help Desk, Datadog, NetCrunch, Munin, PRTG Network Monitor, Icinga, Pandora FMS, LibreNMS, Observium, netdata, PHP Server Monitor, Cabot, OpenNMS, NIXStats и т.д.
Второй тип объекта, агент, — это программный элемент, запущенный на управляемом сетевом устройстве. Это может быть отдельная программа (демон в терминологии Linux) или элемент операционной системы (например, Cisco IOS или операционной системы низкого уровня, управляющей источником бесперебойного питания). Агент предоставляет NMS информацию для управления, отслеживая различные рабочие параметры устройства. На рис. 1 связь между NMS и агентом.
Важно иметь в виду, что запросы и ловушки могут отправляться одновременно. Для времени, когда NMS может опросить агента или когда агент может отправить ловушку, ограничений нет.
Обратите внимание, чтобы настроить мониторинг агента, не обязательно на агенте настраивать ловушку (trap), достаточно на NMS указать IP-адрес агента, версию SNMP, порт 161 и имя Community.
Структура информации для управления и MIB
Структура информации для управления (SMI — Structure Management Information) предоставляет способ определения управляемых объектов и их поведения. У агента есть список отслеживаемых им объектов. Один из таких объектов — состояние работы интерфейса на сетевом оборудовании (например, работает , не работает или тестируется ). Этот список собирает информацию, которой NMS может воспользоваться для определения общего состояния того устройства, на котором работает агент.
В стандарте «The Structure of Management Information Version 1» (Структура информации для управления) (SMIv1, RFC 1155) он определяет, как управляемым объектам присваиваются имена, и указывает связанные с ними типы данных. В стандарте «The Structure of Management Information Version 2» (SMIv2, RFC 2578 ) представлены дополнения для SNMPv2.
База управляющей информации (MIB — Management Information Base) может рассматриваться как база данных управляемых объектов, которые отслеживает агент. Все данные о состоянии или статистическая информация, к которой есть доступ к NMS, определены в MIB. SMI предоставляет способ определения управляемых объектов, тогда как MIB — это определение (в терминологии SMI) самих объектов. Как словарь , в котором показывается написание слов, а затем приводится его толкование, MIB определяет текстовое имя управляемого объекта и объясняет его значение.
Словарь — книга, содержащая перечень слов, обычно с пояснениями, толкованиями или переводом на другой язык.
В агенте может быть реализовано много MIB, но во всех агентах реализована конкретная MIB, которая называется MIB-II ( RFC 1213 ). Этот стандарт определяет переменные для таких параметров, как статистика интерфейса (скорость интерфейса, MTU, количество отправных октетов, количество принятых октетов и т.д.), а также различных параметров, относящихся к самой системе (местоположение системы, контактные сведения и т.д.). Основная цель MIB-II — предоставить общую управляющую информацию TCP/IP. Она не охватывает все возможные объекты, которыми производителю может потребоваться управлять в конкретном устройстве.
Имя, или идентификатор объекта ( OID — Object Identifier), уникально определяет управляемый объект. В SNMP-приложениях делается очень много работы для того, чтобы помочь вам удобно ориентироваться в пространстве имен.
Обратите внимание, как составляется OID для interfaces, на рис. 2 выделено цветом, в скобке есть цифра.
Определяет список объектов, относящихся к работе системы, таких как время работы системы, контактная информация и имя системы
Отслеживает состояние каждого интерфейса на управляемой системе. Группа interfaces отслеживает, какие интерфейсы работают и не работают, и такие параметры, как количество отправленных и полученных октетов, ошибок и потерь пакетов и т.д.
Помимо прочего отслеживает состояние TCP-соединения (например, closed (закрыто), listen (порт прослушивается), sysSent (отправлен пакет syn) и т.д.)
Отслеживает различную статистику протокола EGP (Exterior Gateway Protocol) и хранит таблицу соседей EGP
В настоящее время в этой группе не определено объектов, но другие MIB для конкретных каналов передачи определяются при помощи этого субдерева
Измеряет производительность базовой реализации SNMP на управляемой системе и отслеживает такие параметры, как количество отправленных и полученных SNMP-ПАКЕТОВ
Вот интересный сайт , где вы можете найти искомый OID спускаясь вниз по субдереву, например для OID 1.3.6.1.2.1.2.2.1.8 — Обнаружение сетевых интерфейсов, описание можно посмотреть здесь на этом же сайте .
SNMP и UDP
В качестве транспортного протокола для передачи данных SNMP применяют протокол UDP (User Datagram Protocol). UDP, определенному в RFC 768, было отдано предпочтение перед протоколом TCP (Transmission Control Protocol), так как UDP — протокол без установления соединения, то есть при передачи дейтаграмм (пакетов) туда и обратно между агентом и NMS не создаются соединения из конца в конец. Из-за этого аспекта UDP является ненадежным, потому что на уровне протокола нет подтверждения доставки датаграмм. SNMP-приложение само определяет, потеряны ли датаграммы, и при необходимости передает их повторно. Обычно это достигается путем простого ожидания в течение определенного интервала времени. NMS отправляет агенту UDP-запрос и ожидает ответа. Интервал времени, в течение которого NMS его ожидает, зависит от ее конфигурации. Если интервал времени ожидания превышен, а NMS не получила от агента ответа, она считает пакет потерянным и повторно передает запрос. Количество повторных передач пакетов также настраивается.
Пока дело касается регулярных информационных запросов, ненадежная природа UDP фактически не является проблемой. В худшем случае станция управления отправляет запрос и никогда не получает ответа. Для ловушек (trap) ситуация несколько иная. Если агент отправляет ловушку, а та не достигает адресата, NMS никак не может узнать, что ловушка вообще была отправлена. Агент, в свою очередь, не знает, что ему нужно отправить ловушку повторно, потому что NMS не должна посылать агенту ответ, подтверждающий ее получение.
Достоинство ненадежной природы UDP заключается в том, что этот протокол требует небольшого количества служебной информации, поэтому влияние на производительность вашей сети снижается. Реализации SNMP через TCP существуют, но они больше подходят для особых случаев, когда кто-то разрабатывает агент для проприетарного оборудования. В сильно загруженной и управляемой сети реализация SNMP через TCP — плохая идея. Кроме того, стоит понять, что TCP — не волшебство и что SNMP был разработан для работы в сетях, где есть неполадки — если бы в вашей сети никогда не было сбоев, вам не потребовалось бы за ней наблюдать. При сбоях в сети протокол, который пытается отправить данные, но останавливается, если не может этого сделать, — практически всегда лучший выбор с точки зрения проектирования, чем протокол, который забивает сеть повторными передачами в попытке достичь надежности.
- UDP-порт 161 для отправки и получения запросов;
- UDP-порт 162 для получения ловушки от управляемых устройств.
Каждое устройство, в котором реализован SNMP, по умолчанию должно использовать эти номера портов, но некоторые производители позволяют изменять в конфигурации агента порт по умолчанию. Если вы измените эти значения, нужно уведомить об этом NMS, чтобы она могла опрашивать устройства через правильные порты.
На рис. 3 изображен стек протоколов TCP/IP, который является основой всей связи по TCP/IP. В настоящее время любое устройство, которое связывается через Интернет (например, Windows-системы, Linux-серверы, сетевое оборудование и т.д.), должно использовать этот стек протоколов.
Эта модель называется стеком протоколов потому, что каждый уровень использует информацию из уровня непосредственно под собой и обслуживает уровень непосредственно над собой.
Когда NMS или агент хочет выполнить SNMP-функцию (например, запрос или ловушку), в стеке протоколов происходят следующие события:
В первую очередь само SNMP-приложение (NMS или агент) решает, что оно будет делать. Например, оно может отправить SNMP-запрос агенту, ответ на SNMP-запрос (он будет отправлен агентом) или ловушку NMS. Прикладной уровень обслуживает конечного пользователя, например оператора, запрашивающего информацию о состоянии порта Ethernet-коммутатора.
Следующий уровень, UDP, позволяет двум узлам связываться друг с другом. Помимо прочего UDP-заголовок содержит порт назначения устройства, которому отправляется запрос или ловушка. Порт назначения будет либо 161 (запрос), либо 162 (ловушка).