Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Comment configurer des algorithmes flexibles dans OSPF pour l’ingénierie du trafic de segment routing

Grâce à un algorithme flexible, les IGP sont les seules à calculer les chemins sur le réseau en fonction des contraintes, ce qui simplifie l’ingénierie du trafic sans avoir besoin d’un contrôleur 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 parti.

Quelle est la prochaine étape ?

Pour plus d’informations sur la configuration d’algorithmes flexibles, consultez le Guide de l’utilisateur OSPF

Comprendre l’algorithme flexible OSPF pour le Segment Routing

À partir de la version 21.1R1 de Junos OS, vous pouvez découper un réseau en tranches fines en définissant des algorithmes flexibles qui calculent les chemins à l’aide de différents paramètres et contraintes de liaison en fonction de vos besoins. Par exemple, vous pouvez définir un algorithme flexible qui calcule un chemin pour minimiser la métrique IGP et définir un autre algorithme flexible pour calculer un chemin basé sur la métrique d’ingénierie du trafic afin de diviser le réseau en plans distincts. Cette fonctionnalité permet aux réseaux sans contrôleur de configurer l’ingénierie du trafic à l’aide du routage de segments sans implémenter de contrôleur réseau. Vous pouvez utiliser le préfixe SID pour orienter les paquets le long des chemins basés sur des contraintes. Vous pouvez configurer les SID de préfixe pour un algorithme flexible via les configurations de stratégie.

Les protocoles IGP utilisent une métrique de liaison pour calculer le meilleur chemin. Toutefois, le meilleur chemin IGP n’est pas toujours le meilleur pour certains types de trafic. Par conséquent, le meilleur chemin calculé par l’IGP en fonction de la métrique IGP la plus courte est souvent remplacé par un chemin d’ingénierie du trafic en raison des exigences de trafic qui ne sont pas reflétées par la métrique IGP. En règle générale, RSVP-TE ou SR TE est utilisé pour calculer le chemin en fonction de mesures et de contraintes supplémentaires afin de surmonter cette limitation. Junos installe ces chemins dans les tables de transfert, en complément ou en remplacement du chemin d’origine calculé par les IGP.

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 OSPFv2 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’OSPFv2 peut utiliser pour calculer l’itinéraire.

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

  • 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 un algorithme flexible 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 définitions d’algorithmes flexibles, car chaque algorithme flexible calculera son propre chemin et pourra entraîner des problèmes de performances au-delà.

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

Note:

La modification de la définition de l’algorithme flexible dans un réseau actif ou à la volée peut entraîner des perturbations du trafic jusqu’à ce que tous les nœuds convergent sur les nouveaux chemins.

À partir de Junos OS 21.4R1, nous prenons en charge la définition d’algorithme flexible (FAD) et la métrique de préfixe d’algorithme flexible (FAPM) dans TED, et implémentons deux nouvelles TLV correspondantes : « FAD TLV » et « FAPM TLV » dans BGP-LS. La valeur de FAD TLV contient Flex-Algorithm, Metric-Type, Calculation-Type et Priority, qui ont tous un octet chacun. La TLV peut comporter zéro ou plusieurs sous-TLV. Les cinq sous-tlv sont Flex Algo Exclure toute affinité, Flex Algo Inclure n’importe quelle affinité, Flex Algo Inclure toutes les affinités, Flex Algo Definition Flags et Flex Algo Exclure SRLG.

Le TLV FAD ne peut être ajouté à l’attribut BGP-LS du NLRI de nœud que si le nœud correspondant provient du TLV ou du sous-TLV IGP sous-jacent. L’attribut BGP-LS associé à un NLRI de nœud peut inclure une ou plusieurs TLV FAD correspondant à la définition d’algorithme flexible pour chaque algorithme annoncé par le nœud.

La valeur de FAPM TLV contient Flex-Algorithm (1 octet), Reserved (3 octets) et Metric (4 octets). Le TLV FAPM ne peut être ajouté à l’attribut BGP-LS du préfixe NLRI provenant d’un noeud que si le noeud correspondant provient du préfixe.

À partir de la version 22.4R1 de Junos OS, nous avons défini la métrique de préfixe d'algorithme flexible (FAPM) pour permettre un chemin optimal de bout en bout pour un préfixe interzone. Le routeur de bordure de zone (ABR) doit inclure le FAPM lors de l’annonce du préfixe entre les zones qui est accessible dans cet algorithme flexible donné (algo flexible). Lorsqu’un préfixe est inaccessible, l’ABR ne doit pas inclure ce préfixe dans cet algo flexible lors de la publicité entre les zones. Le FAPM défini fournit un soutien inter-zones.

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 la sous-TLV de l’algorithme flexible de routage de segments pour OSPFv2. 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 :

Définition de l’algorithme Flex (FAD)

Couleur

128

Incluez n’importe quel rouge

129

Incluez n’importe quel vert

130

Incluez n’importe quel vert et bleu

135

Exclure le rouge

Figure 1 : topologie Flexible Algorithm Topology 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 Traffic Flow for Flexible Algorithm Definition 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 Traffic Flow for Flexible Algorithm Definition 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 Traffic flow for Flexible Algorithm Definition 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 Traffic Flow for Flexible Algorithm Definition 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 OSPFv2 é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 avoir une communauté de couleurs BGP associée pour résoudre les routes d’autres services tels que le service VPN. Par défaut, la communauté de couleurs BGP associée est la même que l’ID de l’algorithme flexible. Les routes d’entrée de l’algorithme flexible qui sont installées dans les tables inet(6)color.0 auront cette communauté de couleurs dans la route. Toutefois, vous pouvez configurer une communauté de couleurs BGP différente au niveau de la [edit routing-options flex-algorithm id color desired color community value] hiérarchie.

Note:

La modification de la communauté de couleurs BGP par un algorithme flexible peut entraîner des perturbations du trafic. Si vous modifiez une communauté de couleurs BGP pour un algorithme flexible, toutes les routes relatives à cet algorithme flexible sont supprimées du RIB et rajoutées avec de nouvelles couleurs.

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

  • L’implémentation actuelle des algorithmes flexibles n’est prise en charge que pour OSPFv2, car seul OSPFv2 prend en charge le routage de segments.

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

  • La métrique de délai de liaison n’est pas prise en charge.

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

  • Les raccourcis OSPFv2 et les autres options de configuration de l’ingénierie de trafic OSPFv2 ne sont pas applicables au calcul d’algorithmes flexibles. .
  • L’implémentation actuelle des algorithmes flexibles n’est pas prise en charge pour OSPFv3.
  • La fuite inter-zone (OSPFv2) des SID de préfixe d’algorithme flexible n’est pas prise en charge.

  • 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é.

  • En l’absence de participation à un algorithme flexible, il n’est pas possible d’annoncer la définition d’un algorithme flexible.

  • La publication d’attributs de lien pour l’algorithme flex à l’aide des annonces d’attributs de lien spécifiques à l’application n’est pas prise en charge.

  • Le semi-rigide de classe transport n’est pas pris en charge.

Algorithme flexible basé sur les attributs de lien spécifiques à l’application

À partir de Junos OS et Junos OS Evolved version 22.2R1, vous pouvez publier différents attributs te tels que te-metric, delay-metric ou admin-groups pour RSVP et des algorithmes flexibles sur le même lien. Cela se fait à l’aide d’un attribut de lien spécifique à l’application spécifique à un algorithme flexible, tel que défini dans la RFC 8920.

L’avantage d’avoir un attribut de lien spécifique à l’application d’algorithme flexible annonçant te-metric, delay-metric, ou admin-groups est qu’un seul lien peut annoncer différents attributs te-link pour les applications héritées telles que RSVP et différents attributs te-link pour les algorithmes flexibles.

Pour configurer l’attribut te spécifique à l’application d’un algorithme flexible, incluez l’instruction au niveau hiérarchique et l’instruction application-specific strict-asla-based-flex-algorithm au niveau hiérarchique[edit protocols ospf source-packet-routing].[edit protocols ospf area interface] Avec cette implémentation, il n’est plus obligatoire d’avoir RSVP activé et [edit protocols ospf traffic-engineering advertisement always] d’être configuré sur le lien, ce qui est le cas avec le comportement existant des attributs d’ingénierie du trafic publicitaire.

Note:

L’implémentation Junos OS et Junos OS Evolved de l’attribut de lien spécifique à l’application prend uniquement en charge les applications d’algorithmes flexibles.

Algorithme flexible strict basé sur des attributs de lien spécifiques à l’application

Le comportement par défaut de l’algorithme flexible spécifique à l’application est d’utiliser les attributs te spécifiques à l’application de l’algorithme flexible pour un lien s’il est disponible, et si ce n’est pas le cas, de revenir aux attributs te communs spécifiques à l’application, et si aucun n’est disponible, d’utiliser les attributs te hérités.

L’instruction strict-asla-based-flex-algorithm de configuration de la [edit protocols ospf source-packet-routing] doit être appliquée à tous les algorithmes flexibles exécutés sur les appareils du réseau pour éviter les boucles de routage.

S’il strict-asla-based-flex-algorithm est configuré sur tous les équipements, un attribut te commun spécifique à l’application ou un attribut te spécifique à l’application d’algorithme flexible doit être annoncé pour chaque lien d’algorithme flexible. En l’absence de te-attributs spécifiques à l’application, l’appareil ne revient pas aux attributs te hérités et ignore simplement le lien.

Le système d’exploitation prend en charge les fonctionnalités suivantes en conjonction avec un algorithme flexible basé sur des attributs de lien spécifiques à l’application :

  • Le sous-TLV de l’attribut te spécifique à l’application pour se conformer à la RFC 8920. Le sous-TLV te-attributes spécifique à l’application est un sous-TLV du TLV de liaison étendue OSPFv2 tel que défini dans la RFC 7684.

  • Prend partiellement en charge le masque de bits d’identifiant d’application standard pour annoncer X-bit afin d’obtenir des algorithmes flexibles. Seuls les groupes te-metric, delay-metric ou admin sont annoncés dans le cadre de l’attribut de lien spécifique à l’application.

Le système d’exploitation ne prend pas en charge les fonctionnalités suivantes, associées à l’algorithme flexible basé sur des attributs de lien spécifiques à l’application :

  • La publicité de masques de bits d’identifiant d’application définis par l’utilisateur n’est pas prise en charge.
  • Il n’est pas possible de republier un attribut de lien spécifique à une application à algorithme flexible, ou tout autre attribut de lien spécifique à une application avec BGP-LS, car la base de données d’ingénierie du trafic (TED) ne prend pas en charge l’attribut de lien spécifique à l’application.
  • Il n’est pas possible d’annoncer un attribut de lien commun spécifique à l’application avec un masque de bits d’identifiant d’application standard et une longueur de masques de bits d’identifiant d’application définie par l’utilisateur sur zéro.

  • La publication d’une contrainte de lien SRLG dans un algorithme flexible n’est pas prise en charge.

  • La prise en charge de l’ingénierie de trafic pour plusieurs applications n’est pas prise en charge, à l’exception des algorithmes flexibles.

  • La définition de groupes d’administrateurs indépendants de MPLS n’est pas prise en charge.

Exemple : Algorithme flexible OSPF

Aperçu

Cet exemple montre comment configurer un algorithme flexible dans un réseau OSPFv2. Cet algorithme flexible permet aux réseaux sans contrôleur de configurer l’ingénierie du trafic à l’aide du routage de segments sans implémenter de contrôleur réseau.

À partir de la version 21.1R1 de Junos OS, vous pouvez découper un réseau en tranches fines en définissant des algorithmes flexibles qui calculent les chemins à l’aide de différents paramètres et contraintes de liaison en fonction de vos besoins. L’ensemble composé d’un type de calcul, d’un type de métrique et d’un ensemble de contraintes est appelé définition d’algorithme flexible (FAD). Vous pouvez définir des DCP et les annoncer dans un réseau OSPFv2. Un appareil peut également être configuré pour participer à un certain algorithme flexible, à condition qu’il prenne en charge les contraintes de ce DCP spécifique.

Topologie

La figure 6 montre une topologie d’algorithme flexible dans laquelle il y a 6 périphériques R0, R1, R2, R3, R4 et R5. Deux algorithmes flexibles 128 et 129 sont définis sur chacun de ces appareils. Les groupes d’administrateurs rouge, bleu et vert sont configurés sur les appareils. Les DCP avec différents paramètres tels que les types de métriques, les types de calcul et les contraintes de liaison sont définis sur chacun des périphériques.

Figure 6 : topologie Flexible Algorithm Topology d’algorithme flexible

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

  • Six routeurs MX Series.
  • Junos OS version 21.1R1 ou ultérieure s’exécute sur tous les équipements.

Configuration

Configuration rapide de la CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la hiérarchie [modifier].

Appareil R0

Appareil R1

Appareil R2

Appareil R3

Appareil R4

Appareil R5

Configuration de l’appareil R0

Pour configurer l’algorithme flexible pour OSPFv2, effectuez les opérations suivantes sur l’appareil R0 :

  1. Configurez les interfaces de l’appareil pour activer le transport IP.

  2. Configurez l’adresse de l’interface de bouclage (lo0) utilisée comme ID de routeur pour les sessions OSPF.

  3. Configurez l’ID de routeur et le numéro du système autonome (AS) pour propager les informations de routage au sein d’un ensemble de périphériques de routage appartenant au même AS.

  4. Définissez une stratégie d’équilibrage de charge des paquets et appliquez la stratégie par paquet pour activer l’équilibrage de charge du trafic.

  5. Configurez le filtre de route pour le terme de stratégie de routage qui permet à l’appareil R0 d’atteindre le réseau 192.168.255.10/32.

  6. Configurez MPLS sur toutes les interfaces, à l’exception de l’interface de gestion.
  7. Configurez la plage d’étiquettes MPLS pour attribuer des étiquettes statiques aux liaisons.

  8. Configurez TI-LFA pour activer la protection contre les défaillances de liaisons et de nœuds. Le SR avec TI-LFA permet de restaurer plus rapidement la connectivité réseau en acheminant instantanément le trafic vers un chemin de secours ou un autre chemin en cas de défaillance ou d’indisponibilité du chemin principal.

  9. Configurez le nombre maximal d’étiquettes pour les chemins acheminés par routage de segments afin de protéger les attributs de sauvegarde shortest-path-first.

  10. Configurez les attributs de segment de préfixe, l’étiquette de départ et la plage d’index pour les blocs globaux de routage de segments (SRGB) dans SPRING pour le protocole OSPF.

  11. Activez la protection de liaison de nœud sur les interfaces OSPF qui suivent le chemin de post-convergence.

  12. Configurez l’interface de bouclage en tant que passive pour vous assurer que les protocoles ne s’exécutent pas sur l’interface de bouclage et que l’interface de bouclage est correctement annoncée sur l’ensemble du réseau.

  13. Définir des algorithmes flexibles sur l’appareil R0. Attribuez un nom à chacun des DCP compris entre 128 et 255.

    Spécifiez les paramètres de la définition. OSPFv2 calcule le chemin en fonction de ces paramètres spécifiés du FAD.

    1. Spécifiez le type de calcul en fonction duquel le protocole OSPFv2 calcule le chemin.

    2. Spécifiez le type de mesure en fonction duquel OSPFv2 calcule le chemin.

    3. Si vous avez activé l’ingénierie de trafic RSVP, vous pouvez configurer des groupes d’administrateurs pour de nombreux protocoles afin de colorer un lien individuel.

    4. Affectez les stratégies de groupes d’administration configurées aux interfaces R0 de l’appareil.

    5. Définissez les groupes d’administrateurs selon vos besoins.

      Note:

      Pour que les FAD avec des contraintes de lien fonctionnent, tous les liens pertinents doivent annoncer les couleurs d’administration dans OSPFv2. Vous devez soit activer RSVP sur les interfaces, soit si vous n’avez pas configuré RSVP pour l’ingénierie du trafic, assurez-vous de configurer l’annonce de l’ingénierie du trafic toujours au niveau de la [edit protocols ospf] hiérarchie.

  14. Configurez la participation flexible de l’algorithme sur l’appareil R0. Le même appareil peut faire la publicité d’un DCP et également participer à un algorithme flexible.
  15. Publiez des segments de préfixe via la configuration des stratégies.

Résultats

Vérifiez les résultats de la configuration :

À partir du mode configuration, confirmez votre configuration en entrant les commandes , show interfaces, show routing-optionsshow protocols, et show policy-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les tâches suivantes :

Vérification de la base de données OSPF

But

Vérification de l’affichage du signal de l’algorithme flexible dans la base de données OSPF.

Action

À partir du mode opérationnel, exécutez la show ospf database opaque-area extensive commande.

Sur R0

Signification

Cette sortie sur R0 illustre que :

Trois algorithmes de routage de segments (dont deux algorithmes flexibles) sont annoncés par cet appareil.

Deux DCP sont annoncés par cet appareil.

Vérification des détails de l’algorithme flexible

But

Vérification de l’affichage des détails de l’algorithme flexible.

Action

À partir du mode opérationnel, exécutez la show ospf spring flex-algorithm <flex-algorithm-id> commande.

Sur R0

Signification

Les détails de l’algorithme flexible configuré sur R0 sont affichés.

Vérification des routes internes OSPF spécifiques à un algorithme flexible

But

Vérification de l’affichage des routes internes OSPF spécifiques à l’algorithme flexible.

Action

À partir du mode opérationnel, exécutez la show ospf route flex-algorithm <flex-algorithm-id> commande.

Sur R0

Signification

La show ospf route commande est étendue avec flex-algorithm une option permettant d’afficher les routes internes OSPF spécifiques à un algorithme flexible. Chaque route est préfixée par le flex-algo-id :

Vérification des itinéraires Flex Colored

But

Vérification de l’affichage des routes internes OSPF spécifiques à l’algorithme flexible.

Action

À partir du mode opérationnel, exécutez la show route protocol ospf commande.

Sur R0

Signification

La sortie affiche toutes les routes flexibles colorées programmées dans la table inetcolor.0 au format suivant : prefix_address-flex-algo-id<c>/64

Vérification des journaux OSPF

But

La vérification des journaux OSPF affiche le mot-clé flexible algorithm.

Action

À partir du mode opérationnel, exécutez la show ospf log commande.

Sur R0

Signification

La sortie affiche le mot-clé FlexAlgo ajouté pour les journaux SPF.