Monitoring multi-homed boxen

Mike McClure mmcclure at pneservices.com
Wed Sep 17 18:21:49 CEST 2003


Just define each interface on the router as a service.  Use SNMP to check the
interface status, or you can just ping the IP address(es) bound to that interface. 
Use loopback IP addresses on the routers for the host checks.

That is the best model for a multi-interface host anyway, IMHO.


> Thus spake Tedman Eng (teng at dataway.com) [16/09/03 22:53]:
>> It sort of depends on how the services are set up on the multi-homed host.
>>
>> Do the different interfaces have services specific to each interface?  (For
>> example, DHCP in one side, DNS on the other side).  If so I'd monitor each
>> interface as a separate host.
>>
>> Do you have to go through one interface to get to the other? (For example, a
>> box set up as a gateway, which Nagios is allowed to route through).  If so,
>> I'd set up the near interface as parent, and the far side interface as a
>> child.  This would mark the far side interface 'unreachable' if the near
>> interface goes down.
>
> For the most part, I'm talking about routers here.  Some of them are
> internal to our network, some of them have an interface on an external
> network.  The services they run will (for the most part) be the same on
> every interface -- a remote connection daemon (telnet, ssh), and a routing
> daemon.
>
> So it /is/ important to monitor every daemon on every interface (we need to
> know if peering with Company X goes down, but the rest of the box is up).
>
> I suppose to clarify, what I was trying to avoid is, with ten routers, three
> interfaces per router, that's thirty host objects.  There's no way to
> specify multiple IP addresses in a host object, is there?  Because
> technically they /are/ all the same machine; every interface runs the same
> service.  The only thing that's changed is the IP address of the interface.
> Having multiple IP's per host object would really un-clutter the visual
> display, but would probably be a PITA to get working properly, especially
> with dependancies.
>
> For hosts that provide different services on different interfaces, yes, I
> would easily consider each interface to be a separate host object.  Just not
> for one host that essentially would be duplicated n times.
>
>> Is the same service bound to multiple ports?  If so, monitoring one
>> interface should suffice, since you'll now that if the service itself dies,
>> it's likely dead for all the interfaces.
>
> Ah, but if the non-monitored /interface/ dies, we won't get an error.  If
> there's routing problems to an external interface, or if the card suddenly
> dies, or if the cable is unplugged, we'd need to know for that interface.
>
> Yes, I know, in this case we only really need to monitor connectivity to the
> interface, and not the individual services.  But that brings me back to the
> headache of having many, many more host objects than actual hosts.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting any
> issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
>


-- 
Mike McClure, CCIE # 5125, CISSP # 30232
PNE Services, Inc. -  http://www.pneservices.com
mmcclure [at] pneservices [dot] com
mobile: 913-636-5590



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list