NetXMS Support Forum

Running from 24H without errors. Thanks for all

Problem persists also in version 5.2.4 . Any update about the issue?

PM sent

Any idea?
I found this old thread:
https://www.netxms.org/forum/general-support/failed-db-query-count/msg29219/

Could be a bug with the Juniper DRIVER?

I'm trying to filter out specific ip from network discovery using the filter script, but i can't get the ipaddress of the DiscoveryNode object.
Did i miss something?

tracelevel=0;
trace(tracelevel, "======= Filter::NetworkDiscovery ==========");
trace(tracelevel,$1->ipAddress);
trace(tracelevel,$node->ipAddress);
trace(tracelevel,$1.ipAddress);
trace(tracelevel,$node.ipAddress);
trace(tracelevel,$1->ipAddr);
trace(tracelevel,$node->ipAddr);
trace(tracelevel,$1.ipAddr);
trace(tracelevel,$node.ipAddr);
//trace(tracelevel,$1->snmpOID);
if ($1->ipAddress.address ~= "^172\.2\d\.1\.1") {
  trace(tracelevel, "== Filtered out from discovery ==");
  trace(tracelevel, $1->ipAddr);
  return false;
}
Output:
2025.03.26 08:51:13.767 *I* [nxsl.trace         ] ======= Filter::NetworkDiscovery ==========
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC
2025.03.26 08:51:13.772 *I* [nxsl.trace         ] UNSPEC

After upgrading from 5.0.8 to 5.1.4 i get continuously error messages about duplicated keys when inserting into interface_vlan_list.
I tried to delete switch interfaces and polling new config, but it does not resolve.
Problem seems affect Juniper switches, but i'm not sure of this, we have a lot of devices and i'm still monitoring the log.
Db upgrade did not throw any error.

2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 1: "28289"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 2: "53"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 3: "543"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 4: "3C8AB0DC5A52"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 5: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 6: "528"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 7: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 8: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 9: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 10: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 11: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 12: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 13: "ge-0/0/15.0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 14: "1"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 15: "1"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 16: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 17: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 18: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 19: "1514"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 20: "100000000"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 21: "178116"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 22: ""
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 23: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 24: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 25: ""
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 26: ""
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 27: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 28: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 29: "0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 30: "ge-0/0/15.0"
2025.03.26 08:19:08.367 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 31: "178127"
2025.03.26 08:19:08.368 *D* [db.query           ] Successful prepared sync query: "INSERT INTO interfaces (node_id,if_type,if_index,mac_addr,required_polls,bridge_port,phy_chassis,phy_module,phy_pic,phy_port,peer_node_id,peer_if_id,description,admin_state,oper_state,dot1x_pae_state,dot1x_backend_state,peer_proto,mtu,speed,parent_iface,iftable_suffix,last_known_oper_state,last_known_admin_state,if_alias,ospf_area,ospf_if_type,ospf_if_state,stp_port_state,if_name,id) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) ON CONFLICT (id) DO UPDATE SET node_id=excluded.node_id,if_type=excluded.if_type,if_index=excluded.if_index,mac_addr=excluded.mac_addr,required_polls=excluded.required_polls,bridge_port=excluded.bridge_port,phy_chassis=excluded.phy_chassis,phy_module=excluded.phy_module,phy_pic=excluded.phy_pic,phy_port=excluded.phy_port,peer_node_id=excluded.peer_node_id,peer_if_id=excluded.peer_if_id,description=excluded.description,admin_state=excluded.admin_state,oper_state=excluded.oper_state,dot1x_pae_state=excluded.dot1x_pae_state,dot1x_backend_state=excluded.dot1x_backend_state,peer_proto=excluded.peer_proto,mtu=excluded.mtu,speed=excluded.speed,parent_iface=excluded.parent_iface,iftable_suffix=excluded.iftable_suffix,last_known_oper_state=excluded.last_known_oper_state,last_known_admin_state=excluded.last_known_admin_state,if_alias=excluded.if_alias,ospf_area=excluded.ospf_area,ospf_if_type=excluded.ospf_if_type,ospf_if_state=excluded.ospf_if_state,stp_port_state=excluded.stp_port_state,if_name=excluded.if_name" [1 ms]
2025.03.26 08:19:08.368 *D* [db.query           ] {0x7f4dda4c9440} Successful prepare: "DELETE FROM interface_vlan_list WHERE iface_id=?"

2025.03.26 08:19:08.368 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 1: "178127"
2025.03.26 08:19:08.368 *D* [db.query           ] Successful sync query: "INSERT INTO idata_169885 (item_id,idata_timestamp,idata_value,raw_value) VALUES (101772,1742973548,'68','68')"
2025.03.26 08:19:08.368 *D* [db.query           ] Successful prepared sync query: "DELETE FROM interface_vlan_list WHERE iface_id=?"
2025.03.26 08:19:08.368 *D* [db.query           ] {0x7f4dda4c9440} Successful prepare: "INSERT INTO interface_vlan_list (iface_id,vlan_id) VALUES (?,?)"
2025.03.26 08:19:08.368 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 1: "178127"
2025.03.26 08:19:08.368 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 2: "0"
2025.03.26 08:19:08.368 *D* [db.query           ] Successful prepared sync query: "INSERT INTO interface_vlan_list (iface_id,vlan_id) VALUES (?,?)" [1 ms]
2025.03.26 08:19:08.368 *D* [db.query           ] {0x7f4dda4c9440} bind at pos 2: "0"
2025.03.26 08:19:08.369 *D* [db.query           ] Successful sync query: "INSERT INTO idata_169914 (item_id,idata_timestamp,idata_value,raw_value) VALUES (84034,1742973548,'73','73')"
2025.03.26 08:19:08.369 *D* [db.query           ] Failed prepared sync query: "INSERT INTO interface_vlan_list (iface_id,vlan_id) VALUES (?,?)"
2025.03.26 08:19:08.369 *E* [db.drv             ] SQL query failed (Query = "INSERT INTO interface_vlan_list (iface_id,vlan_id) VALUES (?,?)"): 23505 ERROR:  duplicate key value violates unique constraint "interface_vlan_list_pkey"
DETAIL:  Key (iface_id, vlan_id)=(178127, 0) already exists.
2025.03.26 08:19:08.369 *D* [db.query           ] Successful sync query: "INSERT INTO idata_170124 (item_id,idata_timestamp,idata_value,raw_value) VALUES (66589,1742973548,'0','0')"
2025.03.26 08:19:08.369 *D* [db.query           ] Successful sync query: "INSERT INTO idata_170124 (item_id,idata_timestamp,idata_value,raw_value) VALUES (66590,1742973548,'2','2')" [1 ms]
2025.03.26 08:19:08.370 *D* [db.query           ] Successful sync query: "INSERT INTO idata_170124 (item_id,idata_timestamp,idata_value,raw_value) VALUES (66583,1742973548,'36','36')"
2025.03.26 08:19:08.370 *D* [db.query           ] ROLLBACK TRANSACTION successful (level 0)
2025.03.26 08:19:08.370 *D* [db.query           ] BEGIN TRANSACTION successful (level 1)

Quote from: lukexjin on March 12, 2024, 09:22:19 AMHow to upgrade 4.5.4 from 4.5.3

https://www.netxms.org/documentation/adminguide/upgrade.html

Not a real use-case, reading the doc page i simply thought to scale using dedicated servers for snmp and ping.

up

Hello,
What is the right procedure to create a proxy, in a zone, with only icmp proxying features (snmp discover should be left to netxms server itself) ?
From the section "Setting communication options for zones" (doc https://www.netxms.org/documentation/adminguide/advanced.html) it seems i could set a default ICMP proxy, but from the netxms legacy client i cannot be so granular, i can only set a generic proxy in "Communication" -> "proxy nodes" zone property, that i suppose will do also snmp discover.
Setting icmp proxy in node property instead works as expected, but this is not manageable with many nodes.
My Agent Proxy config:

# Log File
LogFile=/var/log/nxagentd
# IP white list, can contain multiple records separated by comma.
# CIDR notation supported for subnets.
MasterServers=xxx.xxx.xxx.xxx
SubAgent=ping.nsm

ok thanks.

The legacy web war 4.4 does not start anymore on jetty10. There are no errors in jetty logs and the war is correctly loaded :
2023-07-03 13:42:46.724:INFO :oejsh.ContextHandler:Scanner-0-1: Started o.e.j.w.WebAppContext@12015d70{nxmc.war,/nxmc,file:///tmp/jetty-0_0_0_0-8080-nxmc_war-_nxmc-any-835922547430811876/webapp/,AVAILABLE}{/var/lib/jetty10/webapps/nxmc.war}

The web output page is:

HTTP ERROR 404 ProxyServlet: /
URI: /nxmc/
STATUS: 404
MESSAGE: ProxyServlet: /
SERVLET: equinoxbridgeservlet


Jetty 10.0.12 and java 11.0.18

Any idea?

I confirm it works, for virtual chassis too. Thanks.

Just one request concerning a different issue:
is it possible to add the "vlan view" (in the Topology menù) also in the node overview tab in order to have a visual display of their port status? The port view does not display vlans, don't know if the reason is that vlans are on logical interfaces or for design.

ok, i can test it in next days. I prefer a deb package for debian 10.
Thanks

Sorry, but i think this is not right, and probably is the reason of the netxms bug:

According also to:
https://supportportal.juniper.net/s/article/EX-How-to-retrieve-interface-names-mapped-to-a-specific-VLAN-using-SNMP-MIB?language=en_US

In the SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3 oid is not present the snmp ifindex, but the translated dot1dBasePortIfIndex ( 1.3.6.1.2.1.17.1.4.1.2)

in my case:
# Vlan
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.5.1.2.23 = STRING: "n9-2"
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.5.1.5.23 = Gauge32: 2920

# Interface with vlan n9-2 in the switch (in my previous post this info was missed because we filter out logical interfaces from snmp in the switch)
snmpwalk -v2c -c public 172.x.x.x 1.3.6.1.2.1.2.2.1.2.553
IF-MIB::ifDescr.553 = STRING: ge-0/1/3.0

# dot1dBasePortIfIndex ge-0/1/3.0 snmp ifindex  553 has oid index 564
snmpwalk -v2c -c public 172.x.x.x  1.3.6.1.2.1.17.1.4.1.2
SNMPv2-SMI::mib-2.17.1.4.1.2.514 = INTEGER: 505
SNMPv2-SMI::mib-2.17.1.4.1.2.515 = INTEGER: 507
SNMPv2-SMI::mib-2.17.1.4.1.2.516 = INTEGER: 509
SNMPv2-SMI::mib-2.17.1.4.1.2.518 = INTEGER: 513
SNMPv2-SMI::mib-2.17.1.4.1.2.519 = INTEGER: 515
SNMPv2-SMI::mib-2.17.1.4.1.2.520 = INTEGER: 517
SNMPv2-SMI::mib-2.17.1.4.1.2.521 = INTEGER: 519
SNMPv2-SMI::mib-2.17.1.4.1.2.522 = INTEGER: 521
SNMPv2-SMI::mib-2.17.1.4.1.2.523 = INTEGER: 523
SNMPv2-SMI::mib-2.17.1.4.1.2.524 = INTEGER: 525
SNMPv2-SMI::mib-2.17.1.4.1.2.525 = INTEGER: 527
SNMPv2-SMI::mib-2.17.1.4.1.2.526 = INTEGER: 529
SNMPv2-SMI::mib-2.17.1.4.1.2.529 = INTEGER: 535
SNMPv2-SMI::mib-2.17.1.4.1.2.530 = INTEGER: 537
SNMPv2-SMI::mib-2.17.1.4.1.2.531 = INTEGER: 539
SNMPv2-SMI::mib-2.17.1.4.1.2.533 = INTEGER: 546
SNMPv2-SMI::mib-2.17.1.4.1.2.534 = INTEGER: 547
SNMPv2-SMI::mib-2.17.1.4.1.2.535 = INTEGER: 548
SNMPv2-SMI::mib-2.17.1.4.1.2.536 = INTEGER: 549
SNMPv2-SMI::mib-2.17.1.4.1.2.564 = INTEGER: 553

# The correct snmp info about the interface vlan
snmpwalk -v2c -c public 172.x.x.x 1.3.6.1.4.1.2636.3.40.1.5.1.7.1.3.23.564
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.23.564 = INTEGER: 3


Netxms instead use the ifindex ( 553 ) so the vlan is not assigned (because not exists in the mapping) or when exists it's wrongly assigned to a different interface:

# Example of an interface incorrectly recognized by netxms:
snmpwalk -v2c -c public 172.x.x.x 1.3.6.1.4.1.2636.3.40.1.5.1.7.1.3.23.534
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.23.534 = INTEGER: 3

# The wrong assumption
snmpwalk -v2c -c public 172.x.x.x 172.29.1.25 1.3.6.1.2.1.2.2.1.2.534
IF-MIB::ifDescr.534 = STRING: ge-0/0/16

and indeed in my previous post screenshot, the vlan is incorrectly assigned to ge-0/0/16