2017-04-19 775 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的规则。