SNMP（简单网络管理协议）介绍

提供：ZStack云计算

系列教程

本教程为如何利用SNMP实现网络监控与管理系列三篇中的第一篇。

内容介绍

作为系统管理员，我们的主要工作就是收集来自服务器与基础设施的准确信息。目前多种工具都能够帮助我们实现此类信息收集任务，而其中大部分都以同一技术为基础，即SNMP。

SNMP全称为简单网络管理协议。其不仅能够收集服务器的当前状态信息，同时允许管理员借此对预设值进行变更。另外，这套协议本身虽然非常简单，但在实际程序中的使用结构却往往相当复杂。

在本教程中，我们将探讨SNMP协议的各基础知识。具体而言，我们将了解其使用方式、网络中的协议使用惯例以及不同协议版本等等。

基本概念

SNMP是一种用于实现网络堆栈应用层的协议（具体请参阅网络层相关说明)。该协议能够以统一方式对来自不同系统的信息进行收集。尽管其能够以多种途径接入系统，但采用的信息查询方法与路径相关信息则是完全标准化的。

SNMP协议拥有多种版本，而且多数联网硬件设备都会采用某种形式的SNMP接入机制。目前应用最为广泛的为SNMPv1，但其安全性存在一定问题。它的超高人气主要归功于普遍性与较早的推出时间。因此，除非大家拥有明确理由，否则推荐各位优先选择SNMPv3，其包含更多更为先进的安全功能。

总体来讲，由SNMP配置的网络将由多台包含SNMP代理的设备构成。所谓代理，就是一款能够对特定硬件信息进行收集、整理并利用SNMP协议实现查询响应的程序。

这种模式中，负责向代理查询信息的组件被称为SNMP manager。这些组件查询的信息主要为启用SNMP设备的全部状态，且可执行请求以收集信息并设置特定属性。

SNMP Mangers

SNMP manager就是一台计算机，其配置方式为轮询SNMP代理以获取信息。在核心功能层面，这种管理组件在复杂性上远低于客户端配置，因为它的作用只有一种——进行数据查询请求。

该manager可以是任何能够向SNMP代理查询数据且包含正确证书的设备。有时候，我们也可以将其作为监控套件的组成部分。

SNMP协议中的几乎全部定义命令都需要由manager组件负责发送，其中包括GetRequest,GetNextRequest,GetBulkRequest,SetRequest,InformRequest以及Response。另外，manager还需要响应Trap并Response信息。

SNMP代理

SNMP代理的工作很多。它们负责收集本地系统信息并将其保存为可供查询的数据库格式。这种数据库被称为“管理信息库”，或者简称MIB。

MIB是一套层次化预定义结构，负责存储可供查询或者设置的信息。我们可以立足于一套拥有正确凭证的认证主机（即SNMP manager）生成拥有适当格式的SNMP请求。

代理计算机则配置哪些manager有权对其信息进行访问。它还能够作为中间人报告那些其能够接入，但并未面向SNMP流量进行配置的设备的相关信息。如此一来，我们就能够非常灵活地在线访问组件与SNMP。

SNMP代理包含大量由该协议定义的命令，其中包括GetRequest,GetNextRequest,GetBulkRequest,SetRequest以及InformRequest。另外，代理还能够发送Trap消息。

了解管理信息库

SNMP系统中最难以理解的部分当数MIB，或者说管理信息库。MIB是一套遵循manger与代理所提出标准的数据库。这是一套层级化结构，采用全局标准但亦可灵活针对特定供应商方案做出调整。

MIB结构可以被理解为一套向上而下的树状结构。每个分支都由一个标识数字（从1开始）与一个标识字符串进行指定，且二者在整套结构中独一无二。大家可以交替使用字符串与数字。

要引用树状结构中的特定节点，大家必须从该树的未命名root处追踪路径至所需节点。其父ID（数字或字符串）谱系通常为起点，其贯通至目标节点并以此形成地址。层次结构中的每个结点以一个点（.）代表，即各ID字符串或数字以点隔开。这样一条完整的地址即被称为一个对象标识符，或者OID。

硬件供应商有时会将SNMP代理嵌入至设备当中，从而以定制化方式拆分自己的字段与数据点。然而，其同样属于标准化MIB分支，经过合理定义且可用于任何设备。

我们讨论的标准分支皆人性于同一套父分支结构。该分支负责根据MIB-2规范进行信息定义，并作为设备的执行标准存在。

该分支的基础路径为：

1.3.6.1.2.1

我们可以将其解释为字符串形式：

iso.org.dod.internet.mgmt.mib-2

其中1.3.6.1或者iso.org.dod.internet部分代表OID，负责定义互联网资源。而2或者mgmtthat则属于一个管理子类。接下来的1或mib-2则定义MIB-2规范。

这里推荐大家参阅MIB树状结构。此页面显示了我们之前谈到的交界处的连接节点。大家可以借此向上或向下查看“superior”与“subsidiary”引用的含义。

另一款类似的工具为SNMP对象导航器，由思科公司提供。我们可以借此找到自己需要的信息。另外，SolarWinds也提供类似的树状结构。

基本上，如果大家希望查询设备上的信息，那么大部分路径皆以1.3.6.1.2.1开头。大家可以浏览树界面以了解可供查询及设置的信息。

SNMP协议命令

SNMP之所以广受欢迎，一大原因在于其命令相当简单。具体操作要求不高，但又拥有充足的灵活性，这一切都使其成为一套理想的解决方案。

以下PDU，全称为协议数据单元，用于描述协议之后附加的具体消息类型：

Get: Get消息由manager发送至代理处，用于请求特定OID值。此请求由Response消息进行应答，并最终携带相关数据重新回归manager。
GetNext: GetNext消息允许manager请求MIB中的下一序列对象。通过这种方式，我们能够遍历MIB结构，而无需担心具体的OID查询方式。
Set: Set消息由manager发送至代理处，旨在变更该代理所持有的某变量值。我们可以借此控制配置信息，或者修改远程主机状态。这也是惟一一条由该协议定义的写入操作。
GetBulk: 这条请求负责一次性实现多条GetNext请求。返回结果所包含的数据量仅受数据包携带能力的限制。
Response: 由代理发送的response消息用于将任意所请求信息发送回manager。其既负责所请求数据的传输，同时也对收到的请求做出确认。如果无法返回请求的数据，response会添加错误字段以进行进一步信息查询。以上各请求都会匹配对应的response以及Inform消息。
Trap: 由代理生成的trap消息指向manager。Traps属于被动型异步通信，主要由代理用于向事件的对应manager发布当前所托管设备的状态。
Inform:为了确认trap收取完成，manager会向代理发回一条Inform消息。如果该代理未收到此消息，则会再次发送trap消息。

凭借这七种数据单元类型，SNMP得以查询并发送与网络设备相关的各类信息。

协议版本

SNMP协议自初次出现以来已经经历了多次变革。其最初规范分别作为RFC 1065、1066与1067出现于1988年。尽管时隔多年，该版本仍然广受支持。然而，由于此版本存在多种安全问题，包括以明文方式保存凭证等，因此我们不推荐大家使用。

该协议的版本2出现于1993年，针对原有版本做出一系列改进。此版本提供新的“party-based”安全模式，旨在解决上代版本的安全难题。然而，这套新模式始终人气不高，这主要是由于其难以理解及实现。

因此，版本2的多种“副产品”应运而生，其不仅保留了原有改进，同时亦去掉了饱受诟病的安全模式。在SNMPv2c中，基于社区的验证机制（与v1一致）被重新引入。这是v2协议中最具人气的版本。而另一套实现方案SNMPv2u则采用基于用户的安全机制，但其也未能打开市场。

1998年，SNMP协议的第三代版本（也是当前版本）成为新的规范提案。从用户角度看，其最重要的变化就是采用基于用户的安全系统。我们可以利用以下方式设置出用户需要的验证要求：

NoAuthNoPriv: 以此级别接入的用户不具备验证身份，且无法对发送及接收的消息进行隐私保护。
AuthNoPriv: 使用此模式接入必须经过验证，但发出的消息未经过加密。
AuthPriv: 必须验证且消息经过加密。

除了验证之外，版本3还提供访问控制机制为用户可访问的分支提供细化控制。新版本亦能够利用其它传输协议提供的安全保护，例如SSH或者TLS。

总结

在下一篇系列教程中，我们将探讨如何安装并配置必要的组件，从而在系统中上手使用SNMP。

本文来源自DigitalOcean Community。英文原文：An Introduction to SNMP (Simple Network Management Protocol) By Justin Ellingwood

翻译：diradw