NetXMS Support Forum

Yes, you have to configure traps to events matching manually for each trap. Also, if you will go that way and create trap configuration for Juniper traps, it will be nice if you can export trap configuration and publish it here.

Best regards,
Victor

Hi!

You have two options:

1. Create an action of type "execute command on management server", entering your command in "command" field like following:


c:\\Rcmd \\\\exchange1 osql -S exchange1 -U sa -P ourpassword -Q "insert into VGSMDB..loglog (destination, content) values ('Majors','Server %n is down')"


Note that all backslashes are doubled, because backslash is an escape character in action command definition, and you have to use \\ to get single backslash in command.

2. Modify you .bat file to accept server name as argument:


@echo off

c:\Rcmd \\exchange1 osql -S exchange1 -U sa -P ourpassword -Q "insert into VGSMDB..loglog (destination, content) values ('Majors','Server %1 is down')"

pause


and define action to call it, with "command" field set to


my_script.bat %n



In both cases, just add this new action to appropriate rule in event processing policy.

Hope this helps!

Best regards,
Victor

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.