5. Considérations de mise en œuvre du routage

Considérations de mise en œuvre du routage

Avec le passage des numéros de réseau classful aux préfixes classless, il n'est pas possible de déduire le masque de réseau à partir du motif de bits initial d'une adresse IPv4. Cela a des implications sur la manière dont les informations de routage sont stockées et propagées. Les masques de réseau ou les longueurs de préfixe doivent être explicitement transportés dans les protocoles de routage. Les protocoles de routage intérieur, tels que OSPF [RFC2328], Système intermédiaire à système intermédiaire (IS-IS) [RFC1195], RIPv2 [RFC2453], et le protocole de routage intérieur amélioré (EIGRP) de Cisco, ainsi que le protocole de routage extérieur BGP4 [RFC4271], prennent tous en charge cette fonctionnalité, ayant été développés ou modifiés dans le cadre du déploiement du routage inter-domaines sans classe au cours des années 1990.

Les anciens protocoles de routage intérieur, tels que RIP [RFC1058], HELLO, et le protocole de routage intérieur de Cisco (IGRP), et les anciens protocoles de routage extérieur, tels que le protocole de passerelle extérieure (EGP) [RFC904], ne prennent pas en charge le transport explicite de la longueur de préfixe/masque et ne peuvent donc pas être utilisés efficacement sur l'Internet autrement que dans des configurations d'extrémité (stub) très limitées. Bien que leur usage puisse être approprié dans de simples configurations héritées de sites terminaux, ils sont considérés comme obsolètes et ne DOIVENT PAS être utilisés dans des réseaux de transit connectés à l'Internet global.

De même, les tables de routage et de transfert dans les équipements réseau de couche 3 doivent être organisées pour stocker à la fois le préfixe et la longueur de préfixe ou le masque. Un équipement qui organise ses informations de routage/transfert selon les conventions héritées de réseau/sous-réseau de classe A/B/C ne peut pas être censé fonctionner correctement sur des réseaux connectés à l'Internet global ; l'usage d'un tel équipement n'est pas recommandé. Heureusement, très peu de tels équipements sont utilisés aujourd'hui.

5.1. Règles pour l'annonce de routes

Le transfert dans l'Internet est effectué sur la base de la correspondance la plus longue. Cela implique que les destinations qui sont multi-hébergées par rapport à un domaine de routage doivent toujours être annoncées explicitement dans ce domaine de routage (c'est-à-dire qu'elles ne peuvent pas être résumées). Si un réseau est multi-hébergé, tous ses chemins vers un domaine de routage qui est « plus élevé » dans la hiérarchie des réseaux doivent être connus du réseau « plus élevé ».
Un routeur qui génère une route agrégée pour plusieurs routes plus spécifiques doit rejeter les paquets qui correspondent à la route agrégée, mais à aucune des routes plus spécifiques. En d'autres termes, le « saut suivant » pour la route agrégée devrait être la destination nulle. Cela est nécessaire pour empêcher la formation de boucles de transfert lorsque certaines adresses couvertes par l'agrégat ne sont pas accessibles.

Notez qu'en cas de défaillances, un routage partiel du trafic vers un site qui prend son espace d'adressage auprès d'un fournisseur de services mais qui n'est en réalité accessible que via un autre (c'est-à-dire le cas d'un site ayant changé de fournisseur de services) peut survenir parce que ce trafic sera transféré le long du chemin annoncé par la route agrégée. La règle n° 2 empêchera la mauvaise livraison des paquets en amenant ce trafic à être rejeté par l'annonceur de la route agrégée, mais la sortie de « traceroute » et d'autres outils similaires suggérera qu'un problème existe au sein de ce réseau plutôt que dans le réseau qui n'annonce plus le préfixe plus spécifique. Cela peut prêter à confusion ceux qui tentent de diagnostiquer des problèmes de connectivité ; voir l'exemple de la section 6.2 pour plus de détails. Une solution à ce « problème » perçu dépasse le cadre du présent document ; elle réside dans une meilleure éducation de la communauté utilisateur/opérateur, et non dans la technologie de routage.

Une implémentation suivant ces règles doit également être généralisée, afin qu'un numéro de réseau et un masque arbitraires soient acceptés pour toutes les destinations de routage. La seule contrainte restante est que le masque doit rester contigu. Notez que la route dégénérée vers le préfixe 0.0.0.0/0 est utilisée comme route par défaut et DOIT être acceptée par toutes les implémentations. En outre, pour se protéger contre des annonces accidentelles de cette route via le protocole inter-domaines, cette route ne doit être annoncée à un autre domaine de routage que lorsqu'un routeur est explicitement configuré pour le faire, jamais comme une option « par défaut » non configurée.

5.2. Fonctionnement des règles

La règle n° 1 garantit que l'algorithme de transfert utilisé est cohérent entre les protocoles de routage et les implémentations. Les réseaux multi-hébergés sont toujours annoncés explicitement par chacun des fournisseurs de services par lesquels ils sont routés, même s'ils sont un sous-ensemble spécifique de l'agrégat d'un fournisseur de services (s'ils ne le sont pas, ils doivent clairement être annoncés explicitement). Il pourrait sembler que le fournisseur de services « principal » pourrait annoncer le site multi-hébergé implicitement comme partie de son agrégat, mais le transfert à correspondance la plus longue empêche cela de fonctionner. Plus de détails sont fournis dans [RFC4116].

La règle n° 2 garantit qu'aucune boucle de routage ne se forme due à l'agrégation. Considérons un site auquel a été attribué 192.168.64/19 par son fournisseur « parent », qui possède 192.168.0.0/16. Le réseau « parent » annoncera 192.168.0.0/16 au réseau « enfant ». Si le réseau « enfant » venait à perdre sa connectivité interne vers 192.168.65.0/24 (qui fait partie de son agrégat), le trafic en provenance du « parent » vers le « enfant » ayant pour destination 192.168.65.1 suivra la route annoncée par le « enfant ». Lorsque ce trafic atteint le « enfant », cependant, le enfant ne doit pas suivre la route 192.168.0.0/16 de retour vers le « parent », car cela entraînerait une boucle de transfert. La règle n° 2 stipule que le « enfant » ne peut pas suivre une route moins spécifique pour une destination qui correspond à l'une de ses propres routes agrégées (généralement, cela est implémenté en installant une route « discard » ou « null » pour tous les préfixes agrégés qu'un réseau annonce à un autre). Notez que la gestion de la route « par défaut » (0.0.0.0/0) est un cas spécial de cette règle ; un réseau ne doit pas suivre la route par défaut vers des destinations qui font partie de l'une de ses annonces agrégées.

5.3. Note sur les formats de filtres de préfixe

Les systèmes qui traitent les annonces de routes doivent être capables de vérifier que les informations qu'ils reçoivent sont acceptables selon les règles de politique. Les implémentations qui filtrent les annonces de routes doivent autoriser des masques ou des longueurs de préfixe dans les éléments de filtre. Ainsi, les éléments de filtre qui étaient auparavant spécifiés comme

  accept 172.16.0.0

  accept 172.25.120.0.0

  accept 172.31.0.0

  deny 10.2.0.0

  accept 10.0.0.0

ressemblent maintenant à quelque chose comme ceci :

  accept 172.16.0.0/16

  accept 172.25.0.0/16

  accept 172.31.0.0/16

  deny 10.2.0.0/16

  accept 10.0.0.0/8

Cela ne fait que rendre explicite le masque de réseau qui était implicite dans la classification de classe A/B/C des numéros de réseau. Il est également utile d'améliorer la capacité de filtrage pour permettre la correspondance d'un préfixe et de tous les préfixes plus spécifiques ayant le même motif de bits ; heureusement, cette fonctionnalité a été implémentée par la plupart des fournisseurs d'équipements utilisés sur l'Internet.

5.4. Responsabilité et configuration de l'agrégation

Dans des circonstances normales, un domaine de routage (ou « système autonome ») auquel a été alloué ou attribué un ensemble de préfixes a la seule responsabilité de l'agrégation de ces préfixes. Dans le cas habituel, l'AS installera une configuration dans un ou plusieurs de ses routeurs pour générer des routes agrégées basées sur des routes plus spécifiques connues de son système de routage interne. Ces routes agrégées sont annoncées dans le système de routage global par les routeurs de bordure pour le domaine de routage. Les routes internes plus spécifiques qui chevauchent les routes agrégées ne doivent pas être annoncées globalement. Dans certains cas, un AS peut souhaiter déléguer la responsabilité d'agrégation à un autre AS (par exemple, un client peut souhaiter que son fournisseur de services génère des informations de routage agrégées en son nom) ; dans de tels cas, l'agrégation est effectuée par un routeur dans le second AS selon les routes qu'il reçoit du premier, combinées avec des informations de politique configurées décrivant comment ces routes doivent être agrégées.

Notez qu'un fournisseur peut choisir d'effectuer une agrégation sur les routes qu'il reçoit d'un autre sans accord explicite ; cela est appelé « agrégation par procuration » (proxy aggregation). Cela peut être un outil utile pour réduire la quantité d'état de routage qu'un AS doit transporter et propager à ses clients et voisins. Cependant, l'agrégation par procuration peut également créer des conséquences non intentionnelles dans l'ingénierie de trafic. Considérez ce qui se passe si les AS 2 et 3 reçoivent tous deux des routes de l'AS 1 mais que l'AS 2 effectue une agrégation par procuration tandis que l'AS 3 ne le fait pas. Les autres AS qui reçoivent des informations de routage de transit à la fois de l'AS 2 et de l'AS 3 verront une vue incohérente des informations de routage originaires de l'AS 1. Cela peut provoquer un déplacement inattendu du trafic vers l'AS 1 via l'AS 3 pour les clients de l'AS 3 et tous autres recevant des routes de transit de l'AS 3. Parce que l'agrégation par procuration peut causer des conséquences inattendues pour des parties de l'Internet qui n'ont aucune relation avec ni la source des routes agrégées ni la partie fournissant l'agrégation, elle doit être utilisée avec une extrême prudence.

La configuration des routes à combiner en agrégats est une implémentation de la politique de routage et nécessite des informations maintenues manuellement. En ajout à aux informations qui doivent être maintenues pour un ensemble de préfixes routables, la configuration d'agrégation n'est généralement qu'une ligne ou deux définissant la plage du bloc d'adresses IPv4 à agréger. Un site effectuant sa propre agrégation le fait pour des blocs d'adresses qui lui ont été attribués ; un site effectuant une agrégation au nom d'un autre connaît cette information grâce à un accord de délégation d'agrégation. En supposant que la meilleure pratique courante pour les administrateurs réseau est d'échanger des listes de préfixes à accepter les uns des autres, la configuration des informations d'agrégation n'introduit pas de surcharge administrative supplémentaire significative.

La génération d'une route agrégée est généralement spécifiée soit statiquement, soit en réponse à l'apprentissage d'une route dynamique active pour un préfixe contenu dans la route agrégée. Si une telle annonce de route agrégée dynamique est effectuée, il faut veiller à ce que les routes ne soient pas excessivement ajoutées ou retirées (ce qu'on appelle le « flapping » de routes). En général, une annonce de route agrégée dynamique est ajoutée lorsqu'au moins un composant de l'agrégat devient accessible et elle n'est retirée que lorsque tous les composants deviennent inaccessibles. Correctement configurées, les routes agrégées sont plus stables que les routes non agrégées et améliorent ainsi la stabilité du routage global.

Note d'implémentation : L'agrégation de l'espace d'adressage de « classe D » (multicast) dépasse le cadre du présent document.

5.5. Propagation de routes et considérations sur les protocoles de routage

Avant le déploiement initial du CIDR, la pratique courante consistait à propager les routes apprises via les protocoles de routage extérieur (c'est-à-dire EGP ou BGP) à travers le protocole de routage intérieur d'un site (généralement OSPF, IS-IS, ou RIP). Cela était fait pour assurer que des points de sortie cohérents et corrects étaient choisis pour le trafic à envoyer à une destination apprise via ces protocoles. Quatre effets évolutifs — l'avènement du CIDR, la croissance explosive de l'état de routage global, l'adoption généralisée de BGP4, et une exigence de propager l'information de chemin complet — se sont combinés pour rendre cette pratique obsolète. Pour assurer une propagation correcte du chemin et empêcher une incohérence de routage inter-AS (le mécanisme de détection/prévention de boucles de BGP4 exige la propagation du chemin complet), les réseaux de transit doivent utiliser le BGP interne (iBGP) pour transporter les routes apprises d'autres fournisseurs à la fois au sein et à travers leurs réseaux.