Cisco SLA jitter - проблемы с SNMP

[Annlume]

Добрый день, уважаемые форумчане

При настройке тестов SLA (джиттер) на цисках 3845 и 7206 и попытке интегрировать их в систему мониторинга вышло следующее:

 

Опрашиваем циску запросами GET-NEXT по определенному оиду, получаем список инстанций, после чего выполняем запрос GET по определенной инстанции - возвращается ошибка No such instance.

 

Sep 30 14:45:33.409 msk: SNMP: Packet sent via UDP to x.x.x.x

Sep 30 14:45:33.433 msk: SNMP: Packet received via UDP from x.x.x.x on GigabitEthernet0/1

Sep 30 14:45:33.433 msk: SNMP: Get-next request, reqid 24082, errstat 0, erridx 0

rttMonJitterStatsBusies.32042.4229322358 = NULL TYPE/VALUE

Sep 30 14:45:33.437 msk: SNMP: Response, reqid 24082, errstat 0, erridx 0

rttMonJitterStatsBusies.32042.4229324700 = 0

Sep 30 14:45:33.441 msk: SNMP: Packet sent via UDP to x.x.x.x

 

 

 

Sep 30 14:45:37.937 msk: SNMP: Packet received via UDP from x.x.x.x on GigabitEthernet0/1

Sep 30 14:45:37.937 msk: SNMP: Get request, reqid 24084, errstat 0, erridx 0

rttMonJitterStatsBusies.32042.4229324700 = NULL TYPE/VALUE

Sep 30 14:45:37.941 msk: SNMP: Response, reqid 24084, errstat 0, erridx 0

rttMonJitterStatsBusies.32042.4229324700 = NO_SUCH_INSTANCE_EXCEPTION

Sep 30 14:45:37.945 msk: SNMP: Packet sent via UDP to x.x.x.x

 

В результате на циске тест отрабатывает корректно, а в системе мониторинга он уже висит в состоянии таймаута :(

Сначала грешили на иос - нет, закономерностей не отслеживается (проверяли несколько вариантов). Т.е., на другой железке такой же модели с таким же иосом, как на проблемной, все работает.

Может, кто-нибудь сталкивался?

Спасибо

[cae]

При настройке тестов SLA (джиттер) на цисках 3845 и 7206 и попытке интегрировать их в систему мониторинга вышло следующее:

Зачем Вам Busies? Что возвращают все rttMonJitterStatsEntry? Чем обусловлен выбор именно этих oids? Чем rttMonLatestJitterOperEntry не устраивает?

Включите в SNMP-съёме полный дебаг опять же.

[Annlume]

Выбор обусловлен особенностями ПО для мониторинга - там задан набор переменных, которые необходимо возвратить для получения корректного результата. к сожалению, если хоть одна переменная не придет от оборудования - весь тест считается проваленным и уходит в таймаут.

 

При попытке запроса любого объекта прямым запросом GET из ветки rttMonJitterStatsEntry выдается ошибка No Such Instance, GETNEXT - возвращает нормальный результат - группу инстанций объекта со значениями.

[cae]

Выбор обусловлен особенностями ПО для мониторинга - там задан набор переменных, которые необходимо возвратить для получения корректного результата. к сожалению, если хоть одна переменная не придет от оборудования - весь тест считается проваленным и уходит в таймаут.

 

Ну так берите производителя ПО за жабры, включайте дебаг, пускайте на удалённый доступ и пусть камлают. Вы же денег за это заплатили.

А если СПО - правьте ошибки, исходники под рукой... Нету спецов - возьмите со стороны.

Пока мне странно такое поведение софта. По хорошему, достаточно следующих oids для регулярной выборки: sysUpTime, rttMonCtrlAdminOwner, rttMonCtrlAdminTag, rttMonCtrlAdminRttType, rttMonLatestRttOperTime, rttMonLatestJitterOperEntry

Stats, упомянутый Вами, есть не во всех устройствах и не во всех ios, использовать его как-то странно...

Внутри LatestJitter достаточно использовать OperSense==ok, чтобы быть уверенным в валидности записи. Остальные состояния для сбора статистики не важны, их можно просто выводить из коллектора в лог. Ну и, разумеется, надо не делить на ноль ;-) Никакого rocket science.

Ах да, ну и на свитчах поднимать SAA не стоит, чревато последствиями... Для свитчей лучше взять параллельное, более бюджетное решение, благо они есть на рынке.

[Annlume]

Дело не в ошибках ПО. На большой группе устройств тесты отрабатывают корректно.

Также проверяли без ПО через стандартные запросы GET снмп. Проблема в том что по явно существующему ОИДУ и инстанции циска возвращает ответ No Such Instance. Т.е. некорректно обрабатывает SNMP запросы именно оборудование.

 

А писать разработчикам о том чтоб переделывали логику тестов из-за того что на некоторых устройствах глючит SNMP - думаю бессмысленно.

[cae]

Дело не в ошибках ПО. На большой группе устройств тесты отрабатывают корректно.

 

Если версии ios одинаковые - есть три пути:

1. открыть кейс в cisco.

2. пинать разработчиков, чтобы они обрабатывали такую ситуацию.

3. реализовать свой коллектор по GET-NEXT, который будет сохранять в промежуточном месте (db4, sqlite, Storable, etc), из которого потом коллектор ПО будет доставать нужные oids как бы по GET. Средний SNMP-based коллектор вполне умеет обращаться к стороннему скрипту. На самый крайний случай можно сделать скрипт для net-snmpd, если не умеет...

По опыту хождения всеми тремя путями, скажу: первый - для истинных джедаев, способных Силой пинать индусов циски, второй - кошернее, и помочь достичь нирваны способен, но третий быстрее всех. Программистов на питонах и перлах сейчас полно. Работы там где-то на неделю с тестами и перекурами.

[Annlume]

Спасибо, буду думать