8. Options supplémentaires pour la conception

8.1. Injection de routes par un tiers

BGP permet à un locuteur BGP « tiers », c'est-à-dire directement attaché, d'injecter des routes n'importe où dans la topologie réseau, satisfaisant REQ5. Cela peut être réalisé en établissant un peering BGP multi-saut avec certains ou même tous les dispositifs de la topologie. En outre, la distribution de chemins BGP diversifiés [RFC6774] pourrait être utilisée pour injecter plusieurs next hops BGP pour le même préfixe afin de faciliter l'équilibrage de charge, ou la capacité BGP ADD-PATH [RFC7911] si l'implémentation la prend en charge. Malheureusement, dans de nombreuses implémentations, ADD-PATH s'est avéré ne correctement prendre en charge l'IBGP que pour les cas d'usage pour lesquels il a été initialement optimisé ; cela limite le peering « tiers » à l'IBGP uniquement.

Pour mettre en œuvre l'injection de routes dans la conception proposée, un locuteur BGP tiers peut établir un peering avec des commutateurs Tier 3 et Tier 1, injectant le même préfixe mais avec un ensemble particulier de next hops BGP pour les dispositifs Tier 1. Ces next hops sont supposés se résoudre récursivement via BGP et pourraient être, par exemple, des adresses IP sur des dispositifs Tier 3. La programmation résultante de la table de transfert peut fournir la répartition de trafic souhaitée entre différents clusters.

8.2. Summarisation de routes au sein de la topologie Clos

Comme mentionné précédemment, la summarisation de routes n'est pas possible dans la topologie Clos proposée, car elle rend le réseau susceptible de trous noirs de routage en cas de panne d'une seule liaison. Le problème principal est le nombre limité de chemins redondants entre éléments réseau, par ex. il n'existe qu'un seul chemin entre toute paire de dispositifs Tier 1 et Tier 3. Toutefois, certains opérateurs peuvent trouver l'agrégation de routes souhaitable pour améliorer la stabilité du plan de contrôle.

Si une technique de summarisation au sein de la topologie est envisagée, la modélisation du comportement de routage et le risque de trous noirs doivent être étudiés non seulement pour des pannes simples ou multiples de liaisons, mais aussi pour des pannes de trajets fibre ou de domaines optiques lorsque la topologie s'étend au-delà d'un site physique. Une modélisation simple peut consister à vérifier l'atteignabilité sur les dispositifs effectuant la summarization sous condition de panne de liaison ou de trajet entre un ensemble de dispositifs à chaque tier ainsi que vers les routeurs WAN lorsque la connectivité externe est présente.

La summarisation de routes serait possible avec une petite modification de la topologie réseau, mais le compromis serait une réduction de la taille totale du réseau ainsi qu'une congestion réseau sous certaines pannes. Cette approche est très similaire à la technique décrite ci-dessus, qui permet aux routeurs de bordure de résumer tout l'espace d'adressage du centre de données.

8.2.1. Réduction de la couche de dispositifs Tier 1

Pour ajouter davantage de chemins entre les dispositifs Tier 1 et Tier 3, regrouper les dispositifs Tier 2 par paires, puis connecter les paires au même groupe de dispositifs Tier 1. Cela équivaut logiquement à « réduire » les dispositifs Tier 1 en un groupe de moitié moins d'éléments, en fusionnant les liaisons sur les dispositifs « réduits ». Le résultat est illustré à la Figure 6. Par exemple, dans cette topologie DEV C et DEV D se connectent au même ensemble de dispositifs Tier 1 (DEV 1 et DEV 2), alors qu'auparavant ils se connectaient à des groupes distincts de dispositifs Tier 1.

              Tier 2       Tier 1       Tier 2
             +-----+      +-----+      +-----+
+------------| DEV |------| DEV |------|     |-------------+
|       +----|  C  |--++--|  1  |--++--|     |-----+       |
|       |    +-----+  ||  +-----+  ||  +-----+     |       |
|       |             ||           ||             |       |
|       |    +-----+  ||  +-----+  ||  +-----+     |       |
| +-----+----| DEV |--++--| DEV |--++--|     |-----+-----+ |
| |     | +--|  D  |------|  2  |------|     |---+ |     | |
| |     | |  +-----+      +-----+      +-----+   | |     | |
| |     | |                                      | |     | |
+-----+ +-----+                                +-----+ +-----+
| DEV | | DEV |                                |     | |     |
|  A  | |  B  | Tier 3                  Tier 3 |     | |     |
+-----+ +-----+                                +-----+ +-----+
  | |     | |                                    | |     | |
  O O     O O          <- Servers ->             O O     O O

                Figure 6: 5-Stage Clos Topology

Avec cette conception, les dispositifs Tier 2 peuvent être configurés pour n'annoncer qu'une route par défaut vers les dispositifs Tier 3. Si une liaison entre Tier 2 et Tier 3 tombe en panne, le trafic sera réacheminé via le second chemin disponible connu du commutateur Tier 2. Il reste impossible d'annoncer une route de synthèse couvrant les préfixes d'un seul cluster depuis les dispositifs Tier 2, car chacun n'a qu'un seul chemin vers ce préfixe. Il faudrait des serveurs doublement rattachés pour y parvenir. Notez aussi que cette conception n'est résiliente qu'aux pannes d'une seule liaison. Une double panne de liaison peut isoler un dispositif Tier 2 de tous les chemins vers un dispositif Tier 3 spécifique, provoquant un trou noir de routage.

Une conséquence de la modification de topologie proposée serait une réduction de la capacité en ports des dispositifs Tier 1. Cela limite le nombre maximal de dispositifs Tier 2 rattachés et donc la taille maximale du réseau du DC. Un réseau plus grand exigerait d'autres dispositifs Tier 1 avec une densité de ports plus élevée pour appliquer ce changement.

Un autre problème est le rééquilibrage du trafic sous pannes de liaison. Comme il existe deux chemins de Tier 1 à Tier 3, la panne de la liaison entre Tier 1 et commutateur Tier 2 entraînera le basculement de tout le trafic qui empruntait la liaison en panne vers le chemin restant, doublant l'utilisation de ce lien.

8.2.2. Agrégation virtuelle simple

Une approche tout à fait différente de la summarisation de routes est possible si l'objectif principal est de réduire la taille de la FIB tout en laissant le plan de contrôle diffuser l'information de routage complète. D'abord, on peut remarquer que dans de nombreux cas plusieurs préfixes, dont certains moins spécifiques, partagent le même ensemble de next hops (même groupe ECMP). Par exemple, du point de vue des dispositifs Tier 3, toutes les routes apprises des dispositifs Tier 2 en amont, y compris la route par défaut, partageront le même ensemble de next hops BGP, tant qu'il n'y a pas de pannes dans le réseau. Cela permet d'utiliser une technique similaire à celle décrite dans [RFC6769] et d'installer uniquement la route la moins spécifique dans la FIB, en ignorant les routes plus spécifiques si elles partagent le même ensemble de next hops. Par exemple, en conditions normales, seule la route par défaut doit être programmée dans la FIB.

De plus, si les dispositifs Tier 2 sont configurés avec des préfixes de synthèse couvrant tous les préfixes des dispositifs Tier 3 rattachés, la même logique peut s'appliquer aux dispositifs Tier 1 et, par induction, aux commutateurs Tier 2/Tier 3 dans différents clusters. Ces routes de synthèse doivent toutefois permettre la fuite de préfixes plus spécifiques vers les dispositifs Tier 1 pour détecter des incohérences dans les ensembles de next hops si une liaison particulière tombe en panne, modifiant l'ensemble de next hops d'un préfixe donné.

Pour le répéter encore, cette technique ne réduit pas la quantité d'état du plan de contrôle (c'est-à-dire BGP UPDATE, taille du BGP Loc-RIB), mais permet seulement une utilisation plus efficace de la FIB en détectant les préfixes plus spécifiques qui partagent leur ensemble de next hops avec un préfixe moins spécifique qui les englobe.

8.3. Usurpation de messages ICMP Destination Unreachable

Cette section traite des aspects opérationnels du fait de ne pas annoncer les sous-réseaux de liaisons point-à-point dans BGP, comme identifié précédemment comme option à la Section 5.2.3. L'impact opérationnel de cette décision apparaît lors de l'utilisation de l'outil bien connu « traceroute ». Plus précisément, les adresses IP affichées par l'outil seront les adresses point-à-point de la liaison et seront donc inaccessibles pour la connectivité de gestion. Cela complique certains dépannages.

Une façon de contourner cette limitation est d'utiliser le sous-système DNS pour créer des entrées « inversées » pour ces adresses IP point-à-point pointant vers le même nom que l'adresse de loopback. La connectivité peut alors s'établir en résolvant ce nom vers l'adresse IP « primaire » du dispositif, par ex. son interface Loopback, toujours annoncée dans BGP. Cela crée toutefois une dépendance au DNS, qui peut être indisponible pendant une panne.

Une autre option est de faire effectuer au dispositif réseau une usurpation d'adresse IP, c'est-à-dire réécrire les adresses IP source des messages ICMP appropriés envoyés par le dispositif avec l'adresse IP « primaire » du dispositif. Plus précisément, le message ICMP Destination Unreachable (type 3) code 3 (port unreachable) et ICMP Time Exceeded (type 11) code 0 sont requis pour le bon fonctionnement de « traceroute ». Avec cette modification, les sondes « traceroute » envoyées aux dispositifs seront toujours renvoyées avec l'adresse IP « primaire » comme source, permettant à l'opérateur de découvrir l'adresse IP « joignable » de l'équipement. L'inconvénient est de masquer l'adresse du « point d'entrée » dans le dispositif. Si les dispositifs prennent en charge [RFC5837], cela peut permettre le meilleur des deux mondes en fournissant des informations sur l'interface entrante même si l'adresse de retour est l'adresse IP « primaire ».