SNMP configuration for node's primary IP address does not apply to discovered IP interfaces of same node
Description
Acceptance / Success Criteria
Attachments
Lucidchart Diagrams
Activity
Marcel Fuhrmann May 29, 2018 at 8:26 PM
Ok. A hint for the case above in this chapter: https://docs.opennms.org/opennms/releases/22.0.0/guide-admin/guide-admin.html#_provisioning_the_snmp_configuration.
Also we could add a hint here:
Wdyt?
Jeff Gehlbach May 29, 2018 at 2:12 PM
let's not do it in the file; comments there will be lost the first time a user configures this stuff from the web or REST API. If there's a convenient place to put it in the web UI, that's fine; otherwise a note in the admin guide should suffice.
Marcel Fuhrmann May 29, 2018 at 7:10 AM
I can confirm it. After adding those IPs into snmp-config.xml the log entries never appeared again. Does it make sense to add a hint in the file or in the Web UI?
Marcel Fuhrmann May 17, 2018 at 3:10 PMEdited
You are right. The destination IPs I've blurred here:
seem to be always !10.x.x.x addresses which I don't added into my XLS PRIS source.
I can test it by adding this !10.x.x.x addresses to snmp-config.xml. I will give feedback.
Jeff Gehlbach May 16, 2018 at 4:02 PM
is there any chance that the requests with community string public are arriving at a different IP interface on the firewall, one which Provisiond found during the scan phase?
My firewall which has an IP 10.0.0.x gets a lot of failed snmp queries because of community mismatch.
The log tells me that public was used instead of our company community.
As you can see the default community is set to public and the network range where the firewall is located has an other snmp definition in snmp-config.xml.
When I change the default read community to MyCOMM I don't get snmp mismatches anymore.
So my question is: Is that behaviour correct? I thought OpenNMS should not use public if there is a matching definition.