Есть ли какой-либо вариант использования для контекста SNMPv3 для ловушек

Скажем , я хочу отправить SNMP v3 trap/ сообщение об ошибке менеджеру. Обычно я использую авторизацию USM SHA с шифрованием AES. Команда выглядит так:

snmpinform -v 3 -e 0x111111111 -u myuser -a SHA -A mypass1 -x AES -X mypass2 -l authPriv udp:example.com:162 '' 1.0

И это прекрасно работает. Но в руководствах по SNMP и в справках упоминается, что команда traps/informs поддерживает параметр командной строки '-n' для указания контекста SNMP. Эта опция плохо документирована. Я не нашел примеров того, как и почему я должен это использовать. Если я просто добавлю некоторый контекст в приведенную выше команду, то INFORM не дойдет до моего менеджера.

Поэтому мой вопрос заключается в том, как правильно использовать эту опцию и есть ли варианты использования для контекстов SNMP с ловушками

Источник

1 ответ

Решение
  1. Прежде всего цитата из RFC 3411

Например, тип управляемого объекта ifDescr [RFC2863] определяется как описание сетевого интерфейса. Чтобы идентифицировать описание первого сетевого интерфейса устройства X, необходимы четыре элемента информации: snmpEngineID объекта SNMP, который обеспечивает доступ к информации управления на устройстве X, contextName (устройство X), тип управляемого объекта (ifDescr) и экземпляр ("1").

Каждый контекст имеет (как минимум) один уникальный идентификатор в домене управления. Один и тот же элемент информации управления может существовать в нескольких контекстах. Элемент управляющей информации может иметь несколько уникальных идентификаторов. Это происходит, когда элемент управляющей информации существует в нескольких контекстах, и это также происходит, когда контекст имеет несколько уникальных идентификаторов.

Комбинация contextEngineID и contextName однозначно идентифицирует контекст в административном домене; обратите внимание, что может быть несколько уникальных комбинаций contextEngineID и contextName, которые однозначно идентифицируют один и тот же контекст.

  1. Случаи применения

MIB OSPF, определенный IETF (RFC 1850), был разработан для работы только с одним процессом / экземпляром OSPF на данном маршрутизаторе.

Например, существует только один объект ospfRouterId, а не их таблица. Для обработки нескольких экземпляров RFC 4750 предлагает использовать контексты SNMPv3 для предоставления представлений для каждого экземпляра.

Управление связью нескольких экземпляров OSPF с контекстами SNMP

Этот KB предоставляет решение о том, как опрашивать информацию с сервера SNMP v3, который находится в экземпляре маршрутизации не по умолчанию

Ссылка Как получить информацию SNMP v3 из нестандартного экземпляра маршрутизации Juniper

Поэтому существует множество случаев, когда вы можете использовать контексты snmp: безопасность, отдельные логические объекты на одном физическом объекте и т. Д.

Источник
Другие вопросы по тегам