NetXMS Support Forum

Hi Alex,

i have pinned "Package Deployment Jobs" to the pinboard. In this view, the status of the scheduled jobs is not visible. However, if I access the "Package Deployment Jobs" directly through the configuration, the data is refreshed and suddenly all jobs are visible.

If we now try to cancel the jobs, we get the error "Request is out of state"

I completely missed the "zone" option when setting the auto discovery up. my bad. closing thread

Thanks for the help.  I've got the instances discovering properly now.  Thanks for spotting the power consumption oid not matching up with the base oid.  When I checked it the base oid was wrong and the power consumption oid was right.

You can silence these alarms by disabling rules for events SYS_PACKAGE_INSTALLED and SYS_PACKAGE_REMOVED.

I've reopened issue, so devs will look into it.

1. Topology.DefaultDiscoveryRadius

After checking the code, the ad-hoc Topology maps → Layer 2 topology action does send the "use server default" sentinel from the client, and the server is supposed to substitute Topology.DefaultDiscoveryRadius for it. However, we have found a likely bug in how that sentinel survives the trip from client to server (signed/unsigned conversion of the radius field) that can cause the server to use a huge depth instead of the configured one — which matches what you are seeing.

We are opening an internal ticket for the developers to verify and fix. To confirm whether your installation is affected, could you share:

• Server build number and desktop client build number (full version strings).
• A short server log captured during one click on the menu, with these debug tags enabled:
  
  Code Select Expand
  DebugTags = topo.*:7,poll.topology:7,topology.*:7We are interested in the nDepth= value the topology builder receives. If it is something like 4294967295 (or any value other than 5), that is the bug confirmed for your environment.

2. MSTP links via ISP-side intermediate devices

This part is expected behavior, not a bug. NetXMS builds L2 topology by reading FDB, LLDP, CDP and STP tables from each managed device. If the intermediate ISP devices are not managed in NetXMS, there are no neighbor records on the path between your two end nodes, so the server cannot infer the connection. The requirement that all network equipment be registered in the system is documented here: Network topology.

Two ways forward:

• Add the ISP intermediate devices as managed nodes (needs SNMP access from your monitoring zone). Once they participate, LLDP/CDP/STP from each side will let NetXMS stitch the path.
• If you cannot manage them, automatic end-to-end discovery across them will not work — you can add the link manually as a connection on a Network Map.

Useful diagnostic regardless: on each end node's Interfaces tab, the Peer Discovery Protocol column shows how (or whether) each neighbor was discovered — that confirms which protocol is or isn't reaching across the ISP segment.

We will update this thread once the developers confirm the fix for #1.

Hi all,

I have created a few network zones and subnets for testing.

I have added the static zones / subnets into auto discovery but when netxms discovers IPs in those subnets it creates a new entry on the network tab instead of puting it into the predefined sections that were manually created. is this normal behaviour?

is there a way set auto discovery to fill the already set networks?

basically in the screenshot attachted - I would like auto discovery (In red) to auto populate the maunally created (In Green) - is this possible?

Some help would be appreciated, thank you.

Update:
We can see the active jobs for a short time about 10 minutes after they start, but they run so fast that there's no way to cancle them before they disappear from the list again.

Hi Alex,

Thank you for your detailed explanation.

In our case, we cannot see the scheduled jobs and therefore cannot delete them either, as they do not appear in the list (Client 6.1.1).

As you suspected, the error is "Unable to connect to agent." This situation arose because a package was deployed to a node that is monitored only via ICMP (Agent Communication Option - "Use ICMP ping on primary IP address to determine node status"). How can we prevent this? We regularly deploy packages to the cluster that consist of a mix of agent-based and ICMP-based monitoring.

It would be very helpful if we could disable the automatic retry via a central configuration option.

best regards,
Alwin

The "keeps retrying" is by design, and the reason "Hide" is the only menu option on a Failed row is intentional too. Here's what's actually happening:

When a package deployment attempt fails with a transient error (e.g. "Unable to connect to agent"), the server marks the current job as Failed and creates a new job in Scheduled state, 10 minutes later. So you're not looking at one stuck job — you're looking at a chain of new jobs being added every ~10 min.

Consequences:

• You can't cancel a Failed job. The cancel action is only valid against jobs in Scheduled state. That's why "Hide" is the only thing the right-click gives you on a failed row — it's a view filter, not a state change.
• To break the loop, cancel the next Scheduled job in the chain, not the failed ones. Look for the row whose status is Scheduled (timestamped ~10 min after the most recent failure) and right-click → Cancel. After that, no new job will be created and the chain stops.
• Failed rows are cleaned up automatically by the housekeeper based on the server config PackageDeployment.JobRetentionTime (in days, default 7). Drop it temporarily (e.g. to 1) if you want them gone faster, then restore.

Worth checking the errorMessage on the failed rows too — if it's connectivity-related, cancelling alone is just a workaround; fixing agent reachability will stop new failures from being created.

For an SNMP table with a multi-part index, use SNMP Walk - OIDs as the instance discovery method. NetXMS walks the chosen column and uses the OID suffix — the entire composite index (e.g. 1.2, 2.1, ...) — as the instance name (docs). You then reference that suffix in the DCI's OID via {instance}.

Setup on the prototype DCI:

• Instance Discovery → Method: SNMP Walk - OIDs
• Base OID: a column that exists for every PSU — column 3 (name) works well: .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.3
• Metric OID (the DCI itself): .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.7.{instance}

{instance} is replaced with the composite suffix (e.g. 1.2) for each row, producing the correct per-PSU power OID.

For nice DCI display names, attach an Instance Discovery Filter Script that fetches the PSU name from column 3 at the same index and returns [instance, name] — first element keeps the composite suffix for OID substitution, second populates {instance-name} for the description (docs).

Side note: the power-consumption OID in your message has an extra .1 (...11.2.1.1.7.x.y). If columns 1, 2, 3 are group/slot/name as you describe, the power column is .1.3.6.1.4.1.47196.4.1.1.3.11.2.1.7.x.y — worth double-checking with nxsnmpwalk before building the DCI.