Ответ 1
А агенты сохраняют свое состояние на самом устройстве?
Вы можете хранить данные на устройстве или выключать его. Оба варианта возможны и оба выполняются. Проблема с хранением (кэшированием) состояния агента относительно удаленного устройства заключается в том, что система управления никогда не знает, могут ли (кэшированные) данные в агенте быть обновленными. Если вы не можете рассчитывать на это, вам нужно будет использовать диспетчер для запуска синхронизации или опроса состояния удаленного устройства и/или линии связи между агентом и удаленным устройством. Как только вы попадаете в эту игру, часто лучше просто поставить субагент на удаленное устройство и использовать стандартные протоколы SNMP для получения информации.
Если на агенте есть ловушка, можете ли вы сделать опрос на том же OID, чтобы получить ту же информацию?
Большинство хорошо спроектированных MIB фактически помещают измененный объект MIB прямо в ловушку. Таким образом, ваш SNMP Manager не должен опросить агента, чтобы быть уверенным.
Сказав это, ловушка на Entity-MIB не имеет каких-либо переменных состояния. Однако эта MIB используется для описания физической инвентаризации, такой как полки, карты и порты, а ловушка выбрасывается только в случае изменения физической конфигурации. В этом случае ожидается, что ваш SNMP-менеджер снова запустит Entity-MIB, чтобы получить полную новую физическую конфигурацию.
Без использования файла MIB существует ли способ запросить устройство для всей его информации сразу?
Да. Сверните свой собственный MIB и поставьте все, что хотите. Вы можете поместить всю конфигурацию устройства в один объект MIB. Нижняя сторона этого заключается в том, что вам нужно будет написать парсер в вашем диспетчере SNMP для анализа структуры, и если структура изменится, вам нужно будет выяснить значение разницы между текущим значением и предыдущим значением, т.е. вы будете изобретать некоторую SNMP MIB. Однако для очень маленьких MIB это может стоить того.
Вам, вероятно, лучше использовать SNMP GET-BULK или просто делать MIB-ходу, последовательно вызывая SNMP-GET-NEXT, пока не вернется больше объектов.
Если нет, и вы пишете свой собственный настраиваемый менеджер, вам нужно знать структуру того, что он сообщает перед собой?
Если вы хотите, чтобы ваш "настраиваемый менеджер" был простым, вам нужно будет знать структуру вверх. Если вам нужна гибкость, вам понадобится язык описания структуры, с помощью которого можно кодировать структуру, и ваш менеджер должен будет иметь возможность декодировать это из данных агента и заполнять диспетчер, а также получать данные от менеджера и кодировать его в этот формат отправит его агенту (агентам). т.е. вы повторно изобретаете SNMP/SMI, CMIP/CMISE, CIM и множество других систем и протоколов управления, которые уже развернуты.
Если вы настраиваете агента для сообщения, обычно есть способ контролировать частоту того, как часто он посылает ловушку? Или обычно он посылает ловушку так часто, как выполняется какое-то условие?
Это хороший вопрос, потому что вы часто получаете штормовой шторм, забивающий вашу сеть именно тогда, когда вам нужна ваша сеть больше всего. Это затрудняет прогнозирование того, сколько сети требуется.
Используйте ловушки разумно. Например, у Entity-MIB есть только одна ловушка, и ее стоит использовать, поскольку она сообщает о изменениях физической структуры. Интерфейсы-MIB имеют потенциально много ловушек на порт. Для этого MIB лучше всего включить ловушки для интерфейса, привязанного к физическому порту, а не для интерфейсов, уложенных поверх интерфейсов нижнего уровня. Для большой сети часто лучше всего использовать комбинацию опроса плюс ловушки для физического оборудования и физических интерфейсов. Таким образом, вы можете предсказать, какая часть вашей сети будет использоваться для управления трафиком, будь то при нормальной работе или во время сетевой катастрофы.
В некоторых стандартных MIB указывается, как часто или когда вы можете бросить ловушку. Если вы в порядке с этим, используйте его. Вы всегда можете свернуть свой собственный MIB предприятия с конфигурационными объектами MIB, которые позволяют вашему менеджеру дросселировать определенные ловушки.