Welcome to India Contabo!
Since the first week of June 2024 - Contabo has started in Mumbai, India. I have been their user in Germany for a very long time. Indian market is growing in all aspects - from large datacenter buildouts to global cloud players coming in and adding more locations.
Analysing routing
I got a VM on Contabo in Mumbai - server03.bom.anuragbhatia.com (82.180.146.82 and 2400:d321:2191:8556::1)
82.180.146.82 is coming from 82.180.146.0/24 BGP announcement from AS141995 - Contabo Asia. This ASN also seems to be in use in their other Asian locations thus I have to look for specific prefix upstreams instead of just the ASN adjacencies.
Quick look via Oregon route-views:
route-views>sh ip bgp 82.180.146.0/24 long
BGP table version is 224174065, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
V* 82.180.146.0/24 217.192.89.50 0 3303 6453 4755 17439 141995 ?
V* 91.218.184.60 0 49788 12552 9498 141995 141995 141995 ?
V* 37.139.139.17 0 0 57866 6453 4755 17439 141995 i
V* 94.142.247.3 0 0 8283 6453 4755 17439 141995 ?
V* 12.0.1.63 0 7018 6453 4755 17439 141995 ?
V* 208.51.134.254 0 0 3549 3356 64049 55836 17439 141995 i
V* 77.39.192.30 0 20912 57463 9498 141995 141995 141995 ?
V* 140.192.8.16 0 20130 6939 6453 4755 17439 141995 i
V* 193.0.0.56 0 3333 64049 55836 17439 141995 ?
V* 64.71.137.241 0 6939 6453 4755 17439 141995 i
V* 114.31.199.16 0 4826 9498 141995 141995 141995 i
V* 209.124.176.223 0 101 11164 6461 9498 141995 141995 141995 ?
V* 132.198.255.253 0 1351 64049 55836 17439 141995 ?
V* 154.11.12.212 0 0 852 6461 9498 141995 141995 141995 i
V*> 4.68.4.46 0 0 3356 64049 55836 17439 141995 i
V* 202.232.0.2 0 2497 6453 4755 17439 141995 ?
V* 162.250.137.254 0 4901 6079 4637 9498 141995 141995 141995 ?
V* 206.24.210.80 0 3561 209 3356 64049 55836 17439 141995 i
V* 203.181.248.195 0 7660 2516 6453 4755 17439 141995 ?
V* 89.149.178.10 10 0 3257 9498 141995 141995 141995 ?
route-views>
This shows the route being announced to NTT Netmagic AS17439 and Airtel AS9498. Since NTT Netmagic is mostly a datacenter network, its adjacencies are more interesting. NTT Netmagic AS17439 seems to be announcing it to Tata Comm AS4755 and Jio AS55836. This seems like a good mix as Contabo is directly connected to Airtel (a large Indian eyeball network) and Jio (via AS17439).
I have been looking at various latency metrics from Contabo Mumbai for some time and so far it seems great. I don’t see over 50ms with any endpoint across India which I am measuring and a couple of ms when I measure against endpoints within Mumbai.
Contabo - Airtel Mumbai
Contabo Mumbai VM latency check against Airtel Mumbai Ookla Speedtest node
Contabo - Jio Mumbai
Contabo - VI Mumbai
This confirms quite good latency to the majority of networks. As I have stated in past on different posts, broadly entire Indian routing table is downstream of Airtel, Tata Comm, Jio, Sify, BSNL, VI and a bit of Telstra. Out of these Jio, Airtel and Tata Comm are large networks. Contabo seems to be downstream of all these three and hence should have pretty good routing to most of the eyeballs. What they lack as of now is presence at local IXPs. I do not see any route towards any network via an IX + their peeringdb record also doesn’t list any Indian IXPs. I hear they are in the process of connecting to them.
How do I measure?
Wondering how I measure latency from many sources to large number of endpoints? Checkout my blog post about it here or my talk at Hong Kong NOG about it here.
Bandwidth caps and IPv6
The other interesting part is the bandwidth. Contabo globally has a bit different bandwidth pricing compared to its competitors. Most of their competitors would offer a few Gbps worth of bandwidth bursts but would meter overall bandwidth at low values like 2TB-6TB, especially on the lower/starting plans. Contabo on the other hand limits bandwidth bursts to 200Mbps, 400Mbps etc but allows 32TB a month. This makes it easy to pull more data without worrying about hitting caps.
My test VM is Cloud VPS 2 which is capped at 400Mbps.
Some speedtests:
Airtel AS9498 - Mumbai - Test link
Blazenet AS17625 - Mumbai - Test link
Airtel AS9498 - Gurgaon - Test link
On IPv6 part Contabo is great. One major drawback of many Cloud players has been poor IPv6 support. Many of them who support it either give a few of them per VM or some give a /64 but non-routed one. This makes it impossible to make use of massive address space on containers inside without going for ulgy practices of proxy NDP. It unnecessarily extends layer 2 from Containers all the way to the host or makes it easy to cause an outage due to large NDP table size.
Here’s a quick test to see whether Contabo’s IPv6 is routed or not in Mumbai:
anurag@server03 ~> ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 82.180.146.82 netmask 255.255.252.0 broadcast 82.180.147.255
inet6 fe80::250:56ff:fe52:9c5e prefixlen 64 scopeid 0x20<link>
inet6 2400:d321:2191:8556::1 prefixlen 64 scopeid 0x0<global>
ether 00:50:56:52:9c:5e txqueuelen 1000 (Ethernet)
RX packets 186320999 bytes 208878516999 (208.8 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 196242120 bytes 155385549815 (155.3 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
anurag@server03 ~>
This shows /64 on the interface. Let’s put any random IPv6 out of this /64 on the loopback and verify if it’s reachable from outside:
In my netplan config:
lo:
addresses:
- 127.0.0.1/8
- 2400:d321:2191:8556:a:b:c:d/128
And now mtr from my other server in Mumbai
anurag@host01 ~> mtr 2400:d321:2191:8556:a:b:c:d -wrc 10
Start: 2024-07-03T10:00:04+0530
HOST: host01.bom.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1.|-- ctpl-demarc.bom.anuragbhatia.com 0.0% 10 0.9 0.9 0.7 1.5 0.2
2.|-- 2401:7500:fff6::25 0.0% 10 0.8 10.5 0.8 95.9 30.0
3.|-- 2001:de8:1:1::39 0.0% 10 2.8 7.3 2.3 49.6 14.9
4.|-- 2405:203:881::1:446 30.0% 10 21.0 21.5 2.8 88.0 30.3
5.|-- 2405:203:881::1:446 0.0% 10 2.6 2.6 2.4 2.8 0.1
6.|-- 2401:8800:1010:1::12 0.0% 10 2.1 2.1 2.0 2.2 0.0
7.|-- 2400:d321:2191:8556:a:b:c:d 0.0% 10 2.3 2.3 2.2 2.5 0.1
anurag@host01 ~>
This confirms entire /64 is routed on the VM and is usable without any proxy NDP.
I am also running a test RIPE Atlas probe on this VM. This is a RIPE Atlas software probe as a docker container with a routed pool.
anurag@host01 ~> mtr 2400:d321:2191:8556:2::2 -wrc 10
Start: 2024-07-03T10:03:57+0530
HOST: host01.bom.anuragbhatia.com Loss% Snt Last Avg Best Wrst StDev
1.|-- ctpl-demarc.bom.anuragbhatia.com 0.0% 10 0.9 0.9 0.8 1.3 0.2
2.|-- 2401:7500:fff6::25 0.0% 10 0.8 1.9 0.7 4.9 1.5
3.|-- 2001:de8:1:1::39 0.0% 10 2.8 2.7 2.5 3.0 0.2
4.|-- 2405:203:881::1:446 0.0% 10 3.6 3.4 3.2 3.6 0.2
5.|-- 2405:203:881::1:446 10.0% 10 3.1 3.0 2.8 3.3 0.1
6.|-- 2401:8800:1010:1::12 0.0% 10 2.6 2.7 2.6 2.7 0.0
7.|-- server03.bom.anuragbhatia.com 0.0% 10 2.7 3.1 2.7 5.1 0.8
8.|-- ripe-atlas03-1008317.bom.anuragbhatia.com 0.0% 10 2.8 2.9 2.7 3.2 0.2
anurag@host01 ~>
Full disclosure & note: My wife works at Contabo and was part of the team involved in the deployment. I am proud of her work! 😀