multiple addresses per host

[naim]

hello,
Thank you for the great work on zabbix.

Is it possible to have multiple addresses per host? Say you have a complex mesh network, sometimes you get something wrong in routing, and some host is not reachable by its real (public) IP for example, but still reachable by an IP from the private range 192.168.20.5 for example.
In this case i dont want to declare the host down, but to detect whats wrong with say our RIP/v2 service. Some node stopped distributing its RIP table? .. just an example.

Any help appreciated

[Arthur]

Hi,
I had the same problem with cisco router/Modem on the Client side
of the line .. in my case the other interface only came up if the the
backup line kicked in.

All ik could do is define a hostA and a HostB for this machine.
Defining the triggers for this backup line was a other problem.

[naim]

Nagios V.S.

what differentiates zabbix from nagios is that zabbix is :: database frontend to your network infrastructure, generates performance graphs and does notifications, and has a nice frontend that is easy to learn fast.
Nagios on the other hand has a much more complex logic allowing accurate problem diagnosis, simplest of all is this ability to define multiple addresses per host.
Ill still to nagios untill i figure out a way to solve this.

[Alexei]

Try to use active checks, this is recommended approach by the way.

ZABBIX does not care about IP address of your host if you use active checks only. The host, wherever it is, will connect to ZABBIX server and send everything the server needs.

[naim]

Ok, that would work on normal linux/windows/bsd/whatever machines. But when i have some embedded system, a wrap board, some embedded router, etc etc.

I cannot add any service on the remote machine to get accurate notifications, that something is wrong in the routing table and the host is not actually down.

So on monitoring server side::
1)i would check if the host is reachable on its real IP first (routable from some central location on the network by some dynamic routing protocol, [RIP, OSPF... whatever] )
if that fails,
2) i would check if its reachable on its fake IP, reachable from by static routes not dependant on some central dynamic routing protocol

if this second check fails, i would then check the parent host, if its reachable, i then declare the remote host in question down. This is way i dont need to touch any of the remote devices to setup monitoring.

Also im minimizing the actual concurrent checks done by the monitoring server, i only need to ever check reachability of the fake IP in case the main address routed by RIP is not reachable. Similarly i dont need to check the parent hosts for that remote host as long as i can reach it.
Take for example we have 200 similar cases, and you see how many checks im saving.

Err, to summarize, the concept im trying to explain here is, for accurate and detailed monitoring service, i must setup my solution with the following in mind ::

1) the less the number of service i have to monitor, the less the average service check interval is.
2) more accurate monitoring results because we check services more frequently.

as a general case study, i check proxy service running on some remote host, if service is fine, means the link to that service is fine, means the router just before it is fine, so is the wireless link to that router, and the switch before that .. etc etc .. but i only check the parent services and hosts when the service is in a warning or critical state

Sorry, WAY off subject from original post, maybe we need to translate this into some theory documentation on monitoring services :P