NetXMS Support Forum

yes, we plan to release shortly. for now I've uploaded new build to the TestFlight, so it's not expired anymore.

Hi,

Most likely the virtual interfaces are actually present as objects, and what's missing is only the DCIs for them - these are two separate mechanisms. Here's what's actually happening:

NetXMS builds the interface list from the standard ifTable and creates interface objects for everything the device reports - VLAN, PPPoE, bridges and tunnels included, there is no filtering by type at that stage. So after a configuration poll they all should be visible in the Interfaces view under the node - I do believe they are there on your system? If some are genuinely missing even after configuration poll, that would mean RouterOS is not exposing them over SNMP, but that would be unusual.

What filters them out is the Interface Traffic template itself. Its DCIs are created by instance discovery, and the filter script in the prototype DCIs only accepts interfaces with ifType 6, 7 or 22 (ethernet-like types). VLAN (ifType 135), PPP/PPPoE (23), tunnels (131), bridges (209) are all rejected by that check. The filter also skips loopbacks, interfaces whose expected state is not UP, and interfaces with speed at or below 20 Mbit/s.

You can see it happening: run Poll -> Instance discovery on the node and look at the poller output - there will be a "skipped - interface type" line for every virtual interface.

To include them, open the template under Templates -> Interface traffic, edit the instance discovery filter script in the prototype DCIs and extend the interfaceTypes array at the top with the types your virtual interfaces report:

interfaceTypes = [6, 7, 22, 23, 131, 135, 209];
Actual ifType of every interface is shown on the interface object's Overview tab, so check there which values you need. Note: with default server configuration (Server.ImportConfigurationOnStartup = 1) your edits to this template survive server upgrades - stock templates are not overwritten on import.

For CPU / temperature / voltage on MikroTik you don't need to hunt for OIDs manually:

• Health metrics - create DCI with origin "Network device driver". For MikroTik nodes the driver reads the RouterOS health gauge table and offers every gauge the particular model exposes (cpu-temperature, board-temperature, voltage, fan speeds, etc.) by name in the metric selection dialog. Values come exactly as the device reports them, so check the scale and add a transformation script if needed.
• CPU load - standard SNMP DCI on 1.3.6.1.2.1.25.3.3.1.2 (hrProcessorLoad from HOST-RESOURCES MIB, one row per core).

Put these DCIs into your own template and let it apply automatically to all RouterOS devices with auto-apply filter script:

return $node.driver == "MIKROTIK";
- same idea as the custom attribute you already use for interface traffic, just keyed on the driver instead.

Да, подход верный. Ваши icmp unreachable / icmp ok — кастомные события, а для кастомных событий корреляция существует ровно в одном случае: когда нода-источник в режиме обслуживания (там коррелируются вообще все её события). К падению ноды, прокси или коммутатора сервер их никогда не привязывает — это делается только для фиксированного списка системных событий (SYS_ICMP_UNREACHABLE, SYS_INTERFACE_DOWN и т.д.).

Поэтому пара 25/26 — тот же случай, что 31/32, и логика распределяется так же:

• Правило 25 без флага: в нормальной работе события некоррелированные, правило срабатывает всегда. В maintenance они становятся коррелированными, и правило само их пропустит — скрипт с проверкой не нужен.
• Правило 26 с флагом: нужен ровно для сценария «интернет упал (аларм создан, таймеры 8h/1d/3d заведены) → ноду перевели в обслуживание → интернет восстановился». Без флага icmp ok будет пропущено, аларм останется висеть, и через 8 часов придёт письмо о недоступности уже работающего интернета.

Одно замечание на будущее: системное SYS_ICMP_UNREACHABLE при падении ноды коррелируется к её SYS_NODE_DOWN, а ваш кастомный icmp unreachable — нет. Если нода, на которой висит этот DCI, упадёт целиком, придут оба уведомления — и о ноде, и об интернете. Для порогов с кастомными событиями корреляция такие следствия не гасит.

По шторм-детектору: вы его не пропустили — он не сработал, потому что выключен по умолчанию (EventStorm.EnableDetection = 0). Готового правила в EPP под него тоже нет — из коробки есть только шаблон события SYS_EVENT_STORM_DETECTED.

Как это работает, если включить: сервер раз в секунду сравнивает поток событий с порогом EventStorm.EventsPerSecond (по умолчанию 1000 в секунду). Если поток держится выше порога дольше EventStorm.Duration (15 секунд), генерируется SYS_EVENT_STORM_DETECTED, и дальше сервер просто отбрасывает все входящие события, пока поток не упадёт ниже порога — тогда SYS_EVENT_STORM_ENDED и нормальная работа. То есть это не мониторинг, а предохранитель: вашу петлю он бы разорвал, но на время шторма мониторинг слепнет — отбрасываются все события, не только «лишние».

Что сделать:

• Сначала померьте нормальный поток: DCI на объекте сервера с internal-параметром Server.TotalEventsProcessed и обработкой «average delta per second» покажет события в секунду. Порог ставьте с запасом выше нормальных пиков — дефолтные 1000/с для вашей инсталляции почти наверняка слишком высоко, ваша петля могла до них и не дотягивать.
• EventStorm.EnableDetection = 1, порог и длительность — по результатам замера. Все три параметра требуют рестарта сервера.
• Правило в EPP на SYS_EVENT_STORM_DETECTED с алармом или нотификацией — иначе детектор молча отбросит события, и вы узнаете постфактум.

На тот же DCI стоит повесить и обычный threshold — он даст раннее предупреждение на уровне сильно ниже шторма и ничего при этом не отбрасывает.

По галочкам Replace: нет, здесь они бы ничего не изменили. Replace управляет только конфликтами: если объект с таким GUID/именем на сервере уже есть, с галочкой он перезаписывается версией из файла, без — остаётся как был, версия из файла пропускается. Объектов, которых на сервере нет, это не касается — они создаются всегда, независимо от галочек. Ваше событие потерялось не из-за этого — его не было на сервере в момент импорта правил, это и есть тот тикет про импорт.

Но одно следствие проверьте: на свежей инсталляции стандартные события, правила EPP и темплейты уже существуют. Если на старом сервере вы меняли что-то стандартное — severity системных событий, дефолтные правила, — то при импорте без Replace эти изменения молча не применились, остались свежие дефолтные версии.

Да, всё верно — по всем четырём флаг и скрипт стоят правильно:

• 31 (прокси down) — флаг выключен, скрипта нет
• 32 (прокси up) — флаг включён, скрипта нет
• 33 (нода за прокси down) — флаг включён + скрипт maintenance
• 34 (нода за прокси up) — флаг включён, скрипта нет

Ключи таймеров и алармов между парами согласованы (NODE_BY_TUNNEL_DOWN_* в 31/32, NODE_BEHIND_THE_PROXY_DOWN_* в 33/34), а Terminate alarms и Cancel timers в up-правилах перекрывают все ключи из down-правил. Работать будет как задумано.

Одна мелочь, ни на что не влияет: в фильтре правила 31 рядом с SYS_NODE_DOWN стоит SYS_NODE_UNREACHABLE. Для ноды, подключённой напрямую по тоннелю, недоступность — это SYS_NODE_DOWN; SYS_NODE_UNREACHABLE у неё не возникает, а если бы возникло — оно коррелированное и при выключенном флаге всё равно было бы пропущено. Можно оставить как есть.

Не на всех — иначе сломается сценарий с maintenance, который чинили выше. По правилам:

• 33 (нода за прокси, down) — флаг ON + скрипт maintenance
• 31 (прокси, down) — ни флага, ни скрипта
• 32 / 34 (up) — флаг ON, скрипт не добавлять

Почему по-разному:

Down. У ноды за прокси событие SYS_NODE_UNREACHABLE коррелированное — без флага правило 33 не сработает вообще. Раз флаг включён, правило начнёт срабатывать и во время обслуживания, поэтому там нужен return !$object->isInMaintenanceMode;. У прокси собственное SYS_NODE_DOWN некоррелированное, обрабатывается и без флага; а в режиме обслуживания его события становятся коррелированными, и правило само их пропустит — ни скрипт, ни флаг там не нужны.

Up. SYS_NODE_UP коррелируется только когда нода в maintenance — и это ровно тот случай, ради которого флаг включается: нода поднялась в обслуживании, правило должно пропустить событие, закрыть аларм и снять отложенные действия. Если добавить туда проверку maintenance, правило пропустит это событие мимо, аларм не закроется, и через 8 часов придёт письмо о работающей ноде — вернётся исходный баг.

Можно обойтись одной парой. Ключи таймеров и алармов у вас содержат %n_%i, то есть уникальны для каждой ноды — при объединении правил конфликта не будет.

Флаг "Accept correlated events" не переключает правило в другой режим, он только дополнительно разрешает коррелированные события. Некоррелированные обрабатываются в любом случае. Собственное SYS_NODE_DOWN прокси-ноды некоррелированное, SYS_NODE_UNREACHABLE ноды за прокси — коррелированное, поэтому одно правило с включённым флагом покрывает оба случая.

Чтобы слить 31/33 в одно правило: в фильтре указать обе группы (Node by tunnel epp и Node behind the proxy epp) или вообще убрать фильтр по объектам, включить "Accept correlated events", оставить скрипт с проверкой maintenance. То же самое с 32/34.

Две пары имеет смысл держать в двух случаях:

- нужны разные задержки — сейчас у вас 5 минут для прокси и 10 для подчинённых нод; в одном правиле останется одна;
- нужно ограничить действие флага узким списком нод. SYS_NODE_UNREACHABLE коррелируется не только при падении прокси, но и при падении маршрутизатора или коммутатора на пути. Правило с флагом, охватывающее все ноды, при падении коммутатора сработает на каждой ноде за ним — вместо одного письма о коммутаторе придёт письмо на каждую недоступную ноду. Пока в группах только ноды за прокси, этого не случится, но при расширении фильтра на всё дерево — случится.

Отдельно про правила 32/34 (Node up). SYS_NODE_UP не коррелируется никогда, кроме одного случая: все события от объекта в maintenance mode считаются коррелированными. Отсюда сценарий: нода упала (таймеры созданы), после этого её перевели в обслуживание, она поднялась — правило Node up событие пропустит, аларм не закроется и отложенные действия не отменятся, и через 8 часов придёт письмо о недоступности уже работающей ноды. Так что на правилах Node up флаг "Accept correlated events" лучше тоже включить — во всех остальных ситуациях он там ни на что не влияет.

Ошибки при создании правила не было. Список событий у правила сейчас пустой, а пустой список в EPP означает "любое событие" — на скриншоте в разделе Events так и написано, "Any event". После импорта правило 96 создаёт аларм на каждое событие от всех объектов из своего списка source.

Отсюда же и скачки статуса, про которые вы писали в первом сообщении. Это не отдельная проблема, а следствие той же поломки — цикл замыкается сам на себя:

• Любое событие от ноды из списка попадает в правило 96, создаётся аларм severity MINOR.
• Статус объекта считается как максимум из расчётного статуса и severity самого критичного активного аларма, поэтому нода уходит NORMAL → MINOR.
• Смена статуса генерирует SYS_NODE_MINOR.
• Это событие снова попадает в правило 96 — оно же ловит любое событие.
• Парное правило "Terminate telegram alarm when CPU usage is normal" потеряло своё событие точно так же и тоже ловит любое. Оно закрывает аларм, статус падает обратно в NORMAL, генерируется SYS_NODE_NORMAL.
• Дальше по кругу, со скоростью обработки событий.

В логе это видно напрямую: у события SYS_NODE_MINOR стоит lastAlarmKey "High_cpu_usage_ТРК сервер офис_0x0000010C", то есть событие смены статуса обработано именно правилом про CPU.

Семь миллионов ID сожгла именно пара create + terminate. Если бы аларм только создавался, при одинаковом alarm key сервер увеличивал бы repeat count у существующего аларма и новый ID не выделял. Но парное правило каждый раз закрывает аларм, поэтому следующее событие заводит новый.

Что сделать:

• Проверьте все правила, а не только эти два. Импорт молча выбрасывает ссылки на события, которых нет на целевом сервере, и правило остаётся включённым с урезанным списком. Если выпали все события — правило становится catch-all. Пройдитесь по списку правил и посмотрите, где список событий пуст.
• В первую очередь те, что создают алармы или шлют нотификации. У них такая поломка даёт не лишние срабатывания, а вот такой шторм.
• При переносе на новую инсталляцию custom-события и правила должны быть в одном экспорт-файле. Внутри файла порядок правильный, события импортируются раньше правил. Ломается, когда правила и события уезжают разными файлами и правила импортируются первыми — на момент импорта правил событий ещё нет.

База сама не почистится. Рост прекратится, как только уберёте catch-all правила, а накопленные алармы и event log будет разгребать housekeeper по настройкам retention — на семи миллионах записей это не быстро.

На сам импорт завёл тикет — молча терять ссылки на события и оставлять правило включённым он не должен: https://github.com/netxms/netxms/issues/3443

The walks confirm it, and both chassis behave identically. xA hears its own chassis ID (AC:5E:14:7F:89:01) on local ports 1 and 123; xB hears its own (AC:5E:14:7F:74:01) on local ports 1 and 51. In each case one entry points at 10GE2/0/1 and the other at MEth0/0/0, so the two ports see each other. Everything else in both walks is clean - all six Eth-Trunk0 members, the 10GE4/0/47 keepalive and the downstream CE8865 / CE6857E / H3C links resolve correctly in both directions.

You are right that there is no cable between those two ports, and there doesn't need to be. LLDP only requires them to be in the same broadcast domain. Here's what's actually happening:

LLDP frames are sent to 01-80-C2-00-00-0E, which is nearest-bridge scope - a standards-compliant bridge consumes them and never forwards them. So whatever sits between MEth0/0/0 and 10GE2/0/1 either ignores that rule (unmanaged switch, media converter, patch through a passive device) or is explicitly configured to tunnel LLDP. Both ports having exactly one neighbour each - each other - rules out a managed LLDP-speaking switch in between, because then both would show that switch instead.

To pin down which one:

display lldp neighbor interface MEth0/0/0
display lldp neighbor interface 10GE2/0/1
display l2protocol-tunnel group-mac all          # LLDP tunneling configured?
reset lldp statistics interface 10GE2/0/1        # then re-check counters
display lldp statistics interface 10GE2/0/1      # frames still arriving = live path, not stale table

Also check the running config for l2protocol-tunnel lldp enable or link-protocol transport lldp anywhere on the management path.

Note: the description configured on 10GE2/0/1 reads TO_XM-GL-HX-xA_MEth0/0/0 on xA and TO_XM-GL-HX-xB_MEth0/0/0 on xB, which suggests this path was built deliberately. Descriptions go stale, so treat it as a hint rather than proof - but both chassis being labelled and behaving the same way makes an accident unlikely. Worth asking whoever cabled the management network.

If the path is intentional, the LLDP data is correct and the link can be ignored; disabling LLDP on MEth0/0/0 suppresses it.

Separately, NetXMS should not display a node as its own peer no matter what the device reports. STP discovery already filters this case, LLDP does not - that's a bug on our side, filed as https://github.com/netxms/netxms/issues/3439

Коррелированное событие — это событие, для которого сервер уже определил причину и привязал его к корневому событию. Так происходит в нескольких случаях: недоступность узла за прокси/маршрутизатором/коммутатором привязывается к событию падения этого прокси или коммутатора; interface down, SNMP fail, service down на узле, который сам недоступен, привязываются к его же SYS_NODE_DOWN; все события от объекта в режиме обслуживания привязываются к событию входа в maintenance.

По умолчанию правила EPP такие события пропускают, и это осознанное поведение: уведомлять нужно о причине, а не о каждом следствии. Упал коммутатор — приходит одно уведомление о коммутаторе, а не сотня о каждом узле за ним.

Поэтому всегда включать этот флаг не нужно. Включайте его только в правилах, которые должны отработать на каждом событии независимо от того, есть ли у него известная причина: учёт простоя (стандартные правила Start/End downtime), создание аварий и блокирующих таймеров по каждому узлу — ваш случай с правилом 33. В обычных уведомляющих правилах флаг лучше оставить выключенным, иначе вернётся шквал уведомлений о следствиях.

Один нюанс: события от узлов в режиме обслуживания тоже считаются коррелированными, поэтому правило с включённым флагом будет срабатывать и во время maintenance. Если это нежелательно, добавьте в фильтрующий скрипт правила проверку [tt]return !$object->isInMaintenanceMode;[/tt] (это атрибут, без скобок).

Начиная с 5.2 статусный опрос сам запускает пересинхронизацию интерфейсов, если считает, что устройство перезагрузилось (коммит 4943ddf210, NX-2728). Перезагрузка определяется сравнением вычисленного времени старта системы (текущее время минус sysUpTime), а это значение из-за округления и сетевых задержек гуляет на 1–2 секунды между опросами. Любой сдвиг вперёд трактуется как рестарт — и выполняется полная синхронизация интерфейсов, которая не проверяет галочку запрета опроса конфигурации. Поэтому VLAN'ы возвращаются даже с установленной галочкой, обычно в течение нескольких минут: статусный опрос по умолчанию идёт раз в 60 секунд, отсюда и впечатление, что это происходит при раскрытии ноды.

По ISW002 (VLAN 3385–3418) по коду вижу два возможных пути: либо для этих интерфейсов не удалось запустить хук-скрипт (в этом случае интерфейс сейчас создаётся без проверки), либо они не создавались заново, а обновились по ifIndex — обновление существующего объекта хук не вызывает. Чтобы понять, какой вариант у вас, включите в netxmsd.conf отладку:

DebugTags = poll.status:5,node.iface:7
и после следующего появления VLAN'ов пришлите фрагмент лога по этой ноде — интересуют строки "system restart detected" и "accepted/rejected by filter".

Хук пока оставьте.

Проблема в коррелированных событиях. Когда узел за прокси становится недоступен, сервер связывает его SYS_NODE_UNREACHABLE с корневым событием прокси. Правила EPP по умолчанию пропускают коррелированные события — правило обрабатывает их только если в его свойствах включена опция "Accept correlated events". У стандартных правил (например, 85 "Start downtime") она включена — поэтому в фильтре видно "including correlated events". У ваших правил 31/33/34 её нет.

Отсюда всё поведение из вашего лога: событие недоступности "ТРК сервер KMS" не совпало ни с одним из ваших правил (только со стандартными 2/58/86), поэтому не создались ни аварии, ни блокирующие таймеры. А SYS_NODE_UP при восстановлении не коррелируется никогда — правило 34 срабатывает и сразу шлёт "Node up", блокировать его нечем. У прокси всё работает, потому что его собственное событие недоступности не коррелированное.

Что сделать: откройте свойства правила 33 и включите "Accept correlated events". После этого при коротком обрыве прокси таймер будет создаваться и уведомление "Node up" от подчинённых узлов будет блокироваться — так же, как сейчас у прокси.

Один нюанс: при длительном обрыве прокси подчинённые узлы теперь тоже пришлют отложенные уведомления о недоступности (Critical MailAlarm через 10 минут и далее). Если они не нужны — учтите, что просто выключить эти действия нельзя: неактивное действие не создаёт таймер, и блокировка перестанет работать. В этом случае вместо уведомления назначьте отложенным действием с тем же ключом таймера какое-нибудь пустое действие.

Изменённые правила 27/28 по "Интернет резерв" теперь на основную схему не влияют.

Hi Tucson,

The agent is not actually unreachable — it accepts the connection, and the version mismatch is not the problem either. Your log shows what is going on:

- Each new connection completes the initial handshake (CMD_GET_NXCP_CAPS / CMD_NXCP_CAPS) — these control messages are processed directly by the session's network thread.
- The first real request, CMD_SET_SERVER_CAPABILITIES, is received but never answered. It is handed off to the agent's communication thread pool for processing, and that task never runs. The server waits 30 seconds for the response, reports "Request timeout", and closes the connection — you can see "Communication channel closed by peer" exactly 30 seconds after each connect.
- The "Session disconnected by watchdog" lines are not the cause: those are older sessions from previous failed attempts being cleaned up after the 120-second idle timeout (the timestamp deltas in those lines are all ~120 s).

This means all worker threads of the communication thread pool are stuck in requests that never complete. Typical causes are an ExternalParameter / ExternalMetric script that hangs, or a FileSystem.* metric blocking on a dead network mount (stale NFS/CIFS). Once all workers are blocked, the agent still accepts connections but cannot process any command — which matches your "works after restart, dies a few minutes later" pattern: after restart the pool is fresh, and it dies once the server's polls have handed it enough hanging requests. There is also an agent-side bug that prevents the pool from recovering in this situation — I have filed it as https://github.com/netxms/netxms/issues/3436.

To find what is blocking the threads on your side, please run on the agent host:

1. gdb -p $(pgrep nxagentd) --batch -ex 'thread apply all bt' > nxagentd-threads.txt and attach the output (install gdb if needed; eu-stack -p <pid> works too). The stacks of the threads named $COMM/WRK will show exactly where they are stuck.
2. nxget 127.0.0.1 Agent.Uptime — if this hangs, it confirms the thread pool is stuck.
3. df — if it hangs, you have a stale network mount, which is the common cause.

Also check whether your agent config has ExternalParameter / ExternalMetric entries, and whether those scripts can block (waiting on network, locks, prompts). Restarting the agent is a temporary workaround, but it will wedge again until the underlying hang is fixed.

Спасибо за скриншоты, картина стала понятнее. По порядку:

1. Правила на SYS_AGENT_UNREACHABLE / SYS_AGENT_OK для узлов за прокси не будут работать в принципе.

Когда узел недоступен из-за прокси, сервер намеренно не генерирует SYS_AGENT_UNREACHABLE — причина недоступности уже известна, генерируется только SYS_NODE_UNREACHABLE. Но при восстановлении SYS_AGENT_OK генерируется. То есть таймер, который должен блокировать уведомление "появился в сети", никогда не создаётся. Старые телеграм-правила по SYS_AGENT_UNREACHABLE / SYS_AGENT_OK нужно отключить или убрать из них узлы за прокси — иначе они будут слать уведомления на каждый обрыв независимо от новых правил. Эту асимметрию (SYS_AGENT_OK без парного SYS_AGENT_UNREACHABLE) посмотрим на стороне сервера, возможно поправим.

2. Новые правила 33/34 настроены правильно, но по логам правило 33 не срабатывает.

Правило 33 должно создавать аварию на каждый SYS_NODE_DOWN / SYS_NODE_UNREACHABLE. События SYS_NODE_UNREACHABLE для "ТРК сервер KMS" за 12–15.07 в логе есть, а аварий по ним нет вообще (даже завершённых — для сравнения, авария от 08.07 по SYS_NODE_DOWN есть). Раз правило не сработало — таймер не создан, и "Node up" ничем не блокируется. Учтите также, что правила вы поменяли 16.07, а последний обрыв в логах — 15.07 22:18, то есть новые правила реальным обрывом ещё не проверялись.

Что проверить:

- нет ли выше (правила 1–30) правила с флагом "Stop event processing", под которое попадает SYS_NODE_UNREACHABLE от этих узлов;
- включите в конфиге сервера DebugTags=event.policy:6, воспроизведите обрыв и посмотрите в логе строки "match EPP rule" для события SYS_NODE_UNREACHABLE — будет видно, какие правила его обработали;
- после обрыва (пока не прошли 10 минут) откройте список Scheduled Tasks и проверьте, есть ли отложенная задача Execute.Action с ключом вида SYS_AGENT_UNREACHABLE_TUNNEL_AGENT_<имя узла>_<0x...>.

После следующего обрыва пришлите лог событий и список аварий по зависимому узлу.

3. Отдельная и более серьёзная проблема — шторм аварий.

08.07 ID аварий были в районе 43, 15.07 — уже 7 197 667. Семь миллионов аварий за неделю. В логах видно почему: статус узла скачет NORMAL↔MINOR десятки раз в секунду (события SYS_NODE_MINOR / SYS_NODE_NORMAL с тегом NodeStatus), и на каждое такое событие создаётся авария. Это и есть причина постоянного роста базы и ошибок в alarm log. Покажите правило, которое создаёт аварии на события изменения статуса узла — скорее всего, его нужно убрать или сильно ограничить. И надо разбираться, почему статус так флапает — это лучше вынести в отдельную тему.

Thanks — the new data makes this clear. Everything on both switches is now discovered via LLDP, all six Eth-Trunk0 members and the 10GE4/0/47 keepalive resolve correctly in both directions, and the links on the down ports did not come back. Those were stale entries: NetXMS keeps unconfirmed peer information for Objects.Interfaces.PeerRetentionTime days (default 30) before removing it automatically, so your ~2-week-old entries were still within the retention window. You can lower that server configuration parameter if you want faster expiry.

The remaining MEth0/0/0 <-> 10GE2/0/1 "self" link is reported by the switches themselves, not invented by NetXMS. Your other links prove the two chassis advertise distinct LLDP chassis IDs, so the only way this entry can appear is that each switch sees its own LLDP frames back on those two ports. Check on the switch directly: display lldp neighbor interface 10ge 2/0/1 — if it lists the switch itself as neighbor, the loop is physical: either MEth0/0/0 is patched into 10GE2/0/1 on the same chassis (in-band management), or both ports connect to an unmanaged management switch that floods LLDP between them. To check from the NetXMS server side, please walk the full LLDP remote table on both switches and post the output here (or send them to me privately):

nxsnmpwalk -v 2c -c <community> 10.61.99.2 1.0.8802.1.1.2.1.4.1.1
nxsnmpwalk -v 2c -c <community> 10.61.99.3 1.0.8802.1.1.2.1.4.1.1

If the cabling is intentional, the displayed link is correct and can be ignored; disabling LLDP on MEth0/0/0 would also suppress it.