NetXMS Support Forum

а какой expected state для интерфейсов на которых есть IP адреса?

Я немного поспешил с выводами, проблема еще чуть чуть дальше. Похоже корень проблемы - интерфейс коммутатора System, на котором как раз поднят IP коммутатора, в моем случае его expected state был IGNORE, таким образом его статус всегда оставался  Normal, независимо от результата ICMP проверки.

Проверьте пожалуйста мои выкладки.
Если они верны - мне кажется было бы полезно добавить ICMP проверку самой ноды, а не только её дочерних интерфейсов, тк это неочевидное поведение что если интерфейс имеющий IP перевести в expected state =IGNORE, то нода никогда не станет NDF_UNREACHABLE.

Для проверки я создал новую ноду с недоступным IP. Для автоматически созданного ей интерфейса unknown установил expected state =IGNORE, и нода вслед за интерфейсом unknown перешла в состояние NORMAL.



root@monitoring-is:/var/log# tail -f netxmsd | grep TTM6-f4
[05-Dec-2015 19:29:36.688] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:37.695] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:38.702] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:39.709] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:40.714] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:41.721] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:42.727] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:43.733] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:44.737] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:45.743] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:46.749] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:47.754] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:48.760] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:49.767] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:50.773] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:51.779] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:51.779] [DEBUG] DataCollectionTarget(ACC-TTM6-f4)->QueueItemsForPolling(): item 117 "Status" added to queue
[05-Dec-2015 19:29:52.785] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:53.791] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:54.796] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:55.802] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:56.808] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:57.816] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:58.820] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:29:59.827] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:00.832] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:01.839] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:02.847] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:03.853] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:04.162] [DEBUG] Node 2216 "ACC-TTM6-f4" queued for status poll
[05-Dec-2015 19:30:04.162] [DEBUG] Starting status poll for node ACC-TTM6-f4 (ID: 2216)
[05-Dec-2015 19:30:04.162] [DEBUG] StatusPoll(ACC-TTM6-f4): check SNMP
[05-Dec-2015 19:30:04.861] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:05.868] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:06.874] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:07.882] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:08.889] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:09.895] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:10.903] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:11.907] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:12.171] [DEBUG] StatusPoll(ACC-TTM6-f4): SNMP check finished
[05-Dec-2015 19:30:12.171] [DEBUG] StatusPoll(ACC-TTM6-f4): starting child object poll
[05-Dec-2015 19:30:12.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2683 [802.1Q Encapsulation Tag 0336]
[05-Dec-2015 19:30:12.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2668 [15]
[05-Dec-2015 19:30:12.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2685 [802.1Q Encapsulation Tag 0339]
[05-Dec-2015 19:30:12.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2686 [System]
[05-Dec-2015 19:30:12.916] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:13.922] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:14.930] [DEBUG] ItemPoller: calling DataCollectionTarget::queueItemsForPolling for object ACC-TTM6-f4 [2216]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2682 [802.1Q Encapsulation Tag 0001]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2676 [23]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2677 [24]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2658 [5]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2665 [12]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2679 [26 ("UPL to TTM5 agg")]
[05-Dec-2015 19:30:15.171] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2678 [25 (FREE)]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2655 [2]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2657 [4]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2656 [3]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2659 [6]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2660 [7]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2662 [9]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2661 [8]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2671 [18]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2673 [20]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2674 [21 (market)]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2675 [22]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2663 [10]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2667 [14]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2669 [16]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2672 [19]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2680 [27 (FREE)]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2681 [28 (FREE)]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2684 [802.1Q Encapsulation Tag 0338]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2664 [11]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2654 [1]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2666 [13]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): polling interface 2670 [17]
[05-Dec-2015 19:30:15.172] [DEBUG] StatusPoll(ACC-TTM6-f4): finished child object poll
[05-Dec-2015 19:30:15.173] [DEBUG] StatusPoll(ACC-TTM6-f4): bAllDown=false, dynFlags=0x00001011


Вот лог сервера относительно ноды для которой не генерируется SYS_NODE_DOWN.
Меня смутила надпись bAllDown=false, посмотрев код оказалось этот флаг описывает состояние дочерних объектов(интерфейсов), при этом нода переводится в состояние NDF_UNREACHABLE только если bAllDown = true, судя по всему этот флаг у меня не выставляется тк некоторые из интерфейсов коммутатора имеют expected state=ignore и в коде:
                     
                              for(i = 0, bAllDown = TRUE; i < m_dwChildCount; i++)
                                if ((m_pChildList[i]->getObjectClass() == OBJECT_INTERFACE) &&
                                         (m_pChildList[i]->Status() != STATUS_CRITICAL) &&
                                         (m_pChildList[i]->Status() != STATUS_UNKNOWN) &&
                                         (m_pChildList[i]->Status() != STATUS_UNMANAGED) &&
                                         (m_pChildList[i]->Status() != STATUS_DISABLED))
                                {       
                                        bAllDown = FALSE;
                                        break;
                                }

незасимо от их состояния  bAllDown устанавливается в FALSE.

Кроме того, насколько я понял, статус NDF_UNREACHABLE устанавливается только если bAllDown=true, а ICMP ответы к IP ноды вообще не проверяются.

if (bAllDown && (m_dwFlags & NF_IS_NATIVE_AGENT) &&
                    (!(m_dwFlags & NF_DISABLE_NXCP)))
                   if (!(m_dwDynamicFlags & NDF_AGENT_UNREACHABLE))
                      bAllDown = FALSE;
                if (bAllDown && (m_dwFlags & NF_IS_SNMP) &&
                    (!(m_dwFlags & NF_DISABLE_SNMP)))
                   if (!(m_dwDynamicFlags & NDF_SNMP_UNREACHABLE))
                      bAllDown = FALSE;

                DbgPrintf(6, _T("StatusPoll(%s): bAllDown=%s, dynFlags=0x%08X"), m_name, bAllDown ? _T("true") : _T("false"), m_dwDynamicFlags);
                if (bAllDown)
                {
                   if (!(m_dwDynamicFlags & NDF_UNREACHABLE))
                   {
                      m_dwDynamicFlags |= NDF_UNREACHABLE;


Верно ли что:
1) ICMP проверки выполняются только для определения статуса интерфейсов?, для объекта "нода" вцелом ICMP проверки доступности не происходит?
2) Если у ноды есть интерфесы в статусе IGNORE то проверка  (m_pChildList->Status() != STATUS_CRITICAL) && (m_pChildList->Status() != STATUS_UNKNOWN) && (m_pChildList->Status() != STATUS_UNMANAGED) && (m_pChildList->Status() != STATUS_DISABLED) всегда даст FALSE и тогда bAllDown никогда не будет true, соответственно by нода не перейдет в режим  NDF_UNREACHABLE

?

Отмечу что просто Configuration poll не приводит к смене статуса и генерации  SYS_NODE_DOWN, нужно делать именно Configuration poll ( full)

Сейчас возникла похожая ситуация - несколько коммутаторов доступа были отключены по питанию.  Для них сгенерировались ивенты SYS_SNMP_UNREACHABLE, статус у них=0, и SYS_NODE_DOWN ивент не генерируется, при этом коммутаторы не отвечают ни на SNMP, ни на ping уже продолжительное время(4ч).
Я допускаю что теоретически ивент SYS_NODE_DOWN  мог быть подавлен корреляцией, тк в это же время на коммутаторе аггрегации упали порты к этим коммутаторам доступа, однако в таком случае SYS_NODE_DOWN все равно должен появиться в EventLog(насколько я понял) - этого не произошло. После выполнения руками Configuration poll на одной из нод, ивент SYS_NODE_DOWN наконец сгенерировался и стаус ноды стал Critical.

Куда копать чтобы выяснить причину отсутствия SYS_NODE_DOWN?

В дереве объектов дублируюся сети. Сначала  сеть 10.0.2.0/24 отображалась два раза, началось это после добавления новой ноды - для неё создалась отдельная сеть, в старую она не попала.
Нужно сказать что старую я переименовал - дописал к object name название влана, соответственно я подумал что это всё и сломало и удалил обе сети. Через некоторое время появились новые 5 одинаковых сетей, ноды  распределились по ним случайным образом.

Как это исправить?

Опишите подробнее где что обрезается.

Проблема решилась установкой галочки Disable routing table polling в настройках ноды.

Net.Interface.BytesIn64() похоже не поддерживается для Linux ( как и написано в https://wiki.netxms.org/wiki/Agent_Parameters_Compatibility_Matrix)

Однако если ядро 64разрядное, то счетчики 64битные.

root@border0:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:15:17:ba:fd:c2 
          inet6 addr: fe80::215:17ff:feba:fdc2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:210009505322 errors:0 dropped:0 overruns:0 frame:0
          TX packets:339558039233 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:78015839084215 (70.9 TiB)  TX bytes:390754645687990 (355.3 TiB)
          Interrupt:16 Memory:fea80000-feaa0000

Неплохо бы поддерживать такие DCI на 64битных системах.

На этих роутерах в таблице маршрутизации 570k маршрутов, может ли это быть причиной?

На двух Linux маршрутизаторах, которые выступают BGP бордерами у netxms-agent стабильно течет память.
Через сутки после запуска процесс использует 3Gb ram.
Версия агента - 2.0-RC2-2.

На других 4х роутерах проблемы нет, хотя на них мониторятся теже DCI.
Подскажите в какую сторону копать?

У устройства 240 портов, потому думаю такой костыль работает весьма долго, что плохо.

Для коммутатора WS-C4006  netxms не собирает имен интерфейсов ( те что устанавливаются командой set port name 5/10 <description>). Проблема решается костылем в Hook::ConfigurationPoll:

if ($node->snmpOID == ".1.3.6.1.4.1.9.5.46") { // CAT-4006 hack
interfaces = GetNodeInterfaces($node);
transport = CreateSNMPTransport($node);
foreach(i : interfaces) {
base_if_oid = ".1.3.6.1.4.1.9.5.1.4.1.1.4";
// splitting by /
dd=rindex(i->name,"/");
slot=substr(i->name, 1, dd-1);
port= substr(i->name, dd+1);

oid=base_if_oid.".".slot.".".port;

trace(1,"hook: node ".$node->name." oid: ".oid);

ifdescr = SNMPGetValue(transport, oid);
if (ifdescr != null && ifdescr!="") {
RenameObject(i, i->name." (".ifdescr.")");
}
}
}

Быть может возможно сделать для такого девайса особый драйвер чтобы это работало из коробки.

Тоже интересен этот вопрос для этих же моделей, стоит пробовать запускать, заработает?

аналогично для псевдоинтерфейсов IFB