Dav*_*son 19 snmp network-protocols
我正在学习SNMP,并使用它编写一些应用程序.我有一些关于协议的基本问题:
L.R*_*.R. 18
代理商是否将其状态存储在设备本身上？
在最常见的情况下,SNMP代理正在监视的设备上运行.在这种情况下,代理没有其他选项,任何状态信息都必须存储在设备上.SNMP代理只读取或设置这些信息.
如果代理上设置了陷阱,您是否可以对同一个OID进行轮询以获取相同的信息？
我认为你应该能够做到这一点 - 例如SNMPv2陷阱IF-MIB :: linkDown包含三个varbinds - IF-MIB :: ifIndex,IF-MIB :: ifAdminStatus和IF-MIB :: ifOperStatus.在这种特殊情况下,ifIndex指定ifTable中的行,并且可以轮询其他两行.
如果不使用mib文件,有没有办法一次查询设备的所有信息？
是的,使用snmp-walknet-snmp软件包或任何其他可以使用get-next来调查数据的snmp工具.
如果没有,并且您正在编写自己的自定义管理器,您是否必须知道它预先报告的结构？
您确实需要知道设备MIB包含的内容 - 如果没有这些信息,您只能获得数字OID和值,这对开发人员和用户来说都毫无意义.如果是更复杂的MIB,您需要了解有关受管设备的大量详细信息.MIB文件几乎没有包含足够的信息.
Jay*_*dse 12
代理商是否将其状态存储在设备本身上？
您可以在设备上存储或关闭数据.两者都是可能的,两者都完成了.代理存储(缓存)有关远程设备的状态信息的问题在于管理系统从未真正知道代理中的(缓存)数据是否可接受是最新的.如果您不能指望它,则需要使用管理器来触发同步或轮询远程设备的状态和/或代理与远程设备之间的通信链接.进入该游戏后,通常最好将子代理放在远程设备上,并使用标准SNMP协议来获取信息.
如果代理上设置了陷阱,您是否可以对同一个OID进行轮询以获取相同的信息？
大多数设计良好的MIB实际上将已更改的MIB对象放入陷阱.这样,您的SNMP管理器就不必为了确定而轮询代理.
话虽如此,Entity-MIB上的陷阱没有任何状态变量.但是,该MIB用于描述物理库存,例如货架,卡和端口,并且仅在物理配置更改时才会引发陷阱.在这种情况下,您需要让SNMP管理器再次使用Entity-MIB来获取全新的物理配置.
如果不使用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对象来滚动自己的Enterprise MIB,这些对象可让您的管理员限制特定陷阱.