NetXMS Support Forum

Расскажите, каков алгоритм распределения нод по подсетям в дереве объектов? У меня наблюдается странная аномалия - хост с интерфейсами из сетей 192.168.199.0/24 и 10.10.12.0/24 попал в подсеть 1.1.1.0/24. Версия сервера - 1.2.2, консоли - 1.2.4 и 1.2.2 тоже.

Присоединяюсь к вопросу, хотелось бы понять как работает распределение и обнаружение сетей и возможно ли дерево объектов править вручную? На текущий момент некоторые ноды не попадают в свои сети, а одну сеть NetXMS вообще не находит, при этом в этой сети агенты есть.

Распределение по подсетям делается на основе интерфейсов. Т.е. для каждого интерфейса из его IP адреса и маски получаем адрес подсети, и добавляем ноды в соответствуюший обьект подсети. При необходимости создаются новые обьекты. Потенциально возможны проблемы если адрес, который прописан как primary host name отсутствует на интерфейсах по какой-либо причине. В 1.2.3 и 1.2.4 также были исправлены несколько багов, связанных с нодами, которые появлялись прямо в корне, и дублирующимися нодами. Если 1.2.4 помесчает хосты не в те подсети, то надо детально разбиратся - мне надо знать список интерфейсов проблемной ноды и значения с закладки "Overview".

Quote from: Victor Kirhenshtein on November 22, 2012, 11:27:51 PM
Распределение по подсетям делается на основе интерфейсов. Т.е. для каждого интерфейса из его IP адреса и маски получаем адрес подсети, и добавляем ноды в соответствуюший обьект подсети. При необходимости создаются новые обьекты. Потенциально возможны проблемы если адрес, который прописан как primary host name отсутствует на интерфейсах по какой-либо причине. В 1.2.3 и 1.2.4 также были исправлены несколько багов, связанных с нодами, которые появлялись прямо в корне, и дублирующимися нодами. Если 1.2.4 помесчает хосты не в те подсети, то надо детально разбиратся - мне надо знать список интерфейсов проблемной ноды и значения с закладки "Overview".

а если помещаются в корень или дублируюстся в одной сети при каждом проходе network discovery?

Quote from: SKYnv on November 23, 2012, 07:01:00 AM
а если помещаются в корень или дублируюстся в одной сети при каждом проходе network discovery?

мне желательно знать то-же самое - список интерфейсов и значения с Overview для проблемных нод.

Вот проблемная нода. Так же стоит заметить что при проверке базы (nxdbmgr check) появлятся вот такие предложения с запросом на исправление:

Unlinked node object 23964 ("xrx0000aae4250c.root.local") can be linked to subnet 22097 (127.0.0.0). Link?
Unlinked node object 23964 ("xrx0000aae4250c.root.local") can be linked to subnet 22097 (192.168.254.0). Link?

но даже при положительном ответе нода не меняет место расположение, и при повторной проверке, через некоторое время (видимо период опроса Discovery), такой запрос снова повторяется.

Есть также предположение, что такое состояние лочит таблицу mysql, так как заметно возрастает значение iowait, но пока с уверенностью сказать не могу, надо проверить.

Очень интересная ситуация - судя по скриншотам, на loopback интерфейсе устройство сообщает внешний IP адрес, а на собственно ethernet интерфейсе - 127.0.0.1. Поскольку NetXMS сервер loopback интерфейсы (с типом 24) игнорирует, получается странная ситуация. Вопрос в причине перепутанных адресов - это либо баг в NetXMS сервере, либо в SNMP агенте на устройстве. Попробуйте получить список интерфейсов и IP адресов через snmp walk:

nxsnmpwalk -c community device_address .1.3.6.1.2.1.2.2.1.2
nxsnmpwalk -c community device_address .1.3.6.1.2.1.2.2.1.3
nxsnmpwalk -c community device_address .1.3.6.1.2.1.4.20.1

nxsnmpwalk -c community device_address .1.3.6.1.2.1.2.2.1.2

.1.3.6.1.2.1.2.2.1.2.1 [STRING]: Xerox Embedded Ethernet Controller, 10/100/1000 Mbps, v1.0, RJ45, 1000 Mbps full duplex
.1.3.6.1.2.1.2.2.1.2.2 [STRING]: Xerox internal TCP Software Loopback Interface, v2.0

nxsnmpwalk -c community device_address .1.3.6.1.2.1.2.2.1.3

.1.3.6.1.2.1.2.2.1.3.1 [INTEGER]: 6
.1.3.6.1.2.1.2.2.1.3.2 [INTEGER]: 24

nxsnmpwalk -c community device_address .1.3.6.1.2.1.4.20.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.192.168.254.165 [IP ADDRESS]: 192.168.254.165
.1.3.6.1.2.1.4.20.1.2.127.0.0.1 [INTEGER]: 1
.1.3.6.1.2.1.4.20.1.2.192.168.254.165 [INTEGER]: 2
.1.3.6.1.2.1.4.20.1.3.127.0.0.1 [IP ADDRESS]: 255.0.0.0
.1.3.6.1.2.1.4.20.1.3.192.168.254.165 [IP ADDRESS]: 255.255.254.0
.1.3.6.1.2.1.4.20.1.4.127.0.0.1 [INTEGER]: 0
.1.3.6.1.2.1.4.20.1.4.192.168.254.165 [INTEGER]: 1
.1.3.6.1.2.1.4.20.1.5.127.0.0.1 [INTEGER]: -1
.1.3.6.1.2.1.4.20.1.5.192.168.254.165 [INTEGER]: -1

Судя по результатам SNMP walk, устройство таки неправильно сообсчает IP адреса. Я добавлю обработку такой ситуации в NetXMS сервер.

Спасибо.

Не подскажите, как решить ещё одну проблему, у нас есть сеть за vpn подключением, но netxms server её не видит (не определяет при Discovery), пробовал поставить там агента, но всё равно результата нет.

Если у vpn'а нет своих интерфейсов с IP адресами (IPSEC например), то NetXMS сервер не может автоматически найти хосты на другой стороне. Надо добавить вручную хотя-бы один хост с агентом или SNMP на другой стороне туннеля, тогда discovery должен пойти дальше.

Извиняюсь за возможно глупый вопрос, как в новой консоли добавить вручную ноду? Я долго искал как это сделать, но так и не понял алгоритма.

Ноды надо добавлять в контейнер. Правый клик на контейнере - потом "Create node".

Спасибо

Quote from: Victor Kirhenshtein on December 04, 2012, 09:44:14 PM
Ноды надо добавлять в контейнер. Правый клик на контейнере - потом "Create node".

А как создать контейнер? Если я пытаюсь создать зону в разделе "Entire network", то получаю ошибку "Incompatible operation".
Да - у меня включен режим autodiscovery, если это важно.