PDA

View Full Version : Force Zabbix Server to Use Specific Interface


selin
16-12-2005, 17:45
We have Zabbix installed on a LinuxHA cluster. The configuration is as follows:

LNXZBX01
eth0 10.4.4.105
eth0:1 10.4.4.107 (floating/virtual IP)

LNXZBX02
eth0 10.4.4.106
eth0:1 10.4.4.108 (floating/virtual IP)

The cluster does what it is designed to do - fails over the MySQL instance and the IP (10.4.4.107). Unfortunately, the virtual IP is not being used by the Zabbix server to communicate with the agents - instead 10.4.4.105 is used. Hence, the agents reject the connection with the message:

Connection from [10.4.4.105] rejected. Allowed server is [10.4.4.107]

Is there a way of specifying the outbound IP to use for the Zabbix server? Setting the Server=10.4.4.105 in the zabbix_agentd.conf file basically negates the value of the cluster. Not having eth0 set with an IP means that when we choose to take the cluster down, we cannot communicate with the rest of the network.

Any ideas? I saw the patch to work by name, but I was wondering if there was a parameter that I had missed or if the functionality was to be added in the future...?

bdo
24-05-2006, 12:46
Hello

I've got the same problem, and I don't know how to solve it !!

Someone can help plz ???
And what about this "patch to work by name" ?
I would like to try it ...

Thx
Bdo


We have Zabbix installed on a LinuxHA cluster. The configuration is as follows:

LNXZBX01
eth0 10.4.4.105
eth0:1 10.4.4.107 (floating/virtual IP)

LNXZBX02
eth0 10.4.4.106
eth0:1 10.4.4.108 (floating/virtual IP)

The cluster does what it is designed to do - fails over the MySQL instance and the IP (10.4.4.107). Unfortunately, the virtual IP is not being used by the Zabbix server to communicate with the agents - instead 10.4.4.105 is used. Hence, the agents reject the connection with the message:

Connection from [10.4.4.105] rejected. Allowed server is [10.4.4.107]

Is there a way of specifying the outbound IP to use for the Zabbix server? Setting the Server=10.4.4.105 in the zabbix_agentd.conf file basically negates the value of the cluster. Not having eth0 set with an IP means that when we choose to take the cluster down, we cannot communicate with the rest of the network.

Any ideas? I saw the patch to work by name, but I was wondering if there was a parameter that I had missed or if the functionality was to be added in the future...?

wschlich
26-05-2006, 21:49
An option for specifying the local query source address is needed here -- it could be named SourceIP.

Also a ListenIP option is missing for the server (the agent has it).

Alexei, please comment on this issue. TIA!

bdo
01-06-2006, 13:04
This can help you : include this in your HA script :

To Create A new Virtual IP Address
/sbin/ifconfig eth0:0 192.168.1.100

To Force Outbound packets to use this Virtual IP
/sbin/ip route change default via 192.168.1.254 dev eth0:0 src 192.168.1.100
/sbin/ip route change 192.168.1.0/24 dev eth0 src 192.168.1.100


Check the result using ip addr list, ifconfig -a and ip route list

It also works with VLAN and bonding !!

--bdo



An option for specifying the local query source address is needed here -- it could be named SourceIP.

Also a ListenIP option is missing for the server (the agent has it).

Alexei, please comment on this issue. TIA!

Deelight
20-06-2006, 18:16
Thanks, but it would still be great to have a solution to force the zabbix server (and not all the outgoing traffic) to use a specific network interface.

wschlich
20-06-2006, 18:43
binding to a specific IP address for outgoing traffic is a very standard feature for any network application that initiates connections.

usually, you bind a specific service to a specific ip address only used for that service (or group of services, like mail -- smtp/pop3/imap) to achieve the following:

a) being able to move the service from one host to another without having to suffer from DNS update issues/lags
b) not exposing that and what other services are running on the same machine

so, if you bind the service to a service IP for incoming connections, it's just on purpose to bind it to that IP for outgoing connections as well (if it initiates any, like an MTA -- postfix for example supports that).

Deelight
21-06-2006, 10:54
That's right, i'd like to bind the zabbix server to a specific IP adress for outgoing traffic to give authorization to this specific IP address on my monitored servers' firewalls. The other services I have on the machine which hosts the zabbix server are associated with a different IP address which has no access to the monitored servers.

carl
29-12-2006, 22:18
I certainly second this feature request. It's usefull for situations where you want to have a specific zabbix IP so should you want to move zabbix you don't have to either 1) change the actual zabbix servers primary IP (which may have other services running 2) update all the agents to use the new IP

Alexei
29-12-2006, 22:51
I agree that this functionality must be implemented. Meanwhile you can use comma delimited lust of IP addrsses in parameter Server on agent side:

Server=10.4.4.105,10.4.4.106,10.4.4.107,10.4.4.108

azurit
04-01-2008, 17:58
anyone knows when this will be implemented ? i really need to use another interface (i can't bypass it by specifing several IP addresses on agent side..)

qix
04-01-2008, 18:06
I'm not sure if this will work, but if you set the ListenIP parameter in the server config, doesn't this also influence outgoing traffic?

Could someone test this?

I do not yet have HA running but I am required to build it in about the next 6 months or so.

azurit
04-01-2008, 18:14
I'm not sure if this will work, but if you set the ListenIP parameter in the server config, doesn't this also influence outgoing traffic?

Could someone test this?

I do not yet have HA running but I am required to build it in about the next 6 months or so.

no, it won't help, i tested it.

mjnz
03-02-2008, 01:12
Thanks, but it would still be great to have a solution to force the zabbix server (and not all the outgoing traffic) to use a specific network interface.
The way I've done this in the past is to use iptables and source NAT, with a rule similar to:

iptables -t nat -A POSTROUTING -s 10.4.4.105 -p tcp --dport 10050 -j SNAT --to 10.4.4.107

I hope this is of some use to you.

nelsonab
21-08-2008, 09:12
I hope to have a patch in a few days for this.

Alexei
21-08-2008, 09:15
I hope to have a patch in a few days for this.
What patch? It is already implemented for pre-1.4.7 and 1.5.x. The parameter is called SourceIP.

nelsonab
21-08-2008, 09:21
LOL!

I'll try and dl the latest then. Why didn't you comment on the blog, it would have saved me a "little" work... ;-)

Alexei
21-08-2008, 09:27
I didn't know you are working on this! :D

nelsonab
21-08-2008, 09:35
Hmmm... interesting avenue ya'll took to do it. I'll try and send you the patch anyway. The route I took was a little shorter and had a lower impact on overall code.

I setup a global variable in the comms.c file (ya I know that can be bad form) which had a "set" function associated with it. In the zbx_tcp_connect function it would branch to the bind statement if the BINDIP variable had been set, otherwise nothing would be done.

I'll start testing pre7 to see how it goes.

Alexei
21-08-2008, 09:38
It is not only TCP connect! Note that ICMP ping and SNMP connection are also affected.

nelsonab
21-08-2008, 09:44
Hmmm... good point.

And it works!

Thanks!

Any word on when the next release 1.4.x release will be?

tekknokrat
25-09-2008, 23:24
the approaches to workaround the source ip issue sounds complicated and would change whole networkconfiguration.

+1 for source address at least using listenaddress from config.

Alexei
26-09-2008, 16:56
In 1.6, new SourceIP parameter can be used to specify source IP for all ZABBIX processes (agent, server, proxy).

tekknokrat
26-09-2008, 17:57
In 1.6, new SourceIP parameter can be used to specify source IP for all ZABBIX processes (agent, server, proxy).

nice :) I am going to test this.

nelsonab
26-09-2008, 22:28
nice :) I am going to test this.

It works as advertised. :-D

NOB
04-11-2008, 10:37
We have Zabbix installed on a LinuxHA cluster. The configuration is as follows:

LNXZBX01
eth0 10.4.4.105
eth0:1 10.4.4.107 (floating/virtual IP)

LNXZBX02
eth0 10.4.4.106
eth0:1 10.4.4.108 (floating/virtual IP)

The cluster does what it is designed to do - fails over the MySQL instance and the IP (10.4.4.107). Unfortunately, the virtual IP is not being used by the Zabbix server to communicate with the agents - instead 10.4.4.105 is used. Hence, the agents reject the connection with the message:

Connection from [10.4.4.105] rejected. Allowed server is [10.4.4.107]

Is there a way of specifying the outbound IP to use for the Zabbix server? Setting the Server=10.4.4.105 in the zabbix_agentd.conf file basically negates the value of the cluster. Not having eth0 set with an IP means that when we choose to take the cluster down, we cannot communicate with the rest of the network.

Any ideas? I saw the patch to work by name, but I was wondering if there was a parameter that I had missed or if the functionality was to be added in the future...?

Yes, now it's possible but it is not really required for your (simple) setup !
The SourceIP= (in 1.6) doesn't work out of the box with fping, e.g. on RedHat 5 Enterprise Linux.
This needs an unofficial patch for fping, and RH5 EL seems to not provide that patched version of fping.
Other posts state that CentOS uses a different option for Fping (-I) than other distro's like Debian (-S).
And, again, this is not necessary. It'll use the normal routing on your box.
Normally it shouldn't matter where the "fping" is coming from.

If you configure the agent like this
Server=10.4.4.107,10.4.4.105,10.4.4.106
you won't have any problems with your virtual IP. The active checks are send to the virtual IP,
which should be available all the time (that's why you installed ZABBIX as a cluster) and the
other IPs of your ZABBIX-Servers are permitted to do normal checks.

IMO, there is just one occasion where you really need this new feature:

If you have DM installed/configured and the ZABBIX-Master is a
cluster.
In that case you can either reconfigure the routing or use SourceIP=

Regards

Norbert.

tekknokrat
10-11-2008, 15:14
It works as advertised. :-D

of course, I forgot to post that.