NetDevOps — SNMP 协议

Posted 2021-12-20 范桂飓

目录

文章目录

• 目录
• SNMP
• 协议架构
• 局限性

SNMP

SNMP 协议的第 1 个相关 RFC 1065 发布于 1988 年，距今已有 30 年。

SNMP 在网络监控领域已经被广泛使用，例如：Zabbix、Nagios、Cacti 等开源的管理工具，均采用了 SNMP 来采集网络设备接口流量带宽和其他设备信息。

同时，也有大量的基于 Python 的 SNMP 库用来实现运维开发，例如：PySNMP、 EasySNMP、 Net-SNMP 等，并且它们都可以集成到 Ansible 和 SaltStack 等自动化运维工具上。

目前来说，SNMP 更多的被用于做信息采集，提供告警和可视化报表。而在自动化运维方向，则有更适合的 NETCONF 逐渐替换掉 SNMP。

协议架构

在 SNMP 架构中，一个网络设备以 daemon 的方式运行 SNMP Agent，而 NMS（网络管理系统）和网络运维人员所使用的各种 SNMP 管理工具则称为 SNMP Manager，SNMP Agent 能够响应来自 SNMP Manager 的各种请求信息。

SNMP Agent 会维护一个 MIB（管理信息库），里面保存着大量的 OID（对象标识符）。一个 OID 是一对唯一的 Key/Value，SNMP Manager 向 SNMP Agent 查询或修改若干个 Key 所对应的 Value，就可以实现信息采集或者网络设备的配置修改。

需要注意的是，SNMP Manager 一侧的 MIB 并不是必需的。如果使用数字 OID 1.3.6.1.2.1.2.2.1.5，SNMP Manager 可以直接从 SNMP Agent get 接口流量带宽，而不需要安装完整的 MIB。

局限性

• 太古老，并发性能不好。
• 基于 UDP 协议进行不可靠传输，虽然在应用层有 Response 机制保证丢包之后的重复 get/set，但代价就是性能和运行时间都受到影响。
• 最致命的问题是，各厂商都大量的使用私有 MIB，却不存在一个可以自动发现网络设备当前所采用的 MIB 的机制。网络运维人员必须分别向设备厂商索取网络设备的 MIB，耗费大量的时间整理自己需要的 OID，再手工导入到自动化运维平台或者脚本当中。