Comment by jiggawatts | Hacker News Reader

Comment by jiggawatts | Hacker News Reader

Parent Full thread

We should do the right thing even if other people do the wrong thing.

Traffic signs shouldn't be taken down just because some people speed regardless of the posted speed limit.

Fundamentally however, giving clients control over when failover occurs means giving up control over failover.

Literally just a couple of hours ago, I was patiently explaining this to some Azure techs from Microsoft.

The conversation went like this:

> "Just use Traffic Manager for active-passive fail over!" they piped up, helpfully trying to solve my problem.

> "Client software often ignores DNS changes."

> "We designed Azure so that Traffic Manager does failover and load balancers are always active-active."

> "That's nice, but client software ignores DNS changes."

> "Umm..."

Fundamentally, the DNS protocol is just too old and crusty for the modern Internet, much like SMTP and FTP. It's best avoided to the extent possible.

The big providers seem to be converging on Anycast IP routing, where a single address can be routed to multiple data centres dynamically. You're all probably familiar with 8.8.8.8 and 1.1.1.1, both of which are Anycast IPs, but anyone can create a global static IP like that in minutes via a service such as Azure's Cross-region load balancer: https://learn.microsoft.com/en-us/azure/load-balancer/cross-...

> Fundamentally however, giving clients control over when failover occurs means giving up control over failover.

Fundamentally the problem is that you want to direct a client to particular datacenter and it is not always shortest part (shortest != lowest latency) so anycast DNS isn't helping here.

There is reason biggest CDNs use it to direct to particular DC instead of " just anycasting everything" like you're proposing, it's suboptimal.

> You're all probably familiar with 8.8.8.8 and 1.1.1.1,

And both companies behind that still direct you to particular datacenter, not anycasted IP, for the actual content.

Anycast IP are also "expensive", you need to use entire /24 route to get one, and it takes routing table space in every router's memory that is limited, and requires costly replacement if it runs out everywhere, not just where you distribute it.

Aren’t routing tables also cached (not by clients, but by ISPs)? What is their typical TTL?

It varies; for direct peering/connections where a link goes down (and fast failover protocol is used), usually 5 seconds or so. Global propagation takes in the order of 5 minutes or less: https://labs.ripe.net/author/vastur/the-shape-of-a-bgp-updat...

They aren't really cached. Routes are kept in the routing table as long as peers are responsive, if they stop responding to hello's or a link goes down to directly connected peer the routes are removed (or replaced with a less preferred one). While its possible to configure a router to keep routes in the table for a peer that is down for some time its typically not used unless you have a good reason for it.

They are added and withdrawn on demand, or dropped all at once if router loses connectivity with another.

So really it's processing time of every node in the chain. Few seconds to few minutes, not really that different from DNS.

The advantage is that there is no updates if there is no changes, instead of update every time TTL expires but that's about it.

routing tables usually aren't "cached" in the same sense that DNS caches entries.

however. Inside ISP;s routes are usually distributed by an IBGP with a couple of route reflectors, and route reflectors will drop routes if no router within the IBGP domain is advertising the route.

Routes between ISP's are usually fairly static thanks to mechanisms like graceful restart, which makes sure routes do not get dropped, even if BGP has a restart between routers. THere are various other mechanism in which to achieve this. (look up route flap dampening if you want to learn more).

Reply on news.ycombinator.com