本主题描述了 SNMP v1 和 v2 中定义的对象类型。
在“MIB 模块”视图中选择模块，然后在“OID 树”视图中的搜索字段中搜索 ifIndex，这样可找到下列几节中所述的对象信息。单击“OID 树”层次结构中的 ifIndex 对象，以在“详细信息”视图中查看对象信息和文本约定信息。
OBJECT IDENTIFIER 由 SNMP v1 定义，它是 MIB 树的主构建块。对象标识与书籍中的章节标题类似，它们不包含任何实际数据，但是告诉您它们的后代传达何种内容。
OBJECT-TYPE 由 SNMP v1 定义，用作存储受管设备相关信息的容器，或者用作存储设备的特定测量值的容器。
TEXTUAL-CONVENTION (TC) 是对象类型的定义，但不是实际对象。在“MIB 模块”视图中，您可以从视图列表中选择文本约定以查看 MIB 树中显示的已解析的文本约定。在 MIB 树中选择一个 TC 名称可在“详细信息”视图中显示其定义。
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1 ENTERPRISE 部分定义哪个对象是陷阱的父级。但是，可以使用 bgp 将 MIB 树对象定义为父级，并将自己定义为编号为 1 的子级。事实上，bgpVersion 在 RFC1269-MIB 模块中定义为 { bgp 1}。因此，可以向 MIB 树添加 v1 陷阱作为叶子，该叶子使用 ENTERPRISE 作为父级。
SNMP v2 将 TRAP-TYPE 的定义更改为 NOTIFICATION-TYPE，并指定应该像定义其他 MIB 对象那样定义此新 v2 陷阱，至于父级编号和子级编号，只有 v1 陷阱才存在此问题。RFC1155 4.1 节定义了使用零 (0) 作为子级编号是无效的，因为该编号已保留供将来使用。SNMP v2 允许供应商向 v2 MIB 添加自己的 v1 陷阱，向企业名称中添加零，然后在零后面添加陷阱编号，以此使用零。 因此，应该在 v2 下定义一个包含零的对象标识作为企业的子级，然后将 v1 陷阱添加为该零的子级。
这约定使 MIB 作者犯了另一个常见的错误。RFC1155 第 4 节有以下叙述：
“An object type definition consists of five fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type. This must resolve to an instance of the ASN.1 type ObjectSyntax (defined below). Definition: A textual description of the semantics of the object type. Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that objects have consistent meaning across all machines. Access: One of read-only, read-write, write-only, or not-accessible. Status: One of mandatory, optional, or obsolete. Future memos may also specify other fields for the objects which they define.”
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs,
adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute
interval threshold reached." ::= { adslAtucTraps 0 1 } 随 v1 陷阱或 v2 通知传送的对象称为 varbind。Varbind 包含关于所报告事件的附加信息。在 v1 陷阱中，varbind 在 VARIABLES 段中逐项列出；而在 v2 通知中，varbind 在 OBJECTS 段中列出。它们在所有 SNMP 版本中的用途相同。varbind 在列表中的显示顺序很重要，因为 PDU（SNMP 包）将按 varbind 在 MIB 中的列示顺序对关联的值进行编码。
例如，在 OBJECTS 段中指定了以下三个 varbind：ifIndex、ifAdminStatus 和 ifOperStatus。 因此，ifIndex 是以第一个编码的 varbind，ifAdminStatus 是第二个，ifOperStatus 是第三个。通过检查 IF-MIB，我们发现 ifIndex 对象类型定义为 InterfaceIndex。因为这不是对 SNMP 有效的原语 ASN.1 类型，所以它必须为文本约定。通过搜索文本约定，我们发现 InterfaceIndex 实际解析为 Integer32（32 位整数）。因此，当 PDU 到达 MIB 管理器 时，第一个 varbind 将为整数。为了确定该整数的含义，MIB 管理器 必须引用 IF-MIB 模块，查找 ifIndex，然后读取关联的对象信息。通过检查第二个 varbind，我们发现一个枚举整数类型：
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }从 SNMP 包对该 varbind 进行解码后，其值将为一个整数，然后必须根据此枚举列表中的项对其值进行解释。当 MIB 管理器 用于创建规则文件时，它将创建一个查找表来自动链接枚举整数及其文本表示形式。第三个 varbind 也是一个枚举类型，并且值相同。因此，如果 ifAdminStatus 是 1（已启动）而 ifOperStatus 是 2（已关闭），那么我们就知道事件的生成原因而能够继续尝试确定此结果的原因。
将在规则文件中以 $1、$2、$3（以此类推）的形式向用户呈现 varbind，每个数字表示一个 varbind 编号。MIB 管理器 将根据 varbind 元素来创建元素，然后使用这些元素来设置详细信息表中的变量。例如，详细信息表中使用的元素可能为 ifIndex = $1（它将为一个整数）、$ifAdminStatus = $2（它将为诸如“已启动”(1) 等内容”和 $ifOperStatus = $3（它将为诸如“已关闭”(3) 等内容）。将使用 Netcool Knowledge Library (NCKL) 所设置的约定将已对对象设置所作的任何更改自动设置到规则文件中。
表等同于包含数据行和数据列的多维数组。表对象定义为 Entry 对象的 SEQUENCE。而 Entry 对象定义为 OBJECT-TYPE 对象的 SEQUENCE。有时候，供应商设计的系统不常见，例如 Cisco 10k 路由器。此设备保留了一张警报条件内部表，当该表发生更改时，它会生成陷阱和通知。因此，必须发出 SNMP GET 请求来获取该表的内容，从而确定该设置上的活动警报的当前状态。这略微增加了 SNMP 管理器获取警报的难度，但是只要管理员有相应的工具，也并非无法实现。
八位元是由八个位（通常称为 1 个字节）组成的数据构造。而八位元字符串是字节数组（或字节字符串）。术语“八位元字符串”并不暗示该字符串中的所有字节都是字母数字。它们也可能是用作位掩码的二进制字符。