NetXMS Support Forum

Thanks Victor.  Just did an upgrade to 2.0.4 (which was surprisingly easy) and it's all good now.

Rich

Anyone?

Is there a way to refresh the description that was generated during the instance discovery script? 

We've updated our interface descriptions on the switches and I want them to be reflected in the DCI's that were discovered a long time back, but I don't want to delete the DCI's and lose their history.

Running version 1.2.17.

Rich

Hi guys,

I have a 1.2.17 installation sucessfully running for about a year now.  This weekend our DB server had a non-critical failure which recovered after some minor maintenance.  I saw in the NetXMS console the queues for Database writer, IData and Raw DCI values were high (~10m combined).  After the DB was back up I saw the Database writer queue gradually reduce to zero, then the database writer (raw DCI values) queue reduce to zero, but the IData queue kept increasing.  At this point I was still missing DCI data from for the weekend which I had hoped would catch up. 

I left it for a while but in the end I restarted the NetXMS core service and everything is now working fine, but I lost this weekends worth of data.  IData queue is now zero again.

Is there any way to force a DB reconnect / resync without restarting the NetXMS core (and thus losing the data)?

I'm using MSSQL 2010 for the DB and Windows 2008R2 for the NetXMS server.

Thanks,
Richard

Hi Victor,

Yes I changed it in communication properties.  The default community was left alone (I have a number of other nodes using the default and any new ones will use the default).  I disabled all the old communities on the device and changed to the new one.  In fact, the when NetXMS attempts to use the old one it gets no response and the DCI's all move to a deactive state.  The sequence of events seems to be as follows:

1. Change community on router
2. Change community in communication settings
3. Everything works fine
4. After a while (30+ minutes maybe), the communications properties show the old community, but polling still works fine

At this point, I tried doing some polls:

5a. Topology poll partially works.  VLAN list is retrieved but the next query fails.  I see auth errors, so assume old community is partially being used
5b. Interface names poll works.  After I did this, the communications properties now shows the new community (topology poll still fails though)
5c. Configuration poll succeeds.
5d. Status poll succeeds.

I then left it for another while (30+ mins) and the old community is showing in the communications properties.

It may be that the right community is stored in the DB, but I opened the properties at some point and clicked OK, saving the old community and breaking things.  So somewhere the old community is being stored.

Interestingly, I made two community changes to a device and the same thing occurred, except it kept reverting to the previous value.  This at least showed that it wasn't reverting to the default community, but in fact the previous value of community.

Rich

Hi Victor,

After some investigation I suspect the issue is that my community already contains an @ sign.  I'm trying to test this theory, and I've changed the SNMP community on the device and in NetXMS.  It seems however that the old community string is persisting in NetXMS.  The GUI will show the new string for a while, then revert back to the old one.  My feeling is that the topology poll is somehow caching the old community and overwriting the new community (although I've not thoroughly validated this).  My new community is working fine but then when I did a topology poll I see (from wireshark) that it uses the old community, and then the device properties now shows the old community again.

I've restarted the server and agent, but the problem still persists.  How can I reliably change the community for this device without having to recreate the node?

Rich

Hi,

I've been using 1.2.17 for a number of months now - fantastic product and generally working very well.

One issue - I notice that we get a lot of SNMP AUTH events from our Cisco 6509 switches every so often.  Data collects fine via SNMP for these devices, so I did a packet capture and found that there's some SNMP get-next-request requests for OID 1.3.6.1.2.1.17.4.3.1.1 that are using an incorrect community.  NXMS is sending our normal community, but suffixed with some extra characters.

eg: If our community were "public" the above mentioned requests would use a community of "public@301" on some requests, "public@302" on others.

It seems this happens on a schedule and can also be triggered by doing a topology poll.  The Layer 2 switch forwarding database for these devices are blank in NXMS.

Only happens on our 6509.  Our other Cisco switches are fine and show valid layer 2 fdb's.

A bug or config issue?

Thanks,
Richard

Ok thanks Victor.

Will a major version upgrade (ie. 1.2.17 to 2.x) keep the same DB format?  Is it just a seamless upgrade?

Rich

Perfect.  Thanks Tomaskir.  Now that you pointed this out, I found it in the docs   Works like a charm.

Regards,
Richard

Hi guys,

I've seen a number of posts around this topic, but I'm having trouble getting this to work. 

Problem: when I create a DCI that uses instance discovery (eg: ifInOctets) I can't seem to get the interface description into the name of the DCI.

I've tried using the %{script:xxxxx} approach in the DCI name, but I can't find out how to pass {instance} as a parameter to the script and $dci appears to not be set in the script.
I've tried using the return %(true,"<interface_name>") method in the instance filter, but this breaks the {instance} value for the OID.

Any help on a working solution?

Here's an example of my current DCI config:

Description: Input Bandwidth (bps) on {instance}
SNMP OID: .1.3.6.1.2.1.2.2.1.10.{instance}
Transformation: Delta/sec, and $1 * 8 in the script
Instance discovery: SNMP walk of OID .1.3.6.1.2.1.2.2.1.10

Thanks,
Richard

NetXMS version 1.2.17 and SNMP 2c.

I note (and this may not be related) that a walk of .1.3.6.1.2.1.4.20 lists all the IP information, but a walk of .1.3.6.1.2.1.4.34 yields no results.  I'm not personally familiar the difference between ipAddrTable and ipAddressTable.

Rich

Hi,

When I add an F5 BIG-IP node, the IP addresses of the interfaces are not discovered.  When I do a walk of .1.3.6.1.2.1.4.20 I can see all the relevant IP's, but they are not discovered automatically by NetXMS.  SNMPTraps (which the BIG-IP is originating from a different source IP than the primary IP) are not being registered to the correct object and I can't seem to manually add the IP's to the interfaces.

Is there anything I can tune to force the discovery of the IP's? 

Regards,
Richard