Кто выбирает недоступное значение индекса таблицы MIB? Обеспечивает ли агент SNMP уникальность значения?

Я реализую агент SNMP и не уверен, правильно ли я понимаю, как выбираются значения для объекта «t11ZsZoneMemberIndex» (см. ниже) и кто обеспечивает уникальность значений.

Насколько я понимаю, менеджер SNMP выберет значение для объекта «t11ZsZoneMemberIndex» и использует его в поле «имя» VarBind в операции SET. Агент SNMP обеспечивает уникальность значения «t11ZsZoneMemberIndex» при получении SET. Это правильно? Если нет, то почему?

Таблица MIB — это SMIv2 с объектом RowStatus. Я понимаю, откуда берутся значения для других индексов.

t11ZsZoneMemberTable OBJECT-TYPE

    SYNTAX SEQUENCE OF T11ZsZoneMemberEntry
    MAX-ACCESS not-accessible
::= { t11ZsConfiguration 6 }

t11ZsZoneMemberEntry OBJECT-TYPE

    SYNTAX T11ZsZoneMemberEntry
    MAX-ACCESS not-accessible
INDEX { fcmInstanceIndex, fcmSwitchIndex,
    t11ZsServerFabricIndex, t11ZsZoneMemberParentType,
    t11ZsZoneMemberParentIndex, t11ZsZoneMemberIndex }

::= { t11ZsZoneMemberTable 1 }

T11ZsZoneMemberEntry ::= SEQUENCE {

    t11ZsZoneMemberParentType INTEGER,
    t11ZsZoneMemberParentIndex Unsigned32,
    t11ZsZoneMemberIndex Unsigned32,
    t11ZsZoneMemberFormat T11ZsZoneMemberType,
    t11ZsZoneMemberID OCTET STRING,
    t11ZsZoneMemberRowStatus RowStatus
}

t11ZsZoneMemberParentType OBJECT-TYPE

    SYNTAX INTEGER {
        zone(1), -- member belongs to a Zone
        alias(2) -- member belongs to a Zone Alias
    }
    MAX-ACCESS not-accessible
::= { t11ZsZoneMemberEntry 1 }

t11ZsZoneMemberParentIndex OBJECT-TYPE

    SYNTAX Unsigned32 (1..4294967295)
    MAX-ACCESS not-accessible
::= { t11ZsZoneMemberEntry 2 }

t11ZsZoneMemberIndex OBJECT-TYPE

    SYNTAX Unsigned32 (1..4294967295)
    MAX-ACCESS not-accessible
    DESCRIPTION
        "An index value that uniquely identifies this Zone
        Member amongst all Zone Members in the Zone Set
        database of a particular Fabric on a particular switch."
::= { t11ZsZoneMemberEntry 3 }

t11ZsZoneMemberFormat OBJECT-TYPE

    SYNTAX T11ZsZoneMemberType
    MAX-ACCESS read-create
::= { t11ZsZoneMemberEntry 4 }

t11ZsZoneMemberID OBJECT-TYPE

    SYNTAX OCTET STRING (SIZE (1..255))
    MAX-ACCESS read-create
::= { t11ZsZoneMemberEntry 5 }

t11ZsZoneMemberRowStatus OBJECT-TYPE

    SYNTAX RowStatus
    MAX-ACCESS read-create
::= { t11ZsZoneMemberEntry 6 }

person user1034804    schedule 08.11.2011    source источник


Ответы (1)


Вы правы, да. Но все немного сложнее: требования SNMP заключаются в том, что весь набор индексов MIB должен быть уникальным при объединении. Таким образом, указанная выше MIB имеет 6 индексов, поэтому каждая строка в таблице может иметь одну строку для каждой комбинации этих 6 значений. Это означает, что технически значение t11ZsZoneMemberIndex может дублироваться, если другое значение индекса отличается.

Если есть требование, чтобы t11ZsZoneMemberIndex был уникальным сам по себе, то MIB действительно следовало бы определить таким образом и сделать его единственным объектом в списке MIB INDEX. Нет необходимости добавлять несколько уникальных индексов к самому индексу (и это пустая трата полосы пропускания).

Но если есть несколько уникальных экземпляров, и они могут конфликтовать, когда менеджер выполняет SET, тогда да... Менеджер должен отклонить запрос SET и вернуть ошибку, когда отправляемые данные несовместимы с внутренней представление о том, что приемлемо.

person Wes Hardaker    schedule 11.11.2011
comment
Хорошо, спасибо, что указали на тонкость. Так что технически мне пришлось бы отслеживать уникальность t11ZsZoneMemberIndex для каждого уникального кортежа {fcmInstanceIndex, fcmSwitchIndex, t11ZsServerFabricIndex, t11ZsZoneMemberParentType, t11ZsZoneMemberParentIndex}. Звучит как много бухгалтерии. - person user1034804; 11.11.2011
comment
Да, хотя хороший программный компонент с индексным кешем может вам сильно помочь. - person Wes Hardaker; 11.11.2011