What is the snmp (simple network management protocol)?

A closer look at SNMP

If you feel like you want to dig deeper to see how it works and how the functions described in the overview are implemented, I recommend you continue reading!

What is an SNMP Manager?

The SNMP manager is a separate entity that is responsible to communicate with the SNMP agent implemented within network devices. A manager is software dedicated for network management typically running in a computer (PC or Server). Key functions include:

Queries SNMP agents, i.e. requests information
Gets responses from SNMP agents, i.e. collects information.
Sets variables in SNMP agents, i.e. configures devices
Acknowledges asynchronous events from SNMP agents, i.e. collects alarms and notifications

What is an SNMP Agent?

The SNMP agent is a software program that is packaged within the network element. Activating the agent allows it to start collecting the management information database from the device locally and makes it available to the SNMP manager, when it is queried for.

The agents can be based on open-source libraries like the netSNMP Agent or they can be proprietary implementations. This is done typically by some equipment vendors. Key functions:

Collects management information about its local environment and stores it in the MIB.
When a request comes from the SNMP Manager, it retrieves management information from the MIB to send back as a response.
When requested from the SNMP Manager, it updates management information in the MIB concerning the configuration of the device it resides.
Signals an event or fault to the SNMP manager via traps.
Acts as a proxy for some non–SNMP manageable network nodes.

What is the Management Information Base (MIB)?

Every SNMP agent maintains an information database describing the managed device parameters and holding their latest or sometimes historical values.

The SNMP manager must know the structure of this database, to be able to request from the agent specific information. This commonly shared database between the Agent and the Manager is called Management Information Base (MIB).

The MIB is maintained, i.e. filled with data, in the Network Element. There is no copy of it in the SNMP Manager. The SNMP Manager uses the MIB structure to request specific information but when the SNMP Manager receives responses from the SNMP Agent, it translates the information received in a structure better suited to be stored in databases running on computers, i.e. SQL databases such as Oracle, mySQL, Postgres etc.

We have two types of MIBs:

Standard or public MIBs
Private MIBs.

The standard MIBs allow Equipment Manufacturers to make sure that their equipment can be managed from day one by Commercial Of-The-Shelf (COTS) Network Managers. This is possible because the popular Network Managers support almost all standard MIBs.

What happens if the standard MIBs do not include variables for a statistical or control values used specifically by a device? The standard is flexible enough to allow the Equipment Manufacturers to create their own private MIBs that the SNMP Agents and Managers can use.

Summarizing, MIB files are the set of questions that a SNMP Manager can ask the SNMP Agent. The SNMP Agent collects these data locally and stores it, as defined in the MIB. So, the SNMP Manager should be aware of these standard and private questions for every type of agent.

Is the MIB part of SNMP?

Not really.

Although we sometimes use the term SNMP to refer to both the protocol and the information database, if we want to be accurate, the protocol itself does not define which information (which variables) a Network Element should offer.

The protocol uses an extensible design, where the available information is defined by management information bases (MIBs).

MIB structure and Object Identifiers (OIDs)

So, how are the MIBs internally structured and what is the use of OIDs?

The MIB is a collection of information for managing Network Elements. The MIB comprises of variables that store values related with statistics or control of the Network Element it resides. We call these variables Managed Objects and we identify them by an Object Identifier or shorter Object ID (or OID).

MIBs actually use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP. As every Object ID is organized hierarchically in the MIB, we can represent the MIB hierarchy in a tree structure with individual variable identifiers.

2.5. Настройка SNMP

2.5.1. Описание протокола SNMP

SNMP (Simple Network Management Protocol) — стандартный протокол, который широко используется для управления сетевыми устройствами. SNMP протокол работает по технологии клиент-сервер. В роли сервера выступает SNMP Агент, которые работает на управляемых устройствах, например коммутаторах. В роли клиента NMS (Network Management Station) — станция управления сетью. На коммутаторах SNR поддерживается только функции SNMP агента.Обмен информацией между NMS и SNMP агентом осуществляется путем отправки стандартизированных сообщений. В SNMP определены 7 типов сообщений:

Get-Request
Get-Response
Get-Next-Request
Get-Bulk-Request
Set-Request
Trap
Inform-Request

NMS может посылать следующие сообщения Агенту: Get-Request, Get-Next-Request, Get-Bulk-Request и Set-Request. Агент отвечает сообщением Get-Response. Так-же Агент может отсылать Trap сообщения на NMS для информирования о событиях, например UP/DOWN порта и.т.п. Сообщение Inform-Request используется для обмена информацией между NMS.

2.5.2. Описание MIB

Формат сообщений которыми обмениваются NMS и SNMP Агент описан в Management Information Base (MIB). Информация в MIB организована в виде иерархической древовидной структуры. Каждая запись содержит OID (Object IDentifier) и короткое описание. OID состоит из набора чисел разделенных точками. Он определяет объект и его положение в дереве MIB как показано на рисунке.

Иерархия данных SNMP

Архитектура SNMP проста, однако у тех, кто с ней не знаком, иерархия данных, которую использует протокол, может вызвать затруднения.

Для обеспечения гибкости и расширяемости SNMP не требует от сетевых устройств обмена данными в жестком формате фиксированного размера. Вместо этого он использует древовидный формат, в котором данные всегда доступны для сбора.

Дерево данных состоит из нескольких таблиц, которые называются информационными базами управления или MIB. Базы MIB группируют определенные типы устройств или компонентов. Каждая MIB имеет уникальный идентификационный номер, а также идентификационную строку. Числа и строки могут использоваться взаимозаменяемо (аналогично IP-адресам и именам хостов).

Каждая MIB состоит из одного или нескольких узлов, которые представляют собой отдельные устройства или компоненты в сети. В свою очередь, каждый узел имеет уникальный идентификатор объекта, или OID . OID для данного узла определяется идентификатором MIB, в котором он существует, в сочетании с идентификатором узла в его MIB.

Это означает, что OID принимает форму набора чисел или строк. Например: 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3 .

Записанный строками, этот OID будет переводиться как:iso.org.dod.internet.private.transition.products.chassis.card.slotCps.
cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3.

Используя OID, менеджер может запросить у агента информацию об устройстве в сети. Например, если диспетчер хочет знать, включен ли интерфейс, он сначала запросит интерфейсную MIB, а затем проверит значение OID, отражающее рабочее состояние, чтобы определить, включен ли интерфейс.

Особенности и архитектура

В сети рассматриваемого стандарта функционирует один либо несколько административных компьютеров, где запущены программные модули, именуемые менеджерами.

Они выполняют операции отслеживания и управление хостами и периферийными устройствами, к которым подключены.

В общей сложности схема функционирования сети состоит из трёх обязательных компонентов:

агент – программа, которая контролирует управляемый девайс и отправляет сведения о нём администратору в специфичной для протокола форме – осуществляет медиацию данных;
целевые устройства, кои необходимо контролировать – компонент сети, реализующий односторонний (только для чтения) либо двухсторонний обмен информацией с менеджером;
система сетевого менеджмента (Network Management System либо NMS) – программа, взаимодействующая с менеджерами для мониторинга за сетью и её поддержки в актуальном состоянии;
MIB – база данных (необязательный компонент), ей посвящен следующий раздел.

К управляемым объектам относятся:

модемы и модемные стойки;
принтеры;
роутеры и коммутаторы;
мосты;
IP-телефоны и IP-камеры;
серверы и рабочие станции.

Они могут получать управляющие сигналы от администратора и реагировать на них соответствующим образом, перенаправлять их, исходя из заданных параметров.

Информация из объектов управления передаётся менеджеру, который интерпретирует полученные сведения в соответствии с заложенными в него алгоритмами.

Приложение-агент регулярно мониторит управляемый девайс, трансформирует данные в нужную для SNMP форму.

Такая схема позволяет одновременно работать с несколькими менеджерами одному сетевому администратору для управления и контроля работы сети.

snmpd configuration on CentOS/RHEL 7

# yum install net-snmp-utils net-snmp-devel net-snmp

If snmpd is already configured and running, stop the service using below command:

# systemctl stop snmpd.service

# net-snmp-create-v3-user -ro -A test123authPass -a SHA -X test123encPass -x AES user1
adding the following line to /var/lib/net-snmp/snmpd.conf:
createUser user1 SHA "test123authPass" AES test123encPass
adding the following line to /etc/snmp/snmpd.conf:
rouser user1

Note: You have two passwords here authentication password and privacy key for encryption. This should add a line /etc/snmp/snmpd.conf and /var/lib/net-snmp/snmpd.conf as mentioned in the console. So you need to delete those lines if you want to make any changes. So better take a backup of those two conf files.

# systemctl start snmpd.service

Testing with snmpwalk locally:

# snmpwalk -u user1-A test123authPass -a SHA -X test123encPass -x AES -l authPriv 127.0.0.1 -v3

If you have firewall enabled; add enable snmp ports at firewalld level using below commands:

# firewall-cmd --zone=public --add-port=162/udp --permanent
# firewall-cmd --zone=public --add-port=161/udp --permanent
# firewall-cmd --reload

Testing with snmpwalk from Remote machine:

# snmpwalk -u user1 -A test123authPass -a SHA -X test123encPass -x AES -l authPriv 192.168.22.21 -v3

Возможные проблемы

Если ваш клиент не может установить работающее соединение VNC, вам необходимо проверить следующее:

1. Проблемы с соединением — Конфигурация брандмауэра: если вы видите всплывающие ошибки о том, что клиент не может подключиться к удаленному хосту, вам необходимо проверить конфигурацию вашей сети и брандмауэра, чтобы убедиться, что нет проблем с блокировкой, которые могут помешать клиенту подключиться к порту сервера TCP 5901.

2. Черный экран с мышью — обновление YUM или переустановка графического интерфейса: если вы видите черный экран с работающим указателем мыши, это, вероятно, означает, что ваше VNC-соединение работает нормально, но есть что-то, что мешает правильному запуску графического интерфейса рабочего стола. Для исправления:

Выполните yum update, чтобы установить новейшие версии TigerVNC и самого графического интерфейса. Обязательно следите за любыми возникающими проблемами на этапе установки.
Удалите и переустановите графический интерфейс, используя команду yum remove / yum group remove и yum groupinstall снова. Если по-прежнему ничего не работает, вы можете попробовать установить другой графический интерфейс.

How to add Redhat subscription to the server?

If you are a Centos user you may skip this step and go right into the SNMP installation and

Since the error indicated that I don’t have a Redhat subscription, I went ahead and checked the Redhat subscription status by entering the commands below.

 ~]# cat /etc/sysconfig/rhn/systemid cat: /etc/sysconfig/rhn/systemid: No such file or directory 
 ~] # sudo subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Unknown

The output basically shows that I hadn’t added this server to the Redhat subscription.

I had a license to add this server to the subscription. Hence, I went ahead and added the subscription by running the below command.

 ~]# subscription-manager register --auto-attach
Registering to: subscription.rhsm.redhat.com:443/subscription
Username: your username
Password: your password
The system has been registered with ID: you will find your ID here
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Server
Status:       Subscribed

Let me check the Redhat subscription status now.

 ~]# sudo subscription-manager status
+-------------------------------------------+
System Status Details
+-------------------------------------------+
Overall Status: Current

Aha! Some sign of relief as I just added the Redhat server to the Redhat subscription now.Note: Can you run this command while the server is in production?Of course, you can, as it’s just attaching the subscription and won’t make any further changes on the server.

What if I have a test environment where I don’t have Redhat subscription?

If you are in the lab, you must enable ‘Remote Management for Linux’ during the Redhat OS installation. That way, the server would enable the SNMP package before the installation, and you would have the package ready to use. If not, you would need to attach the Redhat subscription to download the SNMP package to the system, which you usually may not have on lab servers, or you may need to find alternate ways to download and install the SNMP package on the Redhat server later on.

Стандарты управления сетями[править]

Помимо стандартов SNMP сообщества IETF есть стандарты, принимаемые международными органами стандартизации; вот крупнейшие из них:

Организация	Стандарты	Особенности
IETF	SNMP	Управление должно быть простым, ориентировано на переменные
ISO	CMIP, CMIS	Управление должно быть мощным, объектно-ориентированное
ITU-T	TMN	Определяется только архитектура
DMTF	WBEM, CIM	Управление сетями и системами, объектно-ориентированное
OMG	CORBA	Архитектура удалённых объектов

Ныне самым успешным семейством стандартов является SNMP; он лидирует по числу управляемых систем (агентов). Управляющие системы (менеджеры) обычно поддерживают множество стандартов, поэтому здесь сложно говорить о лидерстве SNMP. По количеству вложенных денег, возможно, лидирует Telecommunications Management Network (TMN).

Показательно проследить зависимость популярности стандартов от среды их применения. В локальных и глобальных сетях передачи данных, использующих Протокол интернета (Internet Protocol, IP) наиболее широко распространён стандарт SNMP. В системах учрежденческих автоматических телефонных станций (УАТС) и в публичных телефонных сетях наиболее часто используются проприетарные решения. В мобильных сетях в основном используются решения на основе стандартов Международной Стандартизационной Организации (ISO).

Почти все успехи SNMP связаны с особенностями процесса стандартизации в IETF:

Стандарты бесплатны и свободно распространяемы
Стандарты легко доступны в электронной форме
Быстрое развитие стандартов, продуманные этапы стандартизации
На всех этапах ведётся техническая экспертиза
Рабочие группы возглавляют технические, а не политические лидеры
Прототипы систем на основе стандартов демонстрируют их применимость

Недостатки протокола SNMP

Протокол SNMP служит основой многих систем администрирования, хотя имеет несколько принципиальных недостатков.

Отсутствие средств взаимной аутентификации агентов и менеджеров. Единственным средством, которое можно было бы отнести к средствам аутентификации, является так называемая строка общности в сообщениях. Эта строка передается по сети в открытой форме в SNMP-сообщении и служит основой для объединения агентов и менеджеров, так что агент взаимодействует только с теми менеджерами, у которых та же строка общности, что и строка, хранящаяся в памяти агента. Это, безусловно, не способ аутентификации, а способ структурирования агентов и менеджеров. Версия SNMP v.2 должна была ликвидировать этот недостаток, но в результате разногласий между разработчиками стандарта новые средства аутентификации хотя и появились в этой версии, но как необязательные.

Работа через ненадежный протокол UDP (а именно так работает подавляющее большинство реализаций агентов SNMP) приводит к потерям аварийных сообщений от агентов к менеджерам, что может привести к некачественному администрированию. Исправление ситуации путем перехода на надежный транспортный протокол с установлением соединения чревато потерей связи с огромным количеством встроенных агентов SNMP, имеющихся в установленном в сетях оборудовании. (Протокол CMIP изначально работает поверх надежного транспорта стека OSI и этим недостатком не страдает.)

Разработчики платформ администрирования стараются преодолеть эти недостатки. Например, в системе HP OV Telecom DM TMN, являющейся платформой для разработки многоуровневых систем администрирования в соответствии со стандартами ISO, работает новая реализация SNMP, организующая надежный обмен сообщениями между агентами и менеджерами за счет самостоятельной организации повторных передач SNMP-сообщений при их потере.

Как сделать перезапуск сети в CentOS

Ранее я уже касался этого вопроса, но на всякий случай повторим отдельно. Допустим, вы внесли некоторые изменения в конфигурацию сети. Как применить эти настройки, не перезагружая сервер? Очень просто. Для перезапуска сети в CentOS достаточно воспользоваться командой systemd:

Если увидите ошибку:

Значит у вас не установлен пакет network-scripts, а управление сетью выполняется с помощью NetworkManager, который сам перезапускает сеть после изменения настроек.

Если у вас старая версия Centos без systemd, а это 6-я версия и младше, то сеть перезапускается вот так.

Сетевая служба перечитает все сетевые настройки и применит изменения.

Шаг 4 — Проверка аутентификации для сервера агента

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

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

: этот флаг используется для указания версии протокола SNMP, которую вы хотите использовать. В этом обучающем руководстве мы будем использовать версию 3.
: этот флаг используется, если вы работаете со строками доступа для аутентификации в стиле, используемом в версиях 1 и 2 протокола SNMP. Поскольку вы используете аутентификацию с помощью пользователя в стиле версии 3, вам не нужно использовать этот флаг.
: этот параметр используется для указания имени пользователя, которого вы будете использовать для аутентификации. Для чтения или изменения с помощью SNMP необходимо выполнять аутентификацию с помощью известного имени пользователя.
: этот флаг используется для определения уровня безопасности, который вы используете при подключении. Возможные значения — при отсутствии аутентификации и шифрования, — при наличии аутентификации, но без шифрования, и — при использовании аутентификации и шифрования. Имя пользователя, которое вы используете, необходимо настроить в соответствии с уровнем безопасности, который вы указываете, либо аутентификация не будет выполнена.
: этот параметр используется для указания протокола аутентификации, который используется. Возможные значения — или . Его значение должно соответствовать информации, которая была указана при создании пользователя.
: этот параметр используется для указания протокола шифрования, который используется. Возможные значения — или . Его значение должно соответствовать информации, которая была указана при создании пользователя. Это необходимо, если после привилегий пользователя идет , который делает шифрование обязательным.
: данный флаг используется для предоставления фразы-пароля аутентификации, которая была указана при создании пользователя.
: эта фраза-пароль шифрования, которая была указана при создании пользователя. Если ничего не было указано, но алгоритм шифрования был предоставлен, будет использоваться фраза-пароль аутентификации. Это обязательно, если указан параметр , либо если после привилегий пользователя идет , что говорит о необходимости шифрования.

Используя эту информацию, вы можете создать ваши команды. С учетом того, как вы настроили вашего пользователя bootstrap, команды, которые вы будете использовать с этой учетной записью, будут выглядеть следующим образом:

С помощью вашего сервера менеджера выполните тест, чтобы убедиться, что ваша учетная запись bootstrap доступна. Введите следующую информацию, чтобы вывести на экран данные о системе для сервера агента:

Строка — это OID, который отвечает за отображение информации о системе. Он будет возвращать вывод на удаленной системе.

Результат будет выглядеть следующим образом:

Теперь, когда вы убедились, что можете выполнять аутентификацию для сервера с запущенным демоном SNMP, вы можете перейти к созданию стандартной учетной записи пользователя.

База данных

Роль хранилища служебных данных выполняет база управляющей информации MIB (Management Information Base).

Ввиду того, что адреса устройств в цифровом виде очень сложны для запоминания человеком, к ним применяются MIB, описывающие структуру управляемой информации и использующие иерархию пространства имён.

Они также содержат идентификаторы объектов сети, состоящие из двух компонентов:

текстовое наименование;
соответствующий ему цифровой адрес.

Данные управляющей базы не являются неотъемлемым звеном сетей, построенных на основании SNMP протокола, их задача второстепенная – перевод имён объектов из понимаемого человеком формата в цифровой, соответствующий стандарту SNMP. Аналог – DNS серверы, осуществляющие перевод IP в понимаемые людьми адреса сайтов.

Ввиду несовпадения структуры элементов на разных девайсах, без MIB нереально определить цифровые адреса требуемых объектов.

Иерархическая структура БД управляющей информации обязательно содержит разветвления, каждое из коих может также разветвляться.

Они позволяют разработчику интеллектуальных девайсов управлять уникальными функциями оборудования на основании специфических объектов MIB.

Структура

Ныне существует ряд стандартов базы данных для SNMP: MIB-I, MIB-II, MIB-III и RMON MIB.

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

В первой версии спецификация MIB характеризовалась только операциями чтения, запись и редактирование появились во второй редакции, а шифрование – в третьей.

MIB-I определяется 114 объектами, разгруппированными на следующие категории:

Interfaces – конфигурация сетевых устройств (их число, предельный объем пакета);
System – общая информация о девайсе (ID);
ICMP – информация, касающаяся протокола передачи управляющих сигналов ICPM;
Internet Protocol – информация, которая относится к IP;
Address Translation Table – таблица соответствий между физическими и сетевыми адресами;
TCP – сведения о TCP;
UPD – информация про UDP;
EGP – данные о протоколе Exterior Gateway Protocol, который отвечает за обмен маршрутными сведениями.

Рис. 3 – Схема функционирования

В MIB-II появилась пара групп, а число объектов заметно возросло – до 186 штук:

SysUpTime – продолжительность функционирования системы со времени включения;
SysObjectID – идентификатор оборудования.

Соответствие архитектурному стилю REST[править]

Архитектурный стиль REST — это унифицированный многоуровневый кэшируемый клиент-серверный стиль с кодом по запросу и без сохранения состояния (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Как мы определили в результате анализа архитектуры SNMP, система SNMP определяется унифицированным многоуровневым клиент-серверным стилем без сохранения состояния (Unified-Layered-Client-Stateless-Server, ULCSS).

Как мы видим, на SNMP не накладываются ограничения, связанные с репликацией (наличие кэша) и мобильным кодом (применение кода по запросу). В этом смысле стиль SNMP — более свободный, чем REST, т. е. содержит меньше архитектурных особенностей, которые, например, необходимо учитывать при моделировании систем с такой архитектурой.

Однако, даже в SNMPv1 есть особая операция , инициируемая агентом асинхронно по отношению к менеджеру. В SNMPv2 вводится операция , которая также выполняется асинхронно, но между двумя менеджерами. При выполнении таких операций клиент и сервер меняются ролями. При этом используется принцип интеграции на основе извещений. Это элементы однорангового стиля взаимодействия (Peer-to-Peer), хотя в данном случае роли клиента и сервера для конкретных типов протокольных операций выражены явно. В этом смысле стиль SNMP — более ограниченный, чем REST.

Таким образом, при определённых ограничениях система SNMP может быть рассмотрена как REST-овская распределённая система.

Выводы

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

Остались вопросы по работе SNMP? Специалисты Xelent обязательно ответят на них – оставьте заявку на сайте или свяжитесь с нами по указанным телефонам.