IPv6 support

[Michael Friedrich]

-------- Original Message  --------
Subject: Re: [Nagios-users] IPv6 support
From: Andreas Ericsson <ae at op5.se>
To: Nagios Users List <nagios-users at lists.sourceforge.net>
Date: 2011-06-09 18:19
> Why? If the host is reachable via ip6, it's reachable via ip6 and
> that's what you configure. If it's not, you configure ip4 instead.

if you happen to have dualstacked setups in various places, not 
specifically host monitoring, but dependant on the host itsself to 
support the dual stacked way. In my environment, I need a lot of 
diversification between v4 and v6 so it's one of those possible things 
to make the core being aware of the both attributes as well as both 
macros as well as the gui to show and reflect that.

either single checks on each route, or combined and conditional.

> Besides; the kernel automagically translates ip4 addresses to ip6
> ones on ip6 only interfaces, and does the same for ip6 addresses
> on ip4-only ones. It's mentioned in the spec that the protected
> segments for internal use will remain protected in ip6 as well.
> If they weren't, migrating from one to the other would be complete
> hell and damn near impossible without superhuman effort.

it's nice that the kernel does that on the monitoring box (or respective 
where the worker executing the check resides), but as said, when it 
comes to dual stacking, you'll need both addresses. or you'll let your 
nameservers do the trick (or a local resolver), then you wouldn't need 
any forward/reverse translations fixed static by some host attributes. 
but that adds another dependency not always possible/needed/wanted.

> I remain unimpressed. A far cleverer solution would be to have a
> single check run against all non-protected addresses and let that
> plugin look up the ip6 address for the host somewhere else (or
> through a custom variable fetched via livestatus or something, which
> doesn't break the ABI), and then simply report back if any of them
> stop working.

It's not the point what's clever and what might be non-clever. it's all 
about timing constraints and accepting work already done, not having the 
issues to resolve the problem with the well-known workaround trick. sure 
nagios/icinga remains playing lego with the various addons and plugins, 
but as a matter of fact i prefer having it all upstream and available 
throughout the core, and not injected with or by anything else. 
livestatus isn't an option either way, but that's offtopic.

> If this patch had been accompanied by something to make conditional
> macros and command_line arguments work, I'd have cheered all the way
> though.

I don't really get it what you mean - can you explain that a bit more?

kind regards,
Michael

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email: 	michael.friedrich at univie.ac.at
phone: 	+43 1 4277 14359
mobile: +43 664 60277 14359
fax: 	+43 1 4277 14338
web:	http://www.univie.ac.at/zid
	http://www.aco.net

Icinga Core&  IDOUtils Developer
http://www.icinga.org


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
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