Configuration de la prise en charge d’OSPF pour l’ingénierie du trafic

L’ingénierie du trafic vous permet de contrôler le chemin que suivent les paquets de données, en contournant le modèle de routage standard, qui utilise des tables de routage. L’ingénierie du trafic déplace les flux des liaisons encombrées vers d’autres liaisons qui ne seraient pas sélectionnées par le chemin le plus court basé sur la destination calculé automatiquement.

Pour fournir des informations sur la topologie et le chargement du réseau, des extensions ont été ajoutées à l’implémentation d’OSPF par Junos OS. Lorsque l’ingénierie du trafic est activée sur l’équipement de routage, vous pouvez activer l’assistance technique du trafic OSPF. Lorsque vous activez l’ingénierie du trafic pour OSPF, l’algorithme SPF (Short-Path-First) prend en compte les différents chemins de commutation d’étiquettes (LSP) configurés sous MPLS et configure OSPF pour générer des publicités opaques d’état de liaison (LSA) qui portent les paramètres techniques du trafic. Les paramètres sont utilisés pour remplir la base de données d’ingénierie du trafic. La base de données d’ingénierie du trafic est utilisée exclusivement pour calculer des chemins explicites pour l’emplacement des LSP sur la topologie physique. L’algorithme CSPF (Constrained Shortest Path First) utilise la base de données d’ingénierie du trafic pour calculer les chemins empruntés par les LSP MPLS. Le RSVP utilise ces informations de chemin pour configurer les LSP et leur réserver de la bande passante.

Par défaut, l’assistance technique du trafic est désactivée. Pour activer l’ingénierie du trafic, incluez l’énoncé d’ingénierie du trafic . Vous pouvez également configurer les extensions techniques de trafic OSPF suivantes :

• annonce des interfaces sans numéro : (OSPFv2 uniquement) Annonce l’identifiant local de liaison dans le paquet LSA de l’ingénierie du trafic local de liaison. Vous n’avez pas besoin d’inclure cette déclaration si RSVP peut signaler des interfaces non numérotées telles que définies dans la RFC 3477, Signalisation des liaisons non numérotées dans le protocole de réservation de ressources - Ingénierie du trafic (RSVP-TE).

• crédibilité-protocole-préférence — (OSPFv2 uniquement) Attribue une valeur de crédibilité aux routes OSPF dans la base de données d’ingénierie du trafic. Par défaut, Junos OS préfère les routes OSPF dans la base de données d’ingénierie du trafic aux autres routes IGP (Interior Gateway Protocol), même si les routes d’un autre IGP sont configurées avec une valeur de préférence inférieure, c’est-à-dire plus préférée. La base de données d’ingénierie du trafic attribue une valeur de crédibilité à chaque IGP et préfère les routes de l’IGP avec la valeur de crédibilité la plus élevée. Dans junos OS version 9.4 et versions ultérieures, vous pouvez configurer OSPF pour tenir compte des préférences de protocole afin de déterminer la valeur de crédibilité de la base de données d’ingénierie du trafic. Lorsque la préférence de protocole est utilisée pour déterminer la valeur de crédibilité, les routes OSPF ne sont pas automatiquement préférées par la base de données d’ingénierie du trafic, en fonction de votre configuration.

• ignore-lsp-metrics : ignore les métriques LSP RSVP dans les calculs de raccourcis d’ingénierie du trafic OSPF ou lorsque vous configurez LDP sur RSVP LSP. Cette option évite la dépendance mutuelle entre OSPF et RSVP, éliminant ainsi la période pendant laquelle la mesure RSVP utilisée pour tunneliser le trafic n’est pas à jour. En outre, si vous utilisez RSVP pour l’ingénierie du trafic, vous pouvez exécuter LDP simultanément pour éliminer la distribution des routes externes dans le cœur. Les LSP établis par LDP sont tunnelnés à travers les LSP établis par RSVP. Le LDP traite efficacement les LSP conçus pour le trafic comme des sauts simples.

• multicast-rpf-routes — (OSPFv2 uniquement) Installe des routes IPv4 unicast (et non LSP) dans la table de routage multicast (inet.2) pour les vérifications RPF (Reverse Path Forwarding) multicast. La table de routage inet.2 est composée de routes unicast utilisées pour la recherche RPF multicast. Le RPF est un mécanisme d’antispoofing utilisé pour vérifier si le paquet arrive sur une interface qui renvoie également des données à la source du paquet.

• no-topology : (OSPFv2 uniquement) Pour désactiver la diffusion des informations topologiques d’état de liaison. En cas de désactivation, les informations de topologie d’ingénierie du trafic ne sont plus distribuées dans la zone OSPF.

• raccourcis : configure les raccourcis IGP, ce qui permet à OSPF d’utiliser un LSP comme saut suivant, comme s’il s’agissait d’une interface logique de l’équipement de routage entrant vers l’équipement de routage sortant. L’adresse spécifiée dans l’instruction to au niveau de la hiérarchie [edit protocoles mpls label-switched-path lsp-path-name] sur l’équipement de routage entrant doit correspondre à l’ID de routeur de l’équipement de routage sortant pour que le LSP fonctionne comme une liaison directe vers l’équipement de routage sortant et soit utilisé comme entrée pour les calculs SPF OSPF. Lorsqu’ils sont utilisés de cette manière, les LSP ne sont pas différents du mode de transfert asynchrone (ATM) et des circuits virtuels de relais de trames (VC), sauf que les LSPS transportent uniquement le trafic IPv4.

  OSPFv2 installe le préfixe des routes IPv4 dans la table de routage inet.0 , et les LSP sont installés par défaut dans la table de routage inet.3 .

  Les LSP OSPFv3 utilisés pour les raccourcis continuent d’être signalés à l’aide d’IPv4. Toutefois, par défaut, des routes IPv6 de raccourci calculées via OSPFv3 sont ajoutées à la table de routage inet6.3 . Le comportement par défaut est que BGP utilise uniquement des LSP dans ses calculs. Si vous configurez MPLS de sorte que les BGP et les IGP utilisent tous les deux des LSP pour le transfert du trafic, les routes de raccourci IPv6 calculées via OSPFv3 sont ajoutées à la table de routage inet6.0 .

  Note:

  Dans la mesure du possible, utilisez les raccourcis IGP OSPF au lieu des raccourcis techniques de trafic.

• lsp-metric-info-summary : annonce la mesure LSP dans les LSA récapitulatifs pour traiter le LSP comme une liaison. Cette configuration permet aux autres équipements de routage du réseau d’utiliser ce LSP. Pour y parvenir, vous devez configurer les aspects techniques du trafic MPLS et OSPF pour faire la publicité de la métrique LSP dans des LSA récapitulatifs.

Lorsque vous activez l’ingénierie du trafic sur l’équipement de routage, vous pouvez également configurer une métrique OSPF qui est utilisée exclusivement pour l’ingénierie du trafic. La mesure d’ingénierie du trafic est utilisée pour les informations injectées dans la base de données d’ingénierie du trafic. Sa valeur n’affecte pas le transfert OSPF normal.

Cet exemple montre comment activer la prise en charge de l’ingénierie du trafic OSPF pour promouvoir la métrique LSP (label-switched path) dans des annonces récapitulatives d’état de lien (LSA).

Cet exemple montre comment configurer la valeur métrique OSPF utilisée pour l’ingénierie du trafic.

En règle générale, les protocoles de routage internes comme OSPF ne sont pas exécutés sur des liaisons entre des systèmes autonomes. Toutefois, pour que l’ingénierie du trafic inter-AS fonctionne correctement, des informations sur la liaison inter-AS, en particulier l’adresse sur l’interface distante, doivent être mises à disposition à l’intérieur du système autonome (AS). Ces informations ne sont normalement pas incluses dans les messages d’accessibilité externes BGP (EBGP) ou dans les publicités de routage OSPF.

Pour inonder ces informations d’adresse de liaison dans l’AS et les rendre disponibles pour les calculs d’ingénierie du trafic, vous devez configurer le mode passif OSPF pour l’ingénierie du trafic sur chaque interface inter-AS. Vous devez également fournir l’adresse distante pour qu’OSPF la distribue et l’inclue dans la base de données d’ingénierie du trafic. Le mode d’ingénierie du trafic OSPF permet aux chemins de commutation d’étiquettes (LSP) MPLS de découvrir dynamiquement les routeurs de bordure OSPF AS et d’établir un LSP d’ingénierie de trafic sur plusieurs systèmes autonomes.

Cet exemple montre comment configurer le mode passif OSPF pour l’ingénierie du trafic sur une interface inter-AS. La liaison de routeur AS entre les pairs EBGP doit être une liaison directement connectée et doit être configurée en tant que liaison d’ingénierie du trafic passif.

L’une des principales raisons de configurer les chemins de commutation d’étiquettes (LSP) dans votre réseau est de contrôler le chemin le plus court entre deux points du réseau. Vous pouvez annoncer les LSP dans OSPFv2 en tant que liaisons point à point afin que tous les équipements de routage participants puissent tenir compte du LSP lors des calculs SPF. La publicité contient une adresse locale (l’adresse de départ du LSP), une adresse distante (l’adresse de la LSP) et une métrique avec la priorité suivante :

1. Utilisez la métrique LSP définie sous OSPFv2.

2. Utilisez la métrique LSP configurée pour le chemin de commutation d’étiquettes sous MPLS.

3. Si vous ne configurez aucun des éléments ci-dessus, utilisez la métrique OSPFv2 par défaut de 1.

Cet exemple montre comment faire la publicité des LSP dans OSPFv2.

La configuration d’un SID d’adjacence statique sur une interface permet de supprimer le SID d’adjacence alloué dynamiquement et le routage de transit pour le même.

Pour les SID d’adjacence statiques, les labels sont sélectionnés soit dans un pool d’étiquettes réservé statique, soit dans un bloc global de routage de segments OSPF (SRGB).

Vous pouvez réserver une plage d’étiquettes à utiliser pour l’allocation statique des labels à l’aide de la configuration suivante :

user@host# set protocols mpls label-range static-label-range start-value end-value

Le pool statique peut être utilisé par n’importe quel protocole pour allouer une étiquette dans cette plage. Vous devez vous assurer qu’aucun protocole n’utilise le même label statique. Les SIDs d’adjacence OSPF peuvent être alloués à partir de ce bloc d’étiquettes via la configuration à l’aide du mot-clé label. La label valeur des SID d’adjacence spécifiques doit être configurée explicitement. Voici un exemple de configuration :

Le SRGB est un espace d’étiquette global alloué au protocole en fonction de la configuration. Les labels de l’ensemble du SRGB sont disponibles pour OSPF et ne sont pas alloués à d’autres applications/protocoles. Les SID de préfixe (et les SID de nœud) sont indexés à partir de ce SRGB.

Les Adj-SID OSPF peuvent être alloués à partir d’OSPF SRGB à l’aide du mot-clé « index » dans la configuration. Dans de tels cas, il convient de s’assurer que l’index Adj-SID n’est pas en conflit avec tout autre préfixe SID du domaine. Comme les SID de préfixe, les Adj-SIDs seront également configurés en mentionnant l’index par rapport au SRGB. Cependant, le sous-tlv Adj-SID aura toujours le SID en tant que valeur et les indicateurs L et V sont définis. Voici un exemple de configuration :

Les SID d’adjacence statiques peuvent être configurés par zone et en fonction de l’exigence ou non de la protection. Les SID d’adjacence doivent être configurés par interface au niveau de la hiérarchie [edit protocols ospf area area interface interface-name]

• Protégé : garantit que le SID d’adjacence est éligible pour avoir un chemin de secours et qu’un B-flag est défini dans une publicité SID d’adjacence.

• Non protégé : garantit qu’aucun chemin de sauvegarde n’est calculé pour un SID d’adjacence spécifique et qu’aucun indicateur B n’est défini dans une publicité SID d’adjacence.

Voici un exemple de configuration :

Lorsque le routage de segments est utilisé dans les sous-réseaux LAN, chaque routeur du LAN peut annoncer le SID d’adjacence de chacun de ses voisins. Pour configurer un SID d’adjacence pour une interface LAN vers un voisin spécifique, vous devez configurer les SID d’adjacence dans la configuration lan-neighbor au niveau de la hiérarchie [edit protocols ospf area 0.0.0.0 interface interface_name lan-neighbor neighbor-routerid] . Voici un exemple de configuration :

Utilisez la hiérarchie CLI suivante pour configurer le SID d’adjacence :

Utilisez les commandes cli opérationnelles suivantes pour vérifier la configuration :

afficher les détails du voisin ospf

L’exemple de sortie suivant affiche les détails du SID d’adjacence configuré et dynamique.

Le routage de segments exploite le paradigme du routage source. Un nœud oriente un paquet via une liste ordonnée d’instructions, appelée segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur les services. Un segment peut avoir une sémantique locale vers un nœud de routage de segments ou vers un nœud global dans un domaine de routage de segments. Le routage de segments applique un flux à travers n’importe quel chemin topologique et chaîne de services tout en conservant l’état par flux uniquement au nœud entrant vers le domaine de routage de segments. Le routage de segments peut être appliqué directement à l’architecture MPLS sans modification du plan de transfert. Un segment est encodé sous la forme d’un label MPLS. Une liste ordonnée de segments est encodée sous la forme d’une pile de labels. Le segment à traiter se trouve au sommet de la pile. Une fois le segment terminé, le label associé est retiré de la pile. Le routage de segments peut être appliqué à l’architecture IPv6, avec un nouveau type d’en-tête d’extension de routage. Un segment est encodé en tant qu’adresse IPv6. Une liste ordonnée de segments est encodée sous la forme d’une liste ordonnée d’adresses IPv6 dans l’en-tête de l’extension de routage. Le segment à traiter est indiqué par un pointeur dans l’en-tête de l’extension de routage. Une fois un segment terminé, le pointeur est incrémenté.

Les raccourcis techniques du trafic sont activés pour les routes de segment IS-IS étiquetées, lorsque vous les configurez shortcuts aux niveaux hiérarchiques suivants :

• [edit protocols is-is traffic-engineering family inet] pour le trafic IPv4.

• [edit protocols is-is traffic-engineering family inet6] pour le trafic IPv6.

Lorsque le routage de paquets source est déployé dans le réseau, le centre de données, le réseau dorsal et les équipements d’appairage changent les paquets MPLS avec une pile d’étiquettes construite par la source du trafic ; par exemple, les serveurs de centre de données. Dans la version 17.4R1 de Junos OS, le trafic routé à la source coexiste avec le trafic prenant des chemins signalés par RSVP, et le routage source est implémenté sous forme de commutation d’étiquettes régulière via la table mpls.0 à l’aide des opérations de label – pop, swap (vers la même valeur d’étiquette) et swap-push (pour la protection de l’interface). Dans tous les cas, le trafic peut être équilibré entre plusieurs interfaces de couche 3 ou au sein d’une interface agrégée. À partir de la version 17.4R1 de Junos OS, les statistiques de trafic d’un réseau de routage de segments peuvent être enregistrées dans un format conforme OpenConfig pour les interfaces de couche 3. Les statistiques sont enregistrées uniquement pour le trafic SPRING (Source Packet Routing in Networking), à l’exclusion du trafic RSVP et du trafic signalé par LDP, et les statistiques MPLS de la famille sont prises en compte séparément. Les statistiques SR comprennent également des statistiques de trafic SPRING par membre de groupe d’agrégation de liens (LAG) et par identifiant de segment (SID). Pour permettre l’enregistrement des statistiques de routage de segments, incluez sensor-based-stats une déclaration au niveau de la [edit protocol isis source-packet-routing] hiérarchie.

Avant la version 19.1R1 de Junos OS, des capteurs étaient disponibles pour collecter des statistiques de routage de segments pour le trafic de transit MPLS uniquement, qui est par nature MPLS-to-MPLS. À partir de la version 19.1R1 de Junos OS, sur les routeurs MX Series avec des interfaces MPC et MIC et des routeurs PTX Series, des capteurs supplémentaires sont introduits pour collecter des statistiques de routage de segments pour le trafic entrant MPLS, qui est par nature IP vers MPLS. Avec cette fonctionnalité, vous pouvez activer des capteurs pour le trafic de routage de segments IS-IS d’étiquette uniquement, et diffuser les statistiques vers un client gRPC.

Vous pouvez activer les statistiques de routage de segments pour le trafic entrant MPLS à l’aide de l’option egress sous l’instruction per-sid de configuration. Le nom de la ressource pour la fonctionnalité de sortie par sid est :

/junos/services/segment-routing/sid/egress/usage/

Vous pouvez voir l’association du routage IS-IS du label avec les capteurs à l’aide de la sortie de show isis spring sensor info commande. Cette commande n’affiche pas les valeurs de compteur des capteurs réels.

Les données statistiques de routage de segments sont exportées vers un serveur. Vous pouvez consulter les statistiques de routage de segments à partir des chemins OpenConfig suivants :

• /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-addr='L-ISIS-10.1.1.1']/state/counters[name='oc-xxx']/out-pkts

• /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-counter[ip-addr='L-ISIS-10.1.1.1']/state/counters[name='oc-xxx']/out-pkts