Check-Host.cc

MTR Test from South Africa

2 nodes in Johannesburg · NAP Africa Johannesburg

South Africa — 2 Nodes

Cities
Johannesburg
ISPs / ASNs
Google LLC AS396982
Virtarix AS328364
Datacenters
Google LLC
Host Africa (Pty) Ltd
Internet Exchanges
NAP Africa Johannesburg — Principale installation de peering neutre d'Afrique subsaharienne, hébergée à Teraco JHB1

Test MTR depuis l'Afrique du Sud

MTR depuis le nœud Johannesburg (AS396982, Google LLC) exécute une trace de chemin continue vers votre cible, rapportant la latence et la perte de paquets par saut. La caractéristique la plus distinctive des traces MTR sud-africaines est la sortie câble sous-marin — un saut de latence de 160–170 ms vers Londres ou Amsterdam, représentant le temps de propagation du câble SEACOM ou WACS plus tous les sauts backbone Google depuis JHB vers la station d'atterrissage câble. Tout ce qui précède ce saut est le réseau domestique sud-africain ; tout ce qui suit est le chemin international. La traversée câble est typiquement visible comme un saut unique avec une grande augmentation de RTT.

Les traces MTR depuis JHB vers les cibles européennes via SEACOM routent typiquement via Mombasa (Kenya) ou Fujairah (EAU) avant d'atterrir à Marseille ou Djibouti et de continuer par voie terrestre vers l'Europe occidentale. Via WACS, le chemin remonte la côte ouest africaine via Accra ou Dakar avant d'atterrir au Portugal ou en Espagne. Les stations d'atterrissage câble intermédiaires apparaissent comme des sauts dans la sortie MTR avec des ajouts de latence incrémentaux de 20–40 ms chacun. Savoir quel système câble transporte le trafic aide à diagnostiquer si la latence est due au routage câble ou à la congestion sur un segment spécifique.

La propre infrastructure fibre de Google en Afrique signifie que les traces MTR depuis AS396982 à JHB peuvent router via le backbone privé de Google plutôt que le transit public pour certaines destinations — particulièrement les autres réseaux exploités par Google et les principaux partenaires de peering. Les sauts via le backbone de Google apparaissent comme des ASN Google internes (sauts AS15169) dans la sortie MTR. La perte sur les sauts backbone internes de Google est typiquement une limitation de débit ICMP sur les routeurs internes de Google, pas une vraie perte de paquets. Les vrais problèmes de chemin apparaissent comme une perte soutenue depuis le point de défaillance vers l'avant, incluant au saut final de destination.

Infrastructure réseau de l'Afrique du Sud

Johannesburg est le hub internet de l'Afrique subsaharienne. La ville héberge NAP Africa à l'installation JHB1 de Teraco — le plus grand point de colocation et de peering neutre vis-à-vis des opérateurs du continent. Teraco JHB1 abrite plus de 200 réseaux incluant MTN (AS37457), Vodacom (AS36874), Telkom SA (AS10474), et les principaux réseaux de contenu incluant Google, Meta et Akamai. Notre nœud sonde fonctionne sur AS396982 (Google LLC) dans un datacenter Google à Johannesburg, reflétant l'investissement direct de Google dans l'infrastructure réseau africaine dans le cadre de leur stratégie d'expansion régionale. Google exploite sa propre fibre et ses propres arrangements de peering à JHB, se connectant à l'écosystème internet sud-africain plus large via Teraco et NAP Africa.

La connectivité internationale de l'Afrique du Sud repose sur des systèmes de câbles sous-marins atterrissant en plusieurs points le long des côtes est et ouest. SEACOM (opérationnel depuis 2009) relie la côte est-africaine à l'Europe via le Moyen-Orient. WACS (West Africa Cable System) longe la côte ouest reliant l'Afrique du Sud à l'Europe via l'Afrique de l'Ouest. EAST AFRICA MARINE SYSTEM (EASSy) fournit une capacité supplémentaire sur la côte est. La combinaison de plusieurs systèmes câbles atterrissant en Afrique du Sud donne à JHB une meilleure diversité de chemins vers l'Europe que la plupart des autres villes africaines, bien que la bande passante totale disponible reste contrainte comparée aux points d'interconnexion européens ou nord-américains.

RTT de référence depuis le nœud Google de Johannesburg : JHB-vers-Londres est d'environ 160 ms, JHB-vers-Amsterdam 165 ms, JHB-vers-Francfort 170 ms, JHB-vers-New York 200–210 ms, JHB-vers-Singapour 200–210 ms, JHB-vers-Nairobi 30–40 ms, JHB-vers-Lagos 90–100 ms. Les chiffres de latence vers Londres et Amsterdam sont plus faibles que beaucoup ne l'attendent — SEACOM et WACS fournissent des chemins raisonnablement directs vers l'Europe sans le routage multi-sauts des anciens liens satellites. Ces chemins câbles sous-marins ont fait de l'Afrique du Sud l'un des pays les mieux connectés d'Afrique pour la latence internationale.

La présence de Google à Johannesburg via AS396982 s'inscrit dans la stratégie africaine plus large de Google, qui inclut des nœuds Google Cache (GGC) déployés avec les FAI sud-africains et le câble sous-marin Equiano (reliant l'Afrique du Sud au Portugal). Le préfixe AS396982 à JHB est correctement identifié comme un ASN d'infrastructure Google par toutes les principales bases de données GeoIP. Le trafic depuis ce nœud sera reconnu comme originant de l'infrastructure africaine d'un grand fournisseur cloud — pertinent pour les services qui appliquent des règles de routage ou de limitation de débit différentes aux IPs sources de fournisseurs cloud par rapport aux IPs de FAI résidentiels. DE-CIX Johannesburg, lancé dans le cadre de l'expansion africaine de DE-CIX, fournit des options d'interconnexion supplémentaires au-delà de NAP Africa et JINX.

Le backbone domestique de l'Afrique du Sud relie Johannesburg au Cap, Durban et Pretoria sur des fibres longue distance exploitées par Telkom SA et un nombre croissant d'opérateurs privés. JHB-vers-Le Cap est d'environ 30 ms, JHB-vers-Durban 15–20 ms. Le nœud Johannesburg est de loin l'emplacement de test le plus pertinent pour les conditions réseau d'Afrique subsaharienne — il se situe au principal hub de peering du continent avec un accès direct à tous les principaux chemins opérateurs africains et internationaux. Pour tout service ciblant les audiences africaines, une vérification HTTP ou ping depuis ce nœud est la première étape pour comprendre le tableau de connectivité continental.