Algorithmes flexibles dans IS-IS pour l’ingénierie du trafic de routage de segments

Avantages de la configuration d’un algorithme flexible

• Une version légère de l’ingénierie du trafic de routage de segments qui peut être utilisée au cœur du réseau.

• Vous permet de configurer l’ingénierie du trafic à l’aide du routage de segments même sans installer de contrôleur réseau.

• Utilisez le multichemin à coût égal (ECMP) et TI-LFA par tranche sans configurer BGP-LS ou chemin statique.

• Calcul du chemin de sauvegarde TI-LFA à l’aide du même algorithme flexible définition et calcul des contraintes.

• Tirez parti de l’ingénierie du trafic de routage de segments en utilisant uniquement IS-IS sans configurer RSVP ou LDP.

• Possibilité de provisionner des chemins primaires limités sur un seul label.

Qu’est-ce que la définition d’algorithme flexible (FAD) ?

Un algorithme flexible permet à IGP de calculer d’autres meilleurs chemins en fonction de contraintes spécifiées, fournissant ainsi une ingénierie de trafic simple sans utiliser de contrôleur réseau. Il s’agit d’une solution légère pour les réseaux qui n’ont pas mis en œuvre de contrôleur avec un routage de segments à part entière, mais qui veulent tout de même profiter des avantages du routage de segments sur leur réseau. Chaque opérateur peut définir des contraintes ou des couleurs distinctes en fonction de ses besoins.

Pour définir un algorithme flexible, incluez une flex-algorithm id déclaration au niveau de la [edit routing-options] hiérarchie. La définition de l’algorithme flexible (FAD) est attribuée avec un identifiant allant de 128 à 255. Cet algorithme flexible peut être défini sur un ou plusieurs routeurs d’un réseau. Un algorithme flexible calcule le meilleur chemin en fonction des paramètres suivants :

• Calculation type— SPF ou SPF strict sont les deux options de type de calcul disponibles. Vous pouvez spécifier l’un de ces types de calcul dans votre FAD. Sélectionnez le type de calcul SPF si vous souhaitez influencer le calcul SPF sur votre équipement en fonction d’une certaine politique locale, comme les raccourcis techniques du trafic. Si vous sélectionnez un SPF strict, la stratégie locale ne peut pas influencer la sélection du chemin SPF.

• Metric type- La métrique IGP ou la métrique TE sont les options de type de métrique disponibles. Vous pouvez spécifier l’un de ces types de métriques dans votre FAD en fonction des besoins de votre réseau. Si vous ne souhaitez pas utiliser la métrique IGP pour une liaison spécifique, vous pouvez configurer une métrique TE qu’IS-IS peut utiliser pour calculer le routage.

• Priority- Vous pouvez attribuer une priorité à vos DAF selon vos besoins et IS-IS priorise une publicité DAF particulière par rapport à une autre FAD en fonction de la priorité que vous avez attribuée.

  Note:

  Pour que les DFA avec des contraintes de liaison fonctionnent, toutes les liaisons pertinentes doivent annoncer les couleurs d’administration dans IS-IS, ce qui signifie que le RSVP est activé sur les interfaces ou set protocols isis traffic-engineering advertise always est configuré.

• Set of Link constraints- Vous pouvez configurer des groupes d’administrateurs pour de nombreux protocoles au niveau de la [edit protocols mpls admin-groups] hiérarchie afin de colorer une liaison individuelle. Celles-ci admin-groups peuvent ensuite être définies comme include any, include-all ou exclude au niveau de la [edit routing-options flex-algorithm definition admin-groups] hiérarchie.

Nous vous recommandons de configurer des définitions d’algorithmes flexibles sur quelques routeurs seulement pour assurer la redondance et éviter les conflits. La définition d’algorithme flexible est annoncée dans IGP sous la forme FAD sub-TLVs. Dans les très grands réseaux, nous ne recommandons pas de configurer plus de 8 algorithmes flexibles, car chaque algorithme flexible calcule son propre chemin et peut entraîner des problèmes de performances au-delà.

Il vous a également recommandé de configurer plusieurs serveurs FAD dans un niveau ISIS spécifique avant de configurer n’importe quel équipement pour participer à cette FAD. Dans le cas d'un nœud L1/L2 (ABR) ISIS, il est également recommandé de configurer le FAD aux niveaux ISIS 1 et 2. Si un FAD n’est configuré que sur un seul ABR, des chutes de trafic sur les chemins de l’algorithme flex sont possibles si le processus de routage redémarre sur cet ABR. C’est donc une bonne pratique de conception d’avoir plusieurs ABR, dont chacun a le FAD configuré aux deux niveaux ISIS.

La FAD par défaut comporte les paramètres suivants :

• type de calcul : spf

• type de mesure : igp-metric

• priorité : 0

• Contraintes de liaison : aucune

Participation à un algorithme flexible

Vous pouvez configurer des routeurs spécifiques pour qu’ils participent à un algorithme flexible en fonction de vos besoins. Les chemins calculés sur la base d’une définition d’algorithme flexible sont utilisés par diverses applications, chacune utilisant son propre plan de données spécifique pour transférer les données sur ces chemins. L’équipement participant doit annoncer explicitement sa participation dans un algorithme flexible particulier à chaque application de l’algorithme flexible de routage de segments sous-TLV pour IS-IS. Vous pouvez configurer un nœud pour qu’il participe à un algorithme flexible à condition qu’il puisse prendre en charge les contraintes spécifiées dans cette FAD.

Pour configurer la participation à un algorithme flexible, incluez l’instruction flex-algorithm au niveau de la [edit protocols isis source-packet- routing] hiérarchie. Le même équipement peut faire la publicité d’une FAD et participer à un algorithme flexible.

Topologie du réseau configurée avec des définitions d’algorithmes flexibles

La figure 1 montre l’exemple de topologie, il y a 8 routeurs R0, R1, R2, R3, R4, R5, R6 et R7. Quatre algorithmes flexibles, 128, 129, 130 et 135 sont définis et configurés avec des groupes d’administrateurs comme indiqué dans le tableau suivant :

Figure 1 : Topologie d’algorithmes flexibles

La figure 2 montre comment FAD 128 achemine le trafic sur n’importe quelle interface configurée en rouge pour le groupe d’administration.

Figure 2 : Flux de trafic pour la définition d’un algorithme flexible 128

La figure 3 montre comment FAD 129 achemine le trafic sur n’importe quelle interface configurée en vert du groupe d’administration.

Figure 3 : Flux de trafic pour la définition d’un algorithme flexible 129

La figure 4 montre comment FAD 130 achemine le trafic sur n’importe quelle interface configurée en vert et bleu du groupe d’administration.

Figure 4 : flux de trafic pour la définition d’un algorithme flexible 130

La figure 5 montre comment FAD 135 achemine le trafic sur n’importe quelle interface qui n’est pas configurée avec le rouge du groupe d’administration.

Figure 5 : Flux de trafic pour la définition d’un algorithme flexible 135

RIB d’algorithmes flexibles

Pour chaque algorithme flexible qu’un routeur participe aux algorithmes flexibles correspondants, les routes flexibles sont installées dans les groupes RIB d’algorithmes flexibles correspondants, également appelés tables de routage. Par défaut, les routes d’algorithme flexibles IS-IS étiquetées sont installées dans l’inet.color et inet(6)color.0 mpls.0 dans les RIB.

Communauté BGP et algorithmes flexibles

Un algorithme flexible peut être associé à une couleur. Lorsqu’un préfixe de service, tel qu’un service VPN transporte une communauté étendue de couleurs BGP, par défaut, le préfixe de service BGP résout un routage flex-algo qui a la même valeur de couleur associée. Les routes d’entrée d’algorithme flexibles installées dans les inet(6)color.0 tables auront cette valeur de couleur associée au routage. Toutefois, vous pouvez configurer une valeur de couleur associée différente au niveau de la [edit routing-options flex-algorithm id color color] hiérarchie.

Métriques d’algorithme flexibles et de préfixe d’algorithme flexibles qui fuient sur plusieurs instances IS-IS

Nous avons ajouté la prise en charge pour la lecture des identifiants de segments de préfixe (FLEX algo) flexibles d'algorithme (SID) et des métriques de préfixe d'algorithme flexibles (FAPM) sur les instances IGP (Interior Gateway Protocol). Nous avons également ajouté la prise en charge de la lecture des préfixes d’autres protocoles et de l’attribution de préfixes flex algo-SID via une stratégie à ces préfixes.

Figure 6 : Fuite d’algorithmes flexibles entre les instances IGP

Dans l’exemple de topologie illustré en figure 6, différents domaines IS-IS, metro-A, metro-B et le cœur, constituent un domaine de routage à segment unique. Pour un chemin flex algo de routage de segments de bout en bout, les nœuds 02 et 05 doivent lire les SID et FAPM de préfixe algo flex sur les instances IGP.

Les routes Flex algo sont installées dans des inet(6)color.0 tables. Ils peuvent également être installés dans des RIB colorés, par junos-rti-tc-<color>.inet(6).3 exemple lorsque use-transport-class l’instruction est configurée sous routing-options flex-algorithm <id>. Pour prendre en charge la fuite des SID-préfixes flex algo sur les instances IGP, l’instruction use-transport-class doit être configurée pour cet algo flex. La fuite des SID-préfixes flex algo sur les instances IGP est basée sur des stratégies. Voici un exemple de configuration de stratégie :

Lorsque des SIDs de préfixe flex algo sont divulgués à travers des instances IGP, la sous-TLV FAPM sera annoncée avec la mesure dérivée de la stratégie d’exportation ou de la propre métrique du routage. La mesure définie dans la stratégie d’exportation a plus de priorité sur la propre métrique de la route. En outre, IS-IS installe une route maillée dans les tables mpls.0 pour assembler le trafic MPLS entrant d’une instance IGP à l’autre.

Pour plus d’informations sur l’application d’une stratégie d’exportation sur is-IS multi-instance, voir export.

Fuite des préfixes BGP-LU dans un algorithme flexible

Vous pouvez faire fuiter des préfixes BGP-LU dans l’IGP avec des préfixes flex algo-SID. Vous pouvez configurer les prefix-segment préfixes appris BGP-LU (et metric) dans le policy-statement pour faire fuiter les préfixes appris BGP-LU dans flex algo.

Figure 7 : BGP-LU – Fuite d’algorithme flexible

Par exemple, dans la topologie présentée dans La compréhension des algorithmes flexibles IS-IS pour le routage de segments, le domaine IGP inclut flex algos 128 et 129. L’équipement R9 se trouve en dehors du domaine IGP. L’équipement R9 n’est pas accessible via flex algo dans le domaine IGP. Tout trafic destiné à l’équipement R9 suit un chemin flex algo jusqu’à l’équipement R5, puis suit la liaison R5 vers R9 de l’équipement.

Lorsque des SIDs de préfixe flex algo sont divulgués de BGP-LU vers une instance IGP, la sous-TLV FAPM sera annoncée avec la métrique dérivée de la stratégie d’exportation ou de la propre métrique du routage. La mesure définie dans la stratégie d’exportation a plus de priorité sur la propre métrique de la route. En outre, IS-IS installe une route cousue dans les tables mpls.0 pour assembler le trafic MPLS entrant de BGP-LU à IS-IS.

Fuite des préfixes BGP-CT dans un algorithme flexible

Vous pouvez désormais faire fuiter les préfixes BGP-CT dans flex algo et vice-versa.

Figure 8 : BGP-CT – Fuite d’algorithme flexible

Par exemple, la topologie présentée dans La compréhension des algorithmes flexibles IS-IS pour le routage de segments se compose de plusieurs instances IGP IS-IS. L’ISIS-A a flex algo mais n’a pas de BGP-CT. Dans de tels déploiements, les préfixes BGP-CT peuvent être divulgués dans flex algo et vice-versa via des configurations de stratégies.

Actuellement, les préfixes BGP-CT ne prennent pas en charge le transport des informations préfixe-SID. Configurez une stratégie pour le préfixe et associez un préfixe-SID sur le routeur qui redistribue le préfixe dans IS-IS flex algo.

En cas de fuite de SID de préfixe flex algo de BGP-CT, la sous-TLV FAPM sera annoncée avec la métrique dérivée de la stratégie d’exportation ou de la mesure de la route. La mesure définie dans la stratégie d’exportation a une priorité plus élevée sur la mesure du routage. En outre, IS-IS installe une route cousue dans les tables mpls.0 pour assembler le trafic MPLS entrant de BGP-CT à IS-IS.

Fonctionnalités prises en charge et non prises en charge

Junos OS prend en charge des algorithmes flexibles dans les scénarios suivants :

• Prise en charge de la configuration et de la publicité des SIDs de préfixe pour différents algorithmes flexibles.

• Prend en charge partiellement Internet Draft draft-ietf-lsr-flex-algo-05.txt IGP Flexible Algorithm

• La fuite inter-niveau (IS_IS) des SIDs de préfixe d’algorithme flexibles est prise en charge.

Junos OS ne prend pas en charge les fonctionnalités suivantes en conjonction avec des algorithmes flexibles :

• L’algorithme flexible ne s’applique qu’à la topologie unicast par défaut, et la multi-topologie IS-IS n’est pas prise en charge.

• Les raccourcis IS-IS et les autres options de configuration techniques du trafic IS-IS ne sont pas applicables pour le calcul d’algorithme flexible

• La résolution des conflits de préfixe et de SID n’est pas prise en charge.

• L’autre fonctionnalité sans boucle distante n’est pas prise en charge, car TI-LFA est le calcul FRR préféré

• Les groupes d’administrateurs étendus (EAG) ne sont pas pris en charge car ils ne sont pas pris en charge dans IS-IS.