通常，我們使用SNMP協議，最多地就是在Windows系統下進行的。但是Linux SNMP的使用卻更為廣泛。現在我們就來了解一下Linux SNMP的相關內容吧。看看具體的設計是如何實現的。事實上，Linux SNMP被設計成與協議無關，所以它可以在IP，IPX，AppleTalk，OSI以及其他用到的傳輸協議上被使用。

Linux SNMP是一系列協議組和規范，它們提供了一種從網絡上的設備中收集網絡管理信息的方法。Linux SNMP也為設備向網絡管理工作站報告問題和錯誤提供了一種方法。

MIB：管理信息庫

SMI：管理信息的結構和標識

Linux SNMP算法

從被管理設備中收集數據有兩種方法：一種是只輪詢（polling-only）的方法，另一種是基于中斷（interrupt-based）的方法。

如果你只使用只輪詢的方法，那么網絡管理工作站總是在控制之下。而這種方法的缺陷在于信息的實時性，尤其是錯誤的實時性。你多久輪詢一次，并且在輪詢時按照什么樣的設備順序呢？

如果輪詢間隔太小，那么將產生太多不必要的通信量。如果輪詢間隔太大，并且在輪詢時順序不對，那么關于一些大的災難性的事件的通知又會太饅。這就違背了積極主動的網絡管理Linux SNMP目的。

當有異常事件發生時，基于中斷的方法可以立即通知網絡管理工作站（在這里假設該設備還沒有崩潰，并且在被管理設備和管理工作站之間仍有一條可用的通信途徑）。

然而，這種方法也不是沒有他的缺陷的，首先，產生錯誤或自陷需要系統資源。如果自陷必須轉發大量的信息，那么被管理設備可能不得不消耗更多的時間和系統資源來產生自陷，從而影響了它執行主要的功能（違背了網絡管理的原則2）。

而且，如果幾個同類型的自陷事件接連發生，那么大量網絡帶寬可能將被相同的信息所占用（違背了網絡管理的原則1）。尤其是如果自陷是關于網絡擁擠問題的時候，事情就會變得特別糟糕。

克服這一缺陷的一種方法就是對于被管理設備來說，應當設置關于什么時候報告問題的閾值（threshold）。但不幸的是這種方法可能再一次違背了網絡管理的原則2，因為設備必須消耗更多的時間和系統資源，來決定一個自陷是否應該被產生。

結果，以上兩種方法的結合：面向自陷的輪詢方法（trap-directed polling）可能是執行網絡管理Linux SNMP最為有效的方法了。一般來說，網絡管理工作站輪詢在被管理設備中的代理來收集數據，并且在控制臺上用數字或圖形的表示方式來顯示這些數據。這就允許網絡管理員分析和管理設備以及網絡通信量了。

被管理設備中的代理可以在任何時候向網絡管理工作站報告錯誤情況，例如預制定閾值越界程度等等。代理并不需要等到管理工作站為獲得這些錯誤情況而輪詢他的時候才會報告。這些錯誤情況就是眾所周知的Linux SNMP自陷（trap）。