[Xymon] IPv6 debugging on xymon 4.4 (was Re: Roadmap/GitHub?/IPv6)

[Adam Goryachev]

On 18/4/19 06:45, Japheth Cleaver wrote:
> On 4/15/2019 11:28 PM, Christian Herzog wrote:
>> For the short term, testing xymonclient messaging
>>>> meaning client reports to IPv6 XYMONSERVERS?
>> specifying IPv6 XYMONSERVERS on the client doesn't work. No reports 
>> coming in.
>
> Thanks.
>
>> also, any hosts.cfg entry seems to get resolved to IPv4 only, even if 
>> the host
>> entry is IPv6. As soon as I cut IPv4 connectivity on a dual stack 
>> host, conn
>> turns red even if IPv6 is working fine. Probably xymonnet <-> 
>> xymonnet2 again.
>>
>>
>>> Would be good to disable BFQ too if it's enabled, since local 
>>> components
>>> will short-circuit to using that for message submission instead of 
>>> TCP in
>>> 4.x
>> this [1] BFQ? *confused*
>
> Sorry, the "backfeed queue" :)
>
> See README.backfeed: 
> https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.backfeed
>
> The short of it is that it provides an alternate way of submitting 
> messages to xymond for local processes, using SysV-IPC instead of 
> localhost TCP connections. It's much more efficient for injecting lots 
> of messages, but sort of obviates the testing of xymond submissions 
> over IPv6 :)
>
>
>> I've also been thinking about how I would like xymon to behave on 
>> dual stack
>> hosts: in my experience, IPv4 networks are still quite a bit more 
>> stable than
>> IPv6 (I've seen sporadic PD issues, sudden IPv6 routing problems in 
>> the middle
>> of Europe etc), so ideally we would have v4/v6 tests on supported 
>> services on
>> dual stack hosts. I don't know if this means splitting each tests 
>> into two
>> halves or duplicate the whole host entry or something else entirely, 
>> but we
>> need to be able to deal with "v4 is working but v6 isn't" or vice 
>> versa....
>
> Looking into this more, I believe we'll be able to use the existing 
> "conn" framework for handling multiple IP addresses, but we may need a 
> default set of flags for how to handle priority and fallbacks on DNS 
> lookup.
>
> I'd envision something along the lines of:
> IPv4 Only
> IPv4 Mandatory/IPv6 Optional
> IPv4 Optional/IPv6 Mandatory
> IPv6 Only
>
> xymonnet can have a set of flags, but this we'd also want the ability 
> to set flags for for each host.
>
> For non-http checks, a "testip" combined with the choice of dedicated 
> address (of either type) in hosts.cfg should keep checks hitting only 
> one protocol or the other.
>
Sorry, I'm not able to help much since my routers are still all non-IPv6 
capable, but wouldn't we also want:

IPv4 Mandatory/IPv6 Mandatory

In the case that you are operating as a dual stack, you care if v4 only 
users are unable to access your host, as well as if v6 only users are 
unable to access?

Similarly for testip hosts, we should be able to specify both v4 and v6 
address, perhaps the hostname/IP field in the hosts file could be 
extended to allow a comma separated list of addresses ?

As for testing v4 and v6 conn test (or other network tests), why not 
just combine them in the same way the http test can have multiple 
results under the same status or the ssl test gets multiple results from 
https + imaps + pop3s etc all in the same status?

I have tried a few times to get into IPv6, but each time, it's been a no 
go due to some specific issues (either providers not supporting it, my 
not knowing enough about it, or currently, Cisco routers not supporting it:
https://community.meraki.com/t5/Security-SD-WAN/WE-Need-IPV6-Support-in-MX/td-p/1095
https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility

Hopefully, one day, it will happen though.

Regards,
Adam

-- 
Adam Goryachev
Website Managers
P: +61 2 8304 0000                    adam at websitemanagers.com.au
F: +61 2 8304 0001                     www.websitemanagers.com.au