[ZBX-3379] snmp checks do not work with source ip Created: 2011 Jan 05  Updated: 2017 May 30  Resolved: 2013 Jan 16

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 1.8.4, 2.0.1
Fix Version/s: 2.0.5rc1, 2.1.0

Type: Incident report Priority: Major
Reporter: Aleksandrs Saveljevs Assignee: Unassigned
Resolution: Fixed Votes: 8
Labels: snmp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File zabbix-2.0.4-snmp-source-ip.patch    
Issue Links:
Duplicate
is duplicated by ZBX-591 SourceIP not used for web monitoring Closed
is duplicated by ZBX-5377 SNMP does not work if SourceIP is spe... Closed

 Description   

If I do not specify a SourceIP in the server configuration file, then SNMP checks work fine. If I do specify SourceIP (192.168.1.14), then SNMP checks fail with the following error: "Error doing snmp_open()". Printing snmp_errno together with snmp_api_errstring(snmp_errno) gives "-3 Unknown host (192.168.1.7:161)", where 192.168.1.7 is the monitored host, which is weird.



 Comments   
Comment by Alexei Vladishev [ 2011 Jan 05 ]

I believe this or similar problem (regarding ignored SourceIP for SNMP checks) has already been reported. Sorry, cannot find it right now.

Comment by Aleksandrs Saveljevs [ 2011 Jan 05 ]

Related issue: ZBX-591.

Comment by Alexander Vladishev [ 2011 Feb 23 ]

http://www.zabbix.com/forum/showthread.php?t=20980

Comment by Kevin Doren [ 2012 Jul 29 ]

I hit this bug in Zabbix 2.0.1 under CentOS 6.2 64-bit. If SourceIP is set in zabbix_server.conf, no SNMP packets are sent. I developed a (somewhat complex) workaround, posted here: http://www.zabbix.com/forum/showthread.php?p=105717#post105717

Comment by Alex Samad [ 2012 Aug 27 ]

Hi

I ran into this on 2.0.2
started a thread in the forums
http://www.zabbix.com/forum/showthread.php?t=28396

then found this bug report.
Kevin nice work around
Lucky for me I have a proxy zabbix setup with its ip address registered in all the right places !
but it would be nice to get this fixed

I believe this is the section

#ifdef HAVE_SNMP_SESSION_LOCALNAME
if (NULL != CONFIG_SOURCE_IP)
session.localname = CONFIG_SOURCE_IP;
#endif

SOCK_STARTUP;

if (NULL == (ss = snmp_open(&session)))
{
SOCK_CLEANUP;

zbx_snprintf(err, MAX_STRING_LEN, "Cannot open snmp session");
}


in zabbix/src/zabbix_server/poller/checks_snmp.c

I haven't really looked into it, but I would guess the snmp library is not setting the source ip ....

Alex

Comment by Jeremy Jackson [ 2012 Sep 03 ]

As I mentioned in a reply to thread

http://www.zabbix.com/forum/showthread.php?t=28396

Commenting out the session.localname, and instead setting up in /etc/snmp/zabbix_agent.conf:

[snmp] clientaddr x.x.x.x:40161

Allows you to set SourceIP= on a multihomed host, and still have SNMP working. I think there may be an additional issue with not having random (or a range of) source ports, but this is definitely progress.

net-snmp library likely has a way to set "clientaddr" internally in zabbix_server, based on SourceIP=, but setting session.localname is not the right way.

Comment by Jeremy Jackson [ 2012 Sep 03 ]

using "strace", I confirmed that problem with having a fixed source UDP port:

bind(38,

{sa_family=AF_INET, sin_port=htons(40162), sin_addr=inet_addr("199.27.180.33")}

, 16) = -1 EADDRINUSE (Address already in use)

It can be solved by putting in /etc/snmp/zabbix_agent.conf:

[snmp] clientaddr x.x.x.x:0

The 0 in the call to bind() causes Linux kernel to choose random (unused) port#. The zabbix_server.log is now clean!

Comment by Alex Samad [ 2012 Sep 03 ]

Okay maybe i have read your reply wrong.

this is not about the agent its about the server. when i set the source address for the server, snmp fails.

I don't have a source address on the agent installed on my zabbix server, I would presume it would your the default address .

I tried to set the source ip on the server to ip and port and it failed ... lots of errors in the log file.

EDIT: i reread the comments. Looks like i miss read the agent as the zabbix agent not the snmp config ! I will have to check that out

Comment by Jeremy Jackson [ 2012 Sep 03 ]

Sorry, I mis-pasted, it can be solved by putting in /etc/snmp/zabbix_server.conf:

[snmp] clientaddr x.x.x.x:40161

after removing the lines in source code setting session.localname and recompling.

Comment by Jeremy Jackson [ 2012 Sep 04 ]

Today is a holiday.. that must be why brain not engaged...needs to be :0 to let kernel choose random/unused src ports.

[snmp] clientaddr x.x.x.x:0

Comment by Volker Fröhlich [ 2012 Nov 02 ]

http://www.zabbix.com/forum/showthread.php?t=28312

Comment by dimir [ 2012 Dec 06 ]

I cannot reproduce it with latest 2.0 . I set SourceIP in my zabbix_server.conf and snmp checks are not discontinued. The source IP of packets is exactly what I set (I check it with tcpdump). snmp configuration is default.

$ ls /etc/snmp
snmpd.conf  snmptrapd.conf
$ apt-cache show libsnmp15 | grep ^Version
Version: 5.4.2.1~dfsg0ubuntu1-0ubuntu2.2

snmp agent is running on 192.168.3.7, SourceIP is set to 192.168.3.111:

$ sudo tcpdump -n dst host 192.168.3.7
17:50:57.580647 IP 192.168.3.111.52778 > 192.168.3.7.161:  GetRequest(30)  .1.3.6.1.2.1.2.2.1.10.15
...

The server has multiple IPs:

$ /sbin/ifconfig | egrep '111|113'
          inet addr:192.168.3.111  Bcast:192.168.3.255  Mask:255.255.255.0
          inet addr:192.168.3.113  Bcast:192.168.3.255  Mask:255.255.255.0

If I change SourceIP to 192.168.3.113:

$ sudo tcpdump -n dst host 192.168.3.7
17:53:47.855463 IP 192.168.3.113.38970 > 192.168.3.7.161:  GetRequest(30)  .1.3.6.1.2.1.2.2.1.10.15
...

the checks continue to work.

Is the problem in source port? Could you give more details on the snmp library version, configuration you are using?

zalex_ua

yeah, version of libsnmp can be important because, for example ZBX-4393
Btw, maybe you could take a look and fix it ?

Comment by dimir [ 2012 Dec 07 ]

I can reproduce the behavior on the Debian system though:

$ apt-cache show libsnmp15 | grep '^Version'
Version: 5.4.3~dfsg-2
Comment by Volker Fröhlich [ 2012 Dec 07 ]

Not a lot of information, but at least a bit: I'm seeing it with 2.0.3 on RHEL 6: net-snmp-libs-5.5-41.el6_3.1.x86_64.
I also saw it with 1.8.15.

Nothing ever appears on the interface. Sadly, I had no luck investigating with strace and ltrace.

Comment by dimir [ 2012 Dec 07 ]

Well, it seems that they require the localname syntax as "host:port", not just "host" (being "host:0" in our case as we do not care about the local port) when opening an snmp session. I just can't figure out why it is working on Ubuntu.

Comment by dimir [ 2012 Dec 07 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-3379 .

Comment by Volker Fröhlich [ 2012 Dec 07 ]

Patch also fits 2.0.3 without changes and the problem is solved.

Comment by dimir [ 2012 Dec 12 ]

Please also test it with IPv6. I think in that case the syntax should be "[host]:0".

Comment by Andris Mednis [ 2012 Dec 14 ]

The fix solves the issue for IPv4 (tested with NET-SNMP version 5.4.2.1). SourceIP parameter works as expected.

IPv6 works, but ignores SourceIP value and uses the most recently added IPv6 address as a source address.
But "snmpget" also behaves the same, it does not respect "--clientaddr=udp6:[fe80::3ed9:2bff:fe71:5794]" and SNMP agent sees a connection from the most recently added IPv6 address.

Comment by dimir [ 2012 Dec 21 ]

Fixed in pre-2.0.5 r32293, pre-2.1.0 r32295.

Comment by Volker Fröhlich [ 2013 Jan 10 ]

I think you should also backport that to 1.8.16.

Comment by dimir [ 2013 Jan 10 ]

We had a discussion about this and decided not to backport the fix to 1.8 . Sorry. As for a solution for you - upgrade. :-D

Comment by Volker Fröhlich [ 2013 Jan 10 ]

I am on 2.0. In my eyes it's a clear malfunction, but I respect your decision.

Comment by dimir [ 2013 Jan 16 ]

Just in case someone would like to try it before 2.0.5rc1 is out, I'm attaching the patch.

Comment by Volker Fröhlich [ 2013 Jan 16 ]

It's already included in EPEL 2.0.3 and 2.0.4 packages.

Generated at Fri Mar 29 15:55:47 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.