Приветствую!
Есть оборудование на котором установлено 7 STM-1 карт, каждая карта по 63 потока и плюс 63 виртуальных потока, в итоге 126. Почему-то при опросе конфигурации, собирается информация по названиям интерфейсов и их состоянию, только с первой карты. Во всяком случае то, что видно в консоле. Остальные потоки по другим картам не выводятся. Есть ли какое-то ограничение где-то на кол-во выводимых значений в консоли? Вроде бы при проверке nxsnmpwalk он забирает весь конфиг. Но через консоль когда получаю конфигурацию, только конфиг первой в очереди карты, до остальных не доходит. SNMPRequestTimeout = 16000. ConfigurationPollingInterval = 3600.
Где взять лопату и куда копать?
Спасибо заранее.
Ограничений на количество интерфейсов нет. Надо смотреть по логам что происходит при configuration poll.
Подскажите, как включить полный дебаг на конкретную сессию?
Спасибо.
Как включить дебаг для конкретный ноды, так и не разобрался. При установке debug level 9, сыпит понятное дело много чего. По той ноде, которую я запрашивал выбрсило в дебаг message dump на 5 страниц зашифрованного текста типа:
** 00041585000000008000002800000000
** 000415860000000080000029000090A3
** 00041587000000008000002A00000000
Не знаю к этой ноде относится или нет. Но в NetXMS Mangment Console (для Windows, а также и для Mac), ничего не появилось. Ощущение что в базу не попадают данные почему-то. Что еще можно глянуть?
Спасибо.
На конкретную ноду дебаг включить нельзя. Для дебага configuration poll достаточно уровня 6. Потом можно найти записи вида "Starting configuration poll for node ..." и "Finished configuration poll for node..." - между ними среди прочего будет все про данную ноду. Ну и потом можно фильтровать дальше - больжая часть интересующих записей будет содержать текст ConfPoll(...):.
Как я писал выше, там находятся зашифрованные сообщения по типу:
** 00041585000000008000002800000000
** 000415860000000080000029000090A3
** 00041587000000008000002A00000000
Сообщений крайне много подобного рода. А что они означают, я понять не могу.
Похоже на дамп NXCP сообщений. Но они должны появляться только на уровне 8.
Я включал debug 9, поэтому они и появились. А более толковой информации по интерфейсам, которые считывает Poller, нет в дебаге.
Переехал на 2.0-M2. Суть такая:
При опросе через nxsnmpwalk - то вижу все интерфейсы, которые находятся на опрашиваемом оборудовании. Абсолютно все, с корректными именами. Когда же через Windows Management Console запрашиваю конфигурацию, то получаю следующую картину. NetXMS опросил первую карту, получил название интерфейсов. Начал опрашивать конфигурацию второй карты на оборудовании, но названия подставляет из названий первой карты. И так 7 раз подряд. В итоге NetXMS думает что это один и тот же интерфейс, убирает дубликаты и выводит только информацию по одной карте, что в целом является не верным. Могу предоставить в личку лог из nxsnmpwalk и лог из Windows Management Console.
Помогите решить проблему, пожалуйста!
Спасибо заранее.
Мы сегодня выкладываем 2.0-M3. Попробуйте, если проблема останется, то присылайте лог, буду разбираться.
Quote from: Victor Kirhenshtein on April 08, 2015, 01:08:44 PM
Мы сегодня выкладываем 2.0-M3. Попробуйте, если проблема останется, то присылайте лог, буду разбираться.
Подскажите пожалуйста, куда выслать логи? Не хотелось бы их выкладывать в открытую на форум.
Спасибо.
Куда выслать логи?
Спасибо, выслал.
Есть ли какие-то новости?
Спасибо.
Проблема в том, что это устройство использует нестандартную индексацию интерфейсов. По стандарту ветка .1.3.6.1.2.1.2.2.1.2 (ifTable) должна индексироваться через ifIndex, это один integer. В данном случае у нас два значения:
.1.3.6.1.2.1.2.2.1.2.6270.2 [STRING]: TB006270 eth1
здесь индех 6720.2. Сервер берет 2 как индекс интерфейса, но он потом повторяется с другим значением предпоследнего индекса. Поэтому и пересечения. Единственный вариант - сделать драйвер для таких устройств - правда все равно могут быть проблемы с опросом статусов интерфейсов - поскольку сервер будет подставлять индекс интерфейса в стандартные OID'ы - а устройство судя по всему ожидает вот этот двойной индекс.
А нельзя ли как-то убрать проверку двойного индекса?
Интереса ради только что добавил данный шлюз в Cacti. Так вот там нет таких проблем с построением индексов для мониторинга. Cacti выдал все интерфейсы, которые есть на оборудовании с названиями нормально.
Вопрос, можно ли решить данный вопрос как-то в NetXMS или это гиблое дело и я могу забыть об этом?
Спасибо заранее.
Cacti насколько я помню не интерпретирует полученные OID'ы, просто берет хвост после базового для индексации. В NetXMS instance discovery скажем тоже будет работать. Проблема именно в создании объектов интерфейсов - там сервер рассчитывает на стандартный MIB. Решить это можно только добавлением поддержки таких устройств в ядро (т.е. сделать помимо/вместо индекса некое новое свойство интерфейса - суффих в ifMIB, или сделать поддержку составных индексов). А что это за производитель и устройства? В их поддержку нельзя обратится на тему ошибки в реализации стандартного миба?
Оборудование называется Telcobrdige (http://www.telcobridges.com/). Я конечно попытаюсь им заявить о данной трудности, но боюсь это займет очень длительный срок в реализации. Поддержку имен интерфейсов в прошлый раз они делали для нас 1,5 с лишним года (( Т.е. для них это minor задача. И вопрос еще в том, как лучше им это объяснить.
А можно будет организовать мне read-only SNMP доступ на какое-то такое устройство?
В принципе попытаться можно. Нужен только IP-адрес Ваш для добавления в firewall. В личку?
Отправил адрес в личку. Смогу заняться в понедельник-вторник думаю.