Résumé

  • Un message publié sur la liste AfNOG le 20 juillet à 10 h 48 UTC a fourni une commande simple pour faire remonter les doublons de as-TelOneZW.
  • Une nouvelle requête auprès d’AFRINIC retrouve 24 lignes de membres pour 21 ASN uniques: AS37183 est présent trois fois et AS37123 deux fois.
  • Dans la logique d’un ensemble RPSL, ces répétitions n’ajoutent aucun membre distinct. Elles ne prouvent ni panne, ni fuite de route, ni rejet de préfixe.
  • AFRINIC indique que des opérateurs amont et de transit interrogent les IRR pour actualiser leurs filtres; l’anomalie mérite donc un contrôle de maintenance, sans dramatisation.

Trois lignes de plus, zéro réseau de plus.

C’est toute la portée — et tout l’intérêt — d’un court message envoyé lundi sur la liste de l’African Network Operators Group. S. Moonesamy a interrogé le service WHOIS d’AFRINIC, trié les membres de as-TelOneZW, puis placé les occurrences multiples en tête. Le résultat fait apparaître AS37183 à trois reprises et AS37123 à deux reprises.

Le message ne donne pas de cause. Son auteur estime même qu’une explication plausible existe probablement, sans la préciser. Une vérification effectuée par BTW après sa publication reproduit l’état actuel: 24 déclarations de membres, 21 numéros d’AS distincts. L’objet porte la description « TelOne ASNs », dépend de AS8668-MAINTAINER et a pour source AFRINIC.

Il ne s’agit pas d’un bulletin de panne. C’est un cas vérifiable où le texte de la politique contient plus d’occurrences que de sens opérationnel.

Le doublon alourdit l’objet, pas l’ensemble

Le RFC 2622 décrit un as-set comme un ensemble dont l’attribut members énumère des numéros d’AS ou d’autres ensembles. Sur ce plan, trois occurrences d’AS37183 ne créent pas trois systèmes autonomes. Deux occurrences d’AS37123 n’en créent pas deux. Le périmètre unique reste fixé à 21.

La conclusion technique immédiate doit donc rester étroite. Ni le message AfNOG ni la fiche en ligne ne signalent une route filtrée, une origine erronée, un changement de trafic ou une configuration cassée. Une expansion qui respecte la sémantique de l’ensemble ne devrait pas tirer un nouvel ASN distinct d’une ligne répétée.

Cela ne signifie pas que tous les logiciels traitent le texte de la même façon. Certains dédupliquent avant de produire une configuration; d’autres peuvent conserver les lignes brutes dans des fichiers intermédiaires, des journaux, des comparaisons ou des tableaux de bord. Les sources prouvent une redondance en entrée, pas le comportement de chaque consommateur.

Les deux ASN répétés renvoient par ailleurs à des organisations différentes. Les données AFRINIC associent AS37183 à Utande Internet Services (Pvt) Ltd et AS37123 à Telecontract Pvt Ltd, au Zimbabwe. Leur présence dans un ensemble nommé d’après TelOne ne suffit pas à établir une propriété, une filiale ou la nature actuelle de leur relation commerciale. Un AS-set décrit un périmètre de politique de routage, pas un organigramme.

Une anomalie bénigne peut révéler un contrôle absent

Les objets d’Internet Routing Registry occupent une position particulière: ils expriment une intention de routage sous une forme qu’un système peut transformer en contrôle. Le RFC 2622 prévoit que RPSL décrive la politique au niveau d’un AS avec assez de précision pour contribuer à des configurations de routeurs. Le guide public d’AFRINIC précise que des fournisseurs amont et de transit interrogent les registres afin d’actualiser les filtres et de renforcer la cohérence des annonces BGP.

Rien ne prouve que les filtres issus de cet objet soient faux. Le doublon montre plutôt qu’une donnée peut dériver tout en conservant le même résultat mathématique.

C’est justement ce qui rend l’exemple utile. La répétition est facile à ignorer puisqu’elle est souvent sans effet: un membre ou trois copies désignent le même membre. Mais elle peut aussi être la trace d’un processus qui ajoute sans réconcilier, de deux chemins de mise à jour concurrents ou de l’absence d’un contrôle final. Ces scénarios restent des hypothèses. Le message ne contient ni historique de modification ni diagnostic.

La question de gouvernance n’est donc pas de savoir si ce doublon a « cassé Internet ». Elle consiste à demander quelle autre erreur passerait par le même chemin de maintenance. Un ASN valide répété pardonne beaucoup. Un membre périmé, absent ou imbriqué par erreur pourrait produire un résultat bien différent.

Vérifier l’intention avant de nettoyer le texte

Une correction sérieuse commence par confirmer les 21 membres distincts. Le mainteneur doit vérifier qu’ils appartiennent encore tous au périmètre voulu, comprendre l’origine des trois lignes superflues puis, le cas échéant, publier un objet nettoyé. Supprimer les doublons sans valider l’intention rendrait la fiche plus jolie, pas nécessairement plus juste.

Le contrôle suivant doit distinguer représentation et expansion. Il peut comparer le nombre de lignes au nombre de membres directs uniques, développer les ensembles imbriqués, conserver l’historique et produire des alertes séparées pour les doublons, objets manquants, ajouts inattendus ou échecs d’expansion. La documentation de la base RIPE montre pourquoi l’expansion récursive mérite son propre test: le résultat final ne se limite pas toujours aux lignes visibles dans un seul objet.

Enfin, un opérateur qui fabrique des filtres à partir d’un IRR gagne à conserver la provenance: registre interrogé, heure de la requête, méthode d’expansion et état de revue. Cette traçabilité ne rend pas la base infaillible. Elle permet d’expliquer une entrée défectueuse avant qu’elle ne devienne une configuration opaque.

Le message AfNOG démontre ainsi la valeur d’un contrôle peu coûteux. Les trois lignes redondantes ne changent pas les 21 membres distincts. Elles suffisent néanmoins à tester si la politique de routage est réconciliée, relue et observable avant l’arrivée d’une erreur moins tolérante.

Sources