В чем смысл 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: 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. Я ожидаю, что первое число должно начинаться с единицы, сопоставляя логическое число с некоторым физическим числом.

Я предполагаю, что некоторые разработчики также не понимали, что он должен делать ;-)

Читая RFC 2863 (или RFC 2233), ситуация становится еще более запутанной: «Его значение находится в диапазоне от 1 до значения ifNumber. (...)»

«Решение, принятое в этом меморандуме, состоит в том, чтобы просто удалить требование о том, что значение ifIndex должно быть меньше значения ifNumber, и сохранить ifNumber с его текущим определением».

«Это решение также приводит к возможности «дыр» в ifTable, то есть значения ifIndex концептуальных строк в ifTable не обязательно являются смежными, но операция SNMP GetNext (и GetBulk) легко справляется с такими дырами».

"Требование постоянства (между повторными инициализациями) значения ifIndex интерфейса выполняется за счет требования, чтобы после динамического удаления интерфейса его значение ifIndex не использовалось повторно другим динамически добавляемым интерфейсом до тех пор, пока после последующей повторной инициализации системы управления сетью. Это позволяет избежать необходимости назначения (заранее) значений ifIndex для всех возможных интерфейсов, которые могут быть добавлены динамически».

Я думаю, что часть путаницы возникает из-за «value of ifIndex», где неясно, относится ли оно к левой или правой стороне (ИМХО, это правая сторона). Является ли левая сторона уникальным первичным ключом к индексной таблице, а правая — просто произвольным фиктивным значением или что? Возможно, основной недостаток дизайна заключается в том, что доступ к данным интерфейса должен осуществляться по уникальному имени интерфейса, а не по индексу, который может время от времени меняться (индекс все равно можно использовать для перечисления доступных имен). .


network-interface snmp mib
person U. Windl    schedule 19.04.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Нет никаких ограничений на семантику ifIndex, особенно в отношении того, что он должен быть понятен человеку, иначе они были бы явно указаны в RFC. Обратите внимание, что здесь написано «рекомендуется», а не «требуется».

Некоторые агенты SNMP напрямую отображают логические сетевые интерфейсы (VLAN, туннели и т. д.) с номерами экземпляров, которые не имеют смысла для людей. Это просто означает, что ваше программное обеспечение для управления должно иметь дело с несмежными индексами.

person Gambit Support    schedule 19.04.2017
comment
Мой вопрос заключался в том, какая цель у него есть, а не какой цели у него нет. - person U. Windl; 20.04.2017

arrow_upward
1
arrow_downward

ifIndex — это просто произвольное, но уникальное число, отличающее один интерфейс от другого в любой таблице, которая идентифицирует интерфейсы (имеет ИНДЕКС) ifIndex. Как они назначаются, зависит от реализации.

Всегда бывает так, что когда у вас есть читаемый объект INDEX (MAX-ACCESS — это значение, отличное от not-accessible), значение объекта («правая сторона», как вы выразились в своем вопросе) равно значение, закодированное в идентификаторах экземпляра (левая сторона). То есть всегда ifIndex.X = X, потому что ifIndex является ИНДЕКСОМ для самого ifIndex (X = значение ifIndex). Это справедливо для любого объекта X, где X — это ИНДЕКС для X. По этой причине SMIv2 утверждает, что объекты INDEX должны иметь MAX-ACCESS not-accessible, если только в таблице нет других доступных для чтения (доступных) столбцов: их значение всегда можно получить из идентификаторов экземпляра, поэтому наличие столбца, доступного для чтения, излишне.

В SMIv1 не было этого правила, поэтому вы иногда будете видеть читаемые индексы в модулях SMIv1 или, как в случае с ifIndex, в модулях SMIv2, которые изначально были написаны как модули SMIv1, где изменение INDEX на not-accessible нарушило бы совместимость и нарушило бы требования IETF. правила допустимых модификаций стандартных MIB.

person Michael Kirkham    schedule 08.08.2017