hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
--
Dr. Christian Herzog <herzog at phys.ethz.ch> support: +41 44 633 26 68
IT Services Group, HPT H 8 voice: +41 44 633 39 50
Department of Physics, ETH Zurich
8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Hi JC,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ ok I'll try to get this compiled (+1 for moving to git :)
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. I'll be back when I have results.
best, -Christian
Hi JC,
I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it.
in particular:
- do I need any compile switches to enable IPv6 support?
- how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all
- separate v6 hosts file ok, how to make it known then?
thanks, -Christian
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
--
Dr. Christian Herzog <herzog at phys.ethz.ch> support: +41 44 633 26 68
IT Services Group, HPT H 8 voice: +41 44 633 39 50
Department of Physics, ETH Zurich
8093 Zurich, Switzerland http://nic.phys.ethz.ch/
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way.
Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything.
Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system?
-jc
On 4/9/2019 12:12 AM, Christian Herzog wrote:
Hi JC,
I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it.
in particular:
- do I need any compile switches to enable IPv6 support?
- how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all
- separate v6 hosts file ok, how to make it known then?
thanks, -Christian
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Actually, this ended up being pretty broken as-is -- possibly a commit was lost. r8048 has the fix, or the attached patch should work too. Regular ping checks should work again.
https://sourceforge.net/p/xymon/code/8048/tree//branches/4.x-master/xymonnet...
HTH, -jc
On 4/9/2019 9:33 AM, Japheth Cleaver wrote:
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way.
Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything.
Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system?
-jc
On 4/9/2019 12:12 AM, Christian Herzog wrote:
Hi JC,
I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it.
in particular:
- do I need any compile switches to enable IPv6 support?
- how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all
- separate v6 hosts file ok, how to make it known then?
thanks, -Christian
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
ok I'll answer in reverse order...
- compiled and tested r8048
- same issue: conn is red for IPv6-only hosts
- fping: there wasn't any :) I now installed fping 4.2 (buster). no change.
- in xymonserver.cfg I have FPING="xymonping" - is that correct? seems to be the default
- xymonnet --debug log is here: https://people.phys.ethz.ch/~daduke/xymonnet-log
- most interesting line might be DNS lookup failed for ipv6.daduke.org - status DNS server returned answer with no data (1), but 'host ipv6.daduke.org' works and 3 lines later xymonnet says Adding tcp test IP=2a01:4f8:162:464::113
thanks, -Christian
On 4/9/19 6:33 PM, Japheth Cleaver wrote:
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way.
Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything.
Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system?
-jc
On 4/9/2019 12:12 AM, Christian Herzog wrote:
Hi JC,
I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it.
in particular:
- do I need any compile switches to enable IPv6 support?
- how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all
- separate v6 hosts file ok, how to make it known then?
thanks, -Christian
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- Dr. Christian Herzog <herzog at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
by setting
FPING="/usr/bin/fping"
I can make conn green for IPv6 only hosts at least most of the time, but http and ssh stay red ("https://ipv6.daduke.org/ - DNS error").
thanks, -Christian
FPING should be the path to fping (/usr/sibn/fping?) not xymonping.
-----Original Message----- From: Xymon <xymon-bounces at xymon.com> On Behalf Of Christian Herzog Sent: Thursday, April 11, 2019 3:46 AM To: xymon at xymon.com Subject: Re: [Xymon] IPv6 debugging on xymon 4.4 (was Re: Roadmap/GitHub?/IPv6)
ok I'll answer in reverse order...
- compiled and tested r8048
- same issue: conn is red for IPv6-only hosts
- fping: there wasn't any :) I now installed fping 4.2 (buster). no change.
- in xymonserver.cfg I have FPING="xymonping" - is that correct? seems to be the default
- xymonnet --debug log is here: https://people.phys.ethz.ch/~daduke/xymonnet-log
- most interesting line might be DNS lookup failed for ipv6.daduke.org - status DNS server returned answer with no data (1), but 'host ipv6.daduke.org' works and 3 lines later xymonnet says Adding tcp test IP=2a01:4f8:162:464::113
thanks, -Christian
On 4/9/19 6:33 PM, Japheth Cleaver wrote:
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way.
Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything.
Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system?
-jc
On 4/9/2019 12:12 AM, Christian Herzog wrote:
Hi JC,
I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it.
in particular:
- do I need any compile switches to enable IPv6 support?
- how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all
- separate v6 hosts file ok, how to make it known then?
thanks, -Christian
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- Dr. Christian Herzog <herzog at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
FPING should be the path to fping (/usr/sibn/fping?) not xymonping.
you're right. The frankensteined Debian package I built for 4.4 alpha didn't set that correctly. I now compared all config values to our production setup, but FPING was the only notable difference.
Anyway, the status is the same as yesterday: for a v6 only host, conn is now green, but http and ssh stay red (DNS error)
current xymonnet debug log: https://people.phys.ethz.ch/~daduke/xymonnet-log
@JC: how can I debug this further? What other (IPv6 related) test would be interesting for you?
thanks,
-Christian
-----Original Message----- From: Xymon <xymon-bounces at xymon.com> On Behalf Of Christian Herzog Sent: Thursday, April 11, 2019 3:46 AM To: xymon at xymon.com Subject: Re: [Xymon] IPv6 debugging on xymon 4.4 (was Re: Roadmap/GitHub?/IPv6)
ok I'll answer in reverse order...
- compiled and tested r8048
- same issue: conn is red for IPv6-only hosts
- fping: there wasn't any :) I now installed fping 4.2 (buster). no change.
- in xymonserver.cfg I have FPING="xymonping" - is that correct? seems to be the default
- xymonnet --debug log is here: https://people.phys.ethz.ch/~daduke/xymonnet-log
- most interesting line might be DNS lookup failed for ipv6.daduke.org - status DNS server returned answer with no data (1), but 'host ipv6.daduke.org' works and 3 lines later xymonnet says Adding tcp test IP=2a01:4f8:162:464::113
thanks, -Christian
On 4/9/19 6:33 PM, Japheth Cleaver wrote:
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way.
Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything.
Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system?
-jc
On 4/9/2019 12:12 AM, Christian Herzog wrote:
Hi JC,
I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it.
in particular:
- do I need any compile switches to enable IPv6 support?
- how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all
- separate v6 hosts file ok, how to make it known then?
thanks, -Christian
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:
Hi Christian,
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
Regards, -jc
On 4/5/2019 4:47 AM, Christian Herzog wrote:
hey JC,
thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise?
thanks and best regards, -Christian
[1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote:
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point - athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there - along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
-- Dr. Christian Herzog <herzog at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-- Dr. Christian Herzog <herzog at phys.ethz.ch> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
On 4/11/2019 11:07 PM, Christian Herzog wrote:
FPING should be the path to fping (/usr/sibn/fping?) not xymonping. you're right. The frankensteined Debian package I built for 4.4 alpha didn't set that correctly. I now compared all config values to our production setup, but FPING was the only notable difference.
I think it might be worth it to officially retire xymonping in the 4.x branch, as it'll need to be updated for IPv6 as well and fping development seems to be healthy and reliable on platforms. Or at the very least, gate it for IPv6 building in the short term.
Anyway, the status is the same as yesterday: for a v6 only host, conn is now green, but http and ssh stay red (DNS error)
current xymonnet debug log: https://people.phys.ethz.ch/~daduke/xymonnet-log
@JC: how can I debug this further? What other (IPv6 related) test would be interesting for you?
Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're not building NET6 connections at all in xymonnet tests, which means there's more connecting work left to do than expected. I'm not sure if the original plan was to migrate to xymonnet2 before IPv6. The factored-out connectivity routines in lib/tcplib.c are being used for IPv6 connectivity in sending *messages* back and forth between xymon servers and clients, but not for network testing.
For the short term, testing xymonclient messaging and xymond record management (using conn tests as sources) might be the most useful. xymonnet/TCP polling will take some additional patching.
Regards,
-jc
Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're not building NET6 connections at all in xymonnet tests, which means there's more connecting work left to do than expected. I'm not sure if the original plan was to migrate to xymonnet2 before IPv6. The factored-out connectivity I guess it was. Rereading my correspondence with Henrik from 6 years ago, it seems we had it pretty much working using xymonnet2 at that time: https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support (see my last message in that thread). I have no idea what has happened in the xymon source tree during those 6 years, and of course I don't have that config any more, but if we could reproduce those results we might be one step closer.
For the short term, testing xymonclient messaging meaning client reports to IPv6 XYMONSERVERS?
and xymond record management (using conn tests as sources) might be the most useful. meaning what exactly?
I'll go right ahead with those tests and stand by for any xymonnet2 trials you might come up with.
cheers, -Christian
On 4/14/2019 11:53 PM, Christian Herzog wrote:
Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're not building NET6 connections at all in xymonnet tests, which means there's more connecting work left to do than expected. I'm not sure if the original plan was to migrate to xymonnet2 before IPv6. The factored-out connectivity I guess it was. Rereading my correspondence with Henrik from 6 years ago, it seems we had it pretty much working using xymonnet2 at that time: https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support (see my last message in that thread). I have no idea what has happened in the xymon source tree during those 6 years, and of course I don't have that config any more, but if we could reproduce those results we might be one step closer.
Agreed. I'm a bit torn at the xymonnet v xymonnet2 split here, simply due to how some of the code diverges at this point. I suspect adding IPv6 branching into xymonnet will be easier (or at least easier to validate).
For the short term, testing xymonclient messaging meaning client reports to IPv6 XYMONSERVERS? and xymond record management (using conn tests as sources) might be the most useful. meaning what exactly?
Correct. xymonproxy is another component that will need work, but client->xymond and anything at all (xymonnet/xymongen, etc) talking to an IPv6-only xymond would be very helpful. xymongen needs to download full xymondboard copies from xymond, so it's really about catching any assumptions out there on IP size or host lookups.
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
I'll go right ahead with those tests and stand by for any xymonnet2 trials you might come up with.
Thanks! I'll be focusing on 4.3.29 this week, so this will definitely help.
-jc
Agreed. I'm a bit torn at the xymonnet v xymonnet2 split here, simply due to how some of the code diverges at this point. I suspect adding IPv6 branching into xymonnet will be easier (or at least easier to validate). this decision is way above my paygrade :) But we (the xymon community) need to do something since IPv6 is coming, and fast.
and xymond record management (using conn tests as sources) might be the most useful. meaning what exactly? Correct. xymonproxy is another component that will need work, but client->xymond and anything at all (xymonnet/xymongen, etc) talking to an IPv6-only xymond would be very helpful. xymongen needs to download full xymondboard copies from xymond, so it's really about catching any assumptions out there on IP size or host lookups. can you be more specific about what you would like to have tested?
what I can say already:
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.
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*
[1] https://algo.ing.unimo.it/people/paolo/disk_sched/
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....
thanks, -Christian
for reference, I compiled xymon-4.3.99-20130812.tar.gz from https://www.xymon.com/misc/ (the source I had been testing with 6 years ago) and lo and behold, IPv6 only hosts work fine!
I have no idea what the difference between this old tgz and current trunk is, but at least in terms of IPv6 there seems to be a regression.
HTH, -Christian
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.
On 4/17/2019 6:24 AM, Christian Herzog wrote:
for reference, I compiled xymon-4.3.99-20130812.tar.gz from https://www.xymon.com/misc/ (the source I had been testing with 6 years ago) and lo and behold, IPv6 only hosts work fine!
I have no idea what the difference between this old tgz and current trunk is, but at least in terms of IPv6 there seems to be a regression.
HTH, -Christian
Thanks. That tarball does indeed use xymonnet2 rather than the existing one, which does help clear that up a bit.
Do you think you might be able to test a snapshot of https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk ? That would help isolate issues against the latest in that tree.
And for either of these releases, it might be helpful to test xymonnet2 as a poller speaking to a 4.x copy of xymond. In theory, they should be compatible enough to interoperate.
-jc
- Task xymond terminated by signal 6
- Whoops ! Failed to send message (Connection failed)
- Cannot load hosts.cfg from xymond, code 5
- Failed to load from xymond, reverting to file-load
- Failed to get a message, terminating etc
And for either of these releases, it might be helpful to test xymonnet2 as a poller speaking to a 4.x copy of xymond. In theory, they should be compatible enough to interoperate. the point here is that only the 2013 tarball and r8050 have xymonnet2, while r8048 does not. In 2013 it seems to be working fine, in r8050 it's not (see above).
Do you think you might be able to test a snapshot of https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk ? That would help isolate issues against the latest in that tree. I had all sorts of problems getting this compiled, and it's not running well either: conn/ping is missing, most hosts don't show any tests and I get multiple errors in the logs:
-d
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.ba...
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.
Regards, -jc
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.ba...
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/t... https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...
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
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.ba...
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/t... https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...
Hopefully, one day, it will happen though.
Regards, Adam
Sorry, the "backfeed queue" :)
See README.backfeed: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.ba...
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 see.
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 I agree with Adam and even think IPv4 Mandatory/IPv6 Mandatory would be the default in our case.
I'll be ready to perform more tests after the Easter break.
cheers, -d
participants (6)
-
adam＠websitemanagers.com.au
-
cleaver＠terabithia.org
-
daduke＠phys.ethz.ch
-
herzog＠phys.ethz.ch
-
mailinglists＠websitemanagers.com.au
-
Paul.Root＠CenturyLink.com