3. The SNMP Architecture
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 将识别所需的实例.
Return: RFC 1157 Home