Global elastic IPs – multi-region routing

By David Mytton,
CEO & Founder of Server Density.

Published on the 26th July, 2012.

On Jul 24 we received an e-mail from our hosting provider, Softlayer, announcing the availability of a new feature called “Global IP Addresses”. I’m surprised that Softlayer haven’t made more noise about this feature because it’s looking to prove incredibly useful, and is something that even the likes of Amazon don’t provide.

Elastic IPs are a feature of Amazon EC2 which provide region level static IPs which can be rerouted to any instance at any time. This means if one instance goes down, you can repoint them to another instance with minimal downtime – no waiting for DNS updates or replacement instances to come up. However, they are limited to a specific AWS region. They cross availability zones but if a whole region goes down, you can’t point the IP to instances in another region.

This level of failover still has to be handled with DNS with a low TTL where you would update the IPs in the zone when there is an outage. However, this relies on ISPs honouring the TTL. There are reports (source 1, source 2) of TTL being ignored, which means some users may still try to access your old, down IP. This can be mitigated by using round robin DNS but there’s still the possibility of hitting the old IP.

Softlayer’s global IP address option allows you to work around this. For $20/m per IP, you have an IP address which can be routed to any cloud or dedicated instance within the Softlayer network, which includes all their data centres (Dallas, Seattle, Washington, Houston, San Jose, Amsterdam and Singapore). So in the event of a local failure of your server (which might be a load balancer), you can re-route the IP within a single DC. And if the whole DC goes down, you can re-route to a completely different DC.

On a network level this works by routing the traffic for the IP to the user’s closest Softlayer presence which forwards it to the allocated data centre. For example, the IP address provided in their documentation – – is allocated to a node in their Dallas data centre. From one of our AWS nodes in US East, it enters at Washington and hits Dallas via Atlanta:

[sourcecode gutter=”false”]traceroute to (, 30 hops max, 60 byte packets

3 ( 0.497 ms ( 0.602 ms ( 0.744 ms
4 ( 21.862 ms 21.835 ms 21.839 ms
5 ( 0.876 ms ( 0.690 ms 0.972 ms
6 ( 1.838 ms 1.382 ms 1.368 ms
7 ( 2.026 ms 17.269 ms 1.722 ms
8 ( 1.695 ms 2.184 ms 4.305 ms
9 ( 17.115 ms 17.098 ms 17.540 ms
10 ( 14.465 ms 14.445 ms 14.448 ms
11 ( 35.344 ms 36.102 ms 35.154 ms
12 ( 35.143 ms 35.661 ms 34.963 ms
13 ( 34.394 ms ( 35.931 ms 35.928 ms
14 * * *
15 ( 36.230 ms 36.216 ms 36.387 ms[/sourcecode]

And from US West, it goes through San Jose, Los Angeles and then Dallas:

[sourcecode gutter=”false”]traceroute to (, 30 hops max, 60 byte packets

3 ( 0.730 ms ( 0.725 ms ( 4.761 ms
4 ( 4.744 ms 4.738 ms ( 2.070 ms
5 ( 2.299 ms 2.037 ms 2.275 ms
6 ( 9.212 ms ( 1.989 ms ( 5.768 ms
7 ( 2.825 ms 2.803 ms ( 3.223 ms
8 ( 11.286 ms 11.280 ms ( 3.199 ms
9 ( 11.762 ms ( 11.243 ms 10.697 ms
10 ( 80.711 ms ( 11.713 ms 11.235 ms
11 ( 78.446 ms ( 78.208 ms ( 80.954 ms
12 ( 78.568 ms 78.570 ms ( 80.660 ms
13 ( 80.899 ms * ( 77.595 ms[/sourcecode]

We will be testing this new functionality over the next few weeks and will report back any interesting findings.

  • How has this worked out in practice? I remember reading their were many pitfalls of this and to avoid using for anything other than DNS, although I’ve lost the link (typical).. You make a point about providers not respecting DNS TTL, which I’ve certainly observed before, but presuming a global IP works on providers using your latest advertised routes, what if they tweak the route for optimal performance? (i.e. when you call up your provider and say hey this is going from NY to Washington via LA wtf? and they say ah I see and pin the route over a more suitable transit provider)

    • We’ve been using this for over a month now and it’s working well. We’ve rerouted the IP several times for maintenance and we regularly test the automated failover of the load balancer too. Routing always happens within a few seconds and we don’t see any loss of traffic. So everything is working nicely. The big test will be when our primary data centre fails and we have to reroute to another DC. We have tested this with no issues but it’s always difficult to replicate that kind of failure (source of the failure, load on their management systems, etc).

  • Matrix AI

    Global anycast IPs could do the same thing, but this doesn’t use anycast. It relies on Softlayer’s routing tables to point packets going to the global IP to a specific IP. It’s pretty ingenous! This should mean that I should be able to “rent” a global IP from softlayer, and point it to say an AWS EC2 instance or anything really.

  • Mike Jansen

    How is this working 4 years later? Not knowing the network routing infrastructure that well, is there still a single point of failure where the global IP address is being routed to the specific IP address? Or are those tables replicated for failover? Meaning if the infrastructure controlling the routing of the global IP address fails at a single point, are there other nodes that kick in to do the routing?

    We use Amazon and I’m currently re-visiting cross-region redundancy. I looked into cross-region elastic IP addresses a couple years ago with no luck.

    • We still use this and there is still a single point of failure if there’s a complete network outage. We’ve seen that happen once but generally the system works well for localised and even data centre level failures where the network is still responsive.

      We’re in the process of moving to Google Cloud though and will be looking at their global load balancers. Unfortunately they still have a single point of failure in that the GLB service itself could go down, but it’s supposed to be designed not to (we have seen failures there too in recent years)

Articles you care about. Delivered.

Help us speak your language. What is your primary tech stack?

Maybe another time