Résumé

  • Dans son compte rendu du 13 octobre, LACNIC recommande de recevoir toutes les routes BGP sur fibre et seulement une route par défaut via LEO, afin que le satellite prenne le relais si la voie fibre tombe.
  • Cette règle ne détecte pas une coupure. LACNIC évoque des exercices, mais ne cite aucun déploiement opérateur, délai de retrait, test de capacité ou résultat de reprise.

Une politique de routage après la rencontre

CaribNOG 32 s’est tenu à Willemstad, à Curaçao, du 7 au 9 octobre. Dans un billet publié le 13 octobre, LACNIC indique qu’Alejandro Acosta et Nicolás Antoniello ont animé une séance technique après une introduction de Mark Kosters, directeur technique d’ARIN. Le compte rendu relie les conseils aux câbles sous-marins et aux aléas climatiques. C’est le récit de LACNIC, pas une enquête indépendante sur les réseaux insulaires.

La recommandation est concrète : disposer d’au moins une liaison sous-marine en fibre, de préférence plusieurs ; recevoir la table BGP complète par la fibre ; et n’accepter qu’une route par défaut sur une liaison satellite en orbite basse. Le satellite doit transporter le trafic si la voie fibre tombe. LACNIC avertit qu’un seul lien LEO pourrait ne pas suffire à plusieurs FAI, sans publier de capacité, de charge ni de test à l’appui.

Le retrait des routes reste à définir

Une route par défaut sert aux destinations sans entrée plus précise. Elle ne détecte pas une panne. Les routes fibre plus spécifiques restent normalement utilisées ; le trafic ne bascule sur la route satellite qu’après leur retrait ou un changement de politique. Si la panne laisse des routes obsolètes, le secours peut rester inutilisé et les paquets continuer vers une impasse.

Le signal de détection est donc décisif. La chute d’une interface suffit-elle ? L’opérateur attend-il la perte de la session BGP, s’appuie-t-il sur BFD ou utilise-t-il une sonde de service ? Combien de temps une route subsiste-t-elle ? Comment éviter les bascules répétées sur une liaison instable ? Le billet expose l’architecture visée, mais pas ces paramètres ni un essai en production.

Des outils aux fonctions distinctes

Le billet mentionne la validation d’origine RPKI, les protections contre les fuites BGP et BFD. La RFC 6811 vérifie que l’AS d’origine est autorisé pour un préfixe ; elle ne valide pas tout le chemin AS_PATH. Le mécanisme de la RFC 9234 dépend de rôles eBGP convenus entre voisins et du marquage des routes, avec une politique opérateur. Ces fonctions ne prouvent ni la joignabilité ni le déploiement.

LACNIC affirme que BFD peut ramener la détection d’environ 90 secondes à quelques millisecondes. La RFC 5880 fait dépendre ce délai des intervalles négociés et du multiplicateur de détection ; aucun minuteur configuré n’est donné. Le billet rappelle aussi que la découverte de la MTU IPv6 exige le passage des messages ICMPv6, dépendance décrite par la RFC 8201. LACNIC rapporte des exercices DNSSEC et RPKI : une preuve de formation, pas d’adoption en production.

Le dossier public établit une recommandation et des exercices. Il ne dit pas combien de réseaux l’appliquent, si la capacité LEO suffit pendant une coupure ni en combien de temps le trafic revient.

Sources : compte rendu de LACNIC ; programme de CaribNOG 32 ; RFC 6811 ; RFC 9234 ; RFC 5880 ; RFC 8201.