有关 SNMP 的基本问题
我正在学习 SNMP，并使用它编写一些应用程序。我对协议有一些基本问题：
- 代理是否将其状态存储在设备本身上？
- 如果代理上设置了陷阱，您可以对同一 OID 进行轮询以获得相同的信息吗？
- 在不使用 mib 文件的情况下，有没有办法一次性查询设备的所有信息？如果没有，并且您正在编写自己的定制管理器，您是否必须知道它预先报告的内容的结构？
- 如果您要设置代理进行报告，通常是否有办法控制其发送陷阱的频率？或者它通常会在满足某些条件时发送陷阱吗？
I'm learning about SNMP, and writing some applications using it. I have some basic questions about the protocol:
- Do the agents store its state on the device itself?
- If there is a trap set on an agent, can you do a poll on the same OID to get the same information?
- Without using a mib file, is there a way to query a device for all of its information at once? If not, and you're writing your own customized manager, do you have to know the structure of what it reports up front?
- If you're setting up an agent to report, is there usually a way to control the frequency of how often it sends a trap? Or does it usually send a trap as often as some condition is satisfied?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在最常见的情况下，SNMP 代理在监控设备上运行。在这种情况下，代理没有其他选择，任何状态信息都必须存储在设备上。 SNMP代理只是读取或设置这些信息。
我认为你应该能够做到这一点 - 例如 SNMPv2 陷阱 IF-MIB::linkDown 包含三个 varbind - IF-MIB::ifIndex、IF-MIB::ifAdminStatus 和 IF-MIB::ifOperStatus。在这种特殊情况下，ifIndex 指定 ifTable 中的行，并且可以轮询其他两行。
是的，使用
snmp-walk来自 net-snmp 包或任何其他可以使用 get-next 轮询数据的 snmp 工具。您确实需要知道设备 MIB 包含什么 - 如果没有这些信息，您只能得到数字 OID 和值，这对于开发人员和用户来说都是毫无意义的。如果 MIB 更复杂，您需要了解有关受管设备的大量详细信息。 MIB 文件几乎不包含足够的信息。
In the most common scenario the SNMP agent is running on the device which monitors. In this case the agent has no other option and any state information must be stored on the device. SNMP agent just reads or sets these information.
I think you should be able to do that - for example SNMPv2 trap IF-MIB::linkDown contains three varbinds - IF-MIB::ifIndex, IF-MIB::ifAdminStatus and IF-MIB::ifOperStatus. In this particular case the ifIndex specifies the row in the ifTable and other two can be polled.
Yes, use
snmp-walkfrom the net-snmp package or any other snmp tool that can use get-next to poll the data.You do need to know what the device MIB contains - without such information you get only numeric OID and value, which is meaningless both for developers and users. In case of more complicated MIBs you need to know quite a lot of details about the managed device. MIB file hardly ever contains enough information.
您可以将数据存储在设备上或设备外。两者都是可能的，并且都已完成。代理存储（缓存的）有关远程设备的状态信息的问题在于，管理系统永远不会真正知道代理中的（缓存的）数据是否是可接受的最新数据。如果您不能依赖它，则需要使用管理器来触发同步或轮询远程设备的状态和/或代理与远程设备之间的通信链路。一旦您进入该游戏，通常最好在远程设备上放置一个子代理，并使用标准 SNMP 协议来获取信息。
大多数精心设计的 MIB 实际上都会将更改后的 MIB 对象直接放入陷阱中。这样，您的 SNMP 管理器就不必为了确定而轮询代理。
尽管如此，Entity-MIB 上的陷阱没有任何状态变量。但是，该 MIB 用于描述物理库存，例如机架、卡和端口，并且仅当物理配置发生更改时才会引发陷阱。在这种情况下，您需要让 SNMP 管理器再次遍历实体 MIB 以获取完整的新物理配置。
是的。滚动您自己的自定义 MIB 并将您想要的任何内容放入其中。您可以将整个设备配置放入一个 MIB 对象中。这样做的缺点是您必须在 SNMP 管理器上编写一个解析器来解析结构，如果结构发生变化，您将需要弄清楚当前值和先前值之间的差异的含义。即您将重新发明一些 SNMP MIB。然而，对于非常小的 MIB，这可能值得这样做。
您最好使用 SNMP GET-BULK，或者通过连续调用 SNMP-GET-NEXT 进行 MIB 遍历，直到不再返回任何对象。
如果您想让“自定义管理器”保持简单，您必须预先了解其结构。如果您想要灵活性，您将需要结构描述语言来对您的结构进行编码，并且您的管理器将需要能够从代理数据中对其进行解码并填充管理器，并从管理器中获取数据并将其编码此格式将其发送给代理。即您将重新发明 SNMP/SMI、CMIP/CMISE、CIM 以及许多已部署的其他管理系统和协议。
这是一个很好的问题，因为当您最需要网络时，您经常会遇到陷阱风暴，导致网络拥塞。这使得很难预测要提供多少网络。
明智地使用陷阱。例如，Entity-MIB 只有一个陷阱，而该陷阱值得使用，因为它报告物理结构变化。 Interfaces-MIB 每个端口可能有多个陷阱。对于此 MIB，最好只为绑定到物理端口的接口启用陷阱，而不是为堆叠在下层接口之上的接口启用陷阱。对于大型网络，通常最好对物理设备和物理接口结合使用轮询和陷阱。这样，您就可以预测无论是在正常操作期间还是在网络灾难期间，您的网络将有多少用于管理流量。
一些标准 MIB 指定了抛出陷阱的频率或时间。如果您对此感到满意，请使用它。您始终可以使用配置 MIB 对象来滚动自己的企业 MIB，让您的管理器限制特定陷阱。
You can store data on or off device. Both are possible and both are done. The problem with an agent storing (cached) state information about a remote device is that the management system never really knows if the (cached) data in the agent is acceptably up to date. If you cannot count on it, you'll need to use the manager to trigger a synchronization or to poll the state of the remote device and/or the communication link between the agent and the remote device. Once you get into that game, it is often better just to put a subagent on the remote device, and use standard SNMP protocols to get the information.
Most well-designed MIBs actually put the changed MIB object right into the trap. That way, your SNMP Manager does not have to poll the agent just to be sure.
Having said that, the trap on the Entity-MIB does not have any state variables. However, that MIB is used to describe physical inventory such as shelves, cards, and ports, and the trap is thrown only if the physical configuration changes. In this case you are expected to have your SNMP Manager walk the Entity-MIB again to get the full new physical configuration.
Yes. Roll your own custom MIB and put whatever you want in it. You could put your entire device configuration into one MIB object. The down side of this is that you'll have to write a parser on your SNMP Manager to parse out the structure, and if the structure changes you'll need to figure out the meaning of the difference between the current value and the previous value. i.e. You'll re-invent some SNMP MIB. However, for very small MIBs, this might be worth doing.
You are probably better off using SNMP GET-BULK, or just doing a MIB walk by successively calling SNMP-GET-NEXT until no more objects are returned.
If you want to keep your "customized manager" simple, you'll have to know the structure up front. If you want flexibility, you'll need structure-description language with which to encode your structure, and your manager will need to be able to decode this from the agent data and populate the manager, and take data from the manager and encode it in this format to send it to the agent(s). i.e. You'll re-invent SNMP/SMI, CMIP/CMISE, CIM, and a host of other management systems and protocols that have already been deployed.
This is a good question, because you often get a trap storm congesting your network precisely when you need your network the most. That makes it hard to predict how much network to provision.
Use traps judiciously. For example, the Entity-MIB only has one trap, and that one is worth using because it reports on physical structure changes. The Interfaces-MIB has potentially many traps per port. For this MIB, it is best just to enable traps for the interface bound to a physical port, and not for interfaces stacked on top of lower layer interfaces. For a large network, it is often best just to use a combination of polling plus traps for physical equipment and physical interfaces. That way, you can predict how much of your network will be used for management traffic whether during normal operation or during a network disaster.
Some standard MIBs specify how often or when you can throw a trap. If you are OK with that, then use it. You can always roll your own Enterprise MIB with configuration MIB objects that let your manager throttle particular traps.
这取决于设备和应用程序；有些设备将其存储在本地，其他设备则使用代理。
是的，但通常最好在陷阱中包含信息，这样管理站就不必对设备进行多次“往返”。例如，如果您捕获属性值更改，则最好在陷阱中发送旧值和新值。
通常不会...SNMP Get-next 原语就是为这种情况而设计的。
是的，由代理决定何时发送陷阱。
如果您正在开发自己的代理，我强烈建议您查看 Net-SNMP。即使您选择使用其他产品，Net-SNMP 代码也经过精心设计和实现。此外，它还有许多额外功能来帮助开发和测试代理（和管理系统）。
It depends on the device and the application; some devices stores it locally others use a proxy agent.
Yes, but it usually better to include information in the trap so the management station does not have to do multiple "round-trips" to the device. If you trap on an attribute value change, for instance, it is good practice to send the old and new value in the trap.
Generally no... the SNMP Get-next primitive is designed for just such a case.
Yes, it is up to the agent on when to send traps.
If you are developing your own agent, I highly suggest you look at Net-SNMP. Even if you choose to go with another product, the Net-SNMP code is very well designed and implemented. Plus it has lots of extras to help develop and test agents (and management systems).