[a]笔记：SNMP常用概念解释

blog.paessler.com/snmp-monito…

SNMP Explained: What You Must Know About Monitoring via MIB and OIDs By Martina Wittmann Mar 24, 2017 • 16 minute read

Scope of SNMP

First of all, a thought on why one would make use of SNMP. As its name Simple Network Management Protocol says, you can use it for network management. That was simple, wasn't it? But let's continue that train of thought. In order to manage, you need information. This is where SNMP has its greatest value. It gathers all the data and puts it into context, which makes you able to track issues, to make decisions based on real data and to take control wherever necessary. That's what network management is all about. And that's why you as a network admin use SNMP to gain the precious monitoring information you need about your network.

SNMP Communication Partners

Secondly, we should talk about how SNMP management information is transferred. In principle, the SNMP data packages travelling through your network are just like normal messages sent and received between two or more communication partners.

In the case of SNMP, the communication partners are the managing entity on the one hand, for example the computer running your monitoring software, and the managed entity on the other, like your switches, server racks, coffee machine, or what else you want to monitor.

Let's illustrate this with a more human example. Imagine your boss wants to know how the hardware in the company server room is doing, and so he is interested in the temperature values, for example. So you head downstairs to the server room and suddenly feel like you are on vacation in Jamaica. You go back up to let your boss know that the temperature in the server room would make a Finnish sauna（芬兰桑拿） feel cold. Or, another situation could be that you are in the server room, although nobody told you to check the temperature there, and you decide to inform your team because you feel like you have been hit with the heat of a thousand suns, which is not the normal situation. You send an email to the whole IT department, not knowing if anyone will even receive it and who and when someone will react to your message.

Basically, you can compare these procedures to a normal client/server communication. If it is the managing entity (or your boss upstairs in the IT department) that starts the communication to solicit a response from you, this works like pull (or poll). If it is a managed device (this was you downstairs in the server room, temporarily taking over the duty of a temperature sensor) that sends out an SNMP message upon an event, this works like push. In SNMP terminology, a GET request for example follows the pull model, whereas an SNMP trap is "pushed out" without any previous request.

OIDs

Now, let's talk about your message. In your case, the management information regards the server room temperature. Depending on what you monitor, this can also be a printer's toner碳粉 status, the traffic on a switch, or the level of coffee beans in your coffee machine. Each of these pieces of information is called an object and needs an individual address to become the content for an SNMP message. This address is called an OID and stands for object identifier.

If you want the managing entity and a managed device in your network to successfully communicate, both communication partners need to know which pieces of management information, that is which OIDs, are available. Let's assume you have a printer and it wants to tell your monitoring entity not only

• how much toner is left (OID1), but also
• how many sheets it has already printed (OID2) and
• how many sheets are currently queued (OID3).

So both your printer and your monitoring entity need to know that those three are valid pieces of management information, and thus valid OIDs, no matter which of your SNMP communication partners is the sender or receiver of the messages regarding your printer.

MIB

So how do you ensure that both your managing entity and your managed device communication partners are up to date on available OIDs and on what actually lies behind these addresses?

I'll answer this question in a minute, let's use a bit of imagination first. Imagine how many different network devices in the world exist and how much specific management information is available in total!

Hence counting OIDs would be pointless, unless you just really need a hobby and don't mind that you'll never be able to do anything else again. Of course, not all OIDs from all manufacturers may be relevant for you, but you will still have a considerable number of OIDs concerning your network. It would be more than a painstaking and time consuming, or even impossible, adventure to manually manage every single OID.

Luckily, the so-called MIB exists. The short form of Management Information Base, the MIB is an independent format for the definition of management information. In clear text: the MIB contains OIDs in a well-defined way. Or, from your perspective, you can find every object that you can get from a given device in its MIB files. By the way, you can easily recognize a MIB file via the extensions .my or .mib, or .txt.

Now let's get back to the question of how you can ensure that all SNMP communication partners are up to date on available OIDs.

Device manufacturers normally deliver the necessary MIB files along with their products that support SNMP. 

So the communication is usually safe on the side of your managed devices. On the side of your monitoring entity, it is your turn as an admin to become active. You can first try if it works, of course,

but if it doesn't, line up and install the missing MIB files in the way your monitoring tool needs them. 

If you are having trouble finding a MIB file (for whatever reason), try looking on the web or contacting the manufacturer's support.

Hierarchical Structures Everywhere

This may look like a freaky chapter numbering, however, this is an OID.

1.3.6.1.2.1.2. 

Its structure is not "any number whatsoever" but actually really organized. Reading an OID from the left to the right basically corresponds to following an OID tree structure from the root to its leaves. Hopping 跳动from node to node gives you an impression of who is involved in the hierarchy underlying SNMP. Let's follow the nodes of the above mentioned OID.

1 - International Organization for Standardization (ISO)
3 - Identified organizations according to ISO/IEC 6523-2
6 - US Department of Defense (DOD)
1 - Internet protocol
2 - Internet Engineering Task Force (IETF) management
1 - MIB-2
2 - Interfaces

Note that this illustration is by no means complete. For example, the MIB-2 has 228 child nodes in total and all of them have many child nodes, and so on. (SNMP pro tip: You can find all important standard bject definnitions for monitoring with SNMP in the MIB-2. You may easily guess that from the names system, interfaces, IP, ICMP, TCP, UDP, transmission, SNMP, etc.) Some mighty branches of the OID tree are the internet and the private branches.

The internet branch contains the largest part of all existing OIDs (roughly > 90 %), not least because it contains the private branch in which you can find the specific MIB file for specific devices of 46,000 currently listed enterprises and organizations. Conveniently, from a private branch OID you can also read the manufacturers as listed by the Internet Assigned Numbers Authority (IANA), for example

1.3.6.1.4.1.9 Cisco MIBs
1.3.6.1.4.1.311 Microsoft MIBs
1.3.6.1.4.1.2636 Juniper MIBs
1.3.6.1.4.1.8117 North American Association of Food Equipment Manufacturers MIBs

This also means that from the private node 1.3.6.1.4 on, all following OID parts may be specific to manufacturers.

The Value of MIBs

OIDs can theoretically have the impressive length of up to 40 (or even unlimited number of) tuples with an arbitrary number of digits. Easily readable for machines, but not for humans. The MIB is here to help. It is like a lexicon, always providing a name, a definition and a description for given objects, including meta information like data type and access rights. You can compare OIDs to IP addresses and MIB files to DNS entries. On the protocol level, the address in number format is used. Based on MIB information, or DNS information respectively, the addresses are mapped to more human friendly names and completed with additional information.

Wrapping It Up

In order to understand and work with SNMP, keep in mind that you cannot do without basic specifications like MIB and OIDs. If you are a professional network administrator, OIDs and MIB (files) are your bread and butter in the SNMP context.

from: 深入理解net-snmp

MIB是管理信息的集合，是MIB开发人员根据业务的需求或网络管理标准的要求，按照约定的组织规则、定义语法编写的结构化的文本文件。每个MIB中的管理对象都应该清晰地描述该对象所有的属性，包括名字、描述、数据类型等。这些属性的内容能够通过对象的唯一标识OID，被通信双方所识别。

也就是说，MIB是NMS和Agent相互沟通的桥梁，只有Agent实现了该MIB，且NMS认识该MIB，两者才能正确配合实现相应的管理功能。

如果将MIB导入NMS中，则NMS才能知道待管理对象所有的细节。在Agent中实现了MIB中定义的管理对象，则说明该Agent支持该MIB。

在将MIB导入NMS和Agent中实现MIB之前，需要保证MIB组织结构和语法的正确性。一个Agent可以实现多个MIB，每个MIB包含的管理对象可多可少，没有明确的要求。但是SNMP发展至今已有极其广泛的商业应用，现实中已经存在大量的MIB。Agent往往需要实现其中一部分的MIB。

MIB中一部分是ISO定义的标准管理对象，包括MIB-I（RFC1156）和MIB-II（RFC1213）。一般宣称支持SNMP的设备，尤其是入网设备，都应该实现标准的MIB（最后版本MIB-II）。

另一部分是各大厂商、组织或私人自定义的私有MIB。这些私有MIB是厂商根据设备管理的需求，将标准MIB中未覆盖的且设备中需要管理的对象而自定义的MIB。私有MIB定义在节点enterprises（1.3.6.1.4.1）下。

管理对象

管理对象可以以两种形式定义在MIB中

1. 标量对象。该对象在运行期间只有一个实例值的对象；
2. 表格对象。指的是在运行过程中有多个实例值的对象。

对象和实例的区分方法

不管是哪种对象都涉及如何区分对象和对象实例的问题。由于标量对象在运行期间只有一个实例值，所以在表示标量对象的实例时方式很简单：假设标量对象对应的标识符是OID_B，那么该对象的实例标识符表示为OID_B.0，获取该对象实例的PDU中传递的就是OID_B.0。实际上，对于只有一个值的标量对象，按常理来说并没有必要在后序补0以作区分。这样做的目的主要是为和表格对象中的列实例的表示方法一致。

表格对象

表格对象的定义

• 使用SEQUENCE序列结构将各对象定义为序列结构，其中每一项都是标量对象，SEQUENCE的作用就是将这些标量对象按序列的方式组合起来；其中每个标量对象在表格中又称为列对象。要求该序列结构中定义的序列结构顺序一定要和表格中列对象的定义顺序一致，这也是SEQUENCE类型的含义。
• 将SEQUENCE OF定义的序列结构定义为概念行，也称行对象。
• 将概念行作为概念表的语法类型，定义概念表，即表格对象。

表格对象和行对象语法类型都为“not-accessible”。对于该权限我们可以这样理解：表对象作为顶层的节点，其本身不携带任何信息，也就是“概念表”的“概念”的含义所在，其下面的叶子节点才包含具体的管理信息，所以它是不可管理的，也就定义为“not-accessible”。而对于行对象，其术语为“概念”行，同样它的本身是不可管理的，其下的组成元素才是可管理的。

现实应用中我们定义表时，会将上面3点的定义顺序反过来，请看代码：

-- 定义概念表，非叶子节点，不可访问：not-accessible 
exampleTable OBJECT-TYPE 
    SYNTAX SEQUENCE OF ExampleEntry 
    MAX-ACCESS not-accessible 
    STATUS current 
    DESCRIPTION ::= { aroot 1 } 
-- 某个父节点 -- 以序列结构定义概念表中的概念行；非叶子节点，不可访问：not-accessible 
exampleEntry OBJECT-TYPE 
    SYNTAX ExampleEntry 
    MAX-ACCESS not-accessible 
    STATUS current 
    DESCRIPTION "An entry (conceptual row) in the exampleTable." 
    INDEX { exampleIndex } 
     ::= { exampleTable 1 }
 -- 定义序列结构
 ExampleEntry ::= 
     SEQUENCE { exampleIndex Integer32, -- 整型的index 
     exampleValue Integer32, 
     exampleString DisplayString }