2.2.6 и Juniper

[axel]

@victor said in 2.2.6 и Juniper:

Сейчас перепроверял код - никаких подозрительных изменений не видно. С проблемой с TB драйвером это не должно быть связано. Покажите полный walk на 1.3.6.1.2.1.2.2.1.

Во вложении полный вывод.

---

snmpwalk.log

[victor]

И еще ветку .1.3.6.1.2.1.4.20.1.1.

Нет возможности на сервере на время configuration poll для juniper поставить уровень дебага 6 и прислать строки с текстом "NetworkDeviceDriver::getInterfaces"?

[axel]

@victor said in 2.2.6 и Juniper:

Нет возможности на сервере на время configuration poll для juniper поставить уровень дебага 6 и прислать строки с текстом "NetworkDeviceDriver::getInterfaces"?

Поиск по дебагу таких строк не находит.. Даже просто по NetworkDeviceDriver ничего не находится. Может что не так делаю? Нашел только эти логи во время Configuration Poll:

2018.07.17 14:07:09.321 *D* Node::createNewInterface("", 1, 1, bp=0, slot=0, port=0) called for node LAN1 [302091]
2018.07.17 14:07:09.321 *D* Node::createNewInterface(): IP address 192.168.151.7/0
2018.07.17 14:07:09.321 *D* Node::createNewInterface: node=LAN1 [302091] ip=192.168.151.7/0 cluster=(null) [0] add=yes
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending compressed message CMD_OBJECT_UPDATE (408 bytes)
2018.07.17 14:07:09.321 *D* [client.session.1   ] Sending update for object 192.168.151.0/24 [302082]
2018.07.17 14:07:09.321 *D* [client.session.0   ] Sending update for object LAN1 [302091]
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending update for object 192.168.151.0/24 [302082]
2018.07.17 14:07:09.321 *D* [client.session.1   ] Sending update for object LAN1 [302091]
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending update for object LAN1 [302091]
2018.07.17 14:07:09.321 *D* [client.session.1   ] Sending update for object 192.168.151.0/24 [302082]
2018.07.17 14:07:09.321 *D* [client.session.1   ] Sending compressed message CMD_OBJECT_UPDATE (304 bytes)
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending update for object 192.168.151.0/24 [302082]
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending compressed message CMD_OBJECT_UPDATE (304 bytes)
2018.07.17 14:07:09.321 *D* [client.session.0   ] Sending update for object LAN1 [302091]
2018.07.17 14:07:09.321 *D* [client.session.1   ] Sending update for object LAN1 [302091]
2018.07.17 14:07:09.321 *D* New thread started in thread pool MAIN
2018.07.17 14:07:09.321 *D* New thread started in thread pool MAIN
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending compressed message CMD_OBJECT_UPDATE (304 bytes)
2018.07.17 14:07:09.321 *D* Node::updateInterfaceConfiguration(LAN1 [302091]): pIfList == NULL, dwCount = 0
2018.07.17 14:07:09.321 *D* [client.session.2   ] Sending update for object LAN1 [302091]
2018.07.17 14:07:09.321 *D* [client.session.0   ] Sending update for object unknown [302109]
2018.07.17 14:07:09.321 *D* CorrelateEvent: event SYS_IF_ADDED id 1030962 source LAN1 [302091]
2018.07.17 14:07:09.321 *D* CorrelateEvent: finished, rootId=0
2018.07.17 14:07:09.321 *D* [client.session.0   ] Sending compressed message CMD_OBJECT_UPDATE (600 bytes)
2018.07.17 14:07:09.322 *D* [client.session.1   ] Sending update for object unknown [302109]
2018.07.17 14:07:09.322 *D* [client.session.2   ] Sending update for object unknown [302109]
2018.07.17 14:07:09.322 *D* Checking subnet bindings for node LAN1 [302091]
2018.07.17 14:07:09.322 *D* Node::checkSubnetBinding(LAN1 [302091]): checking address 192.168.151.7/24
2018.07.17 14:07:09.322 *D* Node::checkSubnetBinding(LAN1 [302091]): found subnet 192.168.151.0/24 [302082]
2018.07.17 14:07:09.322 *D* [client.session.2   ] Sending message CMD_POLLING_INFO (128 bytes)
2018.07.17 14:07:09.322 *D* [client.session.2   ] Sending message CMD_POLLING_INFO (88 bytes)
2018.07.17 14:07:09.322 *D* [event.proc         ] EVENT SYS_IF_ADDED [3] (ID:1030962 F:0x0001 S:0 TAG:"") FROM LAN1: Interface "unknown" added (IP Addr: 192.168.151.7/24, IfIndex: 1)
2018.07.17 14:07:09.322 *D* [client.session.2   ] Sending message CMD_POLLING_INFO (80 bytes)
2018.07.17 14:07:09.322 *D* [client.session.1   ] Sending compressed message CMD_OBJECT_UPDATE (304 bytes)
2018.07.17 14:07:09.322 *D* [client.session.2   ] Sending compressed message CMD_OBJECT_UPDATE (592 bytes)
2018.07.17 14:07:09.322 *D* Node::detectNodeType(LAN1 [302091]): SNMP node, driver name is JUNIPER
2018.07.17 14:07:09.322 *D* ConfPoll(LAN1): detected node type: 1 (Physical)
2018.07.17 14:07:09.322 *D* [client.session.2   ] Sending compressed message CMD_OBJECT_UPDATE (352 bytes)
2018.07.17 14:07:09.323 *D* [client.session.0   ] Sending compressed message CMD_OBJECT_UPDATE (352 bytes)
2018.07.17 14:07:09.323 *D* [client.session.2   ] Sending compressed message CMD_POLLING_INFO (112 bytes)
2018.07.17 14:07:09.323 *D* [client.session.2   ] Sending compressed message CMD_POLLING_INFO (112 bytes)
2018.07.17 14:07:09.323 *D* Finished configuration poll for node LAN1 (ID: 302091)

Также в этом дебаге вижу следующую строчку и не знаю, нормально это или же нет:

2018.07.17 14:07:04.992 *D* Node::getAgentConnection(NetXMS [98476]): cannot obtain lock on primary connection

@victor said in 2.2.6 и Juniper:

И еще ветку .1.3.6.1.2.1.4.20.1.1

.1.3.6.1.2.1.4.20.1.1.127.0.0.1 [IP ADDRESS]: 127.0.0.1
.1.3.6.1.2.1.4.20.1.1.128.0.0.1 [IP ADDRESS]: 128.0.0.1
.1.3.6.1.2.1.4.20.1.1.128.0.0.16 [IP ADDRESS]: 128.0.0.16
.1.3.6.1.2.1.4.20.1.1.128.0.0.32 [IP ADDRESS]: 128.0.0.32
.1.3.6.1.2.1.4.20.1.1.192.168.151.7 [IP ADDRESS]: 192.168.151.7

Это все, что вывелось.

[victor]

Я добавил в 2.2.7 дополнительный дебаг, посмотрим после обновления. Пока совершенно непонятно, что ему не нравится.

[axel]

Виктор, спасибо.
Вы тогда потом подскажите как включить дебаг для теста.
Ждем 2.2.7
Спасибо заранее.

[victor]

Только что выложили 2.2.7. Для отладки как и перед этим включите уровень 6 перед началом configuration poll.

[axel]

Во вложении новый файл. Но ощущение, что в нем информации не больше, чем в предыдущем.

---

netxms.txt

[victor]

На самом деле добавилось:

2018.07.18 17:33:47.719 *D* Node::getInterfaceList(node=LAN1 [302091]): cannot create SNMP transport

И это очень странно. Сервер напрямую общается с устройством или через прокси?

[axel]

Netmsd и Nxagentd стоят на одном сервере. На этом сервере поднят впн канал до сети где находятся устройства Juniper. Соотвеьственно vpn дает маршрут. То есть nxagentd напрямую через канал стучится на устройство. Самое интересное, как я уже писал выше, если делать nxsnmpwalk то все хорошо.

[victor]

Сейчас обратил внимание, что в примере с nxsnmpwalk указана версия 1, а сервер выбрал 2c. Если в nxsnmpwalk указать версию 2c, тоже работает?

[victor]

Да, и можно скриншот страничек Polling и Communications/SNMP из свойств ноды?

[axel]

Да, и с v2c тоже все работает замечательно в nxsnmpwalk.

---

[victor]

Так он же поставлен в "unmanaged" - поэтому собственно ничего и не опрашивается.

[axel]

@victor said in 2.2.6 и Juniper:

Так он же поставлен в "unmanaged" - поэтому собственно ничего и не опрашивается.

Ну как бы я при добавлении ноды всегда делаю ее Unmanged. Потом отключаю циклический сбор конфигурации, запускаю конфигурирование вручную и только потом ставлю Managed. Всегда это работало. Я попробую конечно сделать Managed и заново запросить конфигурацию.

[axel]

@victor said in 2.2.6 и Juniper:

Так он же поставлен в "unmanaged" - поэтому собственно ничего и не опрашивается.

Виктор огромное СПАСИБО! Действительно дело было в этом. Сейчас все в порядке! Радости моей нет предела

[victor]

Поведение системы действительно изменилось в версии 2.2.5 - до этого configuration poll на unmanaged нодах работал. Я проверил историю изменений - это было исправление для https://track.radensolutions.com/issue/NX-1420 - теперь сервер не пытается коммуницировать с нодами в состоянии unmanaged. Я думаю будет логично добавить в принудительный poll сообщение о невозможности опроса в таком состоянии чтобы исключить странное с точки зрения пользователя поведение системы.

[axel]

Во! Теперь понятно. А то я думал, что я уже запамятовал как я это делал раньше Спасибо за разъяснения!