跳到主要内容

简单网络管理协议(SNMP)应用

  • 状态: Internet Standard
  • 发布日期: December 2002
  • Stream: IETF
  • 废弃了: RFC2573
  • 勘误: 无勘误

本备忘录状态​

本文档为互联网社区规定了互联网标准跟踪协议,并请求讨论和改进建议.有关本协议的标准化状态和状况,请参阅"互联网官方协议标准"(STD 1)的当前版本.本备忘录的分发不受限制.

摘要​

本文档描述了五种简单网络管理协议(SNMP)应用类型,这些应用使用STD 62, RFC 3411中描述的SNMP引擎.所描述的应用类型包括命令生成器(Command Generators)、命令响应器(Command Responders)、通知发起者(Notification Originators)、通知接收器(Notification Receivers)和代理转发器(Proxy Forwarders).

本文档还定义了管理信息库(MIB)模块,用于指定管理操作的目标、通知过滤和代理转发.本文档废弃了RFC 2573.


7. 代理转发应用中的管理目标转换 (Management Target Translation in Proxy Forwarder Applications)​

代理转发器应用在转发SNMP消息时执行管理目标的转换.此转换涉及将传入消息参数(contextEngineID、contextName、securityModel、securityName、securityLevel)映射到适合目标SNMP引擎的传出消息参数.

snmpProxyTable定义代理转发器使用的转换规则.

7.1. 请求转发 (Request Forwarding)​

请求转发涉及从命令生成器接收命令请求,转换请求参数,并将请求转发到命令响应器.

7.1.1. 处理传入请求 (Processing an Incoming Request)​

当代理转发器接收到请求时:

  1. 从接收到的消息中提取传入参数:

    • contextEngineID
    • contextName
    • securityModel
    • securityName
    • securityLevel
    • PDU类型
  2. 使用这些参数作为键查找snmpProxyTable.具体来说,搜索以下条目:

    • snmpProxyType对于读类PDU(Get、GetNext、GetBulk)为read(1),或对于写类PDU(Set)为write(2)
    • snmpProxyContextEngineID匹配传入的contextEngineID
    • snmpProxyContextName匹配传入的contextName
    • snmpProxyTargetParamsIn引用与传入安全参数匹配的目标参数
  3. 如果未找到匹配的条目:

    • 生成错误响应,指示无法转发请求.
    • 具体错误取决于SNMP版本和情况(例如,authorizationError、genErr).
  4. 如果找到匹配的条目:

    • 提取snmpProxySingleTargetOut或snmpProxyMultipleTargetOut值.

7.1.2. 转发请求 (Forwarding the Request)​

找到匹配的snmpProxyTable条目后:

单目标转发 (Single Target Forwarding)​

如果指定了snmpProxySingleTargetOut:

  1. 使用snmpProxySingleTargetOut作为snmpTargetAddrName查找snmpTargetAddrTable.

  2. 提取目标地址信息:

    • snmpTargetAddrTDomain(传输域)
    • snmpTargetAddrTAddress(传输地址)
    • snmpTargetAddrParams(对snmpTargetParamsTable的引用)
  3. 使用snmpTargetAddrParams查找snmpTargetParamsTable.

  4. 提取目标安全参数:

    • snmpTargetParamsMPModel(消息处理模型)
    • snmpTargetParamsSecurityModel
    • snmpTargetParamsSecurityName
    • snmpTargetParamsSecurityLevel
  5. 确定目标上下文:

    • 如果snmpProxyContextEngineID为空,使用传入的contextEngineID.
    • 否则,使用snmpProxyContextEngineID.
    • snmpProxyContextName同理.
  6. 必要时转换PDU:

    • 如果传入和传出的SNMP版本不同,转换PDU格式和错误代码.
    • SNMPv1到SNMPv2: 映射错误代码,转换陷阱格式.
    • SNMPv2到SNMPv1: 映射错误代码(例如,noAccess→genErr),处理异常值.
  7. 使用消息处理子系统的发送PDU原语和目标参数转发请求.

多目标转发 (Multiple Target Forwarding)​

如果指定了snmpProxyMultipleTargetOut:

  1. 在snmpTargetAddrTable中搜索所有snmpTargetAddrTagList包含snmpProxyMultipleTargetOut中指定标签的条目.

  2. 对于每个匹配的目标地址:

    • 遵循单目标转发的步骤2-7.
    • 注意原始请求被复制并发送到多个目标地址.
  3. 多目标的响应处理:

    • 多目标转发通常仅用于读操作.
    • 代理可能需要聚合响应或返回第一个成功的响应.
    • 具体行为取决于实现.

7.1.3. 转发响应 (Forwarding the Response)​

当代理转发器从目标命令响应器接收到响应时:

  1. 必要时转换响应PDU以匹配原始请求者期望的格式.

  2. 将contextEngineID和contextName映射回原始请求者期望的值.

  3. 使用消息处理子系统的返回响应PDU原语返回响应.

7.2. 通知转发 (Notification Forwarding)​

通知转发涉及从通知发起者接收通知并将其转发到一个或多个通知接收器.

7.2.1. 处理传入通知 (Processing an Incoming Notification)​

当代理转发器接收到通知时:

  1. 提取传入参数:

    • contextEngineID
    • contextName
    • securityModel
    • securityName
    • securityLevel
    • 通知类型(陷阱或通知)
  2. 使用这些参数查找snmpProxyTable.搜索以下条目:

    • snmpProxyType对于陷阱通知为trap(3),或对于通知请求为inform(4)
    • snmpProxyContextEngineID匹配传入的contextEngineID(或为空以匹配任何)
    • snmpProxyContextName匹配传入的contextName(或为空以匹配任何)
    • snmpProxyTargetParamsIn引用与传入安全参数匹配的目标参数(或为空以匹配任何)
  3. 如果未找到匹配的条目:

    • 不转发通知.
    • 代理可以在本地记录此事件.
  4. 如果找到匹配的条目:

    • 提取snmpProxyMultipleTargetOut值(通知转发始终使用多目标转发).

7.2.2. 转发通知 (Forwarding the Notification)​

找到匹配的snmpProxyTable条目后:

  1. 在snmpTargetAddrTable中搜索所有snmpTargetAddrTagList包含snmpProxyMultipleTargetOut中指定标签的条目.

  2. 对于每个匹配的目标地址:

    a. 在snmpTargetParamsTable中查找snmpTargetAddrParams.

    b. 提取目标参数.

    c. 根据snmpNotifyTable(如果引用)确定是作为陷阱还是通知发送,或使用与传入通知相同的类型.

    d. 必要时转换通知PDU:

    • SNMPv1陷阱到SNMPv2陷阱: 转换PDU格式,添加sysUpTime.0和snmpTrapOID.0.
    • SNMPv2陷阱到SNMPv1陷阱: 转换PDU格式,提取enterprise、agent-addr、generic-trap、specific-trap.

    e. 使用消息处理子系统的发送PDU原语转发通知.

  3. 如果传出通知是通知请求:

    • 等待来自每个目标的响应.
    • 如果传入通知也是通知,聚合响应.
    • 仅在从所有(或配置的子集)目标接收到响应后,才向原始通知发起者返回响应.

转换示例 (Translation Examples)​

示例1: SNMPv3到SNMPv1请求转换 (SNMPv3 to SNMPv1 Request Translation)​

传入请求:

  • contextEngineID: 0x80001F8880
  • contextName: "publicView"
  • securityModel: 3 (USM)
  • securityName: "admin"
  • securityLevel: authPriv
  • PDU: GetRequest

snmpProxyTable条目:

  • snmpProxyType: read(1)
  • snmpProxyContextEngineID: 0x80001F8880
  • snmpProxyContextName: "publicView"
  • snmpProxyTargetParamsIn: "snmpv3Params"
  • snmpProxySingleTargetOut: "legacyDevice"

snmpTargetAddrTable条目 (legacyDevice):

  • snmpTargetAddrTDomain: snmpUDPDomain
  • snmpTargetAddrTAddress: 192.0.2.10:161
  • snmpTargetAddrParams: "snmpv1Params"

snmpTargetParamsTable条目 (snmpv1Params):

  • snmpTargetParamsMPModel: 0 (SNMPv1)
  • snmpTargetParamsSecurityModel: 1 (SNMPv1)
  • snmpTargetParamsSecurityName: "public"
  • snmpTargetParamsSecurityLevel: noAuthNoPriv

传出请求:

  • 传输: UDP到192.0.2.10:161
  • SNMP版本: SNMPv1
  • 团体名: "public"
  • PDU: GetRequest(相同的variable-bindings)

响应转换:

  • 传入的SNMPv1响应被转换回SNMPv3格式.
  • 响应使用USM进行加密和身份验证.
  • 返回给原始请求者.

示例2: SNMPv1陷阱到SNMPv2陷阱转换 (SNMPv1 Trap to SNMPv2 Trap Translation)​

传入SNMPv1陷阱:

  • Community: "public"
  • enterprise: 1.3.6.1.4.1.9
  • agent-addr: 192.0.2.1
  • generic-trap: linkDown(2)
  • specific-trap: 0
  • time-stamp: 12345

snmpProxyTable条目:

  • snmpProxyType: trap(3)
  • snmpProxyContextEngineID: ""(匹配任何)
  • snmpProxyContextName: ""(匹配任何)
  • snmpProxyTargetParamsIn: ""(匹配任何)
  • snmpProxyMultipleTargetOut: "snmpv2Targets"

具有标签"snmpv2Targets"的snmpTargetAddrTable条目: 具有SNMPv2c或SNMPv3参数的多个条目.

传出SNMPv2/v3陷阱:

  • snmpTrapOID.0: 1.3.6.1.6.3.1.1.5.3 (linkDown)
  • sysUpTime.0: 12345
  • 来自原始陷阱的附加variable-bindings.

特殊考虑 (Special Considerations)​

上下文转换 (Context Translation)​

snmpProxyTable允许上下文转换:

  • 表条目中的空snmpProxyContextEngineID或snmpProxyContextName表示"使用传入值".
  • 非空值表示"将传入上下文映射到此传出上下文".

这允许代理将多个传入上下文映射到单个传出上下文,反之亦然.

防止安全降级 (Security Downgrade Prevention)​

当从较高安全级别转换到较低安全级别时(例如,SNMPv3 authPriv到SNMPv1 noAuthNoPriv),代理应:

  1. 记录安全降级以用于审计目的.
  2. 应用附加访问控制以限制可以降级的操作.
  3. 考虑加密传输(例如,使用IPsec或TLS)以补偿降低的SNMP层安全性.

错误处理 (Error Handling)​

代理必须仔细处理错误:

  • 转换错误: 如果无法转换PDU(例如,SNMPv1中的SNMPv2异常值),返回适当的错误.
  • 转发错误: 如果目标不可达,向原始请求者返回超时或网络错误.
  • 响应转换错误: 如果响应无法转换回来,记录错误并向原始请求者返回genErr.

性能优化 (Performance Optimization)​

代理转发可以通过以下方式优化:

  1. 缓存表查找: 为频繁使用的路径缓存snmpProxyTable、snmpTargetAddrTable和snmpTargetParamsTable查找.
  2. 预编译规则: 在配置时将表条目转换为优化的内部格式.
  3. 连接池: 对于基于TCP的传输,维护到频繁访问目标的持久连接.

5. 通知发起者中的管理目标识别 (Identification of Management Targets in Notification Originators)​

通知发起者应用使用snmpTargetAddrTable和snmpTargetParamsTable来识别应向其发送通知的管理目标,并确定发送通知时应使用的SNMP版本和安全参数.

当发生触发通知生成的事件时,通知发起者:

  1. 查询snmpNotifyTable以确定此通知应使用哪些通知标签.snmpNotifyTable中的每个条目将标签值与通知类型(陷阱或通知)关联.

  2. 从snmpTargetAddrTable中选择目标地址,通过匹配通知标签.对于snmpTargetAddrTable中的每个条目:

    a. snmpTargetAddrTagList对象包含标签值列表.

    b. 如果snmpTargetAddrTagList中的任何标签值与snmpNotifyTable中指定的标签匹配,则选择此目标地址.

  3. 检索每个选定目标地址的传输参数:

    a. snmpTargetAddrTDomain指定传输域(例如,snmpUDPDomain、snmpTCPDomain).

    b. snmpTargetAddrTAddress指定传输地址(例如,IP地址和端口).

  4. 检索每个选定目标地址的SNMP参数:

    a. snmpTargetAddrParams对象引用snmpTargetParamsTable中的条目.

    b. 从引用的snmpTargetParamsTable条目中,通知发起者检索:

    • snmpTargetParamsMPModel(消息处理模型)
    • snmpTargetParamsSecurityModel(安全模型)
    • snmpTargetParamsSecurityName(安全名称)
    • snmpTargetParamsSecurityLevel(安全级别)
  5. 使用检索到的参数为每个选定的管理目标生成并发送通知.

配置示例 (Example Configuration)​

考虑一个需要发送linkDown通知的通知发起者.配置可能包括:

snmpNotifyTable条目:​

  • snmpNotifyName: "linkDownNotify"
  • snmpNotifyTag: "criticalDevices"
  • snmpNotifyType: trap(1)

snmpTargetAddrTable条目:​

条目1:

  • snmpTargetAddrName: "mgmtStation1"
  • snmpTargetAddrTDomain: snmpUDPDomain
  • snmpTargetAddrTAddress: 192.0.2.1:162
  • snmpTargetAddrTagList: "criticalDevices monitoring"
  • snmpTargetAddrParams: "snmpv3Params"

条目2:

  • snmpTargetAddrName: "mgmtStation2"
  • snmpTargetAddrTDomain: snmpUDPDomain
  • snmpTargetAddrTAddress: 192.0.2.2:162
  • snmpTargetAddrTagList: "criticalDevices"
  • snmpTargetAddrParams: "snmpv2cParams"

snmpTargetParamsTable条目:​

条目snmpv3Params:

  • snmpTargetParamsMPModel: 3 (SNMPv3)
  • snmpTargetParamsSecurityModel: 3 (USM)
  • snmpTargetParamsSecurityName: "operator"
  • snmpTargetParamsSecurityLevel: authPriv(3)

条目snmpv2cParams:

  • snmpTargetParamsMPModel: 1 (SNMPv2c)
  • snmpTargetParamsSecurityModel: 2 (SNMPv2c)
  • snmpTargetParamsSecurityName: "public"
  • snmpTargetParamsSecurityLevel: noAuthNoPriv(1)

当发生linkDown事件时:

  1. 通知发起者查询snmpNotifyTable并发现应将带有标签"criticalDevices"的通知作为陷阱发送.

  2. 它扫描snmpTargetAddrTable并找到两个在其标签列表中包含"criticalDevices"的条目:"mgmtStation1"和"mgmtStation2".

  3. 对于mgmtStation1,它使用USM安全和authPriv级别以及安全名称"operator"向192.0.2.1:162发送SNMPv3陷阱.

  4. 对于mgmtStation2,它使用团体字符串"public"向192.0.2.2:162发送SNMPv2c陷阱.

通知请求的超时和重试 (Timeout and Retry for Inform Requests)​

当通知类型为通知(InformRequest-PDU)时,snmpTargetAddrTable还提供超时和重试参数:

  • snmpTargetAddrTimeout: 指定在将请求视为超时之前等待响应的时间(以百分之一秒为单位).

  • snmpTargetAddrRetryCount: 指定如果未收到响应,重试发送通知请求的次数.

通知发起者使用这些参数来实现通知请求的可靠通知传递.

例如,如果snmpTargetAddrTimeout为1500(15秒)且snmpTargetAddrRetryCount为3,则通知发起者将:

  1. 发送通知请求.
  2. 等待最多15秒以获得响应.
  3. 如果未收到响应,最多重试3次.
  4. 在4次总尝试(初始+3次重试)或60秒(4×15秒)后放弃,以先到者为准.

管理目标识别的安全考虑 (Security Considerations for Management Target Identification)​

在识别通知的管理目标时:

  1. 配置的身份验证: 管理目标的配置(snmpTargetAddrTable、snmpTargetParamsTable和snmpNotifyTable)应受访问控制保护,以防止未经授权的修改.

  2. 敏感信息: 安全名称,特别是与SNMPv1或SNMPv2c(团体字符串)一起使用时,应防止泄露.snmpTargetParamsTable应仅供授权用户访问.

  3. 通知过滤: 没有适当的通知过滤(在下一节中描述),所有配置的管理目标将接收所有通知,可能会将敏感信息暴露给未经授权的接收者.

  4. 标签选择: 使用标签允许灵活地对管理目标进行分组,但应注意确保正确应用标签,以防止通知误导.


6. 通知过滤 (Notification Filtering)​

通知过滤提供了一种机制,可以根据通知的内容选择性地将通知发送到管理目标.这允许对哪些管理目标接收哪些类型的通知进行细粒度控制.

通知过滤使用三个MIB表:

  • snmpNotifyFilterProfileTable: 将过滤器配置文件名称与一组目标参数关联.
  • snmpNotifyFilterTable: 根据通知内容定义实际的过滤规则.
  • snmpTargetParamsTable: 包含过滤器配置文件表引用的目标参数名称.

过滤处理算法 (Filter Processing Algorithm)​

当通知发起者为管理目标生成通知时,它按如下方式应用通知过滤:

  1. 从管理目标的snmpTargetAddrParams对象中检索目标参数名称.

  2. 在snmpNotifyFilterProfileTable中查找过滤器配置文件,使用目标参数名称作为索引.

  3. 如果未找到过滤器配置文件,则发送通知(不应用过滤).

  4. 如果找到过滤器配置文件,snmpNotifyFilterProfileName标识snmpNotifyFilterTable中的一组过滤器条目.

  5. 对于通知中的每个variable-binding:

    a. 在snmpNotifyFilterTable中搜索与过滤器配置文件名称匹配的条目.

    b. 按其索引的字典顺序处理条目.

    c. 对于每个过滤器条目,检查snmpNotifyFilterSubtree指定的子树是否与变量的对象标识符匹配.

    d. 如果变量的OID在过滤器子树内或等于过滤器子树,则发生匹配,并考虑snmpNotifyFilterMask(如果指定).

    e. 如果找到匹配:

    • 如果snmpNotifyFilterType为included(1),继续检查其他变量.
    • 如果snmpNotifyFilterType为excluded(2),不向此管理目标发送通知.

    f. 如果在检查所有过滤器条目后未为变量找到匹配,则不发送通知.

  6. 如果所有variable-bindings都通过过滤器,则将通知发送到管理目标.

过滤器掩码语义 (Filter Mask Semantics)​

snmpNotifyFilterMask对象提供对子树匹配的位级控制.它是一个具有以下语义的位掩码:

  • 掩码中的每个八位字节对应于过滤器子树OID中的一个子标识符.
  • 八位字节中的每个位对应于子标识符中的一个位.
  • 如果掩码中的位为1,则子标识符中的相应位必须与变量的OID匹配.
  • 如果掩码中的位为0,则子标识符中的相应位将被忽略(通配符).

零长度掩码(默认值)意味着所有子标识符必须完全匹配.

掩码使用示例:​

过滤器子树: 1.3.6.1.2.1.2.2.1.8
掩码: 0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFF.0xFE

此掩码允许匹配1.3.6.1.2.1.2.2.1.8(ifOperStatus)和1.3.6.1.2.1.2.2.1.9(ifLastChange),因为最终子标识符的最后一位是通配符.

配置示例 (Configuration Examples)​

示例1: 向管理目标发送所有通知 (Sending All Notifications to a Management Target)​

要在不过滤的情况下向管理目标发送所有通知:

  1. 不要在snmpNotifyFilterProfileTable中为目标的参数名称创建条目.

或

  1. 创建一个带有单个包含过滤器的过滤器配置文件:
    • snmpNotifyFilterSubtree: 1(或任何根OID)
    • snmpNotifyFilterMask: ""(空)
    • snmpNotifyFilterType: included(1)

要仅发送与接口(ifTable)相关的通知:

snmpNotifyFilterProfileTable条目:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • 与目标参数名称关联: "stationAParams"

snmpNotifyFilterTable条目:

条目1:

  • snmpNotifyFilterProfileName: "interfaceFilter"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.2
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

此配置允许发送包含来自接口组(1.3.6.1.2.1.2)的变量的通知,同时过滤掉所有其他通知.

示例3: 排除特定通知 (Excluding Specific Notifications)​

要发送所有通知,但不包括与TCP连接表相关的通知:

snmpNotifyFilterProfileTable条目:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • 与目标参数名称关联: "stationBParams"

snmpNotifyFilterTable条目:

条目1:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: included(1)

条目2:

  • snmpNotifyFilterProfileName: "noTcpConnections"
  • snmpNotifyFilterSubtree: 1.3.6.1.2.1.6.13
  • snmpNotifyFilterMask: ""
  • snmpNotifyFilterType: excluded(2)

此配置包括所有通知(条目1),但明确排除包含来自tcpConnTable的变量的通知(条目2).

实现考虑 (Implementation Considerations)​

性能 (Performance)​

通知过滤需要对每个variable-binding针对可能的多个过滤器条目进行OID比较.实现应优化此过程:

  • 使用高效的数据结构(例如,树或哈希表)进行OID查找.
  • 为频繁使用的管理目标缓存过滤器配置文件查找.
  • 考虑在配置时预编译过滤规则.

过滤器顺序 (Filter Order)​

过滤器条目按其索引的字典顺序处理.这意味着:

  • 应相对于更广泛的包含适当配置更具体(更长的OID)的排除.
  • 过滤器条目的顺序会影响过滤的结果.

默认行为 (Default Behavior)​

如果目标参数不存在过滤器配置文件:

  • 默认行为是发送通知(不过滤).
  • 这确保了与不使用通知过滤的系统的向后兼容性.

Variable-Binding要求 (Variable-Binding Requirements)​

RFC 3416要求通知至少包含两个variable-bindings:

  1. sysUpTime.0
  2. snmpTrapOID.0

这些强制性的variable-bindings必须通过过滤器才能发送通知.如果过滤器排除这些OID,则不会向该管理目标发送通知.

安全考虑 (Security Considerations)​

通知过滤可以在多个方面影响安全性:

  1. 防止信息泄露: 过滤可以防止将敏感信息发送到未经授权的管理站.

  2. 配置保护: 过滤器配置表(snmpNotifyFilterProfileTable和snmpNotifyFilterTable)应受访问控制保护,以防止未经授权的修改.

  3. 过滤器绕过: 不正确的过滤器配置(例如,过于宽泛的包含规则)可能允许发送意外的通知.

  4. 拒绝服务: 过于复杂的过滤规则可能消耗过多的处理资源,可能导致拒绝服务.

建议将通知过滤与适当的访问控制(如VACM)和SNMPv3安全功能结合使用,以确保全面的安全性.