Algorithmes flexibles dans IS-IS pour l’ingénierie du trafic de Segment Routing

Avantages de la configuration d’un algorithme flexible

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

• 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 routage ECMP (Equal-cost Multi-Path) et TI-LFA par tranche sans configurer BGP-LS ou un chemin statique.

• Calculez le chemin de sauvegarde TI-LFA en utilisant la même définition d’algorithme flexible et le même calcul de contraintes.

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

• Possibilité de provisionner un chemin principal restreint en fonction d’une seule étiquette.

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

Un algorithme flexible permet à IGP de calculer les meilleurs chemins supplémentaires en fonction de contraintes spécifiées, offrant ainsi une ingénierie de trafic simple sans utiliser de contrôleur de réseau. Il s’agit d’une solution légère pour les réseaux qui n’ont pas encore implémenté de contrôleur avec un routage de segments à part entière, mais qui souhaitent tout de même en tirer profit. Chaque opérateur peut définir des contraintes ou des couleurs distinctes en fonction de ses besoins.

Pour définir un algorithme flexible, incluez flex-algorithm id l’instruction au niveau de la [edit routing-options] hiérarchie. La définition d’algorithme flexible (FAD) se voit attribuer un identifiant compris entre 128 et 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 se basant sur les 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 appareil en fonction d’une certaine stratégie locale, telle que des raccourcis d’ingénierie de trafic. Si vous sélectionnez SPF strict, la stratégie locale ne peut pas influencer la sélection du chemin SPF.

• Metric type- Les options de type de métrique IGP ou TE sont disponibles. Vous pouvez spécifier l’un de ces types de mesures 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 l’itinéraire.

• Priority- Vous pouvez attribuer une priorité à vos DCP en fonction de vos besoins, et IS-IS donne la priorité à une annonce de DCP particulière par rapport à une autre DCP en fonction de la priorité qui vous a été attribuée.

  Note:

  Pour que les FAD avec des contraintes de lien fonctionnent, tous les liens pertinents doivent annoncer les couleurs d’administration dans IS-IS, ce qui signifie que 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 un lien individuel. Ceux-ci admin-groups peuvent ensuite être définis 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 afin d’assurer la redondance et d’éviter les conflits. La définition flexible de l’algorithme est annoncée en IGP sous la forme FAD sub-TLVs. Dans les très grands réseaux, nous vous déconseillons de configurer plus de 8 algorithmes flexibles, car chaque algorithme flexible calculera son propre chemin et pourra entraîner des problèmes de performances au-delà.

Il est également recommandé de configurer plusieurs serveurs FAD dans un niveau ISIS spécifique avant de configurer des appareils pour participer à ce FAD. Dans le cas d'un nœud ISIS L1/L2 (ABR), il est également recommandé de configurer le FAD à la fois au niveau 1 et au niveau 2 d'ISIS. Si un FAD est configuré uniquement sur un seul ABR, des pertes de trafic sur les chemins de l’algorithme flexible sont possibles si le processus de routage redémarre sur cet ABR. C’est donc une bonne pratique de conception d’avoir plusieurs ABR, chacun d’entre eux ayant le DCP configuré aux deux niveaux de l’EI.

Le FAD par défaut a les paramètres suivants :

• Type de calcul : SPF

• Type de métrique : IGP-métrique

• Priorité : 0

• Contraintes de lien : aucune

Participation à un algorithme flexible

Vous pouvez configurer des routeurs spécifiques pour qu’ils participent à un algorithme flexible particulier selon vos besoins. Les chemins calculés sur la base d’une définition d’algorithme flexible sont utilisés par diverses applications, chacune utilisant potentiellement 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 à 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 certain algorithme flexible, à condition qu’il puisse prendre en charge les contraintes spécifiées dans ce 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 appareil peut faire la publicité d’un DCP et également 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’algorithme flexible

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

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

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

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

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

Figure 4 : Flux de trafic pour la définition 130 de l’algorithme flexible

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

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

Algorithmes flexibles

Pour chaque algorithme flexible auquel un routeur participe, les routes de l’algorithme flexible correspondant sont installées dans les groupes RIB d’algorithmes flexibles correspondants, également appelés tables de routage. Par défaut, les routes d’algorithme flexible IS-IS étiquetées sont installées dans inet.color inet(6)color.0 et mpls.0 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, porte une communauté étendue de couleurs BGP, le préfixe de service BGP résout par défaut une route flex-algo qui a la même valeur de couleur associée. Les routes d’entrée de l’algorithme flexible qui sont installées dans les inet(6)color.0 tables auront cette valeur de couleur associée à la route. Toutefois, vous pouvez configurer une valeur de couleur d’association différente au niveau de la [edit routing-options flex-algorithm id color color] hiérarchie.

Algorithme flexible et mesures de préfixe d’algorithme flexible fuites sur IS-IS multi-instances

Nous avons ajouté la prise en charge de la nouvelle publication des identificateurs de préfixe de segment (SID) et des mesures de préfixe d'algorithme flexible (FAPM) sur les instances IGP (Interior Gateway Protocol). Nous avons également ajouté la prise en charge de la nouvelle publication de préfixes provenant d’autres protocoles et de l’attribution de préfixes-SID d’algo flexibles via une stratégie à ces préfixes.

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

Dans l’exemple de topologie illustré à la Figure 6, différents domaines IS-IS, métro-A, métro B et cœur, constituent un domaine de routage à segment unique. Pour un chemin d’algo flexible de routage de segments de bout en bout, les nœuds 02 et 05 doivent annoncer à nouveau les préfixes d’algo flexible, les SID et les FAPM sur les instances IGP.

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

Lorsque des SID de préfixe d’algo flexible sont divulgués entre des instances IGP, le sous-TLV FAPM est annoncé avec la métrique dérivée de la stratégie d’exportation ou la métrique propre à l’itinéraire. La métrique définie dans la stratégie d’exportation a une priorité plus élevée que la métrique propre à l’itinéraire. En outre, IS-IS installe un itinéraire assemblé dans les tables mpls.0 pour lier le trafic MPLS entrant d’une instance IGP à l’autre.

Pour plus d’informations sur l’application d’une stratégie d’exportation sur un IS-IS multi-instance, consultez Exporter.

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 d’algo flexibles-SID. Vous pouvez configurer les prefix-segment (et metric) dans le pour que les policy-statement préfixes BGP-LU appris soient divulgués dans l’algorithme flexible.

Figure 7 : BGP-LU : fuite d’algorithmes flexibles

Par exemple, dans la topologie illustrée dans Comprendre les algorithmes flexibles IS-IS pour le Segment Routing, le domaine IGP inclut les algorithmes flexibles 128 et 129. L’appareil R9 réside en dehors du domaine IGP. L’appareil R9 n’est pas accessible via l’algo flexible dans le domaine IGP. Tout trafic à destination de l’appareil R9 suit un chemin d’algo flexible jusqu’à l’équipement R5, puis suit la liaison de l’appareil R5 vers R9.

Lorsque des SID de préfixe d’algo flexible sont divulgués de BGP-LU vers une instance IGP, le sous-TLV FAPM est annoncé avec la métrique dérivée de la stratégie d’exportation ou la métrique propre à la route. La métrique définie dans la stratégie d’exportation a une priorité plus élevée que la métrique propre à l’itinéraire. En outre, IS-IS installe un routage assemblé dans les tables mpls.0 pour assembler le trafic MPLS entrant de BGP-LU vers IS-IS.

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

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

Figure 8 : BGP-CT – Fuite d’algorithmes flexibles

Par exemple, la topologie illustrée dans Comprendre les algorithmes flexibles IS-IS pour le Segment Routing se compose de plusieurs instances IGP IS-IS. L’ISIS-A a un algorithme de flexion mais pas 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égie.

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

Lorsque des SID de préfixe d’algo flexible sont divulgués à partir de BGP-CT, FAPM sub-TLV sera annoncé avec la métrique dérivée de la politique d’exportation ou de la métrique de l’itinéraire. La métrique définie dans la stratégie d’exportation a une priorité plus élevée que la métrique de l’itinéraire. En outre, IS-IS installe un routage assemblé dans les tables mpls.0 pour lier 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 publication de SID de préfixe pour différents algorithmes flexibles.

• Prise en charge partielle d’Internet Draft draft-ietf-lsr-flex-algo-05.txt de l’algorithme flexible IGP

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

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

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

• Les raccourcis IS-IS et les autres options de configuration de l’ingénierie de trafic IS-IS ne sont pas applicables au calcul d’algorithmes flexibles

• La résolution des conflits entre les préfixes et les SID n’est pas prise en charge.

• La fonctionnalité alternative sans boucle à distance 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.