6. Considérations ECMP
Cette section traite la fonctionnalité Equal Cost Multipath (ECMP) pour la topologie Clos et examine quelques exigences particulières.
6.1. ECMP de base
L'ECMP est le mécanisme fondamental de partage de charge utilisé par une topologie Clos. En pratique, chaque dispositif de niveau inférieur utilise tous ses dispositifs de niveau supérieur directement attachés pour répartir la charge du trafic destiné au même préfixe IP. Le nombre de chemins ECMP entre deux dispositifs Tier 3 dans une topologie Clos est égal au nombre de dispositifs de l'étage intermédiaire (Tier 1). Par exemple, la Figure 5 illustre une topologie où le dispositif Tier 3 A dispose de quatre chemins pour atteindre les serveurs X et Y, via les dispositifs Tier 2 B et C puis les dispositifs Tier 1 1, 2, 3 et 4 respectivement.
Tier 1
+-----+
| DEV |
+->| 1 |--+
| +-----+ |
Tier 2 | | Tier 2
+-----+ | +-----+ | +-----+
+----------->| DEV |--+->| DEV |--+--| |-------------+
| +----| B |--+ | 2 | +--| |-----+ |
| | +-----+ +-----+ +-----+ | |
| | | |
| | +-----+ +-----+ +-----+ | |
| +-----+--->| DEV |--+ | DEV | +--| |-----+-----+ |
| | | +--| C |--+->| 3 |--+--| |---+ | | |
| | | | +-----+ | +-----+ | +-----+ | | | |
| | | | | | | | | |
+-----+ +-----+ | +-----+ | +-----+ +-----+
| DEV | | | Tier 3+->| DEV |--+ Tier 3 | | | |
| A | | | | 4 | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | |
O O O O <- Servers -> X Y O O
Figure 5: ECMP Fan-Out Tree from A to X and Y
L'exigence ECMP implique que l'implémentation BGP doit prendre en charge un fan-out multipath jusqu'au nombre maximal de dispositifs directement attachés en tout point de la topologie, en direction amont ou aval. Normalement, ce nombre ne dépasse pas la moitié des ports présents sur un dispositif de la topologie. Par exemple, un fan-out ECMP de 32 serait nécessaire pour construire un réseau Clos avec des dispositifs à 64 ports. Les routeurs de bordure (Border Routers) peuvent nécessiter un fan-out plus large pour se connecter à de nombreux dispositifs Tier 1 si la summarisation de routes au niveau du routeur de bordure est mise en œuvre comme décrit à la Section 5.2.5. Si le matériel d'un dispositif ne prend pas en charge un ECMP plus large, le regroupement logique de liaisons (agrégation de liaisons en Layer 2) peut servir à fournir un ECMP « hiérarchique » (ECMP Layer 3 couplé à l'ECMP Layer 2) pour compenser les limites de fan-out. Toutefois, cette approche augmente le risque de polarisation des flux, car moins d'entropie sera disponible au second stade d'ECMP.
La plupart des implémentations BGP déclarent les chemins égaux du point de vue ECMP s'ils correspondent jusqu'à l'étape (e) incluse de la Section 9.1.2.2 de [RFC4271]. Dans la conception réseau proposée, il n'y a pas d'IGP sous-jacent ; tous les coûts IGP sont donc supposés nuls ou identiques sur tous les chemins, et des politiques peuvent être appliquées pour égaliser les attributs BGP qui varient selon les valeurs par défaut des fournisseurs, tels que l'attribut MULTI_EXIT_DISC (MED) et le code d'origine. Pour des raisons historiques, il est aussi utile de ne pas utiliser 0 comme valeur MED égalisée ; ces informations BGP utiles et d'autres sont disponibles dans [RFC4277]. Les boucles de routage sont peu probables en raison du processus BGP de sélection du meilleur chemin (qui préfère une longueur AS_PATH plus courte), et des chemins plus longs via les dispositifs Tier 1 (qui n'autorisent pas leur propre ASN dans le chemin) ne sont pas possibles.
6.2. ECMP BGP sur plusieurs ASN
À des fins d'équilibrage de charge applicatif, il est souhaitable d'annoncer le même préfixe depuis plusieurs dispositifs Tier 3. Du point de vue des autres dispositifs, un tel préfixe aurait des chemins BGP avec des valeurs d'attribut AS_PATH différentes, tout en ayant les mêmes longueurs d'AS_PATH. Par conséquent, les implémentations BGP doivent prendre en charge le partage de charge sur les chemins mentionnés ci-dessus. Cette fonctionnalité est parfois appelée « multipath relax » ou « multipath multiple-AS » et permet effectivement l'ECMP entre différents ASN voisins si tous les autres attributs sont égaux comme déjà décrit à la section précédente.
6.3. ECMP pondéré
Il peut être souhaitable que les équipements réseau mettent en œuvre un ECMP « pondéré » afin d'envoyer plus de trafic sur certains chemins du fan-out ECMP. Cela peut aider à compenser des pannes dans le réseau et à diriger plus de trafic vers des chemins disposant de plus de capacité. Les préfixes nécessitant un ECMP pondéré devraient être injectés via un locuteur BGP distant (agent central) sur une session multi-saut comme décrit plus loin à la Section 8.1. Si les implémentations le permettent, la répartition des poids pour plusieurs chemins BGP peut être signalée par la technique décrite dans [LINK].
6.4. Hachage cohérent
Il est souvent souhaitable que la fonction de hachage utilisée pour l'ECMP soit cohérente (voir [CONS-HASH]), afin de minimiser l'impact sur les flux lors des changements d'affinité flux-next-hop lorsqu'un next hop est ajouté ou retiré d'un groupe ECMP. Cela peut servir si le dispositif réseau fait office d'équilibreur de charge, mappant les flux vers plusieurs destinations : dans ce cas, la perte ou l'ajout d'une destination n'a pas d'effet préjudiciable sur les flux déjà établis. Une recommandation particulière sur la mise en œuvre du hachage cohérent est fournie dans [RFC2992], bien que d'autres implémentations soient possibles. Cette fonctionnalité peut naturellement être combinée avec l'ECMP pondéré, l'impact des changements de next hop étant proportionnel au poids du next hop concerné. L'inconvénient du hachage cohérent est une charge accrue sur les ressources matérielles, car en général davantage de ressources (par ex. espace TCAM, Ternary Content-Addressable Memory) sont nécessaires pour implémenter une fonction de hachage cohérente.