NetXMS Support Forum

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

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.

Thanks, issue registered: https://github.com/netxms/netxms/issues/3428

Thanks for the follow-up — you are right, 6.2.1 does not fully fix this.

The fix that went into 6.2.1 removed the visible flickering of the columns, but not the underlying cost. Grid views still re-measure and repack every column on each refresh cycle, and that is what you are seeing as constant repainting on the Data Collection and Interfaces tabs. On a node with many interfaces or DCIs a refresh can be triggered very often, so it never settles.

I've opened https://github.com/netxms/netxms/issues/3418 to track it. The proper fix is to repack columns only when the content actually changes shape (new columns, first data load, or when you ask for it), instead of on every refresh.

Until then you can avoid the problem by unchecking "Resize columns automatically" in the view menu of the affected view. The setting is remembered per view, and with it off the columns are no longer repacked on refresh.

The identical value on both switches is expected, not the fault. 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2 is hwMstpiBridgeID, and under V-STP the M-LAG pair presents itself as one logical bridge, so both chassis report the same bridge ID. In your case that ID (AC:5E:14:7F:89:01) is xA's own dot1dBaseBridgeAddress, which you can see in xA's Hardware Inventory tab.

NetXMS reads that OID specifically to handle this - see https://github.com/netxms/netxms/issues/3353, fixed in 6.2.0. Without it, STP discovery invents a link to the M-LAG peer on every downstream port. Which server version are you running? If it is older than 6.2.0, upgrade first and re-run a configuration poll plus a topology poll on both switches.

The peer-link and keepalive links in your screenshots look correct: the six Eth-Trunk0 members (40GE5/0/34-35, 40GE6/0/34-35, 40GE7/0/34-35) and 10GE4/0/47 all resolve to the right peer and match your diagram. Two other things do look wrong, and neither can come from STP discovery:

1. On both switches, MEth0/0/0 and 10GE2/0/1 list the switch itself as peer node, pointing at each other. STP discovery cannot produce a self-link - it skips a bridge that resolves to the local node.

2. 40GE6/0/6-9 on xA linked to 10GE4/0/42-45 on xB. These ports are DOWN/Disabled, and a down port has no forwarding or blocking STP state, so STP would not report them. They are also absent from your diagram.

Could you widen the Interfaces table and show the "Peer discovery protocol" column? It is cut off in both screenshots, and it is the one field that tells me which discovery source created these links (STP, LLDP, CDP, or FDB). Also confirm whether 40GE6/0/6-9 were ever cabled to xB - if they were, these may just be stale cached links.

TRUNCATE

Thanks for the detailed report.

The missing zone record is not what's breaking discovery. Object ID 4 is a built-in object: the server creates the Default zone in memory at every startup, and the code paths that use it (including active discovery) handle it correctly whether or not a row exists in zones / object_properties - the row only gets written once the zone is actually modified, e.g. when the first subnet is placed into it. So on a freshly initialized database the tables being empty is expected, and this is not specific to SQLite or to Windows.

The error message in the log is misleading, though, and the zone should be persisted at first startup instead of being re-created every time. I've opened https://github.com/netxms/netxms/issues/3410 for that.

For the discovery problem, which is a separate issue, please check the following:

1. Discovery type. In Server Configuration, check NetworkDiscovery.Type. If it is 0 (disabled), the "Scan" action will enqueue addresses but nothing will pick them up. For active scanning of configured ranges it must be 2 (active) or 3 (active and passive).

2. Enable discovery debug output. Either start the server with a higher debug level, or set it at runtime without a restart:

    nxadm -c "debug tag poll.discovery 6"

Then run the scan again and watch netxmsd.log. At level 6 you will see, per address, whether the host responded to the probe and - if it did - whether the potential node was rejected and why ("IP address already known at node ...", "rejected by discovery filter", etc.). Reset it afterwards with nxadm -c "debug tag poll.discovery off".

3. Probing method. By default active discovery only uses ICMP ping. If the target hosts do not answer ICMP, nothing will be found. Check NetworkDiscovery.ActiveDiscovery.EnableSNMPProbing and NetworkDiscovery.ActiveDiscovery.EnableTCPProbing, and make sure ICMP is not blocked between the server and the scanned range.

4. Discovery filter. If a filter script is configured, a responding host can still be dropped. The level 6 log above shows this explicitly.

5. Address ranges. Verify that the ranges under Network Discovery -> Active Discovery Targets are the ones you expect, and that they are IPv4 - IPv6 ranges are skipped by active discovery.

If you post the poll.discovery log from a scan run, I can tell you where it stops.

Thanks for the suggestion — I've opened an issue for it: https://github.com/netxms/netxms/issues/3409

At the moment all backup-related read operations (list of backups, latest backup, individual backup by ID) are gated only by "Read" access on the node, so anyone who can see the node can also pull the full device configuration with whatever it contains. Splitting that into a separate right for the backup list and another for viewing/exporting the actual content makes sense to me.

There are a few things to settle first — mainly what the default should be for existing installations, and the fact that the object access rights mask is nearly out of free bits — so I'll discuss it with the team before we implement anything. Feel free to add your thoughts to the issue.

Самое простое решение - добавить в Hook::CreateInterface:

if (($1.name == "ISW001") and ($1->name ~= "^VLAN.*"))
{
    return false;   // не создавать VLAN-интерфейсы
}
return true;


That's more or less expected with the current caching: the client caches tiles under .nxmc4 and doesn't invalidate them when the tile server changes, so you can get stale/missing tiles from the previous server — which is why clearing the cache fixed it for you. I've filed a ticket to key the cache by tile server URL so switching servers invalidates automatically and you won't need to clear it by hand. Thanks for tracking it down.

Objects already have a "presentation image" property that is meant to control exactly this. It turns out it's currently ignored when the object is rendered on the geo map, so you always get the default icon there. I've opened an issue to fix it — once done, your custom presentation image will be used on geo maps as well. Thanks for the report.

Ticket: https://github.com/netxms/netxms/issues/3398

Hi Leo,

Yes — libcurl.dll will be updated to 8.21.0 or later in the next agent build. It's bundled with the Windows agent, server, client and web UI installers, so all of them get the new DLL.

That said, NetXMS itself is not exploitable through this bug, so there's no urgency here.

CVE-2026-8927 needs four things to line up at once:

1. the proxy is configured through environment variables rather than CURLOPT_PROXY,
2. a curl handle is reused across sequential transfers,
3. the proxy changes between those transfers, and
4. the first transfer authenticated to the proxy using Digest.

The fourth one never happens in NetXMS. libcurl only negotiates Digest against a proxy if the application sets CURLOPT_PROXYAUTH to include CURLAUTH_DIGEST or CURLAUTH_ANY — the default for that option is CURLAUTH_BASIC. We never set CURLOPT_PROXYAUTH anywhere in the codebase, in the agent or the server. So the stale Proxy-Authorization state that the CVE describes is never created in the first place.

Worth heading off one thing that looks related but isn't: the agent's web service support does offer Digest as an authentication option (WebServiceAuthType::DIGEST). That is passed to CURLOPT_HTTPAUTH, which authenticates to the web service itself via the Authorization header. Proxy authentication (Proxy-Authorization) is a separate state machine and is not affected.

If your scanner is flagging the DLL by version rather than by reachability, and you'd rather not wait for the next build, you can drop a newer libcurl.dll into the agent's bin directory yourself. curl keeps its ABI stable across the 8.x series, so a straight 8.21.0 replacement works. Two caveats: it will be overwritten on the next agent upgrade, and it won't carry our code signature.

Hi,

Thanks, my bad. Fixed now.

Simplest approach is to modify retention time in server configuration, then run housekeeper (or just leave it overnight). Once done, vacuum DB and you'll have more space.