檢視原始碼 代理程式功能描述

SNMP 代理程式系統由一個主代理程式和可選的子代理程式組成。

此工具可以輕鬆地在執行時動態擴展 SNMP 代理程式。MIB 可以隨時載入和卸載。也可以在執行時更改 MIB 的實作方式，而無需重新編譯 MIB。MIB 實作與代理程式清楚地分離。

為了方便 MIB 的增量實作，此工具可以為整個 MIB 或其部分生成原型實作。這允許同時開發不同的 MIB 和管理應用程式。

功能

為了實作代理程式，程式設計師會為代理程式將支援的 MIB 中的變數和表格編寫檢測函數。無需任何程式設計即可建立處理 set、get 和 get-next 的執行原型。

此工具組提供以下功能：

  • 多語言、多執行緒、可擴展的 SNMP 代理程式
  • 使用高階程式設計語言輕鬆編寫檢測函數
  • 基本錯誤處理，例如自動類型檢查
  • 存取控制
  • 驗證
  • 透過加密保護隱私
  • 在執行時載入和卸載 MIB
  • 無需重新編譯 MIB 即可變更檢測函數的能力
  • 快速原型設計環境，其中 MIB 編譯器可以使用通用檢測函數，然後由程式設計師完善
  • 一個用於處理事務和設定請求一致性檢查的簡單且可擴展的模型
  • 透過分散式 Erlang 支援子代理程式的概念
  • 一種用於傳送通知（陷阱和通知）的機制
  • 支援在 Mnesia DBMS 中實作 SNMP 表格。

SNMPv1、SNMPv2 和 SNMPv3

SNMP 開發工具組適用於所有三個版本的標準網際網路管理框架；SNMPv1、SNMPv2 和 SNMPv3。它們都具有相同的基本結構和元件。而且它們遵循相同的架構。

這些版本在以下 RFC 中定義：

  • SNMPv1 RFC 1555、1157 1212、1213 和 1215
  • SNMPv2 RFC 1902 - 1907
  • SNMPv3 RFC 2570 - 2575

隨著時間的推移，隨著框架從 SNMPv1、透過 SNMPv2 演變為 SNMPv3，每個架構元件的定義都變得更加豐富和明確，但基本架構保持一致。

SNMPv2 相較於 SNMPv1 的主要功能是：

  • 用於傳輸大量資料的 get-bulk 操作。
  • 增強的錯誤代碼。
  • 更精確的 MIB 規範語言

定義 SNMPv2 的標準文件不完整，因為它們沒有指定 SNMPv2 訊息的外觀。訊息格式和安全性問題留給特殊的管理框架處理。其中一個框架是基於社群的 SNMPv2 框架 (SNMPv2c)，它使用與 SNMPv1 相同的訊息格式和框架。還存在其他實驗性框架，例如 SNMPv2u 和 SNMPv2*。

SNMPv3 規格對 SNMP 採取模組化方法。所有模組彼此分離，並且可以單獨擴展或取代。模組的範例包括訊息定義、安全性和存取控制。SNMPv3 的主要功能是：

  • 新增加密和驗證功能。
  • 定義代理程式設定的 MIB。

所有這些規格通常被稱為「SNMPv3」，但實際上只有定義新訊息格式的訊息模組，以及處理加密和驗證的安全模組無法與 SNMPv1 或 SNMPv2c 一起使用。在此版本的代理程式工具組中，使用所有用於代理程式設定的標準 MIB。這包括用於定義通知管理目標的 MIB。無論代理程式設定為使用哪個 SNMP 版本，都會使用這些 MIB。

此工具組中的可擴展代理程式了解 SNMPv1、SNMPv2c 和 SNMPv3。回想一下，SNMP 由兩個獨立的部分組成，MIB 定義語言 (SMI) 和協定。在協定層級，代理程式可以設定為同時使用 v1、v2c、v3 或它們的任何組合，也就是說，v1 請求會得到 v1 回覆，v2c 請求會得到 v2c 回覆，v3 請求會得到 v3 回覆。在 MIB 層級，MIB 編譯器可以編譯 SMIv1 和 SMIv2 MIB。編譯完成後，任何格式都可以載入到代理程式中，無論代理程式設定為使用哪個協定版本。這表示代理程式會將 v2 通知轉換為 v1 陷阱，反之亦然。例如，v2 MIB 可以載入到僅使用 v1 的代理程式中。RFC 1908 和 RFC 2089 中描述了兩種協定之間的轉換程序。

為了讓實作充分利用增強的 SNMPv2 錯誤代碼，檢測函數在發生錯誤時必須始終傳回 SNMPv2 錯誤代碼。如有必要，代理程式會將這些錯誤代碼轉換為對應的 SNMPv1 錯誤代碼。

注意

從 SMIv1 MIB 轉換為 SNMPv2c 或 SNMPv3 回覆始終非常簡單，但從 v2 MIB 轉換為 v1 回覆則有些複雜。SMIv2 中有一種資料類型稱為 Counter64，SNMPv1 管理員無法正確解碼。因此，代理程式永遠不得將 Counter64 物件傳送給 SNMPv1 管理員。在這些情況下，常見的做法是在將回覆或陷阱傳送給 SNMPv1 管理員時簡單地忽略任何 Counter64 物件。例如，如果 SNMPv1 管理員嘗試 GET 類型為 Counter64 的物件，他會收到 noSuchName 錯誤，而 SNMPv2 管理員會收到正確的值。

操作

要讓代理程式運作，需要執行以下步驟：

  1. 在文字檔中以 SMI 撰寫您的 MIB。
  2. 以 Erlang 撰寫檢測函數並編譯它們。
  3. 將它們的名稱放入關聯檔案中。
  4. 將 MIB 連同關聯檔案一起執行 MIB 編譯器。
  5. 設定應用程式（代理程式）。
  6. 啟動應用程式（代理程式）。
  7. 將編譯的 MIB 載入代理程式。

本節中的圖說明了 SNMP 代理程式開發中涉及的步驟。

MIB Compiler Principles

編譯器會剖析 SMI 檔案，並將每個表格或變數與檢測函數相關聯（請參閱圖 MIB 編譯器原則）。MIB 編譯時不需要實際的檢測函數，只需要它們的名稱。

編譯器產生的二進位輸出檔由代理程式在 MIB 載入時讀取（請參閱圖 啟動代理程式）。檢測是普通的 Erlang 程式碼，會在第一次呼叫時明確或自動載入。

Starting the Agent

SNMP 代理程式系統由一個主代理程式和可選的子代理程式組成。主代理程式可以視為一種特殊的子代理程式。它實作核心代理程式功能、UDP 封包處理、類型檢查、存取控制、陷阱分配等等。從使用者的角度來看，它會像一個普通的子代理程式一樣使用。

如果您的應用程式需要 SNMP 工具組的特殊分散式支援，則只需要子代理程式。如果應用程式需要比主代理程式中更複雜的設定交易方案，也可以使用子代理程式。

以下圖示顯示了系統在執行時的外觀。

Architecture

典型的操作可能包含以下步驟：

  1. 管理員將請求傳送給代理程式。
  2. 主代理程式會解碼傳入的 UDP 封包。
  3. 主代理程式會判斷請求中的哪些項目應該在此處處理，哪些項目應該轉發給其子代理程式。
  4. 所有子代理程式都會重複步驟 3。
  5. 每個子代理程式都會為其載入的 MIB 呼叫檢測。
  6. 呼叫檢測的結果會傳回給主代理程式。
  7. 請求的回應會編碼為 UDP 協定資料單元 (PDU)。

顯示的步驟順序可能比正常情況複雜，但它說明了可用的功能量。應注意以下幾點：

  • 代理程式可以同時載入多個 MIB。
  • 子代理程式也可以有子代理程式。每個子代理程式都可以註冊任意數量的子子代理程式，形成階層結構。
  • 一個 MIB 可以與多個應用程式通訊。
  • 檢測可以使用分散式 Erlang 與應用程式通訊。

大多數應用程式只需要主代理程式，因為代理程式可以同時載入多個 MIB。

子代理程式和 MIB 載入

由於應用程式往往是暫時性的（它們是動態載入和卸載的），因此對這些應用程式的管理也必須是動態的。例如，如果我們有一個機架的設備 MIB 和不同板卡的 MIB，這些板卡可以安裝在機架中，則應該在插入板卡時載入卡片的 MIB，並在移除板卡時卸載。

在此代理程式系統中，有兩種動態安裝管理資訊的方法。最常見的方法是將 MIB 載入代理程式。另一種方法是使用由應用程式控制且能夠註冊和取消註冊自身的子代理程式。子代理程式可以註冊自身來管理子樹（不要與 erlang:register 混淆）。子樹由物件識別碼識別。當子代理程式註冊時，它會收到針對此特定子樹的所有請求，並且負責回應這些請求。還應注意，子代理程式可以隨時啟動和停止。

與其他 SNMP 代理程式套件相比，這種使用子代理程式的方式有顯著差異。其他套件通常使用子代理程式來在執行時載入和卸載 MIB。在 Erlang 中，很容易在執行時載入程式碼，並且可以將 MIB 載入到現有的子代理程式中。不需要建立新程序來處理新的 MIB。

使用子代理程式的原因如下：

  • 提供比主代理程式更複雜的設定交易方案
  • 避免不必要的程序通訊
  • 提供更輕量級的機制來在執行時載入和卸載 MIB
  • 提供與其他 SNMP 代理程式工具組的互動。

有關這些主題的更多資訊，請參閱本使用者指南中的進階代理程式主題章節。

子代理程式之間的通訊協定是在分散式 Erlang 系統中使用的正常訊息傳遞。這表示相較於 SMUX、DPI、AgentX 和類似協定，子代理程式通訊非常有效率。

內容和社群

一個上下文 (context) 是一組可由 SNMP 實體存取的管理資訊集合。一個管理物件的實例可能存在於多個上下文中。一個 SNMP 實體可能存取許多上下文。

每個被管理物件在一個 SNMP 實體內可以存在多個實例。為了識別由 MIB 模組指定的實例，會使用一種方法來通過其「範圍」或上下文來區分實際的實例。上下文通常是一個實體或邏輯裝置。它可以包括多個裝置、單個裝置的子集或多個裝置的子集，但上下文始終被定義為單個 SNMP 實體的子集。為了能夠識別 SNMP 實體內的特定管理資訊項目，必須使用上下文、物件類型及其例項。

例如，來自 RFC1573 的管理物件類型 ifDescr，被定義為網路介面的描述。為了識別 device-X 的第一個網路介面的描述，需要四個資訊：SNMP 實體的 snmpEngineID，該實體提供對 device-X 管理資訊的存取權；contextName (device-X)；被管理物件類型 (ifDescr)；以及實例 ("1")。

在 SNMPv1 和 SNMPv2c 中，訊息中的社群字串被用於（至少）三個不同的目的

  • 識別上下文
  • 提供身份驗證
  • 識別一組陷阱 (trap) 目標

在 SNMPv3 中，這些使用領域中的每一個都有其獨特的機制。上下文由 SNMP 實體的名稱 contextEngineID 和上下文的名稱 contextName 識別。每個 SNMPv3 訊息都包含這兩個參數的值。

有一個 MIB，SNMP-COMMUNITY-MIB，它將社群字串映射到 contextEngineID 和 contextName。因此，每個訊息，無論是 SNMPv1、SNMPv2c 還是 SNMPv3 訊息，始終唯一地識別一個上下文。

對於代理程式而言，接收到的訊息所識別的 contextEngineID 始終等於代理程式的 snmpEngineID。否則，該訊息並非發送給該代理程式的。如果代理程式配置了多個上下文，則檢測程式碼必須能夠確定該請求是發送給哪個上下文的。為此目的提供了一個函式 snmpa:current_context/0。

預設情況下，代理程式除了預設上下文 "" 之外，對任何其他上下文一無所知。如果要支援更多上下文，必須透過使用適當的組態檔案 代理程式組態檔案 來顯式新增這些上下文。

代理程式管理

有一組標準 MIB，用於控制和組態 SNMP 代理程式。除了可選的 SNMP-PROXY-MIB（僅用於代理程式）之外，所有這些 MIB 都在此代理程式中實作。此外，可以配置實際載入哪些 MIB，從而使其對 SNMP 管理器可見。例如，在不安全的環境中，最好不要讓定義存取控制的 MIB 可見。請注意，MIB 定義的資料在代理程式內部使用，即使 MIB 沒有被載入。本章描述了這些標準 MIB 及其一些實作細節。

任何 SNMP 代理程式都必須實作 MIB-II 中定義的 system 群組和 snmp 群組。這些群組的定義已從 SNMPv1 變更為 SNMPv2。發行版中提供了這兩個版本的 MIB 和實作。SNMPv1 的 MIB 檔案稱為 STANDARD-MIB，SNMPv2 的對應檔案稱為 SNMPv2-MIB。如果代理程式僅配置為 SNMPv1，則預設會載入 STANDARD-MIB；否則，預設會載入 SNMPv2-MIB。可以透過顯式載入此 MIB 的另一個版本來覆寫此預設行為，例如，您可以選擇實作這兩個 MIB 中所有物件的聯集。

SNMPv3 代理程式必須實作 SNMP-FRAMEWORK-MIB 和 SNMP-MPD-MIB。如果代理程式配置為 SNMPv3，則預設會載入這些 MIB。這些 MIB 也可以載入其他版本。

還有另外五個標準 MIB，也可以載入代理程式中。這些 MIB 是

  • SNMP-TARGET-MIB 和 SNMP-NOTIFICATION-MIB，它們定義了用於組態管理目標（即通知（陷阱和通知）接收器）的管理物件。這些 MIB 可以與任何 SNMP 版本一起使用。
  • SNMP-VIEW-BASED-ACM-MIB，它定義了用於存取控制的管理物件。此 MIB 可以與任何 SNMP 版本一起使用。
  • SNMP-COMMUNITY-MIB，它定義了用於 SNMPv1 和 SNMPv2c 與 SNMPv3 共存的管理物件。僅當使用 SNMPv1 或 SNMPv2c 時（可能與 SNMPv3 結合使用），此 MIB 才有用。
  • SNMP-USER-BASED-SM-MIB，它定義了用於身份驗證和私密性的管理物件。此 MIB 僅適用於 SNMPv3。

所有這些 MIB 都應載入到主代理程式中。載入後，這些 MIB 始終在所有上下文中可用。

這些 MIB 的 ASN.1 程式碼、Erlang 原始程式碼和產生的 .hrl 檔案都包含在發行版中，並分別放置在 snmp 應用程式的 mibs、src 和 include 目錄中。

.hrl 檔案是使用 snmpc:mib_to_hrl/1 產生的。在您的程式碼中包含這些檔案，如下例所示

-include_lib("snmp/include/SNMPv2-MIB.hrl").

這些表中定義的管理物件的初始值在啟動時從一組組態檔案中讀取。這些組態檔案在 組態檔案 中描述。

STANDARD-MIB 和 SNMPv2-MIB

這些 MIB 包含來自 MIB-II 的 snmp- 和 system 群組，它們在 RFC1213 (STANDARD-MIB) 或 RFC1907 (SNMPv2-MIB) 中定義。它們在 snmp_standard_mib 模組中實作。snmp 計數器全部駐留在揮發性記憶體中，而 system 和 snmpEnableAuthenTraps 變數則使用 SNMP 內建資料庫駐留在永久性記憶體中（有關詳細資訊，請參閱參考手冊，snmp 區段，snmpa_local_db 模組）。

如果需要這些變數的另一個實作，例如將永久性變數儲存在 Mnesia 資料庫中，則必須自行實作這些變數。該 MIB 將被編譯並載入，而不是預設 MIB。新的編譯 MIB 必須與原始 MIB 具有相同的名稱（即 STANDARD-MIB 或 SNMPv2-MIB），並且位於 SNMP 組態目錄中（請參閱 組態檔案）。

始終會載入其中一個 MIB。如果僅使用 SNMPv1，則會載入 STANDARD-MIB，否則會載入 SNMPv2-MIB。

資料類型

SNMPv2 中有一些新的資料類型，這些類型在 SNMPv1 中也很有用。在 STANDARD-MIB 中，定義了三種資料類型，RowStatus、TruthValue 和 DateAndTime。這些資料類型最初在 SNMPv2-TC (RFC1903) 中定義為文字約定。

SNMP-FRAMEWORK-MIB 和 SNMP-MPD-MIB

SNMP-FRAMEWORK-MIB 和 SNMP-MPD-MIB 定義了額外的唯讀管理物件，這些物件在 RFC2271 中定義的通用 SNMP 框架以及 RFC2272 中定義的通用訊息處理和分派模組中使用。它們是通用的，因為它們不與任何特定的 SNMP 版本繫結。

這些 MIB 中的物件分別在 snmp_framework_mib 和 snmp_standard_mib 模組中實作。所有物件都駐留在揮發性記憶體中，並且組態檔案總是在啟動時重新讀取。

如果使用 SNMPv3，則預設會載入這些 MIB。

SNMP-TARGET-MIB 和 SNMP-NOTIFICATION-MIB

SNMP-TARGET-MIB 和 SNMP-NOTIFICATION-MIB 定義了用於組態通知接收器的管理物件。它們在 RFC2273 中詳細描述。此處僅給出簡要說明。

這些 MIB 中的所有表都有一個 StorageType 類型的列。此列的值指定每一列的儲存方式，以及在代理程式重新啟動時會發生什麼情況。實作支援 volatile 和 nonVolatile 值。當這些表最初從組態檔案中填入資料時，這些列將自動具有 nonVolatile 的儲存類型。如果代理程式重新啟動，所有 nonVolatile 列都將在重新啟動後保留，而 volatile 列將會遺失。預設情況下，不會在重新啟動時讀取組態檔案。

預設情況下不會載入這些 MIB。

snmpNotifyTable

snmpNotifyTable 中的一個項目選擇一組應接收通知的管理目標，以及應發送到每個選定管理目標的通知類型（陷阱或通知）。當應用程式使用函式 send_notification/5 或函式 send_trap 發送通知時，呼叫中指定的參數 NotifyName 將用作表中的索引。該通知將發送到該項目選擇的管理目標。

snmpTargetAddrTable

snmpTargetAddrTable 中的一個項目定義了每個管理目標的傳輸參數（例如 IP 位址和 UDP 連接埠）。snmpNotifyTable 中的每一列都可能參照 snmpTargetAddrTable 中的多列。snmpTargetAddrTable 中的每一列都參照 snmpTargetParamsTable 中的一個項目。

snmpTargetParamsTable

snmpTargetParamsTable 中的一個項目定義了要使用的 SNMP 版本，以及要使用的安全參數。

要使用的 SNMP 版本是透過指定訊息處理模型隱式定義的。此版本的代理程式處理模型 v1、v2c 和 v3。

每一列都指定要使用的安全模型，以及安全級別和安全參數。

SNMP-VIEW-BASED-ACM-MIB

SNMP-VIEW-BASED-ACM-MIB 定義了管理物件，用於控制管理器對管理物件的存取權。基於檢視的存取控制模組 (VACM) 可以與任何 SNMP 版本一起使用。但是，如果將其與 SNMPv1 或 SNMPv2c 一起使用，則 SNMP-COMMUNITY-MIB 會定義其他物件，以將社群字串映射到 VACM 參數。

此 MIB 中的所有表都有一個 StorageType 類型的列。此列的值指定每一列的儲存方式，以及在代理程式重新啟動時會發生什麼情況。實作支援 volatile 和 nonVolatile 值。當這些表最初從組態檔案中填入資料時，這些列將自動具有 nonVolatile 的儲存類型。如果代理程式重新啟動，所有 nonVolatile 列都將在重新啟動後保留，而 volatile 列將會遺失。預設情況下，不會在重新啟動時讀取組態檔案。

預設情況下不會載入此 MIB。

VACM 的詳細說明請參閱 RFC2275。此處僅做簡要描述。

其基本概念是MIB 視圖。MIB 視圖是代理程式實作的所有物件的子集。管理員可存取特定的 MIB 視圖，具體取決於使用的安全性參數、發出請求的內容以及請求的類型。

下圖概述了選擇 MIB 視圖的機制

Overview of the mechanism of MIB selection

vacmContextTable

vacmContextTable 是一個唯讀表格，其中列出了所有可用的內容。

vacmSecurityToGroupTable

vacmSecurityToGroupTable 將 securityModel 和 securityName 對應到 groupName。

vacmAccessTable

vacmAccessTable 將 groupName（在 vacmSecurityToGroupTable 中找到）、contextName、securityModel 和 securityLevel 對應到每個操作類型（讀取、寫入或通知）的 MIB 視圖。MIB 視圖以 viewName 表示。以 viewName 表示的 MIB 視圖的定義可以在 vacmViewTreeFamilyTable 中找到。

vacmViewTreeFamilyTable

vacmViewTreeFamilyTable 以 viewName 作為索引，並定義 MIB 視圖中包含哪些物件。

該表格的 MIB 定義如下所示

VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

INDEX { vacmViewTreeFamilyViewName,
        vacmViewTreeFamilySubtree
      }

每個 vacmViewTreeFamilyViewName 都指向一個子樹集合。

MIB 視圖語意

MIB 視圖是包含和排除的子樹的集合。子樹由物件識別符 (OBJECT IDENTIFIER) 識別。每個子樹都關聯一個遮罩。

對於每個可能的 MIB 物件實例，如果符合以下條件，則該實例屬於一個子樹

  • 該 MIB 物件實例的物件識別符名稱至少包含與子樹一樣多的子識別符，並且
  • 當相關聯的遮罩位元為 1 時，該 MIB 物件實例名稱中的每個子識別符都與子樹的對應子識別符相符（0 是符合任何內容的萬用字元）。

MIB 視圖中物件實例的成員資格由以下演算法決定

  • 如果 MIB 物件實例不屬於任何相關的子樹，則該實例不在 MIB 視圖中。
  • 如果 MIB 物件實例恰好屬於一個子樹，則根據該條目的類型，該實例會包含在相關的 MIB 視圖中或從中排除。
  • 如果 MIB 物件實例屬於多個子樹，則使用包含最多子識別符且詞典順序最大的子樹。

注意

如果物件識別符比 MIB 中物件類型的物件識別符長，則它指向物件實例。因此，可以控制是否顯示表格中的特定列。

SNMP-COMMUNITY-MIB

SNMP-COMMUNITY-MIB 定義了用於 SNMPv1 和 SNMPv2c 與 SNMPv3 共存的受管理物件。具體而言，它包含用於在社群字串和獨立於版本的 SNMP 訊息參數之間進行對應的物件。此外，此 MIB 還提供一種機制，用於對傳入請求執行來源位址驗證，以及根據外寄通知的目標位址選擇社群字串。

此 MIB 中的所有表格都有一個 StorageType 類型的欄。此欄的值指定每個列的儲存方式，以及在代理程式重新啟動時會發生什麼情況。此實作支援值 volatile 和 nonVolatile。當表格最初從組態檔填入資料時，這些列會自動具有 nonVolatile 儲存類型。如果代理程式重新啟動，則所有 nonVolatile 列都會在重新啟動後保留，而 volatile 列會遺失。預設情況下，不會在重新啟動時讀取組態檔。

預設情況下不會載入此 MIB。

SNMP-USER-BASED-SM-MIB

SNMP-USER-BASED-SM-MIB 定義了用於使用者式安全性模型的受管理物件。

此 MIB 中的所有表格都有一個 StorageType 類型的欄。此欄的值指定每個列的儲存方式，以及在代理程式重新啟動時會發生什麼情況。此實作支援值 volatile 和 nonVolatile。當表格最初從組態檔填入資料時，這些列會自動具有 nonVolatile 儲存類型。如果代理程式重新啟動，則所有 nonVolatile 列都會在重新啟動後保留，而 volatile 列會遺失。預設情況下，不會在重新啟動時讀取組態檔。

預設情況下不會載入此 MIB。

OTP-SNMPEA-MIB

在早期版本的代理程式中，在存在用於存取控制、MIB 視圖和陷阱目標規範的標準 MIB 之前，使用了 OTP-SNMPEA-MIB。此 MIB 中的所有物件現在都已過時。

通知

通知在 SMIv1 中使用 MIB 定義中的 TRAP-TYPE 巨集定義 (請參閱 RFC1215)。SMIv2 中的對應巨集是 NOTIFICATION-TYPE。當應用程式決定傳送通知時，它會呼叫下列其中一個函式

snmpa:send_notification(Agent, Notification, Receiver
                       [, NotifyName, ContextName, Varbinds])
snmpa:send_trap(Agent, Notification, Community [, Receiver, Varbinds])

提供載入定義通知的 MIB 的代理程式的註冊名稱或程序識別碼，以及通知的符號名稱。

如果使用 send_notification/3,4 函式，則會選取 RFC2273 中定義的所有管理目標。Receiver 參數定義代理程式應將有關通知請求傳遞的資訊傳送至何處。

如果使用 send_notification/5 函式，則必須提供 NotifyName。此參數用作 snmpNotifyTable 中的索引，並且使用該單一條目定義的管理目標。

send_notification/6 函式是該函式的最通用版本。必須指定 ContextName，通知將從該內容傳送。如果未指定此參數，則會使用預設內容 ("")。

保留函式 send_trap 是為了向後相容，不應在新程式碼中使用。使用此函式的應用程式將會繼續運作。當傳送通知時，代理程式會將 snmpNotifyName 用作社群字串。

傳送通知

傳送通知的最簡單方式是呼叫函式 snmpa:send_notification(Agent, Notification, no_receiver)。在這種情況下，代理程式會執行 get 操作，以擷取通知規範（使用 TRAP-TYPE 或 NOTIFICATION-TYPE 巨集）中定義的物件值。通知會傳送至目標和通知表格中定義的所有管理員，可以是未經確認的陷阱，也可以是已確認的通知請求。

如果函式的呼叫者想要知道是否收到特定通知的確認 (前提是該通知作為通知請求傳送)，則 Receiver 參數可以指定為 {Tag, ProcessName} (如需更多詳細資訊，請參閱參考手冊，snmp 章節，snmp 模組)。在這種情況下，代理程式會針對每個管理目標傳送訊息 {snmp_notification, Tag, {got_response, ManagerAddr}} 或 {snmp_notification, Tag, {no_response, ManagerAddr}}。

有時，無法使用 get 操作來擷取通知規範中某些物件的值。但是，當呼叫 send_notification 函式時，這些值是已知的。如果物件是表格中的元素，則會出現這種情況。可以將某些物件的值提供給 send_notification 函式 snmpa:send_notification(Agent, Notification, Receiver, Varbinds)。在此函式中，Varbinds 是 Varbind 的清單，其中每個 Varbind 是下列其中之一

  • {Variable, Value}，其中 Variable 是通知規範中引用的純量變數的符號名稱。
  • {Column, RowIndex, Value}，其中 Column 是欄變數的符號名稱。RowIndex 是指定元素索引的清單。如果屬於這種情況，則在陷阱中傳送的 OBJECT IDENTIFIER 是附加至表格欄的 OBJECT IDENTIFIER 的 RowIndex。這是指定元素的 OBJECT IDENTIFIER。
  • {OID, Value}，其中 OID 是物件實例、純量變數或欄變數的 OBJECT IDENTIFIER。

例如，若要指定 sysLocation 在通知中的值應為 "upstairs"，我們可以使用下列其中一種

  • {sysLocation, "upstairs"} 或
  • {[1,3,6,1,2,1,1,6,0], "upstairs"}

也可以指定應該在通知中傳送，但未在通知規範中定義的額外變數的名稱和值。

通知會傳送至表格中找到的所有管理目標。但是，請確保每個管理員都可以存取通知中的變數。如果變數超出管理員的 MIB 視圖，則此管理員將不會收到通知。

注意

根據定義，無法在通知中傳送具有 ACCESS not-accessible 的物件。但是，從歷史上來看，這種情況經常發生，因此我們允許在通知傳送中執行此操作。如果變數具有 ACCESS not-accessible，則使用者必須在 Varbinds 清單中提供變數的值。代理程式無法執行 get 操作來擷取此值。

通知篩選器

可以將通知篩選器新增至代理程式。當要傳送通知時，將會呼叫這些篩選器。它們的目的是允許修改、抑制或其他類型的動作。

通知篩選器是一個實作 snmpa_notification_filter 行為的模組。可以使用函式 snmpa:register_notification_filter/5 和 snmpa:unregister_notification_filter/2 新增/刪除篩選器。

除非另有說明，否則註冊的篩選器順序將與它們的註冊順序相同。

子代理路徑

如果沒有將物件的值提供給 send_notification 函數，子代理將執行 get 操作來檢索它。如果此子代理中未實作該物件，則其父代理會嘗試執行 get 操作來檢索它。如果該物件也沒有在此代理中實作，則會將該物件轉發給其父代理，依此類推。最終會到達主代理，此時所有未知的物件值都必須被解析。如果即使主代理也不知道某些物件，則會將其視為錯誤，並透過呼叫錯誤報告模組的 user_err/2 進行報告。在這種情況下，不會發送任何通知。

對於給定的通知，通知規範中引用的變數必須由載入 MIB 的代理或此代理的某個父代理實作。如果沒有，則應用程式必須為未知的變數提供值。應用程式還必須為表格中的所有元素提供值。

探索

對於不需要回應的有效負載訊息（例如 SNMPv2-Trap、Response 或 Report PDU），發送者是權威。

對於需要回應的有效負載訊息（例如 Get、GetNext、Get-Bulk、Set 或 Inform PDU），接收者是權威。

代理可以執行探索並對探索做出回應。

代理會自主地回應探索，而無需使用者互動。

通過呼叫 snmpa:discovery/6 函數來啟動對管理器的探索。在 target_addr.conf 檔案中，目標（管理器）條目的 EngineId 欄位的值必須為 discovery。請注意，如果管理器沒有回應，則 Timeout 和 RetryCount 欄位會決定函數在返回之前將掛起多久。

一次只能對一個管理器執行探索。