MOXA ioLogik E2240 и ошибки съема данных по SNMP

В ходе работы над программой мониторинга контроллеров ioLogik (E2210, E2240) столкнулся с такой проблемой у устройств MOXA ioLogik E2240.

При опросе контроллеров по протоколу SNMP на предмет снятия данных по входящим и исходящим линиям от устройства запрашивается ветвь дерева MIB. В ответ приходит таблица, содержащая все значения OID’ов данной ветви.

Так вот, при опросе E2240 оказалось, что в ответ приходят не все данные. В ходе изучения сложившейся проблемы было установлено:

• при смене версии протокола с v2c на v1 данные поступали все;
• процесс приема данных должен оканчиваться в так называемом состоянии «End of SUBTREE Reached», а этого не происходило;
• прерывался прием данных при возникновении ошибки SNMP noSuchName.

Проанализировав факты, пришел к выводу, что железка не присылает (или присылает с ошибкой) самый последний ответ. В случае использования первой версии протокола (когда все значения запрашиваемой ветви передаются последовательно по одному) теряется только последний пакет, сообщающий о передачи всех значений дерева. Когда используется вторая версия протокола, данные передаются порциями по нескольку значений за один раз. В зависимости от числа OID’ов в пакете последний ответ устройства, кроме информационного сообщения о конце передачи, может содержать также несколько значений запрашиваемых OID’ов.

Перепрошивать устройства возможности нет (да еще и неизвестно исправлена ли эта ошибка в новых прошивках), а программа мониторинга все равно должна снимать данные с устройств. Очевидный выбор – использовать первую версию протокола SNMP, но это увеличит время опроса в несколько раз (в зависимости от размера порции данных)! (Для мониторинга увеличение времени опроса в 10 раз с «обычных» 0.5 секунд до 5 секунд является критичным).

Поэтому, стоит подумать, как получить все данные при использовании второго протокола.

Программа получает данные ветки 1.3.6.1.4.1.8691.10.2240.10, которая содержит 128 объектов. Когда размер пакета по-умолчанию равнялся 10, приходили данные по 120 объектам, а последние 8 терялись. Если взять любое из чисел 2,4,8,16,32,64,128, для которых 128 является кратным, и сделать размер порции равным этому числу, то данные будут приходить полностью (потеряется только последний пакет – информационный).

Думаю, лучше установить размер порции равной 16. В этом случае не будет большой нагрузки на железку и быстродействие будет оптимальным (как показал эксперимент использование большего размера пакета не увеличило быстродействие).