Mon blog

Le groupe de travail rtgwg de l'IETF travaille entre autre à définir des protocoles et des méthodes pour éliminer les micro-boucles lors d'un changement des routes dans un réseau IP. Une micro-boucle est la boucle temporaire qui se forme entre deux (parfois davantage) routeurs lorsqu'ils n'ont pas mis à jour leur table de routage pile en même temps. Pendant quelques secondes, le routeur A envoie les paquets à B, qui les envoie à A, qui les envoie à B... Notre RFC 5715 explique le problème, ses causes et ses effets, et expose les solutions existantes.

La section 1 rappelle le fonctionnement du routage IP. Les routeurs n'ont pas une vue commune du réseau. Lorsque celui-ci change, que ce soit suite à une « mauvaise nouvelle » (la rupture d'un câble) ou suite à une « bonne nouvelle » (l'ajout d'un nouveau lien), il faut un temps fini pour propager l'information à tous les routeurs et pour que ceux-ci mettent à jour leur FIB. Pendant ce temps de convergence, les routeurs ne fonctionnent pas sur une vision commune et les micro-boucles apparaissent. Les paquets vont alors tourner en rond, consommant de la capacité du réseau, avant d'être jetés lorsque leur TTL (Hop Count en IPv6) est terminé.

Ces micro-boucles sont-elles graves ? En général, les protocoles situés au dessus corrigent automatiquement. Mais de nouveaux services Internet pourraient être plus sensibles et souhaiteraient une transition sans douleur, sans délai et sans perte de paquets.

Cet idéal est évidemment utopique mais il existe quand même des méthodes pour améliorer les choses comme celles du RFC 4090 pour MPLS ou du RFC 5714 pour IP.

Parmi les voies possibles pour traiter le problème des micro-boucles, il y a des techniques de convergence suffisamment rapides pour que le problème soit minimal, ou bien des topologies du réseau qui rendent les micro-boucles rares ou impossibles.

La section 2 est consacrée à étudier plus en détail ce qu'est une micro-boucle et dans quelles conditions elles se forment. La micro-boucle est un phénomène temporaire, inévitable dans un paradigme de routage « saut après saut » qui est celui d'IP (chaque routeur ne se préoccupe que du saut suivant). Elle est « micro » par sa durée et par le petit nombre de routeurs en jeu (souvent seulement deux). La création d'une boucle nécessite au moins une des conditions suivantes :

• Liens dont les coûts sont asymétriques,
• Existence entre deux routeurs de deux chemins, de coût égal, avec des routeurs qui tranchent de manière différente lorsque deux chemins sont possibles et équivalents,
• Et surtout, ce qui est la cause des micro-boucles, changement de topologie du réseau, pendant la phase de transition. Ce changement est souvent une panne mais ce peut aussi être un ajout d'un nouveau lien, ou bien une action délibérée de l'administrateur réseaux, par exemple parce qu'il change le coût d'un lien.

Les micro-boucles ont deux conséquences :

• Consommation inutile de la capacité du réseau (un paquet peut passer 128 fois dans chaque sens, avant que son TTL n'expire),
• Risque pour la convergence des routeurs car le trafic des protocoles de routage, s'il est pris dans la boucle, risque de ne pas atteindre son destinataire, l'empêchant de mettre sa table à jour.

Que peut-on faire contre les micro-boucles ? C'est un travail pour la section 4 et des suivantes. Il existe plusieurs stratégies, limiter les dégâts, empêcher les boucles de se former, les supprimer quand elles apparaissent ou bien minimiser le risque d'occurrence (par exemple par des réseaux avec davantage de maillage). Elles sont détaillées dans les sections suivantes. D'abord, la section 5 explique comment limiter les dégâts, soit en accélérant la convergence du réseau, soit avec la méthode PLSN (Path Locking with Safe Neighbors), non encore décrite dans un RFC (mais résumée en section 7), qui consiste à tenir compte de l'état du réseau avant et après le changement avant de choisir d'envoyer dorénavant du trafic à un voisin. La simulation montre que cette méthode est efficace mais elle ne fait que limiter les micro-boucles, pas les empêcher.

Et la prévention ? La section 6 est là pour ça. Elle ne liste pas moins de huit méthodes pouvant empêcher les micro-boucles de se former. Mais toutes ne sont pas réalistes. Parmi elles :

• Au lieu de faire passer d'un coup le coût d'un lien coupé de N à « infini », l'incrémenter doucement. L'analyse montre que cela suffira (section 6.1).
• Divers systèmes d'overlays ou de tunnels (sections 6.2 à 6.4). Cela aurait évidemment les inconvénients habituels des tunnels (comme la faible performance de beaucoup de routeurs avec ce type de trafic).
• La cause fondamentale des micro-boucles étant le manque d'information, on pourrait aussi marquer les paquets pour indiquer par où ils sont passés, ce qui permettrait de détecter facilement qu'un paquet est déjà passé et qu'il y a donc une boucle (section 6.5). Mais cela compliquerait les routeurs de manière non-standard.
• On pourrait enfin introduire davantage de synchronisation entre les mises à jour des FIB de chaque routeur (sections 6.7 et 6.8). Actuellement, le changement de FIB se fait dans chaque routeur indépendamment. On pourrait imaginer que chaque routeur calcule la nouvelle FIB (sans l'installer), qu'un algorithme permette de sélectionner le moment du changement et, si tous les routeurs sont à l'heure avec NTP, ils basculeraient au même moment.

Et la suppression des boucles, une fois qu'elles sont formées ? Pour détecter la micro-boucle, La section 8 examine deux possibilités, une forme de mémoire des paquets déjà vus, dans le routeur (très consommatrice en ressources) et une méthode plus simple : détecter une boucle au fait qu'un paquet entre par l'interface où on le ferait sortir (mais cela ne marche que pour les boucles simples, symétriques).

Quel que soit le mécanisme adopté, il va falloir le déployer dans l'Internet existant et la section 9 rappelle donc l'importance de la compatibilité avec cet existant.

Enfin, une comparaison des différentes méthodes occupe la section 10. Plusieurs méthodes semblent réalistes pour les protocoles futurs.