Question of high availability for atlas via different ASNs
Hello, everyone! Greetings from India. I am hosting RIPE Atlas probe at home for a while. I have two connections - primary which is high capacity symmetric link and secondary which is a low-end cable broadband connection. The core router is Ubnt edge router and it runs "load balancing" to keep primary link as primary and switch to secondary if the primary is down for more than 30 seconds. This setup works well for me but RIPE Atlas is not part of this "auto switch" if the primary is down. I wonder if it makes sense to add RIPE Atlas to it? 1. It will improve my monthly availability report and possibly will move from 98% uptime (of primary) to 99.9% uptime (of both links) and that's actually real uptime on LAN. 2. But it would screw up probe data as both networks are completely different and have different sets of upstream resulting in different routing preference to root DNS instances etc. Also, does probe comes only if connectivity is switched? It's a non-BGP setup and when I say "auto switch" of uplinks, it's basically switching the default route from primary to secondary while keeping same private IP on LAN side. Due to NATing, WAN IP changes in this scenario. Curious to hear thoughts if I should or should not. Another way, of course, would be to do it for a month and see data. :) Thanks. -- Anurag Bhatia anuragbhatia.com
On 2017/07/20 19:55 , Anurag Bhatia wrote:
Greetings from India. I am hosting RIPE Atlas probe at home for a while. I have two connections - primary which is high capacity symmetric link and secondary which is a low-end cable broadband connection. The core router is Ubnt edge router and it runs "load balancing" to keep primary link as primary and switch to secondary if the primary is down for more than 30 seconds. This setup works well for me but RIPE Atlas is not part of this "auto switch" if the primary is down.
I wonder if it makes sense to add RIPE Atlas to it?
1. It will improve my monthly availability report and possibly will move from 98% uptime (of primary) to 99.9% uptime (of both links) and that's actually real uptime on LAN.
2. But it would screw up probe data as both networks are completely different and have different sets of upstream resulting in different routing preference to root DNS instances etc.
Hi Anurag,
From an operational point of view we don't care. I.e., if the probe measures what other hosts in your network would see, then that's fine. Even if it would be confusing.
If you want to know what the wider Atlas community thinks, then it would be best to ask on the main Atlas mailing list. Philip
Thanks for inputs Vaibhav and Philip @Philip - Can you share if probes come online and connect back to RIPE infra if WAN IP is changed within 30 seconds? Thanks. On Fri, Jul 21, 2017 at 2:52 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2017/07/20 19:55 , Anurag Bhatia wrote:
Greetings from India. I am hosting RIPE Atlas probe at home for a while. I have two connections - primary which is high capacity symmetric link and secondary which is a low-end cable broadband connection. The core router is Ubnt edge router and it runs "load balancing" to keep primary link as primary and switch to secondary if the primary is down for more than 30 seconds. This setup works well for me but RIPE Atlas is not part of this "auto switch" if the primary is down.
I wonder if it makes sense to add RIPE Atlas to it?
1. It will improve my monthly availability report and possibly will move from 98% uptime (of primary) to 99.9% uptime (of both links) and that's actually real uptime on LAN.
2. But it would screw up probe data as both networks are completely different and have different sets of upstream resulting in different routing preference to root DNS instances etc.
Hi Anurag,
From an operational point of view we don't care. I.e., if the probe measures what other hosts in your network would see, then that's fine. Even if it would be confusing.
If you want to know what the wider Atlas community thinks, then it would be best to ask on the main Atlas mailing list.
Philip
_______________________________________________ RIPE-Atlas-Ambassadors mailing list RIPE-Atlas-Ambassadors@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas-ambassadors
-- Anurag Bhatia anuragbhatia.com
On 2017/07/21 19:02 , Anurag Bhatia wrote:
@Philip - Can you share if probes come online and connect back to RIPE infra if WAN IP is changed within 30 seconds?
If the probe's IP address and default router do not change (due to NAT) then you can expect the probe to be connected again within 4 minutes: one minute to detect that the SSH connection no longer works and a maximum of 3 minutes extra before the probe tries to connect again.
I have one hosted at home, the ip address is using dhcp from providers, so it will changed everytime the lease is expired. I don't see any problem with this. As long as connected to the internet. Me as atlas users also doesn't care if it's changed everyday. Thank you Budiwijaya On Fri, Jul 21, 2017 at 12:55 AM, Anurag Bhatia <me@anuragbhatia.com> wrote:
Hello, everyone!
Greetings from India. I am hosting RIPE Atlas probe at home for a while. I have two connections - primary which is high capacity symmetric link and secondary which is a low-end cable broadband connection. The core router is Ubnt edge router and it runs "load balancing" to keep primary link as primary and switch to secondary if the primary is down for more than 30 seconds. This setup works well for me but RIPE Atlas is not part of this "auto switch" if the primary is down.
I wonder if it makes sense to add RIPE Atlas to it?
It will improve my monthly availability report and possibly will move from 98% uptime (of primary) to 99.9% uptime (of both links) and that's actually real uptime on LAN.
But it would screw up probe data as both networks are completely different and have different sets of upstream resulting in different routing preference to root DNS instances etc.
Also, does probe comes only if connectivity is switched? It's a non-BGP setup and when I say "auto switch" of uplinks, it's basically switching the default route from primary to secondary while keeping same private IP on LAN side. Due to NATing, WAN IP changes in this scenario.
Curious to hear thoughts if I should or should not. Another way, of course, would be to do it for a month and see data. :)
Thanks.
--
Anurag Bhatia anuragbhatia.com
_______________________________________________ RIPE-Atlas-Ambassadors mailing list RIPE-Atlas-Ambassadors@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas-ambassadors
On 20.07.17 19:55 , Anurag Bhatia wrote:
Hello, everyone!
Greetings from India. I am hosting RIPE Atlas probe at home for a while. I have two connections - primary which is high capacity symmetric link and secondary which is a low-end cable broadband connection. The core router is Ubnt edge router and it runs "load balancing" to keep primary link as primary and switch to secondary if the primary is down for more than 30 seconds. This setup works well for me but RIPE Atlas is not part of this "auto switch" if the primary is down.
I wonder if it makes sense to add RIPE Atlas to it? inclu 1. It will improve my monthly availability report and possibly will move from 98% uptime (of primary) to 99.9% uptime (of both links) and that's actually real uptime on LAN.
2. But it would screw up probe data as both networks are completely different and have different sets of upstream resulting in different routing preference to root DNS instances etc.
Also, does probe comes only if connectivity is switched? It's a non-BGP setup and when I say "auto switch" of uplinks, it's basically switching the default route from primary to secondary while keeping same private IP on LAN side. Due to NATing, WAN IP changes in this scenario.
Curious to hear thoughts if I should or should not. Another way, of course, would be to do it for a month and see data. :)
Thanks.
Anurag, I have exactly this set-up, also with an ubnt edge router. I have two probes connected #7 & #8: https://atlas.ripe.net/probes/7/ https://atlas.ripe.net/probes/8/ I route the probes explicitly to each uplink independently of which uplink gets used by most of the household. Personally I would suggest for you to choose one uplink and measure that like you are doing now. If you feel adventurous, get another probe and configure like I do. I would advise against measuring a combination of two uplinks. It will produce confusing data, especially if the uplinks are via two different ASes. Daniel
participants (4)
-
Anurag Bhatia -
Budiwijaya -
Daniel Karrenberg -
Philip Homburg