- ripe-atlas - mailman.ripe.net

Re: [atlas] Email or SMS alert when probe goes offline/online
by Daniel AJ Sokolov 07 Sep '11

07 Sep '11

On 07.09.2011 00:53 wrote Robert: > What do other participants think about having email alerts when a probe > goes offline or online? I generally like the idea. There should be a threshold though - for example the e-mail could be triggered once the probe is offline for 5 minutes. BR Daniel AJ

1 0

Email or SMS alert when probe goes offline/online
by Robert 07 Sep '11

07 Sep '11

What do other participants think about having email alerts when a probe goes offline or online? I'd like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. This means that the alert could serve a dual purpose: . Increased network uptime . Greater availability of the RIPE Atlas Probe (and thus increased data gathering). Anyway, this is something that I'd like to see - email alerts at a minimum. Robert

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Richard L. Barnes 07 Sep '11

07 Sep '11

This might not actually be desirable until the probes stop crashing so often :) It might be more useful to have alarms that trigger on things like sudden or sustained increases in latency or loss, configurable by the probe host. --Richard On Sep 6, 2011, at 10:35 PM, Robert wrote: > What do other participants think about having email alerts when a probe goes offline or online? > > I’d like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. > > This means that the alert could serve a dual purpose: > > · Increased network uptime > · Greater availability of the RIPE Atlas Probe (and thus increased data gathering). > > Anyway, this is something that I’d like to see – email alerts at a minimum. > > > Robert >

1 0

Email or SMS alert when probe goes offline/online
by Robert 07 Sep '11

07 Sep '11

What do other participants think about having email alerts when a probe goes offline or online? I'd like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. This means that the alert could serve a dual purpose: . Increased network uptime . Greater availability of the RIPE Atlas Probe (and thus increased data gathering). Anyway, this is something that I'd like to see - email alerts at a minimum. Robert

1 0

[atlas]Apache again....
by Viktor Naoumov 30 Aug '11

30 Aug '11

Back to apache... 'Listen 8080' was a bad solution because it opens apache to the world. Instead we should do now: Listen 127.0.0.1:8080 #Listen localhost:8080 Having Listen localhost:8080 <VirtualHost *:8080> prevents apache from starting with the following message: zelenka-dev:/etc/apache2# /etc/init.d/apache2 restart Restarting web server: apache2 ... waiting (98)Address already in use: make_sock: could not bind to address 127.0.0.1:8080 no listening sockets available, shutting down Unable to open logs Action 'start' failed. The Apache error log may have more information. failed! looks like it because zelenka-dev:/etc/apache2# host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 but not sure yet.... didn't have time to figure out what do you think? /vty

1 0

[atlas]UI for "My Probes" in IE7 broken (again)?
by Wilfried Woeber, UniVie/ACOnet 11 Jul '11

11 Jul '11

It looks like th UI for the "My Probes" section is broken again for IE7. All the other sections of the site seem to work. Wilfried.

2 2

[atlas]Probe with static IPv6 can 'lock up' if unreachable on IPv6
by Kenneth Aalberg 11 Jul '11

11 Jul '11

Greetings. As advised by other members of the list, I've moved my probe from behind a router that provided IPv6 tunneling and to the pure IPv4 network. However, when reconfiguring the probe, the static IPv6 address I added to it seems to not 'let go'. It now gets an IPv4 address as it should, but it shows as down in the probe list. The configuration page also claims it still has the static IPv6 address configured. I mentioned earlier about fallback to IPv4, but I'd also like to extend the question towards whether there is any functionality that lets the probe try 'last ditch efforts' to connect in cases where its configuration just doesn't work? (As in, give up on static addresses and try DHCP even if it has been assigned a static address) Best regards, Kenneth Aalberg

1 0

[atlas]Falling back to IPv4 if IPv6 connectivity is lost?
by Kenneth Aalberg 11 Jul '11

11 Jul '11

Greetings, Probers. (Yes, that was the first name that came to mind. :P ) I've joined the probecloud, and it is working fine. However, I am on an IPv6 tunnel behind a NAT that doesn't let me configure protocol 41 to be forwarded to one specific host (my linux router). Thus, the AYIYA tunnel is in a NAT table as a normal connection, and will sometimes be cycled out if it is the oldest connection and a new one is attempted, regardless of whether the NAT entry has seen traffic recently or not. The probe receives an IPv6 address, and uses this correctly. However, if the tunnel should go down, the probe will also be marked as down, even if it is actually still alive and can communicate through IPv4. Is there any kind of fallback option to try IPv4 connections before declaring a probe host down? Or would it make more sense for me to disable IPv6 on the probe to ensure it accurately represents the actual state of my connectivity? Best regards, Kenneth Aalberg Probe 737.

3 4

[atlas]Probe rebooting every minute
by Roman Mamedov 09 Jul '11

09 Jul '11

Hello, Probe ID 73, it seems to reboot itself after about 1-2 minutes of operation, even though according to tcpdump on the gateway it can successfully communicate with the control DNS, NTP, server, can ping stuff and does receive ping replies. What could be the problem? -- With respect, Roman

1 0

[atlas]'Location' sorting for the Public Probes
by Carsten Schiefner 04 Jul '11

04 Jul '11

Hi there, not sure sure whether that's been raised already - but the strictly alphabetical ordering of the probes when 'Location' sorting is activated, doesn't make any reals sense to me; cf. the attached screen shot. Maybe a somewhat greater "intelligence" could be deployed here? I'd suggest the DNS approach: from right to left. :-) Cheers, Carsten -- Homer Simpson meint: http://www.youtube.com/watch?v=Fk0To_o6NxE

2 1