NetXMS Support Forum

Pohoze na issue 305 iz bugtrackera, no ja esche poizuchaju dump. Esli prichina ta-ze, to v 1.0.5 eto ispravleno, segodnja ili zavtra ja sdelaju build.

The current scheme is "for historical reasons". Now I have much better understanding of how it should work, but it's a major change in server's architecture. I completely agree that physical interfaces and IP addresses must be separate entities. I plan to make this change in 1.1.x branch (along with many other required changes).

Best regards,
Victor

Hi!

It's not possible to just graph data in different units. However, you can convert bytes to bits at collection time using transformation script, and then work everywhere with bits.

Best regards,
Victor

Hi!

It's impossible to extract part of the varbind's OID as event's parameter. However, it's possible to extract varbind's value. If trap contains some value identifying BGP peer, then it can be extracted. I suppose that BGP trap can contain either .1.3.6.1.2.1.15.3.1.7.<peer_ip_here> (bgpPeerRemoteAddr) or .1.3.6.1.2.1.15.3.1.5.<peer_ip_here> (bgpPeerLocalAddr). In that case, you can add varbind matching in trap configuration, with matching OID set to .1.3.6.1.2.1.15.3.1.7 for example. When matching varbinds, NetXMS looks for longest possible match, so it will match OID with any peer IP appended to it, which is fine in that case, because there should be one trap per one peer down event.

Best regards,
Victor

Did you see NetXMS listening on UDP port 162? If not, please post server's log file. If server is listening on port 162, try to set configuration variable LogAllSNMPTraps to 1, and check SNMP trap log. If you will see traps coming, then you just need to configure server to handle traps correctly. You can use this topic as a reference: https://www.netxms.org/forum/configuration/how-to-configure-snmp-traps-from-my-emc-box/.

Best regards,
Victor

You can disable appropriate rule in event processing policy (the one processing SYS_INCORRECT_NETMASK event), or make an exclusion in source field of this rule for problematic nodes.

Best regards,
Victor

Unfortunately it's not possible.

Best regards,
Victor

Yes, this is by design. NetXMS server read all IP addresses configured on nodes and create interface objects for each address found. For HSRP, you can create cluster object and make your switches members of that cluster - then on cluster object level you can configure virtual IPs. In that case NetXMS will not create interface objects for addresses listed as cluster virtual addresses. It's probably not very convenient for network devices, but is the only workaround right now. We are open for ideas on how to improve that

Best regards,
Victor

Setting interface to "unmanaged" state means that it's status is not of any interest, and effectively excludes interface from status polls. Status of unmanaged interface will never change unless it will be returned to "managed" state. However, it does not affect data collection related to this interface, so if you, for example, has DCI for traffic on this interface, it will continue to collect data.

Best regards,
Victor

You can set them to "unmanaged" state (right click -> select "Unmanage").

Best regards,
Victor

Could you please post config.log here?

Best regards,
Victor

I could change it in upcoming 1.0.5 version, which I plan to release this or next week, depending on resolving few serious issues (mostly issue 305).

Best regards,
Victor

Novij nxmibc v attache.

Hi!

Yes, it's possible, but that will involve a lot of manual work. You can create separate container somewhere in the service tree, bind all nodes to that container, and create new map with root object set to that container. Then you should open new map, turn off automatic layout, and manually layout nodes.

Best regards,
Victor

Hi!

You are right, most of the libraries must have LGPL license instead of GPL. One of the main ideas behind NetXMS is to make it a good platform for building customized solutions, so GPL license in each file is mostly because of copy-and-paste then intentional limitations. I'll do review of licensing and change license files appropriately, but anyway you can be sure that you can use all APIs under LGPL license.

Best regards,
Victor