Netxms 3.0 zone proxy inside zone not reachable. Works if proxy in server zone.

[normalcy]

Hi have upgraded to 3.0.2292 and am trying to create a node in a zone and set it as the zone proxy and it doesn't seem to work if the proxy is in the zone.

eg: I have zone 1 and 2.  Netxms server is in zone 1.  If I create the proxy node in zone 1 and set it as the zone proxy for zone 2 (the old way as I understand it) then I can successfully poll all zone 2 nodes and things like the internal topology show the connection going via the proxy.

If I create the node in zone 2 as a zone proxy (or move the node into the zone 2) then the proxy itself can't be reached in a status poll and the whole zone goes unreachable.

My understanding is that the new way is to create the proxy for the zone inside that actual zone?  Doesn't seem to be working for me.

Have tried setting the zone 2 proxy to be its own proxy for polling/services and also tried the netxms server proxy.  Only thing that works is to put the proxy in the root zone 1 as we used to.

[normalcy]

I think I've got this working now, just testing to be sure.

Looks like I have to specify an undocumented ZoneUIN value in the agent? 

netxms/src/agent/core/nxagentd.cpp at 85ad72844ebe7361d714efac575e8f69f15517cb · netxms/netxms

NetXMS - Open Source network and infrastructure monitoring and management - netxms/src/agent/core/nxagentd.cpp at 85ad72844ebe7361d714efac575e8f69f15517cb · netxms/netxms

GitHub (github.com)

At least after setting that and restarting and then moving the agent into the zone it now seems to have kept the connection working.

[Filipp Sudanov]

Hi!

I was not able to reproduce this. What kind of communication are you using with the proxing agent - direct connection to it from the server or agent tunnel (agent to server communication)?
When you moved the agent from zone 1 to zone 2, did you do Status poll or tried Full Configuration poll?

[normalcy]

Hi, I could only try status polls as configuration polls were unavailable as the node was classed as unreachable.  Any other nodes polled would only say that the proxy was unreachable.

It is directly reachable through an L2TP VPN.  Tried with or without dst-nat on the client router (currently no nat from server to agent as non-overlapping IP space).

Tried both creating the node in the zone and setting as node proxy or moving into the zone from root zone. 

So far since adding ZoneUIN to agent config its been holding steady for a few hours now.  The only mention in the docs regarding that attribute I can find is with regard to syslog source mapping?

[Filipp Sudanov]

Currently, as of 3.0, it works that way, that as soon as you create a node, Full configuration poll is being done. If server is not able to ping AND connect to agent, the node will be marked at unreachable and the only thing that will remove unreachable flag and initiate communications is to manually run Full configuration poll  again.
The thing is that after node creation, while user goes to properties of a zone to set that node as a proxy, the node gets unreachable. There is a way to create a node in a zone and set it as proxy for that zone in one step - in new node creation there's a checkbox "Create as zone proxy for selected zone". It's among other checkboxes and is easy to overlook. There are thoughts to improve user-friendliness of all this.

As for ZoneUIN parameter - as far as I know, it's related to SNMP Traps and Syslog monitoring; also it's used when tunneling agent connects to server so that server could auto-assign node to correct zone. Proxy should work without this parameter configured.