SNMP的IF-MIB::ifIndex在IF-MIB::ifTable中的含义是什么？
我想知道:我有一个设备具有以下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: 1073741863snmptranslate -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的含义。我的期望是，第一个数字应该从一个开始，将一个逻辑数字映射到某个物理数字。
我猜想一些实施者也不知道它应该做什么;-)
阅读RFC 2863 (或RFC 2233)，情况变得更加混乱：“其值介于1和ifNumber的值之间。(.)”
“本备忘录中采用的解决方案是删除ifIndex值必须小于ifNumber值的要求，并保留ifNumber的当前定义。”
此解决方案还可能在ifTable中出现“漏洞”，即ifTable中概念性行的ifIndex值不一定是连续的，但是SNMP的GetNext (和GetBulk)操作很容易处理这些漏洞。
“在接口的ifIndex值被动态删除之后，在网络管理系统重新初始化之后，它的ifIndex值才会被不同的动态添加接口重新使用。这就避免了(预先)为所有可能动态添加的接口分配ifIndex值的需要。”
我认为混淆的部分原因是“ifIndex的价值”，不清楚它是指左侧还是右侧(IMHO是右侧)。左边是索引表的唯一主键，右边是任意的虚拟值，还是什么？可能主要的设计缺陷是，接口数据应该由唯一的接口名访问，而不是通过可能不时更改的索引访问(索引仍然可以用于枚举可用的名称)。
回答 2
Stack Overflow用户
发布于 2017-04-19 14:36:08
ifIndex的语义没有任何限制，特别是它应该对人类有意义，否则它们将在RFC中得到解释。注意，它写的是“推荐”，而不是“必需”。
一些SNMP代理直接将逻辑网络接口(VLAN、隧道等)映射为对人类毫无意义的实例号。这只是意味着你的管理软件必须处理非连续指数。
Stack Overflow用户
发布于 2017-08-08 12:06:49
ifIndex只是一个任意但唯一的数字，它将一个接口和另一个接口区别开来，该表通过(索引为) ifIndex来标识接口。如何分配它们取决于实现。
通常情况是，当您有一个可读的索引对象(MAX-ACCESS是not-accessible以外的一个值)时，对象的值(正如您在问题中所说的“右侧”)等于编码到实例标识符中的值(左侧)。也就是说，ifIndex.X = X，总是这样，因为ifIndex本身就是ifIndex的索引(X =ifIndex的值)。对于任何对象X，如果X是X的索引，则这是正确的。因此，SMIv2声明索引对象将具有MAX-ACCESS not-accessible，除非表中没有其他可读(可访问)的列:它们的值总是可以从实例标识符中获得，因此使列具有可读性是多余的。
SMIv1没有这条规则，这就是为什么您有时会在SMIv1模块中看到可读的索引，或者像在ifIndex的例子中一样，最初作为SMIv1模块编写的SMIv2模块，在这些模块中，将索引更改为not-accessible会破坏兼容性，并且违反了IETF允许对标准MIB进行修改的规则。
https://stackoverflow.com/questions/43497966
复制相似问题
腾讯云开发者
