В создание протокола SNMP внесли свой вклад разработки по трем направлениям:
Достоинства и недостатки этих трех методов (HEMS, SGMP и CMOT) частои горячо обсуждались в течение второй половины 1987 г. В начале 1988 г.был образован комитет Internet Activities Board - IAB (IAB - это группа, ответственная за техническую разработку протоколов Internet) для разрешения дебатов по поводу протокола сетевого управления. В конечномитоге комитет IAB пришел к соглашению, что улучшенная версия SGMP,которая должна была называться SNMP, должна стать временным решением;для долгосрочного применения должна быть проанализирована одна изтехнологий, базирующихся на OSI (либо СМОТ, либо сам СMIP). Дляобеспечения легкого пути наращивания была разработана общая структурасетевого управления (которая теперь называется стандартной СтруктуройУправления Сети - Network Management Framework).
Сегодня SNMP является самым популярным протоколом управления различнымикоммерческими, университетскими и исследовательскими об'единенными сетями. Деятельность по стандартизации, связанная с SNMP, продолжаетсяпо мере того, как поставщики разрабатывают и выпускают современныеприкладные программы управления, базирующиеся на SNMP. SNMP относительно простой протокол, однако набор его характеристик являетсядостаточно мощным для решения трудных проблем, возникающих при управлении гетерогенных сетей.
SNMP является протоколом прикладного уровня, предназначенным для облегчения обмена информацией управления между сетевыми устройствами.Пользуясь информацией SNMP (такой, как показатель числа пакетов всекунду и коэффициент сетевых ошибок), сетевые администраторы могут более просто управлять производительностью сети и обнаруживать и решать сетевые проблемы.
Модель управления
Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемыхустройствах, в которых они работают, и делают эту информацию доступнойдля систем управления сетями (network management systems - NMS) с помощью протокола SNMP. Эта модель представлена графически на Рис. 32-1.
Управляемое устройство может быть узлом любого типа, находящимся в какой-нибудь сети: это хосты, служебныеустройства связи, принтеры, роутеры, мосты и концентраторы. Т.к.некоторые из этих систем могут иметь ограниченные способности управления программным обеспечением (например, они могут иметь центральные процессоры с относительно малым быстродействием илиограниченный об'ем памяти), программное обеспечение управления должносделать допущение о наименьшем общем знаменателе. Другими словами, программы управления должны быть построены таким образом, чтобы минимизировать воздействие своей производительности на управляемое устройство.
Т.к. управляемые устройства содержат наименьший общий знаменательпрограммного обеспечения управления, тяжесть управления ложится наNMS. Поэтому NMS обычно являются компьютерами калибра АРМпроектировщика, которые имеют быстродействующие центральные процессоры,мегапиксельные цветные устройства отображения, значительный об'ем памяти и достаточный об'ем диска. В любой управляемой сети может иметься одна или более NMS. NMS прогоняют прикладные программысетевого управления, которые представляют информацию управления пользователям. Интерфейс пользователя обычно базируется настандартизированном графическом интерфейсе пользователя (graphical user interface - GUI).
Сообщение между управляемыми устройствами и NMS регулируется протоколом сетевого управления. Стандартный протокол сети Internet, Network Management Framework, предполагает парадигму дистанционной отладки,когда управляемые устройства поддерживают значения ряда переменных исообщают их по требованию в NMS. Например, управляемое устройствоможет отслеживать следующие параметры:
Типы команд
Если NMS хочет проконтролировать какое-либо из управляемых устройств,она делает это путем отправки ему сообщения с указанием об изменении значения одной из его переменных. В целом управляемые устройства отвечают на четыре типа команд (или инициируют их):
Различия в представлениии информации
Обмен информацией в управляемой сети находится потенциально под угрозойсрыва из-за различий в технике представления данных, используемой управляемыми устройствами. Другими словами, компьютеры представляют информацию по-разному; эту несовместимость необходимо рационализировать, чтобы обеспечить сообщение между различными системами. Эту функцию выполняет абстрактный синтаксис. SNMP использует для этой цели подмножество абстрактного синтаксиса, созданного дляOSI - Abstract Syntax Notation One (ASN.1) (Система обозначений для описания абстрактного синтаксиса). ASN.1 определяет как форматы пакетов, так и управляемые об'екты. Управляемый об'ект-это простохарактеристика чего-либо, которой можно управлять. Управляемый об'ект отличается от переменной, которая является конкретной реализациейоб'екта. Управляемые об'екты могут быть скалярными (определяя отдельную реализацию) или табулярными величинами (определяя несколько связанных друг с другом реализаций).
Базы данных управления
Все управляемые об'екты содержатся в Информационной базе управления (Management Information Base - MIB),которая фактически является базой данных об'ектов. ЛогическиMIB можно изобразить в виде абстрактного дерева, листьями которогоявляются отдельные информационные элементы. Идентификаторы об'ектовуникальным образом идентифицируют об'екты MIB этого дерева.Идентификаторы об'ектов похожи на телефонные номера тем, что ониорганизованы иерархически и их отдельные части назначаются различными организациями. Например, международные телефонные номера состоят изкода страны (назначаемого международной организацией) и телефонногономера в том виде, в каком он определен в данной стране. Телефонныеномера в США далее делятся на код области, номер центральнойтелефонной станции (СО) и номер станции, связанной с этой СО.Аналогично, идентификаторы об'ектов высшего уровня MIB назначаютсяМеждународной Электротехнической Комиссией ISO (ISO IEC). ID об'ектовнизшего уровня назначаются относящимися к ним организациями. На Рис. 32-2 изображены корневая и несколько наиболее крупных ветвейдерева MIB.
Дерево MIB расширяемо благодаря экспериментальным и частным ветвям.Например, поставщики могут определять свои собственные ветви для включения реализаций своих изделий. В настоящее время вся работа по стандартизации ведется на экспериментальной ветви.
Структуру MIB определяет документ, называемый Структура ИнформацииУправления (Structure of Management Information - SMI). SMI определяетследующие типы информации:
Операции
SNMP является простым протоколом запроса/ответа. Узлы могут отправлятьмножество запросов, не получая ответа. Определены следующие 4 операции SNMP:
Сообщения SNMP состоят из 2 частей: имени сообщества (community name) и данных (data). Имя сообщества назначает среду доступа для набора NMS,которые используют это имя. Можно сказать, что NMS, принадлежащие одному сообществу, находятся под одним и тем же административным началом. Т.к. устройства, которые не знают правильного имени сообщества, исключаются из операций SNMP, управляющие сетей такжеиспользуют имя сообщества в качестве слабой формы опознавания.
Информационная часть сообщения содержит специфичную операцию SNMP (get, set, и т.д.) и связанные с ней операнды. Операнды обозначаютреализации об'екта, которые включены в данную транзакцию SNMP.
Сообщения SNMP официально называются протокольными единицами данных(protocol data units - PDU). На Рис. 32-3 изображен формат пакета SNMP.
PDU операций get и set SNMP состоят из следующих частей:
SNMP Version 2.0 is an evolution of the initial version SNMP (now called SNMP v.1) derived from two specifications published in July 1992: Secure SNMP and the Simple Management Protocol (SMP).
Secure SNMP defined security features that are not available in SNMP v.1, but Secure SNMP used message formats that are incompatible with SNMP v.1. Compared with SNMP v.1, SMP offered greater flexibility in terms of the resources it can manage, the size of data transfers, and the environments in which it can operate (OSI networks and other communications architectures in addition to TCP/IP networks.) A subset of SMP capabilities allowed it to interoperate with SNMP v.1.
As the Internet community analyzed these two new specifications, a consensus emerged that SMP should serve as the basis for the development of a new SNMP standard and that many of the security features from Secure SNMP would be incorporated into that new standard. The result is SNMP v.2, which was published as a set of proposed Internet standards in the spring of 1993.
SNMP v.2 includes improvements in the SMI, in protocol operations, in management architecture, and in security.
The SNMP v.2 SMI supports several new data types and incorporates a new convention for creating and deleting conceptual rows in a table. The network address data type now supports OSI NSAP addresses, as well as IP addresses. There is now a 64-bit counter data type, as well as the existing 32-bit counter, and there is now an unsigned integer type to represent integers in the range 0 to 232--1.
SNMP v.2 introduces the concept of an information module, which specifies a group of related definitions. There are three kinds of information modules:
SNMP v.2 defines two new operations:
With the exception of the way SNMP v.2 responds to get, get-next, set, and trap operations, the SNMP v.2 versions of these operations are identical to their SNMP v.1 counterparts. In SNMP v. 1, if the responding agent cannot provide values for all the variables in the list, it does not provide any values. In SNMP v.2, a variable binding list is prepared even if values cannot be supplied for all variables. If an exception condition is associated with the variable, the variable is paired with the name of that exception condition.
To simplify PDU processing, all operations except the get-bulk operation use the same PDU format. Figure 32-4 shows the PDU format used by the get, get-next, set, response, and trap operations, as well as the new inform operation.
Figure 32-4 : PDU Format for the Get, Get-Next, Inform, Response, Set, and SNMP v.2 Trap Operations
The fields of the PDU for get, get-next, set, response, and trap operations are as follows:
When used by the get, get-next, set, trap, and inform operations, the error status and error index fields are set to 0. Only the response operation sets the error status and error index fields.
The get-bulk request operation uses the PDU format shown in Figure 32-5.
Figure 32-5 : PDU Format for the Get-Bulk Operation
The fields of the PDU for the get-bulk operation are as follows:
SNMP v.2 supports the centralized network management strategies of SNMP v.1 as well as distributed strategies based on the new manager-to-manager MIB. In a distributed architecture, some systems operate both in the role of manager and of agent. When acting as an agent, a system accepts commands from a superior management system. These commands can deal with access to information stored locally or can require the system (now acting as an intermediate manager) to provide summary information about subordinate agents. In addition, an intermediate manager can issue trap information to a superior manager.
The lack of authentication capability is the most serious security deficiency of SNMP v.1, making it vulnerable to unauthorized changes to the configuration of a network. For that reason, many vendors have not implemented set operations, thereby reducing SNMP v.1 to a monitoring facility.
SNMP v.2 includes provisions for preventing the following types of security threats:
Figure 32-6 : SNMP v.2 Message Format
The fields of the SNMP v.2 message formats are as follows:
SNMP v.2 supports three uses of the message format:
Through the authentication procedure, SNMP v.2 can assure that messages are received as sent, without modification or replays. A message-digest algorithm calculates a 128-bit digest over the appropriate portion of an SNMP v.2 message. The digest added to the message is recalculated by the recipient to verify that there has been no modification. The timestamps are based on the maintenance of loosely synchronized clocks among managers and agents. The message recipient uses the timestamp to verify that the message is recent, to determine the proper resequencing of multiple messages, and to detect message replays.
The new message formats, protocol operations, and security features make SNMP v.2 incompatible with SNMP v.1. The easiest way to accomplish to transition an existing network from SNMP v.1 to SNMP v.2 is to upgrade the manager systems to support SNMP v.2 in a way that allows coexistence of SNMP v.2 managers, SNMP v.2 agents, and SNMP v.1 agents. The issues fall into two categories:
One way to achieve coexistence at the protocol level is to reach existing SNMP v.1 agents through an SNMP v.2 agent that acts as a proxy agent on behalf of an SNMP v.2 manager. The proxy agent maps get-bulk PDUs to get-next PDUs and SNMP v.1 trap PDUs to SNMP v.2 trap PDUs, but passes get, get-next, and set PDUs unchanged, as shown in Figure 32-7.
Figure 32-7 : Mapping Approach for Interoperability
Another way to achieve coexistence at the protocol level is to use a "bilingual" SNMP v.2 manager that supports both SNMP v.1 and SNMP v.2. When a management application needs to contact an agent, it can use SNMP v.1 or SNMP v.2, based on information in a local database that identifies the agent as supporting SNMP v.1 or SNMP v.2, as shown in Figure 32-8.
Figure 32-8 : Bilingual Manager Approach for Interoperability
