Используя протокол SNMP, можно получать данные разными способами. Выбор способа зависит от задачи. Самый простой путь - использование метода Get, когда запрашивается значение ключа по конкретному адресу. При методе Walk будет последовательно опрошена вся ветка, а при BulkWalk значения будут возвращаться не поштучно, а небольшими блоками.
Попробуем получить данные для конкретного OID .1.3.6.1.2.1.1.1.0 (sysDescr.0) тремя разными способами и посмотрим на отличия в работе пакета net-snmp. Запросы в примерах обозначены Q, а ответы R. Здесь мы, по большей части, рассмотрим порядок запросов и ответов, а не их содержание.
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0
Здесь все просто. Мы запросили заранее известный адрес и получили ответ.
Q: get-next-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0
Все несколько усложнилось. Метод Walk предполагает, что в качестве начального адреса указан раздел верхнего уровня, в котором требуется найти все нижележащие адреса. Поэтому он спрашивает адрес следующего OID, используя get-next-request. Однако в get-response приходит адрес уже другой ветки, что значит, что текущая исчерпана до конца. Собственно говоря, на этом работа Walk заканчивается (нас обманули, расходимся). Дальше уже идет обычный Get-запрос на конкретный адрес. Судя по всему, это инициатива самого пакета net-snmp. Не следует ожидать подобного поведения всякий раз, когда вы используете Walk тогда, когда следовало бы применить Get.
Q: getBulkRequest 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0, 1.3.6.1.2.1.1.3.0, 1.3.6.1.2.1.1.4.0 ....
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0
В случае с BulkWalk сложилась похожая ситуация. На запрос для getBulkRequest был возвращен связанный массив данных, но самый первый OID в нем отсутствует. Затем он запрашивается отдельно тем же способом, что в первом и втором случаях.
Теперь попробуем опросить всю ветку .1.3.6.1.2.1.1 (system), используя те же методы.
Q: get-request 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1 (noSuchObject)
Все как в первом случае, только нам сообщают, что конкретно по этому адресу ничего нет. То есть при помощи Get мы не можем получить результат, не зная точного OID.
Q: get-next-request 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1.1.0
Q: get-next-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0
Q: get-next-request 1.3.6.1.2.1.1.2.0
R: get-response 1.3.6.1.2.1.1.3.0
....
Q: get-next-request 1.3.6.1.2.1.1.9.1.4.71
R: get-response 1.3.6.1.2.1.2.1.0
Здесь Walk отрабатывает как задумано - при помощи get-next-request каждый раз запрашивается следующий OID, который возвращается в get-response вместе с содержимым. Рано или поздно адрес, возвращенный в get-response, выходит за пределы запрошенного. После этого опрос прекращается, а последнее полученное значение игнорируется, т.к. относится уже к другому разделу.
Q: getBulkRequest 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1.1.0 1.3.6.1.2.1.1.2.0 ... 1.3.6.1.2.1.1.9.1.2.2
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.2.2
R: get-response 1.3.6.1.2.1.1.9.1.2.3 1.3.6.1.2.1.1.9.1.2.4 ... 1.3.6.1.2.1.1.9.1.2.12
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.2.12
R: get-response 1.3.6.1.2.1.1.9.1.2.13 1.3.6.1.2.1.1.9.1.2.14 ... 1.3.6.1.2.1.1.9.1.2.22
...
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.4.70
R: get-response 1.3.6.1.2.1.1.9.1.4.71 1.3.6.1.2.1.2.1.0 ... 1.3.6.1.2.1.2.2.1.1.8
Здесь хорошо виден механизм работы BulkWalk. Выглядит так, будто бы мы спросили get-next-request, только получили не 1 результат, как в случае с Walk, а 10 в каждом get-response (в примере для каждой строчки показаны 2 первых и последний). В последнем ответе мы опять получаем данные, относящиеся к другому разделу OID. В этот раз из 10 штук в наш раздел попадает только первый OID, а остальные будут отброшены и не отображены при выводе результатов.
Теперь подведем итоги. При опросе sysDescr.0 нам требовалось получить одно конкретное значение для определенного OID. Лучшим вариантом для этого оказался метод Get, который выполнил ровно то, что задумано, за две сетевые транзакции (вопрос и ответ). Walk и BulkWalk в этом же случае свелись в итоге к все тому же Get, т.к. ни в том ни другом случае первый ответ не содержал нужной информации. При работе с пакетом net-snmp можно получить результат, используя эти методы, но это не лучший способ, т.к. он избыточен, требует больше времени и заставляет устройство проводить ненужную работу, а сеть - передавать лишние данные. Таким образом, для "прицельного" запроса по известному заранее адресу лучше всего подходит метод Get.
А вот при опросе system метод Get оказался бесполезен. Методами же Walk и BulkWalk результат был получен, но время опроса и количество транзакций сильно отличались. По адресу system в момент опроса находилось 221 значение. Для метода Walk потребовалось 444 сетевые транзакции (221*2+1 запрос +1 ответ, указывающие на окончание ветки раздела), а для BulkWalk - всего 46 ((221+9)/10*2), т.е. почти в 10 раз меньше. Поэтому метод BulkWalk, хоть и содержит большее количество избыточных данных, зато требует гораздо меньшего количества сетевых операций, что положительно сказывается на надежности и скорости работы. Если это возможно (позволяет оборудование и рабочая среда), лучше использовать BulkWalk.
Попробуем получить данные для конкретного OID .1.3.6.1.2.1.1.1.0 (sysDescr.0) тремя разными способами и посмотрим на отличия в работе пакета net-snmp. Запросы в примерах обозначены Q, а ответы R. Здесь мы, по большей части, рассмотрим порядок запросов и ответов, а не их содержание.
snmpget .1.3.6.1.2.1.1.1.0
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0
Здесь все просто. Мы запросили заранее известный адрес и получили ответ.
snmpwalk .1.3.6.1.2.1.1.1.0
Q: get-next-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0
Все несколько усложнилось. Метод Walk предполагает, что в качестве начального адреса указан раздел верхнего уровня, в котором требуется найти все нижележащие адреса. Поэтому он спрашивает адрес следующего OID, используя get-next-request. Однако в get-response приходит адрес уже другой ветки, что значит, что текущая исчерпана до конца. Собственно говоря, на этом работа Walk заканчивается (нас обманули, расходимся). Дальше уже идет обычный Get-запрос на конкретный адрес. Судя по всему, это инициатива самого пакета net-snmp. Не следует ожидать подобного поведения всякий раз, когда вы используете Walk тогда, когда следовало бы применить Get.
snmpbulkwalk .1.3.6.1.2.1.1.1.0
Q: getBulkRequest 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0, 1.3.6.1.2.1.1.3.0, 1.3.6.1.2.1.1.4.0 ....
Q: get-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.1.0
В случае с BulkWalk сложилась похожая ситуация. На запрос для getBulkRequest был возвращен связанный массив данных, но самый первый OID в нем отсутствует. Затем он запрашивается отдельно тем же способом, что в первом и втором случаях.
Теперь попробуем опросить всю ветку .1.3.6.1.2.1.1 (system), используя те же методы.
snmpget .1.3.6.1.2.1.1
Q: get-request 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1 (noSuchObject)
Все как в первом случае, только нам сообщают, что конкретно по этому адресу ничего нет. То есть при помощи Get мы не можем получить результат, не зная точного OID.
snmpwalk .1.3.6.1.2.1.1
Q: get-next-request 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1.1.0
Q: get-next-request 1.3.6.1.2.1.1.1.0
R: get-response 1.3.6.1.2.1.1.2.0
Q: get-next-request 1.3.6.1.2.1.1.2.0
R: get-response 1.3.6.1.2.1.1.3.0
....
Q: get-next-request 1.3.6.1.2.1.1.9.1.4.71
R: get-response 1.3.6.1.2.1.2.1.0
Здесь Walk отрабатывает как задумано - при помощи get-next-request каждый раз запрашивается следующий OID, который возвращается в get-response вместе с содержимым. Рано или поздно адрес, возвращенный в get-response, выходит за пределы запрошенного. После этого опрос прекращается, а последнее полученное значение игнорируется, т.к. относится уже к другому разделу.
snmpbulkwalk .1.3.6.1.2.1.1
Q: getBulkRequest 1.3.6.1.2.1.1
R: get-response 1.3.6.1.2.1.1.1.0 1.3.6.1.2.1.1.2.0 ... 1.3.6.1.2.1.1.9.1.2.2
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.2.2
R: get-response 1.3.6.1.2.1.1.9.1.2.3 1.3.6.1.2.1.1.9.1.2.4 ... 1.3.6.1.2.1.1.9.1.2.12
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.2.12
R: get-response 1.3.6.1.2.1.1.9.1.2.13 1.3.6.1.2.1.1.9.1.2.14 ... 1.3.6.1.2.1.1.9.1.2.22
...
Q: getBulkRequest 1.3.6.1.2.1.1.9.1.4.70
R: get-response 1.3.6.1.2.1.1.9.1.4.71 1.3.6.1.2.1.2.1.0 ... 1.3.6.1.2.1.2.2.1.1.8
Здесь хорошо виден механизм работы BulkWalk. Выглядит так, будто бы мы спросили get-next-request, только получили не 1 результат, как в случае с Walk, а 10 в каждом get-response (в примере для каждой строчки показаны 2 первых и последний). В последнем ответе мы опять получаем данные, относящиеся к другому разделу OID. В этот раз из 10 штук в наш раздел попадает только первый OID, а остальные будут отброшены и не отображены при выводе результатов.
Теперь подведем итоги. При опросе sysDescr.0 нам требовалось получить одно конкретное значение для определенного OID. Лучшим вариантом для этого оказался метод Get, который выполнил ровно то, что задумано, за две сетевые транзакции (вопрос и ответ). Walk и BulkWalk в этом же случае свелись в итоге к все тому же Get, т.к. ни в том ни другом случае первый ответ не содержал нужной информации. При работе с пакетом net-snmp можно получить результат, используя эти методы, но это не лучший способ, т.к. он избыточен, требует больше времени и заставляет устройство проводить ненужную работу, а сеть - передавать лишние данные. Таким образом, для "прицельного" запроса по известному заранее адресу лучше всего подходит метод Get.
А вот при опросе system метод Get оказался бесполезен. Методами же Walk и BulkWalk результат был получен, но время опроса и количество транзакций сильно отличались. По адресу system в момент опроса находилось 221 значение. Для метода Walk потребовалось 444 сетевые транзакции (221*2+1 запрос +1 ответ, указывающие на окончание ветки раздела), а для BulkWalk - всего 46 ((221+9)/10*2), т.е. почти в 10 раз меньше. Поэтому метод BulkWalk, хоть и содержит большее количество избыточных данных, зато требует гораздо меньшего количества сетевых операций, что положительно сказывается на надежности и скорости работы. Если это возможно (позволяет оборудование и рабочая среда), лучше использовать BulkWalk.
Комментариев нет:
Отправить комментарий