RFC 1157 - 简单网络管理协议 (SNMP)
网络工作组 请求评论: 1157 废弃: RFC 1098
作者: J. Case (SNMP Research) M. Fedor (Performance Systems International) M. Schoffstall (Performance Systems International) J. Davin (MIT Laboratory for Computer Science)
日期: May 1990
目录
- 1. 本备忘录的状态
- 2. 引言
- 3. SNMP 架构
- 3.1. 架构目标
- 3.2. 架构要素
- 3.2.1. 管理信息的范围
- 3.2.2. 管理信息的表示
- 3.2.3. 管理信息所支持的操作
- 3.2.4. 协议交换的形式和含义
- 3.2.5. 管理关系的定义
- 3.2.6. 被管对象引用的形式和含义
- 3.2.6.1. 消除有歧义的 MIB 引用
- 3.2.6.2. 解析跨 MIB 版本的引用
- 3.2.6.3. 对象实例的标识
- 3.2.6.3.1. ifTable 对象类型名称
- 3.2.6.3.2. atTable 对象类型名称
- 3.2.6.3.3. ipAddrTable 对象类型名称
- 3.2.6.3.4. ipRoutingTable 对象类型名称
- 3.2.6.3.5. tcpConnTable 对象类型名称
- 3.2.6.3.6. egpNeighTable 对象类型名称
- 4. 协议规范
- 4.1. 过程要素
- 4.1.1. 公共结构
- 4.1.2. GetRequest-PDU
- 4.1.3. GetNextRequest-PDU
- 4.1.3.1. 表遍历示例
- 4.1.4. GetResponse-PDU
- 4.1.5. SetRequest-PDU
- 4.1.6. Trap-PDU
- 4.1.6.1. coldStart Trap
- 4.1.6.2. warmStart Trap
- 4.1.6.3. linkDown Trap
- 4.1.6.4. linkUp Trap
- 4.1.6.5. authenticationFailure Trap
- 4.1.6.6. egpNeighborLoss Trap
- 4.1.6.7. enterpriseSpecific Trap
- 5. 定义
- 6. 致谢
- 7. 参考文献
- 8. 安全注意事项
- 9. 作者地址
1. 本备忘录的状态
本 RFC 是 RFC 1098 的重新发布,更改了"本备忘录的状态"部分以及一些小的印刷更正. 本备忘录定义了一个简单的协议,逻辑上远程用户可以通过该协议检查或更改网络元素的管理信息. 特别是,与其描述管理信息结构和管理信息库的配套备忘录一起,这些文档提供了用于管理基于 TCP/IP 的互联网(特别是互联网)的简单,可行的体系结构和系统.
互联网活动委员会建议所有 IP 和 TCP 实现都应通过网络进行管理. 这意味着实现互联网 MIB (RFC-1156) 和至少两个推荐的管理协议 SNMP (RFC-1157) 或 CMOT (RFC-1095) 之一.需要注意的是,目前SNMP是完整的互联网标准,CMOT是草案标准. 另请参阅主机和网关要求 RFC,了解有关此标准适用性的更多具体信息.
请参阅最新版本的"IAB 官方协议标准"RFC,了解有关标准 Internet 协议的现状和现状的最新信息.
本备忘录的分发不受限制.
2. 引言
正如 RFC 1052(IAB 关于制定互联网网络管理标准的建议)中所报告的那样,针对基于 TCP/IP 的互联网的网络管理采取了双管齐下的策略. 短期内,简单网络管理协议(SNMP)将用于管理互联网社区中的节点. 从长远来看,OSI网络管理框架的使用将受到检验.生成了两个文档来定义管理信息:定义管理信息结构 (SMI) [2] 的 RFC 1065 和定义管理信息库 (MIB) [3] 的 RFC 1066. 这两个文档的设计目的是与 SNMP 和 OSI 网络管理框架兼容.
这一策略在短期内非常成功:基于互联网的网络管理技术在几个月内就被研究界和商业界采用. 结果,部分互联网社区及时变得可通过网络进行管理.
正如 RFC 1109 第二届特设网络管理审查小组报告 [4] 中所报告的,SNMP 和 OSI 网络管理框架的要求比预期有更多不同.因此,SMI/MIB 与两个框架之间的兼容性要求被暂停. 这一行动允许运营网络管理框架 SNMP 通过生成定义新 MIB 项目的文档来响应互联网社区中的新运营需求.
IAB 已将 SNMP,SMI 和初始互联网 MIB 指定为具有"推荐"状态的完整"标准协议". 通过此行动,IAB 建议所有 IP 和 TCP 实现均应由网络管理,并且可网络管理的实现预计采用和实现 SMI,MIB 和 SNMP.
因此,基于 TCP/IP 的互联网的当前网络管理框架包括: 基于 TCP/IP 的互联网的管理信息的结构和标识,它描述了如何定义包含在 MIB 中的管理对象,如 RFC 1155 [5] 中所述;基于 TCP/IP 的互联网网络管理的管理信息库,它描述了 RFC 1156 [6] 中规定的 MIB 中包含的管理对象;以及简单网络管理协议,它定义了用于管理这些对象的协议,如本备忘录中所述.
正如 RFC 1052(IAB 关于制定互联网网络管理标准的建议)中所报告的那样,互联网活动委员会已指示互联网工程任务组 (IETF) 在网络管理领域创建两个新的工作组. 一组负责进一步规范和定义管理信息库(MIB)中包含的元素.另一个负责定义对简单网络管理协议 (SNMP) 的修改,以满足网络供应商和运营社区的短期需求,并与 MIB 工作组的输出保持一致.
MIB 工作组制定了两份备忘录,其中一份定义了管理信息结构 (SMI) [2],供 MIB 中包含的被管对象使用. 第二个备忘录 [3] 定义了管理对象的列表.
SNMP 扩展工作组的输出是本备忘录,其中包含对初始 SNMP 定义 [7] 的更改,这些更改需要与 MIB 工作组的输出保持一致. 为了与 IAB 的指令保持一致,即工作组"对保持 SNMP 简单的需要极其敏感",这些变化应该是最小的. 尽管对本备忘录中反映的 SNMP 的更改进行了相当多的关注和争论,但最终的协议并不向后兼容其前身简单网关监控协议 (SGMP) [8].尽管协议的语法已经改变,但最初的理念,设计决策和架构仍然保持不变. 为了避免混淆,已分配新的 UDP 端口供本备忘录中描述的协议使用.
3. SNMP 架构
SNMP 架构模型中隐含的是网络管理站和网络元素的集合. 网络管理站执行监视和控制网络元件的管理应用程序. 网络元件是诸如主机,网关,终端服务器等的设备,其具有负责执行网络管理站请求的网络管理功能的管理代理. 简单网络管理协议(SNMP)用于在网络管理站和网元中的代理之间传递管理信息.
3.1. 架构目标
SNMP 明确最小化了管理代理本身实现的管理功能的数量和复杂性. 这个目标至少在四个方面具有吸引力:
-
支持该协议所需的管理代理软件的开发成本相应地降低了.
-
远程支持管理功能的程度相应提高,从而在管理任务中可以最充分地利用互联网资源.
-
远程支持的管理功能的程度相应地增加,从而对管理工具的形式和复杂性施加尽可能少的限制.
-
网络管理工具的开发人员很容易理解和使用简化的管理功能集.
该协议的第二个目标是监视和控制的功能范例能够充分扩展,以适应网络操作和管理的额外的,可能未预料到的方面.
第三个目标是架构尽可能独立于特定主机或特定网关的架构和机制.
3.2. 架构要素
SNMP 架构从以下方面阐述了网络管理问题的解决方案:
-
协议传达的管理信息的范围,
-
协议传达的管理信息的表示,
-
对协议支持的管理信息的操作,
-
管理实体之间交换的形式和含义,
-
管理实体之间管理关系的定义,以及
-
管理信息引用的形式和含义.
3.2.1. 管理信息的范围
通过 SNMP 的操作传递的管理信息的范围正是由所有非聚合对象类型的实例所表示的范围,这些非聚合对象类型要么在互联网标准 MIB 中定义,要么根据互联网标准 SMI [5] 中规定的约定在其他地方定义.
MIB 中对聚合对象类型的支持既不是与 SMI 一致所必需的,也不是由 SNMP 实现的.
3.2.2. 管理信息的表示
通过 SNMP 的操作传达的管理信息根据 ASN.1 语言 [9] 的子集来表示,该子集是为 SMI 中的非聚合类型的定义指定的.
SGMP 采用了使用 ASN.1 语言的明确定义子集的约定 [9]. SNMP 通过利用 ASN.1 的稍微复杂的子集来描述被管对象并描述用于管理这些对象的协议数据单元,从而延续并扩展了这一传统. 此外,为了简化最终过渡到基于 OSI 的网络管理协议的愿望,导致在 ASN.1 语言中定义了管理信息的互联网标准结构 (SMI) [5] 和管理信息库 (MIB) [6]. ASN.1 语言的使用在一定程度上是受到早期工作中 ASN.1(特别是 SGMP)的成功使用的鼓励. ASN.1 的使用限制是 SMI 的一部分,这有助于实现 SGMP 所倡导和验证的简单性.另外,为了简单起见,SNMP 仅使用 ASN.1 [10] 基本编码规则的子集. 即,所有编码都使用定长形式. 此外,只要允许,就使用非构造函数编码而不是构造函数编码. 此限制适用于 ASN.1 编码的所有方面,包括顶级协议数据单元及其包含的数据对象.
3.2.3. 管理信息所支持的操作
SNMP 将所有管理代理功能建模为变量的更改或检查. 因此,逻辑远程主机(可能是网络元件本身)上的协议实体与驻留在网络元件上的管理代理交互,以便检索(获取)或改变(设置)变量. 这一策略至少有两个积极的后果:
-
其具有将管理代理实现的基本管理功能的数量限制为两个的效果:一个操作将值分配给指定的配置或其他参数,另一个操作检索这样的值.
-
该决定的第二个效果是避免在协议定义中引入对命令式管理命令的支持:此类命令的数量实际上在不断增加,并且此类命令的语义通常是任意复杂的.
SNMP 中隐含的策略是,对任何重要细节级别的网络状态的监控主要通过轮询监控中心部分的适当信息来完成. 有限数量的未经请求的消息(陷阱)指导轮询的时间和焦点. 限制未经请求的消息的数量与简单性和最小化网络管理功能生成的流量的目标是一致的.
从一组明确支持的管理功能中排除命令式命令不太可能排除任何所需的管理代理操作. 目前,大多数命令都是请求设置某个参数的值或检索该值,并且当前支持的少数命令式命令的功能很容易通过该管理模型以异步模式容纳. 在该方案中,命令式命令可以被实现为参数值的设置,该参数值随后触发期望的动作. 例如,可以通过简单地设置指示系统重新启动之前的秒数的参数来调用此操作,而不是实现"重新启动命令".
3.2.4. 协议交换的形式和含义
SNMP中管理实体之间的管理信息通信是通过协议消息的交换来实现的.这些消息的形式和含义在下面第 4 节中定义.
与最小化管理代理复杂性的目标一致,SNMP消息的交换仅需要不可靠的数据报服务,并且每条消息完全且独立地由单个传输数据报表示. 虽然本文档指定通过 UDP 协议 [11] 进行消息交换,但 SNMP 的机制通常适用于各种传输服务.
3.2.5. 管理关系的定义
SNMP 架构允许参与协议的实体之间存在各种管理关系. 驻留在使用 SNMP 相互通信的管理站和网络元件处的实体被称为 SNMP 应用实体. 实现 SNMP 并因此支持 SNMP 应用程序实体的对等进程称为协议实体.
SNMP 代理与任意一组 SNMP 应用程序实体的配对称为 SNMP 社区. 每个SNMP团体由一串八位位组命名,称为该团体的团体名称.
由事实上属于由所述消息的团体组件命名的SNMP团体的SNMP应用实体发起的SNMP消息被称为真实的SNMP消息. 用于将 SNMP 消息识别为特定 SNMP 团体的真实 SNMP 消息的规则集称为身份验证方案.根据一种或多种认证方案识别真实 SNMP 消息的功能的实现称为认证服务.
显然,SNMP 应用实体之间管理关系的有效管理需要身份验证服务(通过使用加密或其他技术)能够高度确定地识别真实的 SNMP 消息. 一些 SNMP 实现可能希望仅支持简单的身份验证服务,该服务将所有 SNMP 消息标识为真实的 SNMP 消息.
对于任何网络元素,MIB 中属于该元素的对象子集称为 SNMP MIB 视图. 请注意,SNMP MIB 视图中表示的对象类型的名称不需要属于对象类型名称空间的单个子树.
集合{ READ-ONLY,READ-WRITE }的元素称为SNMP访问模式.
SNMP 访问模式与 SNMP MIB 视图的配对称为 SNMP 社区配置文件. SNMP 社区配置文件表示对指定 MIB 视图中的变量的指定访问权限.对于给定 SNMP 社区配置文件中 MIB 视图中的每个变量,对该变量的访问由配置文件根据以下约定表示:
-
如果所述变量在 MIB 中定义为"Access:"为"none",则它不能作为任何运算符的操作数;
-
如果所述变量在 MIB 中定义为"读写"或"只写",并且给定配置文件的访问模式为 READ-WRITE,则该变量可用作 get,set 和 trap 操作的操作数;
-
否则,该变量可用作 get 和 trap 操作的操作数.
-
在"只写"变量用作 get 或 trap 操作的操作数时,为变量给出的值是特定于实现的.
SNMP 社区与 SNMP 社区配置文件的配对称为 SNMP 访问策略.访问策略表示由指定 SNMP 社区的 SNMP 代理向该社区的其他成员提供的指定社区配置文件. SNMP 应用程序实体之间的所有管理关系都是根据 SNMP 访问策略在架构上定义的.
对于每个 SNMP 访问策略,如果指定 SNMP 团体的 SNMP 代理所在的网络元素不是指定配置文件的 MIB 视图所属的网络元素,则该策略称为 SNMP 代理访问策略.与代理访问策略关联的 SNMP 代理称为 SNMP 代理.虽然代理访问策略的粗心定义可能会导致管理循环,但代理策略的谨慎定义至少在两个方面是有用的:
-
它允许监视和控制无法使用管理协议和传输协议寻址的网络元件. 也就是说,委托代理可以提供协议转换功能,允许管理站将一致的管理框架应用到所有网络元件,包括诸如调制解调器,复用器的设备以及支持不同管理框架的其他设备.
-
它有可能保护网络元素免受复杂的访问控制策略的影响. 例如,委托代理可以实现复杂的访问控制,从而使MIB内的不同变量子集可供不同的管理站访问,而不增加网络元件的复杂性.
图1举例说明了管理站,委托代理和管理代理之间的关系. 在此示例中,委托代理被设想为某个管理域的普通互联网网络操作中心(INOC),该管理域与一组管理代理具有标准管理关系.
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
域:元素的管理域 PCommunity:使用代理的团体名称 DCommunity:直接团体的名称
图 1 网络管理配置示例
3.2.6. 被管对象引用的形式和含义
SMI 要求定义一致的管理协议地址:
-
模糊 MIB 引用的解析,
-
存在多个 MIB 版本时 MIB 参考的分辨率,以及
-
MIB 中定义的对象类型的特定实例的标识.
3.2.6.1. 消除有歧义的 MIB 引用
因为任何 SNMP 操作的范围在概念上仅限于与单个网络元素相关的对象,并且因为对 MIB 对象的所有 SNMP 引用(隐式或显式)通过唯一变量名称,所以对 MIB 中定义的任何对象类型的任何 SNMP 引用不可能解析为该类型的多个实例.
3.2.6.2. 解析跨 MIB 版本的引用
任何 SNMP 操作引用的对象实例正是作为操作请求的一部分指定的对象实例,或者(在 get-next 操作的情况下)其在整个 MIB 中的直接后继者. 具体地,对作为互联网标准MIB的某些版本的一部分的对象的引用不解析为不是所述互联网标准MIB的所述版本的一部分的任何对象,除非所请求的操作是get-next并且指定的对象名称在作为互联网标准MIB的所述版本的一部分呈现的所有对象的名称中按字典顺序位于最后的情况.
3.2.6.3. 对象实例的标识
MIB 中所有对象类型的名称均在 Internet 标准 MIB 或符合 SMI 命名约定的其他文档中明确定义. SMI 要求一致的管理协议定义用于识别特定网络元素的这些对象类型的各个实例的机制.
MIB 中定义的任何对象类型的每个实例在 SNMP 操作中都通过称为"变量名称"的唯一名称进行标识.通常,SNMP 变量的名称是 x.y 形式的 OBJECT IDENTIFIER,其中 x 是 MIB 中定义的非聚合对象类型的名称,y 是 OBJECT IDENTIFIER 片段,它以特定于命名对象类型的方式标识所需实例.
这种命名策略允许最充分地利用 GetNextRequest-PDU 的语义(参见第 4 节),因为它为相关变量分配名称,以便在 MIB 中已知的所有变量名称的字典顺序中是连续的.
下面针对许多对象类型类别定义了对象实例的特定于类型的命名. 以下命名约定均不适用的对象类型的实例由 x.0 形式的对象标识符命名,其中 x 是 MIB 定义中所述对象类型的名称.
例如,假设想要识别变量 sysDescr 的实例,sysDescr 的对象类是:
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
因此,对象类型 x 将为 1.3.6.1.2.1.1.1,并附加实例子标识符 0.也就是说,1.3.6.1.2.1.1.1.0 标识 sysDescr 的唯一实例.
3.2.6.3.1. ifTable 对象类型名称
子网接口的名称 s 是 i 形式的 OBJECT IDENTIFIER 值,其中 i 具有与 s 关联的 ifIndex 对象类型的实例的值.
对于每个对象类型 t(其定义的名称 n 具有 ifEntry 前缀),t 的实例 i 由 n.s 形式的 OBJECT IDENTIFIER 命名,其中 s 是子网接口的名称,i 表示有关该子网接口的信息.
例如,假设想要识别与接口 2 关联的变量 ifType 的实例.相应地,ifType.2 将识别所需的实例.
3.2.6.3.2. atTable 对象类型名称
AT 缓存网络地址的名称 x 是 1.a.b.c.d 形式的 OBJECT IDENTIFIER,其中 a.b.c.d 是与 x 关联的 atNetAddress 对象类型的值(采用熟悉的"点"表示法).
地址转换等价 e 的名称是 s.w 形式的 OBJECT IDENTIFIER 值,这样 s 是与 e 关联的 atIndex 对象类型实例的值,并且 w 是与 e 关联的 AT 缓存网络地址的名称.对于每个对象类型 t(其定义的名称 n 具有 atEntry 前缀),t 的实例 i 由 n.y 形式的 OBJECT IDENTIFIER 命名,其中 y 是 i 表示信息的地址转换等效项的名称.
例如,假设想要查找地址转换表(ARP 缓存)中与 89.1.1.42 的 IP 地址和接口 3 关联的条目的物理地址.因此,atPhysAddress.3.1.89.1.1.42 将标识所需的实例.
3.2.6.3.3. ipAddrTable 对象类型名称
IP 可寻址网络元素的名称 x 是 a.b.c.d 形式的 OBJECT IDENTIFIER,其中 a.b.c.d 是与 x 关联的 ipAdEntAddr 对象类型实例的值(采用熟悉的"点"表示法).
对于每个对象类型 t(其定义的名称 n 具有 ipAddrEntry 前缀),t 的实例 i 由 n.y 形式的 OBJECT IDENTIFIER 命名,其中 y 是 IP 可寻址网络元素的名称,i 表示有关该网络元素的信息.
例如,假设想要查找 IP 接口表中与 89.1.1.42 的 IP 地址关联的条目的网络掩码.因此,ipAdEntNetMask.89.1.1.42 将识别所需的实例.
3.2.6.3.4. ipRoutingTable 对象类型名称
IP 路由的名称 x 是 a.b.c.d 形式的 OBJECT IDENTIFIER,其中 a.b.c.d 是与 x 关联的 ipRouteDest 对象类型实例的值(采用熟悉的"点"表示法).
对于每个对象类型 t(其定义的名称 n 具有 ipRoutingEntry 前缀),t 的实例 i 由 n.y 形式的 OBJECT IDENTIFIER 命名,其中 y 是 IP 路由的名称,i 表示有关该路由的信息.
例如,假设想要查找 IP 路由表中与 89.1.1.42 的目的地关联的条目的下一跳.因此,ipRouteNextHop.89.1.1.42 将识别所需的实例.
3.2.6.3.5. tcpConnTable 对象类型名称
TCP 连接的名称 x 是 a.b.c.d.e.f.g.h.i.j 形式的 OBJECT IDENTIFIER,其中 a.b.c.d 是与 x 关联的 tcpConnLocalAddress 对象类型的该实例的值(采用熟悉的"点"表示法),并且 f.g.h.i 是该实例的值(采用熟悉的"点"表示法)与 x 关联的 tcpConnRemoteAddress 对象类型的值,并且使得 e 是与 x 关联的 tcpConnLocalPort 对象类型的实例的值,并且使得 j 是与 x 关联的 tcpConnRemotePort 对象类型的实例的值.
对于每个对象类型 t(其定义的名称 n 具有 tcpConnEntry 前缀),t 的实例 i 由 n.y 形式的 OBJECT IDENTIFIER 命名,其中 y 是 TCP 连接的名称,i 表示有关该连接的信息.
例如,假设想要查找 TCP 端口 21 上的 89.1.1.42 的本地地址与 TCP 端口 2059 上的 10.0.0.51 的远程地址之间的 TCP 连接的状态.因此,tcpConnState.89.1.1.42.21.10.0.0.51.2059 将识别所需的实例.
3.2.6.3.6. egpNeighTable 对象类型名称
EGP 邻居的名称 x 是 a.b.c.d 形式的 OBJECT IDENTIFIER,其中 a.b.c.d 是与 x 关联的 egpNeighAddr 对象类型实例的值(采用熟悉的"点"表示法).
对于每个对象类型 t(其定义的名称 n 具有 egpNeighEntry 前缀),t 的实例 i 由 n.y 形式的 OBJECT IDENTIFIER 命名,其中 y 是 i 表示其信息的 EGP 邻居的名称.
例如,假设想要查找 89.1.1.42 的 IP 地址的邻居状态. 因此,egpNeighState.89.1.1.42 将识别所需的实例.
4. 协议规范
网络管理协议是一种应用协议,通过该协议可以检查或改变代理的MIB的变量.
协议实体之间的通信是通过消息交换来完成的,每个消息都使用 ASN.1 的基本编码规则(如第 3.2.2 节中所讨论的)在单个 UDP 数据报中完整且独立地表示. 消息由版本标识符,SNMP 团体名称和协议数据单元 (PDU) 组成.协议实体在与其关联的主机上的 UDP 端口 161 接收除报告陷阱之外的所有消息(即,除包含 Trap-PDU 的消息之外的所有消息)的消息.应在 UDP 端口 162 上接收报告陷阱的消息以进行进一步处理. 该协议的实现不需要接受长度超过 484 个八位位组的消息. 但是,建议在可行的情况下实现支持更大的数据报.
SNMP 的所有实现都必须支持五种 PDU:GetRequest-PDU,GetNextRequest-PDU,GetResponse-PDU,SetRequest-PDU 和 Trap-PDU.
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- the individual PDUs and commonly used
-- data types will be defined later
END
4.1. 过程要素
本节描述实现 SNMP 的协议实体的操作.但请注意,它无意于限制任何一致性实现的内部架构.
在下文中,使用术语传输地址. 对于 UDP,传输地址由 IP 地址和 UDP 端口组成. 其他传输服务可用于支持 SNMP. 在这些情况下,应相应地定义传输地址.
生成消息的协议实体的顶层操作如下:
-
它首先构造适当的 PDU,例如 GetRequest-PDU,作为 ASN.1 对象.
-
然后,它将这个 ASN.1 对象以及团体名称,源传输地址和目标传输地址传递给实现所需身份验证方案的服务. 此身份验证服务返回另一个 ASN.1 对象.
-
然后,协议实体使用团体名称和生成的 ASN.1 对象构造 ASN.1 消息对象.
-
然后使用 ASN.1 的基本编码规则序列化这个新的 ASN.1 对象,然后使用传输服务发送到对等协议实体.
类似地,接收消息的协议实体的顶层动作如下:
-
它对传入数据报执行基本解析,以构建与 ASN.1 Message 对象相对应的 ASN.1 对象.如果解析失败,它将丢弃数据报并且不执行进一步的操作.
-
然后它验证 SNMP 消息的版本号.如果不匹配,它将丢弃数据报并且不执行进一步的操作.
-
然后,协议实体将 ASN.1 消息对象中找到的团体名称和用户数据以及数据报的源和目标传输地址一起传递给实现所需身份验证方案的服务. 该实体返回另一个 ASN.1 对象,或发出身份验证失败信号. 在后一种情况下,协议实体注意到此失败,(可能)生成陷阱,并丢弃数据报并且不执行进一步的操作.
-
然后,协议实体对从认证服务返回的 ASN.1 对象执行基本解析,以构建与 ASN.1 PDU 对象相对应的 ASN.1 对象. 如果解析失败,它将丢弃数据报并且不执行进一步的操作. 否则,使用命名的 SNMP 社区,选择适当的配置文件,并相应地处理 PDU. 如果此处理的结果是返回消息,则发送响应消息的源传输地址应与原始请求消息发送到的目标传输地址相同.
4.1.1. 公共结构
在介绍协议的六种 PDU 类型之前,有必要考虑一些经常使用的 ASN.1 构造:
-- request/response information
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
ErrorIndex ::=
INTEGER
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
RequestID 用于区分未完成的请求. 通过使用 RequestID,SNMP 应用程序实体可以将传入响应与未完成的请求关联起来. 在使用不可靠的数据报服务的情况下,RequestID 还提供了一种识别网络重复消息的简单方法.
ErrorStatus 的非零实例用于指示处理请求时发生异常. 在这些情况下,ErrorIndex 可以通过指示列表中的哪个变量导致异常来提供附加信息.
术语"变量"指的是被管对象的实例. 变量绑定(或 VarBind)是指变量名称与变量值的配对. VarBindList 是变量名称和相应值的简单列表. 一些 PDU 只关心变量的名称而不关心它的值(例如,GetRequest-PDU). 在这种情况下,协议实体将忽略绑定的值部分. 但是,值部分仍必须具有有效的 ASN.1 语法和编码. 建议将 ASN.1 值 NULL 用于此类绑定的值部分.
4.1.2. GetRequest-PDU
GetRequest-PDU的形式为:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
GetRequest-PDU 仅在其 SNMP 应用实体的请求时由协议实体生成.
收到 GetRequest-PDU 后,接收协议实体根据以下列表中的任何适用规则进行响应:
-
如果 variable-bindings 字段中任一对象的名称与相关 MIB 视图内可用于 get 操作的某个对象名称不完全匹配,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 noSuchName,error-index 字段的值为接收消息中该对象名称组件的索引.
-
如果 variable-bindings 字段中命名的任一对象属于聚合类型(定义见 SMI),接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 noSuchName,error-index 字段的值为接收消息中该对象名称组件的索引.
-
如果如下所述生成的GetResponse-PDU的大小超出本地限制,则接收实体向接收到的消息的发起者发送相同形式的GetResponse-PDU,除了error-status字段的值为tooBig,并且error-index字段的值为0之外.
-
如果由于前述规则均未涵盖的原因,无法检索 variable-bindings 字段中命名的任一对象的值,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 genErr,error-index 字段的值为接收消息中该对象名称组件的索引.
如果前述规则均不适用,则接收协议实体将 GetResponse-PDU 发送到所接收消息的发起者,使得对于所接收消息的变量绑定字段中指定的每个对象,GetResponse-PDU 的相应组件表示该变量的名称和值. GetResponse-PDU的错误状态字段的值是noError并且error-index字段的值为零. GetResponse-PDU 的 request-id 字段的值是接收到的消息的值.
4.1.3. GetNextRequest-PDU
GetNextRequest-PDU 的形式与 GetRequest-PDU 的形式相同,除了 PDU 类型的指示之外. 在 ASN.1 语言中:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
GetNextRequest-PDU 仅在其 SNMP 应用实体的请求时由协议实体生成.
收到 GetNextRequest-PDU 后,接收协议实体根据以下列表中的任何适用规则进行响应:
-
如果 variable-bindings 字段中的任一对象名称在字典序上不先于相关 MIB 视图内可用于 get 操作的某个对象名称,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 noSuchName,error-index 字段的值为接收消息中该对象名称组件的索引.
-
如果如下所述生成的GetResponse-PDU的大小超出本地限制,则接收实体向接收到的消息的发起者发送相同形式的GetResponse-PDU,除了error-status字段的值为tooBig,并且error-index字段的值为0之外.
-
如果由于前述规则均未涵盖的原因,无法检索 variable-bindings 字段中命名对象的字典序后继对象值,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 genErr,error-index 字段的值为接收消息中该对象名称组件的索引.
如果前述规则均不适用,则接收协议实体将 GetResponse-PDU 发送到所接收消息的发起者,使得对于所接收消息的 variable-bindings 字段中的每个名称,GetResponse-PDU 的相应组件表示该对象的名称和值,该对象的名称是按照相关 MIB 视图中可用于 get 操作的所有对象的名称的字典顺序,以及给定组件的名称字段的值,该值的直接后继者. GetResponse-PDU的error-status字段的值为noError,并且errorindex字段的值为0. GetResponse-PDU的request-id字段的值是接收到的消息的值.
4.1.3.1. 表遍历示例
GetNextRequest-PDU 的一项重要用途是遍历 MIB 内的概念信息表.这种类型的 SNMP 消息的语义与用于识别 MIB 中对象类型的各个实例的特定于协议的机制一起,提供对 MIB 中相关对象的访问,就好像它们享受表格组织一样.
通过下面概述的 SNMP 交换,SNMP 应用实体可以提取特定网络元素的路由表中每个条目的目标地址和下一跳网关.假设该路由表有三个条目:
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
管理站向 SNMP 代理发送一个 GetNextRequest-PDU,其中包含指示的 OBJECT IDENTIFIER 值作为请求的变量名称:
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
SNMP 代理使用 GetResponse-PDU 进行响应:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
管理站继续:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
SNMP 代理响应:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
管理站继续:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
SNMP 代理响应:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
管理站继续:
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
由于表中没有更多条目,因此 SNMP 代理返回已知对象名称的字典顺序中的下一个对象. 该响应向管理站发出路由表结束的信号.
4.1.4. GetResponse-PDU
GetResponse-PDU 的形式与 GetRequest-PDU 的形式相同,除了 PDU 类型的指示之外. 在 ASN.1 语言中:
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
GetResponse-PDU 仅在收到 GetRequest-PDU,GetNextRequest-PDU 或 SetRequest-PDU 时由协议实体生成,如本文档其他部分所述.
接收到 GetResponse-PDU 后,接收协议实体将其内容呈现给其 SNMP 应用实体.
4.1.5. SetRequest-PDU
SetRequest-PDU 的形式与 GetRequest-PDU 的形式相同,除了 PDU 类型的指示之外. 在 ASN.1 语言中:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
SetRequest-PDU 仅在其 SNMP 应用实体的请求时由协议实体生成.
收到 SetRequest-PDU 后,接收实体根据下表中的任何适用规则进行响应:
-
如果 variable-bindings 字段中命名的任一对象不能用于相关 MIB 视图中的 set 操作,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 noSuchName,error-index 字段的值为接收消息中该对象名称组件的索引.
-
如果对于 variable-bindings 字段中命名的任一对象,value 字段的内容按照 ASN.1 语法未体现出与该变量要求相符的类型、长度和值,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 badValue,error-index 字段的值为接收消息中该对象名称的索引.
-
如果如下所述生成的GetResponse 类型消息的大小超出本地限制,则接收实体向接收到的消息的发起者发送相同形式的GetResponse-PDU,除了error-status字段的值为tooBig,并且error-index字段的值为0之外.
-
如果由于前述规则均未涵盖的原因,无法更改 variable-bindings 字段中命名的任一对象的值,接收实体就向接收消息的发起方发送形式相同的 GetResponse-PDU,但 error-status 字段的值为 genErr,error-index 字段的值为接收消息中该对象名称组件的索引.
如果上述规则均不适用,则对于在接收到的消息的 variable-bindings 字段中命名的每个对象,将相应的值分配给变量. SetRequest-PDU 指定的每个变量赋值应该像针对同一消息中指定的所有其他赋值同时设置一样进行.
然后,接收实体向接收到的消息的发起者发送相同形式的GetResponse-PDU,除了所生成的消息的error-status字段的值为noError并且error-index字段的值为0之外.
4.1.6. Trap-PDU
Trap-PDU的形式为:
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
Trap-PDU仅在SNMP应用实体的请求时由协议实体生成. SNMP 应用程序实体选择 SNMP 应用程序实体的目标地址的方式是特定于实现的.
接收到 Trap-PDU 后,接收协议实体将其内容呈现给其 SNMP 应用实体. Trap-PDU 的 variable-bindings 组件的重要性是特定于实现的.
generic-trap字段的值的解释是:
4.1.6.1. coldStart Trap
coldStart(0) 陷阱表示发送协议实体正在重新初始化自身,从而可能会更改代理的配置或协议实体实现.
4.1.6.2. warmStart Trap
warmStart(1) 陷阱表示发送协议实体正在重新初始化自身,这样代理配置和协议实体实现都不会更改.
4.1.6.3. linkDown Trap
linkDown(2) 陷阱表示发送协议实体认识到代理配置中表示的通信链路之一出现故障.
linkDown 类型的 Trap-PDU 包含受影响接口的 ifIndex 实例的名称和值作为其 variable-bindings 的第一个元素.
4.1.6.4. linkUp Trap
linkUp(3) 陷阱表示发送协议实体识别出代理配置中表示的某条通信链路已经恢复.
linkUp 类型的 Trap-PDU 包含受影响接口的 ifIndex 实例的名称和值作为其 variable-bindings 的第一个元素.
4.1.6.5. authenticationFailure Trap
authenticationFailure(4) 陷阱表示发送协议实体是未正确验证的协议消息的收件人. 虽然 SNMP 的实现必须能够生成此陷阱,但它们还必须能够通过特定于实现的机制抑制此类陷阱的发射.
4.1.6.6. egpNeighborLoss Trap
egpNeighborLoss(5) 陷阱表示某个以发送协议实体为 EGP 对等方的 EGP 邻居已被标记为不可用,并且该对等关系不再存在.
egpNeighborLoss 类型的 Trap-PDU 包含受影响邻居的 egpNeighAddr 实例的名称和值作为其 variable-bindings 的第一个元素.
4.1.6.7. enterpriseSpecific Trap
enterpriseSpecific(6) 陷阱表示发送协议实体认识到某些企业特定事件已发生. specific-trap 字段标识发生的特定陷阱.
5. 定义
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetNextRequest-PDU ::=
[1]
IMPLICIT PDU
GetResponse-PDU ::=
[2]
IMPLICIT PDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
PDU ::=
SEQUENCE {
request-id
INTEGER,
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
},
error-index -- sometimes ignored
INTEGER,
variable-bindings -- values are sometimes ignored
VarBindList
}
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the
network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END
6. 致谢
本备忘录受到 IETF SNMP 扩展工作组的影响:
Karl Auerbach, Epilogue Technology
K. Ramesh Babu, Excelan
Amatzia Ben-Artzi, 3Com/Bridge
Lawrence Besaw, Hewlett-Packard
Jeffrey D. Case, University of Tennessee at Knoxville
Anthony Chung, Sytek
James Davidson, The Wollongong Group
James R. Davin, MIT Laboratory for Computer Science
Mark S. Fedor, NYSERNet
Phill Gross, The MITRE Corporation
Satish Joshi, ACC
Dan Lynch, Advanced Computing Environments
Keith McCloghrie, The Wollongong Group
Marshall T. Rose, The Wollongong Group (chair)
Greg Satz, cisco
Martin Lee Schoffstall, Rensselaer Polytechnic Institute
Wengyik Yeong, NYSERNet
7. 参考文献
[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.
[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.
[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.
[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.
[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.
[6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.
[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.
[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.
[9] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.
[10] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.
[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980.
8. 安全注意事项
本备忘录不讨论安全问题.
9. 作者地址
Jeffrey D. Case SNMP Research P.O. Box 8593 Knoxville, TN 37996-4800
电话: (615) 573-1434
Email: [email protected]
Mark Fedor Performance Systems International Rensselaer Technology Park 125 Jordan Road Troy, NY 12180
电话: (518) 283-8860
Email: [email protected]
Martin Lee Schoffstall Performance Systems International Rensselaer Technology Park 165 Jordan Road Troy, NY 12180
电话: (518) 283-8860
Email: [email protected] James R. Davin MIT Laboratory for Computer Science, NE43-507 545 Technology Square Cambridge, MA 02139
电话: (617) 253-6020
Email: [email protected]