2017-04-19 291 views
0

我想:我有一個具有以下SNMP MIB條目的設備:什麼是SNMP的IF-MIB ::的ifIndex的IF-MIB :: ifTable中的含義是什麼?

IF-MIB::ifNumber.0 = INTEGER: 46 
IF-MIB::ifIndex.805306369 = INTEGER: 805306369 
IF-MIB::ifIndex.805306370 = INTEGER: 805306370 
.... 
IF-MIB::ifIndex.1073741861 = INTEGER: 1073741861 
IF-MIB::ifIndex.1073741862 = INTEGER: 1073741862 
IF-MIB::ifIndex.1073741863 = INTEGER: 1073741863 

snmptranslate -IR -Td ifIndex說:

IF-MIB::ifIndex 
ifIndex OBJECT-TYPE 
    -- FROM IF-MIB 
    -- TEXTUAL CONVENTION InterfaceIndex 
    SYNTAX Integer32 (1..2147483647) 
    DISPLAY-HINT "d" 
    MAX-ACCESS read-only 
    STATUS current 
    DESCRIPTION "A unique value, greater than zero, for each interface. It 
      is recommended that values are assigned contiguously 
      starting from 1. The value for each interface sub-layer 
      must remain constant at least from one re-initialization of 
      the entity's network management system to the next re- 
      initialization." 
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) interfaces(2) ifTable(2) ifEntry(1) 1 } 

但我真的不明白的​​的意思是什麼。我的期望是第一個數字應該從1開始,將邏輯數字映射到某個物理數字。

我的猜測是,一些執行者也說不明白什麼應該做;-)

閱讀RFC 2863(或RFC 2233中),形勢變得撲朔迷離,甚至更多: 「它值1之間的範圍ifNumber的價值。(......)「

」本備忘錄採取的辦法就是刪除要求 說的ifIndex的值必須小於ifNumber, 的價值,並保留ifNumber其目前的定義「。

「這個解決方法還導致的可能性‘在 ifTable中孔’,即,ifTable中 概念行的ifIndex值不一定是連續的,但SNMP的的GetNext(和GETBULK) 操作容易地與涉及這樣的洞。「

「的 接口的的ifIndex值的用於恆常要求(再初始化之間)通過要求後的界面 被動態移除,其ifIndex的值不被重新使用由 不同動態添加滿足接口,直到網絡管理系統的以下 重新初始化之後,這避免了 需要的ifIndex值的分配(提前)對可能被動態地添加所有可能 接口「。

我認爲混亂的一部分來自於「ifIndex」的值「」,其中不清楚它是指左側還是右側(恕我直言它是右側)。左側是索引表的唯一主鍵,右側是任意的虛擬值,或者是什麼?也許主要的設計缺陷是接口的數據應該由唯一接口名稱由可能隨時改變索引來訪問,而不是(索引仍可使用枚舉可用的名稱)。

回答

1

有到的ifIndex的語義沒有限制,尤其是,它應該是有意義的人,否則他們將在RFC被明確地闡述。注意它說「推薦」,而不是「必需」。

一些SNMP代理直接映射邏輯網絡接口(VLAN,隧道等)用實例號是毫無意義的人類。這隻意味着您的管理軟件必須處理非連續的索引。

+0

我的問題是有什麼樣的目的,而不是它沒有什麼目的。 –

1

ifIndex只是一個任意但唯一的數字,在任何表格中區分一個接口與另一個接口,這些表格通過(具有的索引)ifIndex來標識接口。它們如何分配取決於實施。

當您有一個可讀的INDEX對象(MAX-ACCESS是一個非not-accessible的值)時,總是這樣的,對象的值(在您的問題中將它放在「右側」等於編碼到實例標識符中的值(左側)。也就是,ifIndex.X = X,總是,因爲ifIndexifIndex的索引本身(X =值爲ifIndex)。這是任何對象X其中XX的INDEX如此。出於這個原因,SMIv2的指出INDEX對象是具有最大權限not-accessible除非沒有其它可讀的(可訪問的)列在表中:總是可以從實例標識符獲得其值,所以具有該列是可讀的是多餘的。

SMIv1沒有這個規則,這就是爲什麼你會在SMIv1模塊中看到可讀索引的原因,或者在ifIndex的情況下,原來寫爲SMIv1模塊的SMIv2模塊,其中將INDEX更改爲not-accessible會破壞兼容性並破壞了IETF關於允許修改標準MIB的規則。