我想知道:我的设备有以下SNMP MIB条目:
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 }
但我真的不明白F-MIB::ifIndex.805306369 = INTEGER: 805306369
的含义是什么。我的期望是第一个数字应该从1开始,将逻辑数字映射到某个物理数字。
我的猜测是,一些实施者也不明白它应该做什么; - )
阅读RFC 2863(或RFC 2233),情况变得更加混乱: “它的值介于1和ifNumber的值之间。(...)”
“本备忘录中采用的解决方案只是删除要求 ifIndex的值必须小于ifNumber的值, 并保留ifNumber及其当前定义。“
“这种解决方案也导致了”漏洞“的可能性 ifTable,即ifTable中概念行的ifIndex值 不一定是连续的,但SNMP的GetNext(和GetBulk) 操作很容易处理这些漏洞。“
“对于持续性(重新初始化之间)的要求 通过在接口之后要求接口来满足接口的ifIndex值 动态删除,其ifIndex值不会被a重用 不同的动态添加界面,直到以下之后 重新初始化网络管理系统。这避免了 需要为所有可能的ifIndex值分配(提前) 可以动态添加的接口。“
我认为部分混乱来自于“ ifIndex 的值”,其中不清楚它是指左侧还是右侧(恕我直言,它是右侧)。左侧是索引表的唯一主键,右侧是任意虚拟值,还是什么?也许主要的设计缺陷是接口数据应该由唯一的接口名称访问,而不是可能随时更改的索引(索引仍可用于枚举可用的名称)
答案 0 :(得分:1)
ifIndex的语义没有任何限制,特别是它应该对人类有意义,否则它们将在RFC中明确地阐明。注意它说“推荐”,而不是“必需”。
某些SNMP代理直接映射逻辑网络接口(VLAN,隧道等),其实例编号对人类毫无意义。这只是意味着您的管理软件必须处理非连续索引。
答案 1 :(得分:1)
ifIndex
只是一个任意但唯一的数字,区分一个接口,在任何表中通过(具有INDEX)ifIndex
来标识接口。如何分配它们取决于实施。
当你有一个可读的INDEX对象(MAX-ACCESS是not-accessible
以外的值),对象的值("右边"正如你在问题中所说的那样)等于编码到实例标识符中的值(左侧)。也就是说,始终是 ifIndex.X = X
,因为ifIndex
是ifIndex
的索引,本身(X
= ifIndex
的值) 。对于 X 的任何对象都是如此,其中 X 是 X 的INDEX。出于这个原因,SMIv2声明INDEX对象具有MAX-ACCESS not-accessible
,除非表中没有其他可读(可访问)列:它们的值总是可以从实例标识符中获取,因此将列设置为可读是多余的。
SMIv1没有这个规则,这就是为什么你有时会在SMIv1模块中看到可读索引的原因,或者在ifIndex的情况下,最初编写为SMIv1模块的SMIv2模块,其中将INDEX更改为{{ 1}}会破坏兼容性并违反IETF规则,允许修改标准MIB。