Résumé
- La configuration redondante recommandée par Megaport sépare les Ports et les domaines de couche 2 côté client, puis établit chaque service avec les deux route servers. Cette architecture protège plusieurs couches sans prouver à elle seule la diversité physique du transport.
- AMS-IX distingue la connexion directe, EasyAccess dont le transport IP inclus est organisé par AMS-IX, et la connexion organisée par un revendeur. Le mot «distant» ajoute donc une chaîne de livraison qu’il faut attribuer.
- Le second chemin ne doit être compté qu’après un exercice où une panne nommée supprime le premier service tandis que l’autre conserve les routes et la capacité attendues.
Le double affichage trompeur
Deux lignes vertes apparaissent dans le portail. Elles portent des identifiants différents et leurs sessions BGP sont établies. La tentation est forte d’inscrire «redondant» dans le registre d’architecture.
Il faut pourtant remonter vers le réseau du client. Les deux lignes aboutissent-elles au même routeur? À deux VLAN sur un seul Port? À deux Ports dans le même châssis ou la même salle? Leur transport partage-t-il une fibre métropolitaine, un point de livraison, une alimentation ou une équipe capable de modifier les deux services? Deux objets logiques peuvent rester distincts tout en disparaissant lors de la même panne.
Les sources citées ne révèlent le parcours d’aucun client. Cette limite interdit d’attribuer à Megaport une concentration non démontrée. Elle interdit aussi de transformer l’état d’un portail en preuve de diversité.
Megaport présente MegaIX comme un échange virtuel intégré à son réseau mondial défini par logiciel. Un client peut atteindre un IX local ou distant depuis un Port existant, notamment au moyen d’un VXC. Cette souplesse évite d’installer du matériel et une liaison locale dans chaque destination. Elle ne supprime pas le transport: elle en déplace la fourniture, la visibilité et la responsabilité.
Le guide d’AMS-IX rend cette responsabilité concrète. Une connexion directe rejoint l’échange dans une colocation et peut nécessiter un cross-connect. EasyAccess inclut un transport IP organisé par AMS-IX. Une connexion partenaire est organisée par le revendeur choisi. Le service d’échange peut être le même, mais la chaîne de livraison, les démarcations et l’escalade ne le sont pas.
Chaque couche a sa propre preuve
La documentation de Megaport fixe un minimum utile. Pour une configuration IX redondante, elle demande deux Ports séparés, deux domaines de couche 2 côté client et, pour chaque service, le peering avec les deux route servers. Elle déconseille un réseau commuté commun entre les routeurs et deux services dépendant d’un seul route server.
Ces règles ne sont pas décoratives. Elles évitent de confondre deux sessions avec une architecture prise en charge. Mais elles ne publient pas le chemin de fibre, le fournisseur de transport, les bâtiments, les sources d’énergie, les points de livraison partenaires ou les fenêtres de maintenance d’un acheteur.
Il faut donc tenir plusieurs colonnes. L’indépendance des routeurs appartient au client. Celle des Ports appartient à l’accès. L’isolation de couche 2 limite un domaine de diffusion commun. Les deux route servers protègent la disponibilité de cette fonction BGP. La diversité du transport concerne ce qui relie le client à l’échange. La diversité opérationnelle concerne les identités, l’automatisation, la maintenance et le pouvoir d’intervention. Une colonne remplie ne complète pas les autres.
Ce cadrage ne reprend pas la commission Strategic Circle sur la politique du route server DE-CIX. Ici, la question n’est pas de savoir quelles routes un serveur redistribue ni quelle politique est déléguée. Elle porte sur la survie du chemin qui transporte les routes déjà acceptées.
BGP n’est qu’un témoin de couche
Megaport distingue le peering multilatéral via ses deux route servers du peering bilatéral avec un participant. Une session établie prouve une adjacence à un instant donné. Le looking glass ajoute une observation de l’état de routage. Aucun des deux ne décrit tous les composants physiques en amont.
La procédure de dépannage de Megaport le montre: une panne IX peut exiger de vérifier l’interface, les erreurs, l’optique, le câblage, le MTU, LACP, le VLAN, l’adressage, les tables de routage, l’accès au route server ou au pair bilatéral, puis les erreurs BGP. Elle prévoit aussi un test de bout en bout. Une session active peut coexister avec un trafic perdu ailleurs; une session tombée ne nomme pas automatiquement la pièce défaillante.
La capacité reste une autre inconnue. Le secours peut être séparé mais sous-dimensionné pour le trafic déplacé. Aucun document cité ne fournit le débit contracté, la congestion, la latence ou le résultat de bascule d’un client. «Connecté» ne signifie donc pas «capable d’absorber la charge».
APNIC enregistre AS133937 sous le nom MEGAPORTPTYLTD-AS-AP. Cette identité publique n’atteste ni la préférence d’une route ni l’indépendance de deux transports privés.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
