Résumé

  • Le 16 juillet 2026 à 08h00 UTC, RIPE RIS a observé AS135632 annonçant103.77.9.0/24,116.206.164.0/24et116.206.167.0/24: 768 adresses IPv4 réparties sur trois routes, sans IPv6 annoncé. Chacun des 1 063 chemins AS collectés plaçait AS141421 (MUX Broadband) immédiatement avant Cactus.
  • Les preuves établissent un système autonome voisin visible, pas un câble physique. Elles ne révèlent pas combien de sessions BGP, d’interconnexions, de circuits, de routeurs, de bâtiments, de relais sur les toits, de conduits ou de domaines d’alimentation se trouvent sous cette relation logique.
  • Le parc de routes a considérablement changé. RIPE a vu huit préfixes IPv4 et un voisin en juillet 2025, aucune route originaire de Cactus dans un instantané de mi-octobre, sept préfixes via AS141421 en avril 2026, et trois en mai. Ces observations prouvent des changements de routage, pas une perte de clients, une migration physique ou une capacité installée réduite.
  • Le site Web et la messagerie de Cactus sont hébergés dans AS31898 plutôt que AS135632, de sorte que ces surfaces de contact publiques pourraient rester joignables lors d’un retrait des routes originaires de Cactus. L’accès des clients, les services locaux, la commutation interne et les opérations de support dépendraient d’arrangements non visibles dans le routage public ou les documents de l’entreprise.

La session s’arrête à 08h00 UTC

Commençons par la panne plutôt que par la brochure.

À 08h00 UTC, la session de bord transportant les trois préfixes publics de Cactus Network Solutions vers AS141421 cesse d’échanger une joignabilité utilisable. La cause pourrait être une interface défaillante, une erreur de maintenance en amont, un redémarrage de routeur, un circuit d’accès endommagé, une erreur de configuration ou une perte d’alimentation à l’une ou l’autre extrémité. Une fois que tout intervalle de rétention de route a expiré, et à condition qu’aucune seconde session ou voisin ne commence à annoncer les mêmes préfixes, l’effet à l’extérieur du réseau est simple: les autres systèmes autonomes cessent d’apprendre comment atteindre103.77.9.0/24,116.206.164.0/24et116.206.167.0/24.

Ce n’est pas une topologie hypothétique inventée à partir d’un nom d’entreprise. L’instantané d’état de routageRIPEstat à la date de publicationa compté trois routes IPv4 originaires, 768 adresses, aucune route IPv6 et un voisin observé. La capture d’état BGP correspondantecontenait 1 063 chemins de collecteurs. AS135632 était l’origine dans tous, et AS141421 était le système autonome immédiatement précédent dans tous.

Ce qui reste joignable au moment de la panne est plus révélateur que ce qui disparaît.

Le domaine public de Cactus résolu en192.185.56.104dans laréponse A renvoyée par Google Public DNS. Laréponse d’informations réseau de RIPEpour cette adresse a placé sa route de couverture dans AS31898, en dehors d’AS135632. Leserveur de messageriedu domaine étaitmail.cactuspk.com,qui résolvait la même adresse IPv4 hébergée en externe. Sesserveurs de noms faisant autoritéutilisaient également l’espace de nomswebsitewelcome.com. Par conséquent, le retrait des propres routes de Cactus ne retirerait pas, en soi, le préfixe d’hébergement du site Web public ni celui de l’hôte de messagerie.

Le site Web pourrait encore se charger. Un serveur de messagerie pourrait encore accepter du courrier. Un appelant pourrait encore joindre le numéro de téléphone publié via un service de télécommunications distinct. Aucun de ces résultats ne prouve qu’un abonné de Cactus peut atteindre l’Internet au sens large. Le personnel à l’intérieur d’un bureau desservi par Cactus pourrait être incapable d’atteindre les systèmes de support hébergés en externe, même si ces systèmes restent disponibles pour tous les autres.

Un client et un ingénieur de support pourraient ainsi voir des faces opposées de la même panne: la page de support est en ligne depuis l’étranger, tandis que le circuit du client n’a aucune route utilisable vers l’extérieur.

La communication locale est une inconnue distincte. Si les radios d’accès client, les commutateurs, l’adressage et les services locaux restent alimentés, les paquets entre deux points à l’intérieur du même domaine de routage pourraient continuer à circuler sans route globale. Ils pourraient également dépendre de systèmes centraux ou de chemins qui tombent en panne avec le transfert en amont. Les preuves publiques ne montrent pas la topologie interne, si les abonnés utilisent un adressage public ou privé, où se produit l’authentification, ou si le trafic local est commuté localement. La bonne réponse à « qu’est-ce qui reste joignable?

» est par conséquent une liste à mesurer, pas une hypothèse confiante.

Ce que la table de routage publique établit

BGP est un protocole de joignabilité inter-domaines. Laspécification BGP de basedécrit l’échange de préfixes et d’informations de chemin AS entre systèmes de routage. Elle ne code pas une route de rue, un dessin de fibre, un emplacement sur un toit, une alimentation électrique, une vitesse de port ou un contrat de réparation. Les preuves de Cactus doivent être conservées dans ces couches.

Mot de preuveCe que cela signifie iciCe que cela ne signifie pas
EnregistréUn enregistrement de registre public associe une organisation, un contact ou une ressource numérique à Cactus.La ressource est actuellement routée, occupée, physiquement à Lahore ou transportant des clients.
AnnoncéAS135632 a originaire un préfixe dans BGP pendant un intervalle donné.Chaque adresse était active, la capacité était disponible, ou chaque client pouvait passer du trafic.
ObservéLes collecteurs RIPE ont reçu une route ou un chemin AS à un moment donné.Tout réseau dans le monde a vu le même chemin, ou le chemin correspond à un circuit physique.
InconnuLe matériel public n’a pas établi le fait.L’actif ou la sauvegarde est absent, défectueux ou inutilisé.

À la date de publication, le résultat des préfixes annoncés de RIPE pour la période du 1er au 16 juillet montrait les trois mêmes /24 en continu depuis le début de l’intervalle demandé jusqu’à la dernière observation disponible à 08h00 UTC le 16 juillet. Le résultat d’état de routage indiquait que 320 des 326 pairs IPv4 de RIS voyaient les routes. Aucun préfixe IPv6 n’était visible pour aucun des 321 pairs IPv6 dans cet instantané.

Les preuves de chemin par préfixe sont inhabituellement cohérentes. RIPE a renvoyé 360 chemins pour103.77.9.0/24, 360 pour116.206.164.0/24et 343 pour116.206.167.0/24. Chaque chemin capturé pour chaque préfixe se terminait parAS141421 AS135632. Il n’y avait aucun chemin collecté dans lequel un autre système autonome apparaissait directement avant Cactus.

Cette conclusion est plus solide que de dire qu’un répertoire commercial liste un fournisseur. C’est une observation route par route à travers des centaines de vues de collecteurs. Pourtant, sa limite est tout aussi importante. Plusieurs liens physiques ou plusieurs sessions BGP peuvent exister entre les deux mêmes systèmes autonomes tout en produisant le même chemin AS. Inversement, une seule session BGP peut être transportée sur une infrastructure avec une protection cachée à l’intérieur du réseau d’un fournisseur. Le chemin AS seul ne peut pas distinguer ces cas.

Le profil PeeringDB géré par l’opérateur pour AS135632 identifie Cactus, utilisant également le nom Sprint Broadband, comme un réseau câble/DSL/FAI pakistanais. Il ne publie pas de lignes d’échange ou d’installation. Cette absence réduit ce qui peut être vérifié via PeeringDB; elle ne prouve pas que Cactus n’a pas d’équipement dans une installation partagée, pas d’interconnexion privée, pas d’accès à un échange distant et pas de service de gros protégé.

Le registre public d’APNIC pour ORG-CNSP1-AP identifie Cactus Network Solutions (CNS) Pvt Ltd comme un registre Internet local pakistanais et donne une adresse à New Garden Town, Lahore. L’enregistrement du mainteneur et l’enregistrement de contact d’intervention en cas d’incident préservent la même identité organisationnelle et la maintenance de contact actuelle. Ce sont de bonnes preuves que l’entreprise reste un détenteur de ressources actif. Une adresse administrative n’est pas une preuve d’un routeur central, d’un relais, d’un entrepôt, d’un point d’agrégation client ou d’un transfert en amont dans ce bâtiment.

Trois /24 ne sont ni une capacité ni un nombre de clients

Un /24 contient 256 adresses IPv4. Trois /24 contiennent donc 768 adresses. Cette arithmétique est exacte et opérationnellement limitée.

Le nombre ne révèle pas les abonnés. Un ménage pourrait recevoir une adresse publique, de nombreux ménages pourraient en partager une via une traduction au niveau du fournisseur, une entreprise pourrait en recevoir plusieurs, et les interfaces d’infrastructure pourraient consommer une partie du pool. Les adresses peuvent également être réservées, routées mais inactives, utilisées pour des équipements réseau ou attribuées dynamiquement. Aucune source publique n’établit la politique d’adressage actuelle de Cactus.

Le nombre d’adresses ne révèle pas non plus la bande passante. Un engagement de transit de 100 Mbps et un engagement de transit de 10 Gbps peuvent annoncer les mêmes trois préfixes. Les routes indiquent où les paquets doivent aller; elles ne précisent pas combien de trafic le transfert peut supporter avant congestion, quelles classes sont prioritaires, quelles conditions de rafale s’appliquent, ou combien de capacité de réserve existe après une panne.

Chaque /24 a sa propre histoire mais la même sortie actuelle

Les trois routes actuelles ne doivent pas être traitées comme une statistique indivisible. Chacune est annoncée indépendamment, peut être retirée indépendamment, et peut transporter un mélange différent d’adresses d’infrastructure ou d’abonnés. Les données publiques ne révèlent pas ce mélange, mais elles rendent le comportement de routage de chaque /24 observable séparément.

Route actuelleChemins capturés à 08h00 UTCContinuité observée récemmentVoisin immédiat actuelRésultat de validation d’origine
103.77.9.0/24360Visible du 1er au 16 juillet; absent du 16 avril au 12 mai avant de revenirAS141421Inconnu
116.206.164.0/24360Visible du 1er au 16 juillet; visible en continu du 8 janvier jusqu’à la date de publication après de courtes lacunes début janvierAS141421Inconnu
116.206.167.0/24343Visible du 1er au 16 juillet; visible en continu du 1er novembre 2025 jusqu’à la date de publicationAS141421Inconnu

Le nombre de chemins plus faible pour116.206.167.0/24n’est pas une preuve d’une bande passante plus faible ou d’un service client moins bon. Cela signifie que moins de chemins de collecteurs étaient présents dans cette réponse capturée. La participation des collecteurs, le filtrage et le timing peuvent différer. Ce qui est commun aux trois résultats est plus important: chaque chemin capturé utilisait AS141421 à la dernière limite externe-AS.

Il n’y avait également aucune route de couverture observée pour absorber la perte d’une annonce plus spécifique. RIPE n’a renvoyé aucun état BGP pour les routes de couverture103.77.8.0/22ou116.206.164.0/22au même horodatage. Ainsi, dans la table publique capturée, le retrait de103.77.9.0/24ne laisserait pas une route /22 originaire de Cactus la couvrir. Il en va de même pour les deux /24 visibles dans le bloc116.206.

Ce détail donne à Cactus deux problèmes de résilience différents.

Le premier est une panne partagée. Si la limite AS135632-AS141421 cesse de transporter toutes les exportations, les trois routes peuvent disparaître ensemble car elles partagent le même voisin visible. Le second est une panne sélective. Une erreur de filtre de route, une erreur de politique spécifique à un préfixe ou un problème d’origination local peut supprimer un /24 tandis que les deux autres restent sains. Les clients dans la plage affectée pourraient être injoignables même si un tableau de bord agrégé indique qu’AS135632 est toujours en ligne.

C’est pourquoi un moniteur externe devrait tester au moins une adresse contrôlée dans chaque préfixe annoncé. Une seule sonde vers le site Web de l’entreprise serait inutile car le site est en dehors de l’ASN de Cactus. Une seule sonde à l’intérieur de116.206.167.0/24manquerait un retrait sélectif de103.77.9.0/24. La joignabilité devrait être testée depuis plusieurs réseaux indépendants, avec le résultat lié à l’état BGP au même moment. Cela distinguerait au moins trois événements: route absente, route présente mais point de terminaison indisponible, et point de terminaison joignable avec une livraison de paquets dégradée.

L’historique des routes donne également à l’opérateur un cas de test naturel.103.77.9.0/24est revenu après près de quatre semaines d’absence en avril et mai 2026, tandis que116.206.164.0/24et116.206.167.0/24étaient visibles des deux côtés de cet intervalle. Les données publiques ne peuvent pas dire si la route de retour transportait des abonnés, de l’infrastructure ou de l’espace inutilisé. Cactus le peut. Elle pourrait utiliser l’événement pour expliquer si le retrait était planifié, comment les utilisateurs d’adresses ont été gérés, quelles alarmes se sont déclenchées et pourquoi la route est revenue.

Les quatre /24 qui ne sont plus visibles après le 16 avril méritent la même formulation rigoureuse.103.77.10.0/24,103.77.11.0/24,116.206.165.0/24et116.206.166.0/24apparaissaient dans l’historique de RIPE et étaient absents à la publication. C’est un fait d’annonce. Ce n’est pas une preuve que l’espace d’adressage enregistré correspondant a été vendu, abandonné, révoqué ou déconnecté physiquement. Un inventaire actuel des préfixes devrait étiqueter chaque bloc comme routé, réservé, utilisé en interne, attribué via un autre arrangement ou retiré, avec la date et l’autorité pour l’état.

Pour un acheteur, ce n’est pas un détail administratif. Si une adresse statique promise se trouve dans un /24 qui est parfois retiré indépendamment, la question de niveau de service est spécifique à la route. Si des équipements critiques sont répartis sur deux des /24 actuels, cela peut protéger contre une erreur spécifique à un préfixe mais pas contre la limite commune AS141421. Si tous les pools de traduction clients, les résolveurs DNS et les systèmes de gestion se trouvent dans un seul /24, les deux autres routes peuvent offrir moins de séparation pratique que le nombre de routes ne le suggère.

La table publique ne peut pas révéler ces emplacements.

L’empreinte de trois routes est donc suffisamment petite pour être auditée avec précision. Cactus peut publier un inventaire non sensible, surveiller chaque préfixe, tester les exportations normales et alternatives, et conserver un enregistrement d’événement lorsqu’une route change. Cela serait plus informatif qu’un pourcentage de disponibilité large car cela montrerait exactement quelle population d’adresses restait joignable sous quelle panne.

Le site Web de l’entreprise fait des affirmations beaucoup plus importantes, y compris un service gigabit, un réseau sans fil tout IP, des lignes louées institutionnelles et plus de 20 000 utilisateurs de confiance. Mais la page d’accueil live de Cactus contient également du texte commercial sur des offres haut débit en Inde, des témoignages de fournisseurs de thèmes et un langage générique sans rapport avec l’opérateur de Lahore. La page de contact inclut une affirmation de popularité d’Aivahthemes à côté de l’adresse de Lahore. Une page de contacts distincte a des exemples de détails à Chicago et New York.

Ces résidus rendent les affirmations d’échelle numérique du site inutilisables comme faits opérationnels.

La conclusion plus sûre est plus modeste. Le site est joignable, présente Cactus comme un fournisseur d’accès Internet résidentiel et professionnel, publie des coordonnées à Lahore, et discute de services sans fil, fibre et lignes louées. Il ne fournit pas de nombre d’abonnés actuel fiable, de carte de couverture commandable, d’inventaire actif de tours, de capacité de transit, de série d’utilisation ou de registre de disponibilité audité. L’empreinte de 768 adresses ne doit pas être gonflée avec des chiffres provenant de textes commerciaux compromis.

Une page IPinfo indépendante pour AS135632 corrobore la vue actuelle de trois préfixes, 768 adresses et zéro IPv6, et étiquette le réseau comme un FAI grand public. Elle rapporte également un petit ensemble d’adresses Cactus répondant au ping. Ces sondes soutiennent la proposition que les points de terminaison dans les routes répondent depuis le Pakistan; elles n’identifient pas les clients, les zones de service actives, les sites radio, la congestion ou la résilience. Un profil bgp.tools indépendant liste encore sept préfixes IPv4 et le même ASN en amont.

Son nombre plus élevé reflète un inventaire plus large ou temporellement différent de la vue RIPE à la date de publication. La différence est une raison d’horodater les affirmations, pas de choisir le nombre le plus élevé.

Le parc de routes a déjà changé

La preuve la plus utile concernant le basculement n’est pas une promesse. C’est ce que les routes ont fait.

Le 16 juillet 2025, RIPE observait AS135632 annonçant huit préfixes IPv4, couvrant 2 048 adresses, sans IPv6 et avec un voisin. Le voisin visible ce jour-là était AS24499, Telenor Pakistan, comme le montre la réponse des voisins historiques. C’est la preuve d’une frontière publique en amont différente de celle vue en juillet 2026.

L’historique des annonces sur un an enregistre ensuite une rupture brutale. Les préfixes visibles à l’été 2025 se sont terminés le 26 septembre. Le flux de mises à jour pour103.77.9.0/24montre des retraits généralisés après des chemins via AS24499. Aucun préfixe originaire d’AS135632 n’apparaît dans l’instantané d’état de routage de mi-octobre.

Le 22 octobre, les annonces sont revenues. Le flux de mises à jour autour de la restauration montre de nouveaux chemins se terminant parAS141421 AS135632. Au 15 avril 2026, sept /24 IPv4 étaient visibles via un voisin observé, AS141421. Quatre de ces sept ont cessé d’apparaître le 16 avril.103.77.9.0/24a également disparu et est réapparu le 12 mai. L’instantané du 13 mai s’était stabilisé sur le total actuel de trois.

Ces horodatages établissent trois choses.

Premièrement, AS135632 a changé sa frontière visible en amont. Deuxièmement, son ensemble de routes publiques s’est contracté de huit à sept à trois sur la période observée. Troisièmement, il y a eu un intervalle d’environ 26 jours entre le retrait de septembre et la restauration d’octobre pendant lequel RIPE n’a pas vu d’annonce d’AS135632.

Ils n’établissent pas pourquoi. Une absence visible par les collecteurs pourrait coïncider avec une migration de fournisseur, un changement de routage délibéré, l’utilisation d’adresses attribuées par le fournisseur, une erreur de politique, un service suspendu ou une autre condition. Cela ne nous dit pas si les clients de détail étaient hors ligne, déplacés derrière un autre espace public, servis via un autre ASN, utilisant une connectivité privée, ou pas encore actifs. De même, le retrait de quatre /24 en avril 2026 ne prouve pas que Cactus a perdu des clients ou décommissionné des équipements.

Ces adresses pourraient être inutilisées, conservées, routées différemment ou en attente d’un autre usage.

L’historique importe néanmoins pour un acheteur. Il prouve que la configuration publique n’est pas statique et qu’un changement de voisin s’est produit. Une explication crédible de la résilience devrait donc répondre non seulement à « qui est en amont aujourd’hui? » mais aussi à « comment le trafic a-t-il continué pendant la dernière transition en amont, quels préfixes ont bougé, combien de temps a pris la convergence, et qu’ont vécu les clients? »

Un voisin peut cacher plusieurs circuits, mais pas un deuxième chemin AS

AS141421 est identifié par le registre de systèmes autonomes d’APNIC comme MUX Broadband (Private) Limited au Pakistan. Au même moment, l’état de routage RIPE de MUX montrait cinq préfixes IPv4 annoncés, trois préfixes IPv6 et sept voisins observés. Sa vue des voisins incluait trois systèmes autonomes apparaissant avant MUX sur les chemins observés et quatre apparaissant après, dont AS135632.

La connectivité plus large de MUX peut rendre le service qu’elle vend plus résilient qu’un seul lien externe. Cette résilience ne peut pas être transférée automatiquement à Cactus. La limite de panne en question est la limite entre AS135632 et AS141421. Si MUX conserve d’excellentes routes vers l’Internet au sens large mais que Cactus ne peut pas livrer ses préfixes à MUX, ces options en amont n’aident pas les adresses de Cactus. Il en va de même si un routeur de bord partagé de Cactus, un transfert local, une alimentation électrique ou une configuration tombe en panne avant que le trafic n’atteigne MUX.

En même temps, le résultat d’un seul voisin ne justifie pas de tracer une ligne sur une carte de la ville. Cactus pourrait avoir deux circuits vers MUX à différents endroits, deux routeurs sur un seul circuit, deux sessions sur un seul service protégé, ou un seul transfert non protégé. MUX pourrait transporter le trafic sur une infrastructure redondante en interne. Aucun de ces designs n’est visible dans le chemin AS. Le chemin physique exact entre les entreprises, y compris s’il traverse Lahore, Multan ou une installation nommée, est inconnu.

Une évaluation officielle des achats de soins de santé du Pendjab crée une tension utile. Le rapport technique d’offre du 19 juillet 2023 a marqué Cactus « Oui » contre une exigence qu’un soumissionnaire ait deux fournisseurs en amont, écrits comme PIE et TW1. Le même tableau l’a marqué conforme pour la licence LL/CVAS et finalement responsable.

Ce document est une preuve solide de ce que les évaluateurs des achats ont accepté en 2023. Ce n’est pas un diagramme BGP actuel. Il n’identifie pas les circuits, les ASN, les sites, les annonces de routes, les périodes de contrat ou le comportement de basculement derrière la réponse à deux fournisseurs en amont. L’exigence peut avoir concerné un service géré particulier, des fournisseurs de gros derrière un autre fournisseur, la capacité commerciale alors en vigueur ou des preuves non reproduites dans l’évaluation de deux pages.

La vue RIPE actuelle, en revanche, répond à une question plus étroite: quel système autonome apparaissait directement avant AS135632 dans les chemins publics le 16 juillet 2026? La réponse était seulement AS141421.

Le « Oui » des achats et l’instantané de routage ne sont donc pas mutuellement exclusifs. Ensemble, ils définissent la question de diligence raisonnable. Cactus peut la résoudre en identifiant les deux domaines de péremption actuels, en montrant quels préfixes publics chacun porte, et en démontrant qu’une perte contrôlée de l’un entraîne l’autre à annoncer et transférer des routes utilisables dans un intervalle donné.

IPv6 est absent, mais ce ne serait pas une sauvegarde magique

Le parc de routes actuel de Cactus n’a pas de deuxième famille d’adresses visible. RIPE a compté zéro préfixe IPv6 annoncé en juillet 2025, en avril 2026, en mai 2026 et dans l’instantané à la date de publication. IPinfo et bgp.tools rapportent indépendamment la même absence. Le domaine public de Cactus n’a également renvoyé aucune adresse dans la réponse AAAA de Google Public DNS.

IPv6 est un protocole de couche réseau distinct, spécifié dans la RFC 8200, avec un espace d’adressage beaucoup plus grand qu’IPv4. Dans un service double pile correctement conçu, un client et une application peuvent avoir à la fois une joignabilité IPv4 et IPv6. Les techniques client décrites par Happy Eyeballs Version 2 peuvent essayer les familles disponibles d’une manière destinée à réduire le délai visible par l’utilisateur lorsqu’un chemin est mauvais.

Mais IPv6 n’est pas un substitut automatique à une route IPv4 défaillante. L’appareil client doit recevoir une configuration IPv6 fonctionnelle. Le réseau d’accès doit le transporter. Le DNS doit publier une destination IPv6 le cas échéant. La destination doit être disponible sur IPv6. Cactus doit annoncer un préfixe IPv6, et la relation en amont doit le transporter. Aucune de ces preuves de route publique n’existe pour AS135632 à la date de publication.

Même si Cactus ajoutait IPv6 demain, la diversité des familles d’adresses ne créerait pas nécessairement une diversité physique. IPv4 et IPv6 peuvent traverser le même routeur, la même radio, la même fibre, le même transfert et le même ASN en amont. Une perte de puissance ou une coupure à ce point commun supprimerait les deux. Inversement, IPv6 délivré sur un chemin indépendamment alimenté et routé pourrait préserver certaines applications double pile lors d’une panne de routage spécifique à IPv4. Le bénéfice dépend de l’implémentation, pas de la présence d’une allocation IPv6 seule.

Le propre état de route de MUX prouve que le voisin visible est capable d’annoncer IPv6. Il ne prouve pas que MUX offre à Cactus un service IPv6, que Cactus en a demandé un, ou que l’équipement client est prêt. L’absence à la date de publication est donc spécifique: aucune route IPv6 originaire de Cactus n’était visible. La raison, le plan de déploiement et l’effet client sont inconnus.

Cela importe économiquement aussi bien que techniquement. Un petit pool IPv4 peut encourager le partage d’adresses, compliquant les services entrants, la gestion des abus et l’attribution aux clients. IPv6 peut réduire la rareté des adresses et améliorer la joignabilité de bout en bout pour les services compatibles. Pourtant, le déploiement nécessite un support sur site client, une surveillance, une politique de sécurité, une pratique du personnel et une préparation du service d’assistance. Pour un fournisseur régional, le test n’est pas « le fournisseur en amont supporte-t-il IPv6?

» mais « un client peut-il l’utiliser, les opérations peuvent-elles le diagnostiquer, et survit-il à une panne définie? »

Le dernier kilomètre est suggéré, pas cartographié

Cactus se présente comme un fournisseur d’accès local plutôt qu’une coquille de routage pure. Sa page de services sépare la connectivité résidentielle, professionnelle et personnalisée. La page de services aux entreprises traite du haut débit dédié, de la gestion de réseau et de la connectivité sécurisée. La page d’accueil fait référence à un réseau sans fil tout IP et demande aux utilisateurs de vérifier les tours dans leur localité.

Ces descriptions soutiennent une large inférence selon laquelle Cactus a commercialisé un accès de dernier kilomètre et d’entreprise, y compris la livraison sans fil. Elles n’établissent pas un nombre actuel de tours, un itinéraire de fibre, un parc de poteaux, une détention de spectre sous licence, un inventaire d’équipements chez le client ou une limite de service. Le résidu de thème préconfiguré du site rend ses pourcentages, totaux d’abonnés et langage de couverture large particulièrement faibles.

Un document plus concret mais historique est une proposition de Cactus datée du 25 septembre 2020, téléchargée publiquement sur Scribd. Elle proposait un lien point à point avec un débit d’information garanti de 20 Mbps à Lahore utilisant deux antennes de 34 dBi et deux unités AirFiber 5 GHz. Elle prévoyait deux jours pour l’installation, incluait la maintenance récurrente du lien et de la tour, faisait référence à l’enregistrement de fréquence, et attribuait une alimentation et une mise à la terre appropriées sur le site client au client.

La proposition est utile car elle décrit une conception commerciale réelle sous le nom de Cactus. Elle est limitée car elle a six ans, est spécifique à un circuit proposé, est hébergée par un tiers et ne prouve pas que le lien a été commandé, installé ou reste actif. Elle ne peut pas être extrapolée en une carte actuelle des tours de Cactus. Elle identifie cependant des surfaces de défaillance qui restent techniquement plausibles pour le sans fil fixe: ligne de vue, alignement d’antenne, accès au toit, santé radio, interférences, alimentation sur site client, mise à la terre et disponibilité d’équipement de remplacement.

Aucune source examinée ne fournit les coordonnées d’un relais ou d’une tour Cactus en exploitation. Les adresses de Garden Town dans les registres de l’entreprise et d’APNIC sont des emplacements de contact administratifs. L’adresse d’Al-Qadir dans la proposition de 2020 est une adresse de bureau historique. Aucune ne doit être tracée comme un nœud de réseau sans preuve distincte.

La fibre est également non résolue. Le site en direct utilise un langage de fibre, et un fournisseur peut livrer un accès fibre sans posséder chaque câble, conduit ou poteau. Le matériel public n’identifie pas si Cactus possède de la fibre d’accès, loue des dérivations, revend un autre opérateur, combine sans fil et fibre, ou confie les clients à une infrastructure tierce. Un chemin BGP via MUX ne peut pas répondre à cette question. L’adjacence logique pourrait se situer au-dessus de n’importe lequel de ces arrangements physiques.

L’alimentation électrique et la réparation sur le terrain décident si une route est utilisable

La diversité de routage n’a de valeur que si l’équipement qui l’utilise reste alimenté et réparable.

Considérons quatre pannes. Si une radio de toit perd de l’alimentation mais que le bord de Cactus continue d’annoncer les trois préfixes, la table de routage globale peut sembler saine tandis que les clients derrière ce relais sont hors ligne. Si la session de bord vers MUX échoue tandis que le réseau d’accès reste alimenté, les liens locaux peuvent rester actifs mais les destinations externes peuvent disparaître. Si les circuits nominal et alternatif entrent dans le même bâtiment et qu’un seul événement d’alimentation local désactive le routeur partagé, deux contrats ne produisent aucune diversité utilisable.

Si une tempête déplace une antenne point à point, la capacité en amont de réserve ne restaure pas la ligne de vue.

La proposition sans fil de 2020 faisait explicitement de l’alimentation et de la mise à la terre sur le site client une condition de mise en service et excluait les dommages causés par les surtensions, fluctuations ou mise à la terre inadéquate. Cette limite contractuelle est opérationnellement importante. Elle suggère qu’au moins une conception historique de Cactus dans laquelle la disponibilité du service dépendait en partie des conditions électriques contrôlées par le client.

Elle ne révèle pas si Cactus fournissait une alimentation sans interruption, des batteries ou une protection contre les surtensions ailleurs, ou quelle autonomie avait un système de secours.

Un accord de services de support distinct daté de décembre 2020, également téléchargé publiquement, décrivait d’abord un diagnostic à distance, puis une visite sur site si le travail à distance échouait. Il listait un numéro de support, plusieurs contacts techniques et une séquence d’escalade de gestion. C’est la preuve que Cactus a documenté une pratique d’escalade sur le terrain pour un client à ce moment-là. Ce n’est pas un effectif actuel, un engagement de panne réseau ou la preuve que les mêmes personnes, horaires et délais de réponse couvrent les clients haut débit en 2026.

La page de contact actuelle de Cactus liste une adresse Awami Complex à Garden Town, un numéro de téléphone, un email et des heures de bureau de 9h à 17h. Le site ailleurs prétend un support étendu ou 24h/24. Parce que les mêmes pages contiennent du contenu préconfiguré sans rapport, la promesse de support exacte nécessite une confirmation dans un contrat client actuel.

Pour un petit opérateur, la main-d’œuvre locale peut être la réserve effective. Une radio de rechange dans un placard n’est utile que si quelqu’un peut identifier l’unité défaillante, obtenir un accès au toit, traverser Lahore, aligner le remplacement en toute sécurité et clôturer le défaut. Une deuxième session de transit n’est utile que si quelqu’un la surveille, maintient la parité de politique et remarque quand elle a silencieusement cessé d’accepter un préfixe. Le nombre de techniciens est moins important que la couverture testée des compétences, des quarts de travail, des permissions d’accès et des pièces de rechange.

Aucune de ces quantités n’est publique pour Cactus. Il n’existe pas de série de temps moyen de réparation actuelle, de planning d’astreinte, d’inventaire des pièces de rechange, de plan d’accès au toit, d’autonomie de batterie, de politique de groupe électrogène, de réserve de carburant, de fenêtre de maintenance, de couverture de surveillance ou de compte rendu post-incident. Leur absence dans le matériel public n’est pas la preuve de faibles opérations. Cela signifie qu’un client ne peut pas évaluer la résilience à partir du site Web et de la table BGP seuls.

La sécurité de l’origine des routes est un test différent

Tous les trois préfixes actuels ont renvoyé un résultatunknowndu service de validation d’origine de route de RIPE:103.77.9.0/24,116.206.164.0/24et116.206.167.0/24. Aucune autorisation d’origine de route validante n’a été renvoyée.

La validation d’origine, décrite dans la RFC 6811, permet à un routeur de comparer un préfixe annoncé et un ASN d’origine avec des données d’autorisation cryptographiquement vérifiables. Un état inconnu n’est pas une route invalide. Cela signifie que le système de validation n’a pas trouvé d’autorisation de couverture qui rendait l’annonce valide ou invalide.

Publier des autorisations correctes pourrait réduire une classe de risque de routage: un autre réseau annonçant accidentellement ou malveillant l’espace de Cactus. Cela ne créerait pas un deuxième fournisseur en amont, n’ajouterait pas de bande passante, n’alimenterait pas une radio ou ne raccourcirait pas un trajet de réparation. La disponibilité et la sécurité de l’origine des routes doivent donc être mesurées séparément. Un réseau résilient peut encore avoir une protection d’origine faible, et une route parfaitement autorisée peut encore disparaître lorsque son seul transfert utilisable tombe en panne.

Une affirmation de résilience testable a cinq parties

Cactus n’a pas besoin de révéler des diagrammes sensibles pour rendre sa résilience évaluable. Il doit publier ou fournir des réponses vérifiables aux limites où les pannes se propagent.

1. Exporter les mêmes routes via une alternative réellement utilisable

Pour chacun des trois /24 actuels, identifier les arrangements de routage externe normaux et alternatifs. Si les deux sessions sont avec AS141421, indiquer si elles se terminent sur des routeurs Cactus différents, des dispositifs MUX différents, des sites de transfert différents et des circuits d’accès physiquement indépendants. Si un second système autonome existe, montrer que chaque préfixe est accepté et propagé à travers lui.

Effectuer ensuite un retrait contrôlé de la session normale. Mesurer le temps jusqu’à ce que les sondes externes retrouvent une joignabilité stable via l’alternative. Tester les trois routes, pas une seule adresse représentative. Enregistrer si les sessions client avec état survivent, si les pools de traduction changent, et si les chemins de retour restent utilisables.

La réponse de 2023 concernant deux fournisseurs en amont rend ce test particulièrement raisonnable. Un acheteur devrait demander des preuves actuelles plutôt que de supposer qu’une réponse d’offre vieille de trois ans décrit encore le bord de production.

2. Séparer la diversité logique de la diversité physique

Documenter les sites de transfert et les points de défaillance communs à un niveau adapté au client. Deux sessions BGP sur un seul routeur ne sont pas une diversité de routeur. Deux circuits dans un seul conduit ne sont pas une diversité de route. Deux radios sur une seule alimentation non protégée ne sont pas une diversité d’alimentation. Deux fournisseurs qui dépendent tous deux du même tronçon de gros peuvent ne pas être une diversité de fournisseur au point qui importe.

Le chemin AS public ne peut résoudre aucune de ces conditions. Cactus et ses fournisseurs le peuvent, via des identifiants de circuit, des enregistrements de démarcation, des déclarations d’entrée diversifiée et un exercice de défaillance contrôlée.

3. Traiter IPv6 comme un service opérationnel

Un plan IPv6 devrait inclure un espace alloué, une autorisation de route, un transport en amont, une délégation client, un comportement de résolveur, une politique de pare-feu, une surveillance et un support. Un pilote devrait prouver que les clients double pile atteignent des destinations de test indépendantes via les deux familles et qu’un défaut spécifique à une famille ne provoque pas de délai d’application inacceptable.

Si IPv4 et IPv6 partagent le même transfert physique, le dire. La deuxième famille améliore encore la disponibilité des adresses et la portée du protocole, mais elle ne doit pas être vendue comme une protection contre une panne de circuit ou d’alimentation commune.

4. Mesurer l’alimentation électrique à chaque dépendance

Indiquer l’autonomie de secours en charge pour le routeur de bord, le transfert en amont, le commutateur d’accès, la radio de relais et l’équipement chez le client inclus dans le service. Tester les batteries plutôt que de citer la capacité nominale. Identifier quel côté est responsable de la mise à la terre, de la protection contre les surtensions et du remplacement. Si un groupe électrogène est utilisé, enregistrer le comportement de démarrage, la disponibilité du carburant et la charge réellement supportable.

La proposition historique montre pourquoi cette limite importe: un service peut être techniquement mis en service tout en laissant une dépendance électrique décisive au client.

5. Intégrer la réparation sur le terrain dans la promesse de service

Définir quand le délai de réparation commence, quelles preuves ouvrent un défaut, quels horaires sont couverts et quels événements interrompent le délai. Détenir des radios compatibles, des unités d’alimentation, des optiques et des routeurs en quantités connues. Vérifier l’accès aux toits et aux sites clients en dehors des heures de bureau. Exercer l’escalade lorsque le diagnostic à distance échoue.

Un engagement de support actuel devrait remplacer l’inférence de l’accord de 2020 et du site Web de qualité mitigée. Les clients ont besoin de la réponse applicable à leur circuit, pas d’une matrice de contact ancienne pour un autre service.

Qui supporte la panne

L’effet d’un bord étroit diffère selon le client.

Un utilisateur résidentiel derrière une traduction d’adresse peut voir chaque application externe échouer en même temps lorsque les routes publiques disparaissent, tandis qu’un voisin sur un réseau mobile peut encore charger le site de support de Cactus. Une entreprise utilisant une adresse publique de Cactus peut perdre son VPN entrant, ses services hébergés ou ses caméras distantes dès que la route est retirée. Un client de connectivité gérée peut conserver un lien d’accès et une gestion de réseau local mais perdre le chemin Internet inclus dans le contrat.

Une institution achetant un service point à point pourrait rester connectée entre deux sites locaux même si le transit global échoue, selon où ce circuit est commuté. Aucun de ces designs de service n’est confirmé pour un client actuel nommé.

L’opérateur porte également un risque de communication particulier. Parce que son site Web et sa messagerie sont hébergés en externe, la surface de statut public peut survivre à une panne d’AS135632. C’est potentiellement utile: Cactus peut publier des mises à jour depuis une connexion non affectée. Cela peut aussi être trompeur si aucune page de statut ne distingue « notre site Web est en ligne » de « les routes de nos abonnés sont joignables ». Un simple service de statut hébergé en externe avec des sondes indépendantes pour les trois préfixes transformerait cette séparation en un avantage opérationnel.

L’économie est également asymétrique. Maintenir un deuxième fournisseur en amont, des routeurs de rechange, des batteries et un stock de terrain coûte de l’argent même lorsque rien ne tombe en panne. Un petit parc d’adresses publiques ne révèle pas si la base de revenus peut supporter cette réserve. Il ne prouve pas non plus que Cactus est petite en termes d’abonnés; la traduction peut placer de nombreux utilisateurs derrière peu d’adresses. Ce que l’on peut dire, c’est que trois routes publiques concentrent la panne observable dans un ensemble compact. Surveiller chaque préfixe depuis plusieurs réseaux externes est techniquement simple.

Le niveau de preuve est Moyen, avec une limite physique marquée

Cactus Network Solutions a plus de preuves opérationnelles publiques que son site Web mince ne le suggère au premier abord. AS135632 est actuellement visible. Trois /24 IPv4 ont été observés en continu dans la première quinzaine de juillet. Des centaines de chemins de collecteurs atteignaient chaque route. APNIC maintient les enregistrements de l’organisation et des contacts d’intervention. Le domaine public et les canaux de contact fonctionnent.

Des documents commerciaux historiques montrent Cactus offrant des liens sans fil et un support sur site, et une évaluation officielle des achats enregistre l’entreprise comme un soumissionnaire télécom responsable en 2023.

Les preuves de routage sont solides pour la proposition étroite qu’elles soutiennent. AS135632 a annoncé trois /24 IPv4 à 08h00 UTC le 16 juillet 2026; aucune route IPv6 n’était visible; et chaque chemin collecté entrait via AS141421. L’historique est également clair que le nombre de voisins et de routes a changé.

Les preuves physiques et de récupération sont faibles. Il n’y a pas de carte actuelle vérifiée de la fibre d’accès, des tours, des relais sur les toits, des bâtiments de transfert ou des chemins d’entrée diversifiée. Il n’y a pas d’engagement de transit public, de niveau d’utilisation, de nombre de clients, d’autonomie de secours, de stock de pièces de rechange ou de performance de réparation. L’ancienne proposition et l’accord de support identifient des dépendances plausibles sans prouver la conception actuelle.

C’est exactement pourquoi le titre est un test plutôt qu’un verdict. Un voisin visible ne prouve pas un câble. Trois /24 ne prouvent pas une petite entreprise. Aucun IPv6 ne prouve pas une panne imminente. Mais si la session transportant ces routes s’arrête et qu’aucune annonce alternative n’apparaît, l’espace d’adressage public de Cactus n’a nulle part ailleurs d’aller visible. Le site Web peut rester en ligne dans un autre ASN; le sort du réseau client sera décidé par des circuits, des routeurs, des radios, de l’alimentation électrique et des personnes que Cactus n’a pas rendus inspectables publiquement.

La preuve décisive serait un basculement contrôlé observé de l’extérieur: chaque /24 reste joignable via une alternative utilisable indépendamment, le trafic client continue dans un intervalle de récupération donné, le service double pile est testé là où il est proposé, et l’équipement sous les deux chemins survit au même exercice. D’ici là, la résilience de Cactus n’est pas réfutée. C’est simplement une affirmation opérationnelle qui attend le seul test que sa table de routage publique rend impossible à éviter.