MIB編譯器和載入MIB
目錄
簡介
大多數網路管理系統 (NMS) 為使用者提供載入 MIB 的方法。載入 MIB 是 NMS 瞭解新 MIB 物件的一種方式，例如其名稱、物件識別碼 (OID) 和資料類型的種類 (例如計數器)。
MIB可能會在載入後進行解析，也可能稍後發生，例如，當NMS應用程式運行時。執行解析的軟體是MIB編譯器。
任何供應商的MIB編譯器都應成功解析任何語法正確的MIB。遺憾的是，不同的MIB編譯器可能會表現出不同的異常。
思科持續努力確保向客戶發佈的MIB語法正確。思科還避免了在常見NMS產品中證明有問題的MIB結構。儘管做出了這些努力，但不可能滿足現場所有MIB編譯器的怪異之處。
本文討論一些常見問題並提出解決方法。如果您在供應商的MIB編譯器中遇到上述任何問題(RFC 14xx與RFC 19xx問題除外)，則是由於該MIB編譯器的缺陷。您可能希望敦促您的供應商修復其編譯器。
必要條件
需求
本文檔的讀者應熟悉MIB。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
常見MIB載入問題
載入排序
載入MIB時，載入順序是最重要也是最常見的問題。許多MIB使用其他MIB中定義的定義。這些定義列在MIB頂部附近的IMPORTS子句中。
例如，如果MIB mumble從MIB mumble匯入定義，則某些MIB編譯器要求您在載入MIB mumble之前載入MIB bumble。如果載入順序錯誤，編譯器將宣告匯入的MIB未定義。
這是許多其他MIB從中匯入的MIB清單以及載入它們的順序。這可能解決了95%的載入順序問題（大多數其他MIB都可以按任何順序載入）：
-
SNMPv2-SMI.my
-
SNMPv2-TC.my
-
SNMPv2-MIB.my
-
RFC1213-MIB.my
-
IF-MIB.my
-
CISCO-SMI.my
-
CISCO-PRODUCTS-MIB.my
-
CISCO-TC.my
註：如果您正在載入這些MIB的v1版本，則MIB檔名實際上將類似於IF-MIB-V1SMI.my（「 — V1SMI」新增到從v2轉換到v1的MIB的名稱中）。 例外情況是RFC1213-MIB.my MIB，它僅作為v1版本存在（即沒有RFC1213-MIB-V1SMI.my）。
如果您嘗試載入另一個MIB，並且如果編譯器抱怨未定義的項，則識別此MIB從哪些MIB匯入，並驗證您首先載入了所有其他MIB。
註：對於每個MIB，您可以在SNMP Object Navigator > View & Download MIBs中檢視需要先載入的MIB的精確清單（使用確切的編譯順序）;選擇View MIB dependencies and download MIB。
資料型別定義不匹配
雖然Cisco MIB資料型別定義不會不匹配，但您可能會發現某些標準RFC MIB也是如此。例如：
-
MIB mumble定義：SomeDatatype ::= INTEGER(0..100)
-
MIB bumble定義：SomeDatatype ::= INTEGER(1..50)
此範例被視為簡單錯誤，MIB成功載入並出現警告訊息。
下一個示例被視為非平凡錯誤（即使兩個定義基本上是等效的），並且未成功分析MIB。
-
MIB mumble定義：SomeDatatype ::= DisplayString
-
MIB bumble定義：Some資料型別：:=二進位制八位數字串(大小(0.255))
如果MIB編譯器將這些錯誤視為錯誤，或者希望清除警告消息，則編輯定義此相同資料型別的MIB之一，以便定義匹配。
對象識別符號重新定義
如果載入這些MIB，可能會遇到OID重新定義（儘管也可能存在出現此錯誤的其他例項）：
例如：
-
OLD-CISCO-CPU-MIB.my定義：lcpu對象識別符號：:= { local 1 }
-
OLD-CISCO-ENV-MIB.my定義：lenv對象識別符號：:= { local 1 }
載入這兩個MIB時，MIB編譯器可能會抱怨lcpu OBJECT IDENTIFIER正使用新名稱lenv重新定義。OLD-CISCO-MEMORY-MIB.my和OLD-CISCO-SYSTEM-MIB.my類似地為{ local 1 }命名新名稱。
這被視為簡單錯誤，並且MIB成功載入一條警告消息。
如果MIB未成功載入，或者您希望消除警告消息，則編輯其中一個MIB，以便所有MIB使用相同的名稱。
內建資料型別定義
許多MIB編譯器都內建了一些資料型別的知識，例如DisplayString。有些編譯器在MIB中看到這些資料型別的定義時會抱怨。例如，DisplayString是在SNMPv2-TC中定義的。
解決方法是刪除或註釋掉MIB檔案中的違規定義。
備用大小
這是一個在語法上有效的示例，該示例指示MyDatatype型別的值長度將為0、5或20個八位元：
MyDatatype ::= OCTET STRING (SIZE(0 | 5 | 20))
有些MIB編譯器不接受此語法。通常，一個充分的解決方法是選取其中一個尺寸並移除其它尺寸。應該保持最大的尺寸。例如，上一個示例將更改為：
MyDatatype ::= OCTET STRING (SIZE(20))
奇數對象識別符號
有些OID被視為奇數，因為它們不引用SMI中的節點(與大多數OBJECT IDENTIFIER一樣)。 然而，它們的語法是有效的。一個常見的示例是空對象識別符號，例如{ 0 0 }。有些MIB編譯器不關心與SMI中的節點不對應的OBJECT識別符號。以下是MIB語法的示例，它們可能導致這些編譯器出現問題：
zeroDotZero OBJECT IDENTIFIER ::= { 0 0 }
myMIBObject OBJECT-TYPE
DEFVAL { {0 0} }
解決方法是刪除MIB檔案中那些型別的引用或註釋掉。
陷阱定義
在SNMPv1 MIB中，陷阱是使用TRAP-TYPE宏定義的。在SNMPv2 MIB中，陷阱是使用NOTIFICATION-TYPE宏定義的。
某些MIB編譯器不喜歡它們正在解析的MIB檔案中的這些定義（它們不支援這些宏）。
如果是這種情況，您可以刪除陷阱定義或註釋掉定義(例如，將MIB註釋分隔符-置於行的開頭)。
基於RFC 14xx的編譯器與基於RFC 19xx的編譯器
RFC 1442至1452定義基於參與方的SNMPv2。這些RFC已被較新的標準草案RFC 1902至1908取代。
在MIB語法方面，這兩個SNMPv2版本之間幾乎沒有差異；但也有一些人。Cisco MIB當前基於RFC 19xx規則。
註：幾年前，當Cisco MIB基於RFC 14xx時，一些基於RFC 19xx的編譯器會抱怨Unsigned32 ::= CISCO-TC.my和PNNI-MIB.my MIB中的TEXT-CONVENTIONS行。這是因為Unsigned32是RFC 19xx中預定義的資料型別。因此，思科過去有這些MIB的備用版本（CISCO-TC-NO-U32.my和PNNI-MIB-NO-U32.my），沒有針對Unsigned32的定義，因此需載入到已知此資料型別的編譯器中。此已不再適用。
將MIB載入並編譯到第三方NMS中
將Cisco MIB、陷阱和圖示載入到第三方NMS的最佳和最有效的方法是使用CiscoWorks整合實用程式（整合實用程式），它作為CiscoWorks公共服務(或獨立於http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-utility)的一部分提供，並帶有相應的整合實用程式介面卡(位於http://www.cisco.com/tacpage/sw-center/cw2000/cmc3rd.shtml)和最新的網路管理整合資料套件(NMIDB)。 有關詳細資訊，請檢視整合實用程式文檔。
或者，您可以查閱第三方NMS有關MIB載入和編譯的文檔。本文檔包含有關HP OpenView和IBM NetView的說明；但是由於產品可能會更改，您仍應查閱HP或IBM文檔。
在HP OpenView或IBM NetView的GUI上
按照以下步驟載入所需的Cisco MIB:
-
將檔案複製到網路管理工作站的目錄/usr/OV/snmp_mib中。
這是HP OpenView和IBM NetView查詢MIB文檔的預設目錄。如果將這些路徑放在其他位置，請在loadmib圖形介面中指定顯式路徑名。
-
設定許可權，以便您具有對MIB的讀取訪問許可權。
-
在GUI選單中，選擇Options > Load/Unload MIBs。
-
按照平台文檔中的說明編譯或載入Cisco MIB。
從HP OpenView或IBM NetView的命令列介面
發出/opt/OV/bin/xnmloadmib -load filename 命令，載入MIB檔案。
意見