Здравствуйте, господа.
У нас возникла проблема в совсместной работе snmptrapd
(
http://net-snmp.sourceforge .net/ ) и коммутаторов DES-3526. Проблема
заключается в том, что аутентификация SNMP v3 сбоит после некоторого
периода работы. При этом есть очень большие подозрения, что
некорректно работает именно DES-3526.
На машине с Linux(CentOS 5.1) установлен пакет
net-snmp-5.3.1-19.el5_1.1 из состава которого настроен и запущен
snmptrapd. Этот демон принимает SNMP Trap v2 и вызывает скрипт для их
обработки. Скрипт производит настройку свитча(VLAN,
traffic_segmentation). Несколько первых trap успешно аутентифицируются
и обрабатываются. В дальнейшем происходит сбой аутентификации, который
устраняется только перезагрузкой коммутатора: перезагрузка snmptrapd
не помогает.
Trap, посылаемый вручную, после того, как аутентификация с коммутатора
дала сбой, успешно аутентифицируется. При этом в trap, посылаемом
вручную, я специально указываю тот же EnginID, что и у коммутатора,
чтобы исключить вероятность того, что "глючит" snmptrapd. Есть
подозрение, что коммутатор некорректно вычисляет хеш, используемый
мехнизмом аутентификации.
Во вложении файлы:
switch.cfg - конфиг коммутатора.
tcpdump.dat - файл содержащий SNMP пакеты захваченные утилитой tcpdump.
snmptrap_by_hand - команда snmptrap с параметрами, с которыми
посылается trap вручную.
snmptrapd.log - trace snmptrapd.
В файле snmptrapd.log:
в строках, начинающихся с "usm:" видно состояние процесса аутентификации
в конце, где находится trace обработки trap, посылаемого вручную(с
текстом "this is a test") видно, что trap успешно аутентифицируется.
При настройке коммутатора пользователи snmp имели пароли:
ro_user -> password1
rw_user -> password2
Помогите, пожалуйста, с разрешением данной ситуации.
P.S. Копия топика и вложенные файлы посланы на следующие адреса:
idemin@dlink.ru
vkaragezov@dlink.ru
Вход
Регистрация
FAQ
Поиск
