-------- Original Message -------- Subject: Re: [Nagios-users] IPv6 support From: Andreas Ericsson <a...@op5.se> To: Nagios Users List <nagios-users@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.friedr...@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@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