Cacti / cacti

Cacti ™
http://www.cacti.net
GNU General Public License v2.0
1.63k stars 404 forks source link

Wrong port when using devices with non-standard SNMP port #2490

Closed sysres-dev closed 5 years ago

sysres-dev commented 5 years ago

Bug description Some of my devices are only available on non-standard SNMP ports. When I add them some of the data sources are created with the standard (161) port. Creating the device via the GUI or the CLI leads to the same result.

Here is an extract from my cacti DB showing the problem :

MariaDB [cacti]> select local_data_id,snmp_port from poller_item where host_id=56363;
+---------------+-----------+
| local_data_id | snmp_port |
+---------------+-----------+
|        888928 |      9504 |
|        888928 |      9504 |
|        888929 |      9504 |
|        888929 |      9504 |
|        888930 |      9504 |
|        888930 |      9504 |
|        888931 |      9504 |
|        888931 |      9504 |
|        888932 |      9504 |
|        888932 |      9504 |
|        888933 |      9504 |
|        888934 |      9504 |
|        888935 |      9504 |
|        888937 |      9504 |
|        888938 |      9504 |
|        888939 |      9504 |
|        888940 |      9504 |
|        888941 |      9504 |
|        888942 |      9504 |
|        888943 |      9504 |
|        888944 |      9504 |
|        888945 |       161 |
|        888946 |      9504 |
|        888947 |      9504 |
|        888948 |       161 |
|        888949 |       161 |
|        888950 |       161 |
|        888951 |       161 |
|        888952 |      9504 |
|        888953 |       161 |
|        888954 |       161 |
|        888955 |      9504 |
|        888956 |       161 |
|        888957 |      9504 |
|        888958 |      9504 |
|        888959 |       161 |
|        888960 |       161 |
|        888961 |       161 |
+---------------+-----------+
38 rows in set (0.01 sec)

When I manually update the poller_item table, everything starts to work at the next poll.

I exported some templates to compare them and they are identical except for the OID being polled and the name.

Expected behavior The SNMP port set on the device should be used by default.

Cacti tech infos

Date | Wed, 06 Mar 2019 08:52:31 +0100
Cacti Version | 1.1.38
Cacti OS | unix
RSA Fingerprint | 22:9a:ef:ad:d8:de:1d:e7:95:7d:89:98:bd:4f:b9:df
NET-SNMP Version | NET-SNMP version: 5.7.2
RRDtool Version | RRDtool 1.4.x
Devices | 26906
Graphs | 457301
Data Sources | 
 Script/Command: 16628
 SNMP Get: 76833
 SNMP Query: 291019
 Script Query: 62037
 Script Server: 26703
 Script Query - Script Server: 31695
 Total: 504915

I tried looking into the code for what could cause this, but I didn't find anything obvious...

Thanks for any idea you could have to help sort this out.

netniV commented 5 years ago

Your expected resolution is the same as your 'bug' as far as I can see. The devices are using the port defined against them. You will need to also supply the SNMP details against the host table.

Also, how are these devices being added ? Are the SNMP details being passed when they are? If this is via Automation, do these devices actually respond on different ports to different communities?

sysres-dev commented 5 years ago

Here is the (anonymized) detail from the host table. The devices I monitor with Cacti are NATted behind a router, so they all share the same IP, but nothing uses 161/udp. I doubled check and nothing answers on this port at the same IP.

MariaDB [cacti]> select description, snmp_port, hostname from host where hostname ='xx.yy.zz.129';
+-------------+-----------+--------------+
| description | snmp_port | hostname     |
+-------------+-----------+--------------+
| dev01       |      9508 | xx.yy.zz.129 |
| dev02       |      9504 | xx.yy.zz.129 |
| dev03       |      9507 | xx.yy.zz.129 |
+-------------+-----------+--------------+
3 rows in set (0.00 sec)

I usually add devices via the CLI as I have tens of thousands of them to manage, but I tried adding one with the GUI to see if it was any different. And it wasn't. These devices all use the same community but on different ports.

Here is an example of what I use to add a device.

php /var/www/cacti/cli/add_device.php --proxy --ip=xx.yy.zz.129 --description=dev02 --template=167 --avail=snmp --notes="siteXY" --poller="2" --site="1" --ping_method=icmp --community=abcdef --version="2" --port=9504 --timeout="2001" --max_oids=20

Thanks.

cigamit commented 5 years ago

So, you are using a separate device per proxy port, or are you attempting to create graphs separately from each port in a single device? I would not suggest the later.

I have tested 1.2.2 and can not reproduce this under certain circumstances, and I have also used the proxy setting in snmp myself in the past. So, I'm aware of the configuration.

What you should do is this. Check the Data Template for the Graphs that are not working as expected, and see if the Data Template allows over-riding of the SNMP port value. If it's set, undo it. However, if you are using the later method, don't make that change.

Let me know what you find. By the way, this is one area of Cacti that confuses a lot of people. It's very flexible, but if you make a little mistake, it's not always easy to trace it. Something we are continually thinking about.

sysres-dev commented 5 years ago

Hi,

Each port is a different device. I checked the data templates and the SNMP ports are not overridden. The only thing (that I can see) that changes between the working templates and the non-working ones is the OID (and sometimes the data type [COUNTER/GAUGE]). I 'm still searching my configuration and my database for what could be the reason for this behaviour, but I'm running out of ideas :)

Thanks

cigamit commented 5 years ago

Can you get me the name of the Data Template that the SNMP port information is not working with?

sysres-dev commented 5 years ago

It's a custom template. I have attached the exported XML to this issue. cacti_data_template_ucd_tcpcurrestab.zip

cigamit commented 5 years ago

Some of the SNMP information was not mapped properly, likely due to the upgrade and likely this template was using a customer SNMP Get Data Input Method at one time. The way to fix it is just edit the Data Template, and save it. Everything should be working after that.

sysres-dev commented 5 years ago

Thanks, I saved every impacted template again. And all is working fine now!