Jump to content
Калькуляторы

Cisco SLA jitter - проблемы с SNMP GET -> No such instance

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

При настройке тестов 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

 

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

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

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

Спасибо

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this