7. Propriétés de convergence du routage

Cette section examine les propriétés de convergence du routage dans la conception proposée. Il est avancé qu'une convergence subseconde est atteignable si l'implémentation prend en charge la désactivation rapide des sessions de peering EBGP et des mises à jour RIB et FIB opportunes en cas de panne de la liaison associée.

7.1. Délais de détection des pannes

BGP s'appuie typiquement sur un IGP pour contourner les pannes de liaison ou de nœud à l'intérieur d'un AS, et met en œuvre un mécanisme par sondage ou piloté par événements pour obtenir des mises à jour sur les changements d'état de l'IGP. La conception de routage proposée n'utilise pas d'IGP ; les mécanismes restants utilisables pour la détection des pannes sont donc le délai d'expiration des keep-alive BGP (ou tout autre mécanisme de keep-alive) et les déclencheurs de panne de liaison.

S'appuyer uniquement sur les paquets keep-alive BGP peut entraîner des délais de convergence élevés, de l'ordre de plusieurs secondes (sur de nombreuses implémentations BGP, la valeur minimale configurable du temporisateur d'attente BGP est de trois secondes). Toutefois, de nombreuses implémentations BGP peuvent fermer les sessions EBGP locales en réponse à l'événement « link down » sur l'interface sortante utilisée pour le peering BGP. Cette fonctionnalité est parfois appelée « fast fallover ». Comme les liaisons des centres de données modernes sont majoritairement des connexions point-à-point en fibre, une panne d'interface physique est souvent détectée en millisecondes et déclenche ensuite une reconvergence BGP.

Les liaisons Ethernet peuvent prendre en charge des normes de signalisation ou de détection de panne telles que Connectivity Fault Management (CFM) décrit dans [IEEE8021Q] ; cela peut rendre la détection de panne plus robuste. En variante, certaines plateformes peuvent prendre en charge Bidirectional Forwarding Detection (BFD) [RFC5880] pour permettre une détection de panne subseconde et une signalisation de panne vers le processus BGP. Toutefois, l'usage de l'un ou l'autre impose des exigences supplémentaires au logiciel et éventuellement au matériel des fournisseurs, et peut contredire REQ1. Jusqu'à récemment avec [RFC7130], BFD ne permettait pas non plus la détection de la panne d'un seul membre de liaison sur un LAG, ce qui aurait limité son utilité dans certaines conceptions.

7.2. Délais de propagation des événements

Dans la conception proposée, l'impact du MinRouteAdvertisementIntervalTimer BGP (temporisateur MRAI), spécifié à la Section 9.2.1.1 de [RFC4271], doit être pris en compte. Selon la norme, il est requis que les implémentations BGP espacent les messages BGP UPDATE consécutifs d'au moins MRAI secondes, valeur souvent configurable. Les messages BGP UPDATE initiaux après un événement portant des routes retirées ne sont en général pas affectés par ce temporisateur. Le temporisateur MRAI peut entraîner des délais de convergence importants lorsqu'un locuteur BGP « attend » que le nouveau chemin soit appris de ses pairs et ne dispose pas d'information de chemin de secours locale.

Dans une topologie Clos, chaque locuteur EBGP a typiquement soit un chemin (les dispositifs Tier 2 n'acceptent pas les chemins d'autres Tier 2 du même cluster en raison du même ASN), soit N chemins pour le même préfixe, où N est un nombre très grand, par ex. N=32 (le fan-out ECMP vers le tier suivant). Par conséquent, si une liaison vers un autre dispositif d'où un chemin est reçu tombe en panne, il n'y a soit aucun chemin de secours (par ex. du point de vue d'un commutateur Tier 2 perdant la liaison vers un dispositif Tier 3), soit le secours est immédiatement disponible dans le BGP Loc-RIB (par ex. du point de vue d'un dispositif Tier 2 perdant la liaison vers un commutateur Tier 1). Dans le premier cas, l'annonce de retrait BGP se propagera sans délai et déclenchera la reconvergence sur les dispositifs affectés. Dans le second cas, le meilleur chemin sera réévalué et le groupe ECMP local correspondant au nouvel ensemble de next hops sera modifié. Si le chemin BGP était le meilleur chemin précédemment sélectionné, un « implicit withdraw » sera envoyé via un message BGP UPDATE comme décrit en Option b à la Section 3.1 de [RFC4271] en raison du changement de l'attribut BGP AS_PATH.

7.3. Impact des fan-out de la topologie Clos

La topologie Clos présente de grands fan-out, ce qui peut affecter la convergence « du haut vers le bas » dans certains cas, comme décrit dans cette section. Lorsqu'une liaison entre un dispositif Tier 3 et Tier 2 tombe en panne, le dispositif Tier 2 enverra des messages BGP UPDATE à tous les dispositifs Tier 1 en amont, retirant les préfixes affectés. Les dispositifs Tier 1, à leur tour, relaieront ces messages à tous les dispositifs Tier 2 en aval (sauf l'originateur). Les dispositifs Tier 2 autres que celui à l'origine de l'UPDATE devraient alors attendre que TOUS les dispositifs Tier 1 en amont envoient un message UPDATE avant de retirer les préfixes affectés et d'envoyer l'UPDATE correspondant en aval vers les dispositifs Tier 3 connectés. Si le dispositif Tier 2 d'origine ou les dispositifs Tier 1 relais introduisent un délai dans leurs annonces UPDATE, le résultat peut être une « dispersion » des messages UPDATE pouvant durer plusieurs secondes. Pour éviter un tel comportement, les implémentations BGP doivent prendre en charge les « update groups ». Un « update group » est défini comme un ensemble de voisins partageant la même politique sortante : le locuteur local enverra les mises à jour BGP aux membres du groupe de façon synchrone.

L'impact d'une telle « dispersion » croît avec la taille du fan-out de la topologie et peut aussi croître sous une activité de convergence élevée sur le réseau. Certains opérateurs peuvent être tentés d'activer des fonctions de type « route flap dampening » que les fournisseurs incluent pour réduire l'impact plan de contrôle des préfixes qui clignotent rapidement. Toutefois, en raison des problèmes décrits avec des faux positifs dans ces implémentations, notamment lors de tels événements de « dispersion », il n'est pas recommandé d'activer cette fonctionnalité dans cette conception. Le contexte et les problèmes du « route flap dampening » ainsi que des changements d'implémentation possibles sont bien décrits dans [RFC7196].

7.4. Portée d'impact des pannes

Un réseau est déclaré convergé en réponse à une panne une fois que tous les dispositifs dans la portée d'impact de la panne ont été informés de l'événement et ont recalculé leurs RIB et mis à jour leurs FIB en conséquence. Une portée d'impact de panne plus large signifie en général une convergence plus lente, car davantage de dispositifs doivent être notifiés, et produit un réseau moins stable. Cette section décrit les avantages de BGP par rapport aux protocoles à état des liens pour réduire la portée d'impact des pannes dans une topologie Clos.

BGP se comporte comme un protocole à vecteur de distance en ce sens que seul le meilleur chemin du point de vue du routeur local est envoyé aux voisins. Ainsi, certaines pannes sont masquées si le nœud local trouve immédiatement un chemin de secours et n'a pas besoin d'envoyer de mises à jour plus loin. Dans le pire cas, tous les dispositifs d'une topologie de centre de données doivent soit retirer complètement un préfixe, soit mettre à jour les groupes ECMP dans leurs FIB. Toutefois, de nombreuses pannes n'auront pas un impact aussi large. Il existe deux types principaux de pannes où la portée d'impact est réduite :

• Panne d'une liaison entre dispositifs Tier 2 et Tier 1 : Dans ce cas, un dispositif Tier 2 met à jour les groupes ECMP affectés en retirant la liaison en panne. Il n'est pas nécessaire d'envoyer de nouvelles informations aux dispositifs Tier 3 en aval, sauf si le chemin a été choisi comme meilleur par le processus BGP, auquel cas seul un « implicit withdraw » doit être envoyé et cela ne devrait pas affecter le transfert. Le dispositif Tier 1 affecté perd le seul chemin disponible pour atteindre un cluster particulier et devra retirer les préfixes associés. Ce processus de retrait de préfixe n'affecte que les dispositifs Tier 2 directement connectés au dispositif Tier 1 affecté. Les dispositifs Tier 2 recevant les messages BGP UPDATE retirant les préfixes devront simplement mettre à jour leurs groupes ECMP. Les dispositifs Tier 3 ne participent pas au processus de reconvergence.

• Panne d'un dispositif Tier 1 : Dans ce cas, tous les dispositifs Tier 2 directement attachés au nœud en panne devront mettre à jour leurs groupes ECMP pour tous les préfixes IP d'un cluster non local. Les dispositifs Tier 3 ne participent pas à nouveau au processus de reconvergence, mais peuvent recevoir des « implicit withdraws » comme décrit ci-dessus.

Même dans le cas de telles pannes où plusieurs préfixes IP devront être reprogrammés dans la FIB, il convient de noter que tous ces préfixes partagent un seul groupe ECMP sur un dispositif Tier 2. Par conséquent, pour les implémentations avec une FIB hiérarchique, un seul changement doit être fait dans la FIB. « FIB hiérarchique » signifie ici une structure FIB où les informations de transfert next-hop sont stockées séparément de la table de recherche de préfixe, et cette dernière ne contient que des pointeurs vers les informations de transfert respectives. Voir [BGP-PIC] pour la discussion sur les hiérarchies FIB et la convergence rapide.

Même si BGP réduit la portée des pannes dans certains cas, une réduction supplémentaire du domaine de faute par summarisation n'est pas toujours possible avec la conception proposée, car cette technique peut créer des trous noirs de routage comme mentionné précédemment. Par conséquent, la pire portée d'impact de panne sur le plan de contrôle est le réseau entier, par ex. en cas de panne de liaison entre dispositifs Tier 2 et Tier 3. Le nombre de préfixes impactés dans ce cas serait bien moindre qu'en cas de panne dans les couches supérieures d'une topologie Clos. La propriété d'avoir une si grande portée de panne n'est pas le résultat du choix d'EBGP dans la conception, mais plutôt de l'utilisation de la topologie Clos.

7.5. Micro-boucles de routage

Lorsqu'un dispositif en aval, par ex. un dispositif Tier 2, perd tous les chemins pour un préfixe, il a normalement la route par défaut pointant vers le dispositif en amont, ici le dispositif Tier 1. Il est alors possible d'atteindre une situation où un commutateur Tier 2 perd un préfixe, mais un commutateur Tier 1 a encore le chemin pointant vers le commutateur Tier 2 ; cela produit une micro-boucle transitoire, car le commutateur Tier 1 continue à envoyer les paquets vers le préfixe affecté au commutateur Tier 2, et le Tier 2 les renvoie via la route par défaut. Cette micro-boucle dure le temps nécessaire au dispositif en amont pour mettre à jour complètement ses tables de transfert.

Pour minimiser l'impact de telles micro-boucles, les commutateurs Tier 2 et Tier 1 peuvent être configurés avec des routes statiques « discard » ou « null » plus spécifiques que la route par défaut pour les préfixes manquants pendant la convergence du réseau. Pour les commutateurs Tier 2, la route de rejet doit être une route de synthèse couvrant tous les sous-réseaux serveur des dispositifs Tier 3 sous-jacents. Pour les dispositifs Tier 1, la route de rejet doit être une synthèse couvrant les sous-réseaux d'adresses IP serveur alloués pour l'ensemble du centre de données. Ces routes de rejet ne prévalent que pendant la convergence du réseau, jusqu'à ce que le dispositif apprenne un préfixe plus spécifique via un nouveau chemin.