NetXMS Support Forum

Ok. I switched to 0. Works now.

I just don't understand why?
Originally for zoning I had to turn this on. Now with the proxy I have to turn it off? 

Hi Victor,

TrapSourcesInAllZones is set to 1. I thought that's what it has to be to accept traps/syslog from all zones?
I am pretty sure I had problems with SNMP traps in the past while this was set to 0?

Server Version: 2.1-M1
Agent Version: 2.1-M1

Agent Configuration below, with some information replaced with XYZs.

ConfigIncludeDir = C:\XYZ\NetXMS\etc\nxagentd.conf.d
LogFile = C:\XYZ\NetXMS\nxagentd.log
FileStore = C:\XYZ\NetXMS\var
EnableWatchdog = yes
SubAgent = filemgr.nsm
SubAgent = ping.nsm
SubAgent = logwatch.nsm
SubAgent = portcheck.nsm
SubAgent = winperf.nsm
SubAgent = wmi.nsm
SubAgent = ups.nsm
RequireAuthentication = yes
SharedSecret = XYZXYZXYZ
MasterServers = W.X.Y.Z
EnableProxy = yes
EnableSNMPProxy = yes
EnableSNMPTrapProxy = yes
EnableSyslogProxy = yes
EnableWatchdog = yes
ZoneId = 65

Cheers

Definitely not working for me.

I just configured another site and ended up with syslog data for a router in zone 65 showing as coming from a router in zone 33. They just happen to have the same internal IP address (both are being monitored via proxies and the proxies have the correct ZoneId entries in their configuration file and are in the same zones as the routers).

Hi,

Just to test this, I did the following:
- removed Node A from NetXMS
- ensured the Node B is in the site's zone and has the ZoneId config set
- confirmed the site has Node B configured as its proxy
- restarted Node B's NetXMS service and ran a configuration poll
- re-added Node A, directly placing it in the site's zone using its internal IP address
- confirmed Node A is sending logs from its internal interface to Node B

That means the following conditions are all met:
x Nodes A and B are in site zone
x Site's public IP translated to Node B
x Node B set as zone's proxy
x ZoneId in nxagentd.conf on Node B set to ID of site's zone
x Primary IP for Node A set to internal IP address reachable from Node B

Result:
The logs are still showing as coming from the node that has the same internal IP address, but is located in the default zone 0.

I upped debugging on the server to 8 and could see the following in the logs (IPs/Hostnames) changed:
[20-Dec-2016 09:36:46.273] [DEBUG] AgentConnectionEx::onSyslogMessage(): Received message from agent at <PROXY_PUBLIC_IP>, node ID 47780
<190>620: <ROUTER_HOSTNAME>: 000616: Dec 20 09:36:45.266 AEDT: %SEC-6-IPACCESSLOGNP: list 23 denied 0 42.237.64.29 -> 0.0.0.0, 1 packet
[20-Dec-2016 09:36:46.273] [DEBUG] Syslog message: ipAddr=<ROUTER_INTERNAL_IP> objectId=29870 tag="620" msg="620: <ROUTER_HOSTNAME>: 000616: Dec 20 09:36:45.266 AEDT: %SEC-6-IPACCESSLOGNP: list 23 denied 0 42.237.64.29 -> 0.0.0.0, 1 packet  "
[20-Dec-2016 09:36:46.285] [DEBUG] AgentConnectionEx::onSyslogMessage(): Received message from agent at <PROXY_PUBLIC_IP>, node ID 47780
[20-Dec-2016 09:36:46.285] [DEBUG] AgentConnectionEx::onSyslogMessage(): Received message from agent at <PROXY_PUBLIC_IP>, node ID 47780
[20-Dec-2016 09:36:46.285] [DEBUG] AgentConnectionEx::onSyslogMessage(): message ID is invalid (node <PROXY_NODE_NAME> [47780])

Not sure where the message ID is invalid is coming from?

Cheers

Hi Victor,

The problem with the suggested setup is this (example IPs):
Node A: Firewall with public IP 100.100.100.1, private IP 192.168.0.1
Node B: Server with private IP 192.168.0.2

To connect the proxy on Node B, I have to configure a port forward and add Node B using the public IP 100.100.100.1.
However, Node A has that IP on one of the interfaces. The result is that NetXMS does not let me place both nodes into the same zone, because of an IP address conflict.

In the past I noticed that the above does not cause issues if:
- I add Node B while Node A does not exist in NetXMS and place it in the right zone
- I add Node A and place it directly into the right zone (at that point NetXMS doesn't know about the IP conflict yet).

While the IP conflict is technically still there, NetXMS doesn't seem to complain or break with this setup.

Maybe the IP address conflict is actually a bug?

Cheers

Hi,

I did some searching to confirm this, but it appears the Filter in the Syslog Monitor (NetXMS Management Console) is very basic in that it does not accept regular expressions or boolean things like "hostname AND deny"?
I know I can do this and a lot more in the actual syslog View, but sometimes just being able to filter things out on the fly as they come through is all that's required (regex would be a winner), as opposed to having to re-execute a search query over and over while looking at the logs as they come in.

Did I miss something in the documentation or is this currently not possible?

Cheers

Just tried that:
- Moved the proxy back into the default zone (0)
- Moved the router back into the site's zone (
- Configured proxy agent with zoneid 8
- Restarted proxy agent and ran configuration poll
- Reconfigured router to send syslog to proxy node from internal interface

Result: messages show as coming from the beforementioned Node C that's in the default zone.
Looks like the zoneid in the config is being ignored?

Hi,

Reading that 2.1 includes a Syslog Proxy, I just had to give this a spin.

Doing this, I encountered an issue with the server matching the messages to the correct node. I am using zoning, which probably plays a part in this.

Node A is a router at a site.
Node B is the proxy node.
The site has a single public IP address, so to connect the proxy node I have to create a port forward on that IP address.
That also means I cannot add Node A and Node B into the same zone (IP conflict). Node B is therefore in the Default zone, while Node A is in that site's zone.

I reconfigured Node B to act as Syslog proxy and reconfigured Node A to send syslog messages to Node B.

The result was that the messages were linked to Node C - a completely unrelated router which is sitting in the default zone and happens to have the same internal IP address as Node A.

Based on the above, my guess was that any syslog messages coming in from or proxied through Node B are automatically placed in the Default zone and then matched as per the server's SyslogNodeMatchingPolicy (in my case 0, i.e. IP, then hostname - but being in the wrong zone, the order would not matter).

So I moved Node A into its own zone and changed its IP in NetXMS to its public IP, syslog was reconfigured to send directly to the NetXMS server.
Node B was moved into the site's zone.

That should fix all other devices on the network sending syslog through Node B (haven't tested this yet) while the router's syslog goes straight to the NetXMS server.

Next problem now: the server has two systems with the same public IP address and can't tell where the messages are actually coming from.
I changed the SyslogNodeMatchingPolicy from 0 to 1 and restarted the NetXMS server, but that made no difference. Clearly the hostname matching isn't working in this case. I am not even sure which hostname it's comparing? The Object or the Primary host name? Changing the Object name made no difference.
I need to use an FQDN for the Primary host name to be able to query the router, but the router in question only sends the hostname in the syslog message. If I put an FQDN in as hostname on the router itself, it appears to ignore everything from the first "." onwards when it adds it to syslog messages. Other devices do not even allow hostnames longer than maybe 16 characters. Looks like I've hit a dead end?

Is there a way to setup "rules" to handle assigning syslog messages to devices?
How do other users handle this?

Maybe a future solution would be for NetXMS to ignore the actual IP/hostname presented for data collection and only use the interface IP addresses for IP conflict, topology and syslog checks, considering that the IP used to query the proxy node is not actually on the proxy node?

Cheers

Looks like we basically went through the same steps when running into this problem.
And yes, using the external IP of the server works (after reconfiguring Postfix to allow to relay).
Thanks for pointing that out.

Cheers

Hi,

Email alerts on our system stopped working after we upgraded to NetXMS 2.1-M1 (which required an upgrade to Ubuntu 16 for JDK8 and was followed by an upgrade of Postgres to 9.5 - so plenty of changes).

The NetXMS configuration was pretty basic and meant to send emails through localhost. Manually sending via telnet works without a problem.
I increased debug logging on the server, monitored Postfix logs as well as NetXMS and found that Postfix does not even see a connection attempt from NetXMS.
NetXMS on the other hand gives me this (email address/server name/DCI data replaced):

[07-Dec-2016 17:13:48.650] [DEBUG] *actions* Executing action 4 ([Email] Standard Alert) of type SEND EMAIL
[07-Dec-2016 17:13:48.650] [DEBUG] *actions* Sending mail to EMAIL_ADDRESS: ""DCI_DESCRIPTION" is in state "NORMAL" - (Parameter: DCI_PARAMETER)"
[07-Dec-2016 17:13:48.655] [DEBUG] SMTP(0x7f5d6c2a3390): Failed to send e-mail, remaining retries: 4
[07-Dec-2016 17:13:48.656] [DEBUG] SMTP(0x7f5d6c2a3390): Failed to send e-mail, remaining retries: 3
[07-Dec-2016 17:13:48.656] [DEBUG] SMTP(0x7f5d6c2a3390): Failed to send e-mail, remaining retries: 2
[07-Dec-2016 17:13:48.656] [DEBUG] SMTP(0x7f5d6c2a3390): Failed to send e-mail, remaining retries: 1
[07-Dec-2016 17:13:48.657] [DEBUG] SMTP(0x7f5d6c2a3390): Failed to send e-mail, remaining retries: 0
[07-Dec-2016 17:13:48.657] [DEBUG] EVENT SYS_SMTP_FAILURE [22] (ID:4307970 F:0x0001 S:1 TAG:"") FROM SERVER_HOSTNAME: Unable to send e-mail to <EMAIL_ADDRESS>: Unable to resolve SMTP server name

I am not sure what there is to resolve for localhost or the IP 127.0.0.1 (I tested that as well). But either way, localhost does resolve locally without problems and telnet to localhost on port 25 works fine.

Has anyone else run into this?

Hi,

I thought I'd give the Hypervisor subagent a spin on a Hyper-V server, but then noticed that the vmgr.nsm isn't actually in the (2.1M1) agent package?
Where can I get this from?

Cheers

Hi,

Would it be possible to implement something like a field to enter date/time (or a field for date and a 24h slider for time) to basically go back in time and show all "Last Values" for a node as they were at that time? That would make it possible to just select a random point in time and see the status of everything on that node at that moment as NetXMS saw it.

Cheers

Yes, just adding that as an auto apply rule to a container would work.
As I said though, this will only update on configuration polls - there could be hours between them.

And yes, nodes can be in multiple containers.

Just happen to have implemented some monitoring where the graphs "connecting the dots" as described is an issue as well.
Being able to store a NULL value in case of an error in collection or a node not being available and having the system actually show a gap in a graph based on that would indeed be nice.

Same here. Windows 10 running the desktop client.