Web Squad ISP

Status
Not open for further replies.
Is there any way to test the Asian connection via the looking glass? Want to do some ping tests to Blizzard game servers and a few other services.

It’s live. If we’re learning the route via those sessions, it will be favoured (fewest hops always wins). If we’re learning Blizzard’s prefixes there, then it should be good. I’d prefer not to allow all Blizzard from China Telecom as last time it caused havoc- their network doesn’t react well to multi-homed peers/clients like us.
 
Plus one in terms of interest. I'm on SADV and looking to signing up with WebSquad.

Frogfoot and SADV delays have pushed launches to early next year. I can’t provide a timeline until their commercial team’s results-open in January.
 
I'm not sure what IP the Apex server is. I googled, came across this site : https://gameserverping.com/apex which says its 35.186.156.249

Traceroute on that IP is a bit weird... isn't it?

1 <1 ms <1 ms <1 ms router.lan [192.168.3.1]
2 2 ms 1 ms 1 ms core.as-02.jb1.za.ws.net.za [160.119.230.1]
3 2 ms 2 ms 2 ms core.cr-xe-01.jb1.za.ws.net.za [160.119.224.29]
4 2 ms 2 ms 2 ms core.pe-xe-ix01.jb1.za.ws.net.za [160.119.224.17]
5 3 ms 3 ms 3 ms 196-60-9-113.ixp.joburg [196.60.9.113]
6 * * * Request timed out.
7 2 ms 2 ms 2 ms 172.253.65.252
8 2 ms 2 ms 2 ms 74.125.245.195
9 164 ms 160 ms 164 ms 172.253.67.187
10 160 ms 160 ms 160 ms 216.239.58.3
11 228 ms 228 ms 228 ms 172.253.65.176
12 243 ms 243 ms 243 ms 216.239.58.254
13 256 ms 255 ms 256 ms 72.14.232.70
14 287 ms 288 ms 287 ms 108.170.227.203
15 375 ms 375 ms 375 ms 108.170.235.221
16 447 ms 444 ms 447 ms 172.253.51.111
17 440 ms 440 ms 440 ms 209.85.243.180
18 439 ms 440 ms 440 ms 172.253.68.247
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 444 ms 444 ms 445 ms 249.156.186.35.bc.googleusercontent.com [35.186.156.249]
 
I'm not sure what IP the Apex server is. I googled, came across this site : https://gameserverping.com/apex which says its 35.186.156.249

Traceroute on that IP is a bit weird... isn't it?

1 <1 ms <1 ms <1 ms router.lan [192.168.3.1]
2 2 ms 1 ms 1 ms core.as-02.jb1.za.ws.net.za [160.119.230.1]
3 2 ms 2 ms 2 ms core.cr-xe-01.jb1.za.ws.net.za [160.119.224.29]
4 2 ms 2 ms 2 ms core.pe-xe-ix01.jb1.za.ws.net.za [160.119.224.17]
5 3 ms 3 ms 3 ms 196-60-9-113.ixp.joburg [196.60.9.113]
6 * * * Request timed out.
7 2 ms 2 ms 2 ms 172.253.65.252
8 2 ms 2 ms 2 ms 74.125.245.195
9 164 ms 160 ms 164 ms 172.253.67.187
10 160 ms 160 ms 160 ms 216.239.58.3
11 228 ms 228 ms 228 ms 172.253.65.176
12 243 ms 243 ms 243 ms 216.239.58.254
13 256 ms 255 ms 256 ms 72.14.232.70
14 287 ms 288 ms 287 ms 108.170.227.203
15 375 ms 375 ms 375 ms 108.170.235.221
16 447 ms 444 ms 447 ms 172.253.51.111
17 440 ms 440 ms 440 ms 209.85.243.180
18 439 ms 440 ms 440 ms 172.253.68.247
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 444 ms 444 ms 445 ms 249.156.186.35.bc.googleusercontent.com [35.186.156.249]

Traceroute looks good. But looks like Apex is using Google Cloud Platform instead of AWS (Amazon) - which correct me if I'm wrong, they used to use? All google bound traffic hits Google's peering at the 5th hop 196.60.9.113 (there's a second IP too). All Google traffic also returns via the same path (they local pref peering). Just seems to me the internal route on Google is pretty long there - 444ms is probably Asia, but via the UK/Amsterdam.
 
Traceroute looks good. But looks like Apex is using Google Cloud Platform instead of AWS (Amazon) - which correct me if I'm wrong, they used to use? All google bound traffic hits Google's peering at the 5th hop 196.60.9.113 (there's a second IP too). All Google traffic also returns via the same path (they local pref peering). Just seems to me the internal route on Google is pretty long there - 444ms is probably Asia, but via the UK/Amsterdam.
Yes, they're on google.

What is weird is that last week it was 150ms to Singapore, now it's more
 
Yes, they're on google.

What is weird is that last week it was 150ms to Singapore, now it's more

little we can do about Google’s global network. They make their own transit decisions and route all their own traffic to SA. Do you have a before MTR?
 
Understanding Ping (Latency)

At the most basic level, latency is the time it takes a packet to travel a round trip between two points on the Internet. This means very little when connecting to a server in South Africa, but significantly more when connecting to a server in the EU, US or Asia. For the rest of this piece, I'm not going to take last mile and backhaul networks into account - we're looking at internet from our core out.

The internet is not this big box ISPs plug into, it’s a collections of hundreds of thousands of networks. Some tiny, with a point of presence in just one location and some are huge - spanning tens, hundreds, if not thousands of global locations. The peering and transit design of these networks is what makes the internet work. Tier 1 providers are considered so when they peer at all major global exchanges (Think HE, Cogent, Telia, Century Link etc)

The cable systems arriving in South Africa in Ysterfontein (Cape Town) and Mtunzini (KZN) are also not providers of internet (ignoring the conflated wholesale businesses attached to some cables). The cables are actually really long fibre routes with L2 circuits between South Africa and London or Marseilles or other cable systems. Physics is pretty steady, so we’re not going to see light make it to Europe and back in less than 130-140ish ms (Landing station to landing station). The light still needs to travel from a landing station to a Datacentre (and this can involve long terrestrial routes through South Africa).

ISPs peer with other ISPs and networks, and purchase transit for traffic not available via peering for their client’s traffic. Transit providers purchase capacity on cable systems and interconnect their global core networks (which in turn connect to other networks) to provide connectivity to their clients.

Now that we have a basic understanding of the mechanics of the internet, it is vital to remember that latency differs (even by microseconds) between any two points on the internet. It is also important to note that the internet is constantly changing. Every network is continuously improving a part of their routing and in turn or continuously breaking another part, making tweaks, changing providers or routes and so on. Things break too. Cable systems get picked up by anchors, terrestrial cables get broken by TLBs and hardware fails. With this in mind, the route a packet takes between your PC and a destination may change from time to time.

We’re multi-homed at Web sQuad. This means we have multiple peering points and multiple transit networks to connect us to the world. We operate each home independently and as part of a larger South African network. This gives us the advantage of redundancy (if a route/provider fails). It also gives us the ability to leverage each of those network’s strengths to get the best possible advertisements (how other networks see us) as well as routes (how we see other routes) from them. We’ve picked our upstream transit networks carefully for this reason: We get a balanced distribution of advertisements to global networks and hopefully that translates into a very low latency network to most places.

Obviously it's impossible to optimise every single one of the networks out there all the time. This is why we ask you for an MTR/traceroute as well as a source location (so we know which core network to look at). We're happy to look at our routing tables we receive from transit or from peers and make changes (if we can and we know it won't affect other services). With larger CDNs and networks, we're happy to engage their Network OPS teams to see if they can make changes to improve matters.
 
So my service with Cool Ideas is ending today and I was wondering, would it be faster getting myself back online tomorrow through the self activation or through Web Squad's website?
 
So my service with Cool Ideas is ending today and I was wondering, would it be faster getting myself back online tomorrow through the self activation or through Web Squad's website?

I’ve dropped you a DM with details. For today, best way is via our direct order channels (website).
 
Status
Not open for further replies.
Top
Sign up to the MyBroadband newsletter
X