NetXMS Support Forum

Under Map Properties, Map Options, select Floor plan in "Display objects as" drop down. Add devices to the map.
From what I can tell the devices will now be rectangles only, which can be resized by clicking and dragging the bottom right corner (and only the bottom right corner) of said rectangle.

Hi,

The Console does not like losing network connectivity and it does not auto-reconnect.
If you have a bad connection or packetloss, you're like to encounter this quite a bit.

A workaround might be to install Tomcat on the NetXMS server and use the Web Console instead (as the Web Console itself wouldn't be losing connection to the local server)? Note that I have not tested this, it's just an assumption.

Cheers

Hi,

Not sure what database system you are using. Just adding the column to the table did not take any time at all in our case despite the 100+ million rows (we're using Postgres). It was the subsequent updating of the column with actual data that took forever. Probably more of a developer question at this point, as other db systems might behave differently?

Cheers

Hi,

If you have a closer look at your screenshot, you will notice that the OID in the walk which is holding the data is .1.3.6.1.4.1.8691.7.7.1.16.5.2.9.0.
The parameter you are trying to poll in your DCI is .1.3.6.1.4.1.8691.7.7.1.16.5.2.9, which is not the same thing and doesn't hold any data, hence you are getting unsupported as a result.
Add the .0 at the end of your DCI parameter and you should be good to go.

Cheers

No sure about that one.
After the db upgrade I started our server and triggered the online upgrade. It ran in the background for about three days (we have tables with 100+ million rows), but finished ok.
I am assuming the database connection didn't drop out during the upgrade?
From what I understood, it should be safe to re-run the online-upgrade. It is not altering tables, but populating the new zone_uin fields with the correct data, so should just pick up where it left when it failed.

Hi,

NetXMS requires unique IPs per zone. As you are using the same IP twice (the public IP), you are seeing that error.

You probably want to either:

• use a proxy node in the network (e.g. only your DC or RDS) and configure other hosts in the network to talk to the proxy/allow the proxy to talk to them. If you search the forum you should be able to find some help on how to set this up. Documentation can be found here
• use Agent Tunnels to have each node talk back to the server instead. This is a bit more involved to set up, but means you are not depending on a single proxy node for all agents behind some NAT device. Documentation can be found here. There is also an older forum post here back from when I first struggled with setting this up. 

Some not so great (read: "terrible, don't do this") options for the sake of completeness:
- If you have plenty of public IPs, you can create each port forward with a separate public IP
- You can create a separate zone for each server. IPs only have to be unique across zones.

Cheers

Hi,

The Event Processing Policy determines what happens with any event (including "deactivation events").
Check your EPP and see if you have a policy that handles deactivation threshold events and if it is configured to send an email.
If not, you can configure/assign an action to do so (maybe have a look at the policy that handles the "activation event" for an example).

Cheers

Hi,

The following should work.


searchTimeTotal = 0;
activeDCIs=0;
foreach (dci : FindAllDCIs($node,"\\MSExchange ADAccess Domain Controllers(*)\\LDAP Search Time") )
{
dciValue = GetDCIValue($node,dci->id);
if ( dciValue == null ) continue; // To skip in case of errors
searchTimeTotal+=dciValue;
activeDCIs++;
}
return format((searchTimeTotal/activeDCIs),2); // You may want to change the number of decimals or round instead.


Cheers

That looks like it already tried the upgrade once before. The zone_uin column didn't exist in the alarms table until 2.2.6, so there shouldn't be a duplicate column.
Not sure if it's safe to simply drop that column from the database manually, so the upgrade can re-add it - or if you need to restore your database to a stage prior to the first upgrade.

Hi again,

As I said, it's been a while.
You can actually define the Active Discovery Targets under Configuration --> Network Discovery -> Active Discovery Targets.
So as long as your server can reach the networks that you add there, active discovery should work.

Cheers

It's been a while since I looked at this, but for all I recall active discovery only works from the NetXMS server (which will discover things in its own network but will not attempt to scan all private network ranges in hopes of finding something), hence your local network discovery works.
Passive discovery uses data collected from routers and switches via SNMP, hence if you have access to those devices, discovery in other networks works as well.
Hence discovering other networks without router or switch access doesn't work, which is what you're seeing.

Unless the above has changed, you may be stuck with trying to run nmap on the NetXMS server for known networks you want to discover and then use nxshell to create nodes based on the result.

Cheers

Hi,

Assuming you want to see the switches per tower as well as all connected devices, the following should work:

In the properties of each switch in tower 1, select Location. For the sake of this example, set Street Address to "Tower 1".
Create a new network map, map type Layer 2 Topology. Select one of the switches in Tower 1 as Seed Node.

Now right-click the map, select Properties -> Object Filter and paste the following:
if ( $node->streetAddress == "Tower 1" ) return true;
interfaces = GetNodeInterfaces($node);
foreach(i : interfaces)
{
if ( i->peerNode != null ) peerNode = i->peerNode;
else continue;
if ( peerNode->streetAddress == "Tower 1" ) return true;
}
return false;

What the above does is allow any node onto the map that has a street address of "Tower 1" (and is connected to your seed node), as well as any node that has an interface connected to a node with a street address of "Tower 1" (as long as that node is linked to your seed node somehow and within the discovery radius).

Probably not the prettiest or most efficient way of doing it, but a quick test worked on my system.

The driver used for our Cisco routers is "GENERIC". Haven't seen any exception to that.
Cisco-SB is showing up on some Cisco small business switches (e.g. SG-300), while CATALYST-GENERIC and in one case CATALYST-2900XL are in use for Catalyst switches.

We were running 2.2.4 up until yesterday, it's 2.2.5 now (so the data above is from 2.2.5).

Cheers

Hi,

I had a look at several C891s we have. One didn't provide the FDB via SNMP, the others did. I don't think that's a NetXMS issue, as all four devices poll ok via SNMP. One of them simply didn't have any data in the table. Could be a firmware issue. The one that didn't work was running a 15.0 firmware, the others were all on different versions of 15.2.
Regarding the switch topology, do you have CDP and/or LLDP enabled on the router and switches?

Cheers

Hi,

We're using syslog mostly to trigger alerts on specific events rather than for statistics, so not sure if there's an easier way or if the below will even do what you're looking for:
1. Create syslog rules and events for the log entries you want statistics on
2. Add the generated events to Event Processing Policies and have a script that sends data to a Push DCI. The data from the event could be used inside the script to determine which node and Push DCI to update.

Cheers