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

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

Pour fournir à l’ingénierie de trafic et au MPLS des informations sur la topologie et la charge du réseau, des extensions ont été ajoutées à l’implémentation Junos OS d’OSPF. Lorsque l’ingénierie de trafic est activée sur le périphérique de routage, vous pouvez activer la prise en charge de l’ingénierie de trafic OSPF. Lorsque vous activez l’ingénierie de trafic pour OSPF, l’algorithme shortest-path-first (SPF) prend en compte les différents chemins de commutation d’étiquettes (LSP) configurés sous MPLS et configure OSPF pour générer des annonces d’état de lien (LSA) opaques qui portent des paramètres d’ingénierie de 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 les chemins explicites de placement 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. RSVP utilise ces informations de chemin pour configurer des prestataires de services linguistiques et leur réserver de la bande passante.

Par défaut, la prise en charge de l’ingénierie de trafic est désactivée. Pour activer l’ingénierie de trafic, incluez l’instruction d’ingénierie de trafic . Vous pouvez également configurer les extensions d’ingénierie de trafic OSPF suivantes :

• advertise-unnumbered-interfaces—(OSPFv2 uniquement) Annonce l’identificateur local de liaison dans le paquet LSA d’ingénierie du trafic de liaison locale. Vous n’avez pas besoin d’inclure cette instruction si RSVP est capable de signaler des interfaces non numérotées telles que définies dans la RFC 3477, Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE).

• credibility-protocol-preference—(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 supérieure. 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 ayant la valeur de crédibilité la plus élevée. Dans Junos OS version 9.4 et ultérieure, vous pouvez configurer OSPF pour qu’il prenne en compte les préférences de protocole afin de déterminer la valeur de crédibilité de la base de données Traffic Engineering. 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 mesures LSP RSVP dans les calculs de raccourcis d’ingénierie de trafic OSPF ou lorsque vous configurez LDP sur LSP RSVP. Cette option évite la dépendance mutuelle entre OSPF et RSVP, éliminant ainsi la période pendant laquelle la métrique RSVP utilisée pour le trafic de tunnelisation n’est pas à jour. En outre, si vous utilisez RSVP pour l’ingénierie de trafic, vous pouvez exécuter LDP simultanément afin d’éliminer la distribution de routes externes dans le cœur. Les LSP établis par LDP sont tunnelisés via les LSP établis par RSVP. Le LDP traite efficacement les LSP issus de l’ingénierie du trafic comme des sauts uniques.

• multicast-rpf-routes—(OSPFv2 uniquement) Installe les routes IPv4 unicast (et non les LSP) dans la table de routage multicast (inet.2) pour les vérifications RPF (Multicast Reverse-Path Forwarding). La table de routage inet.2 est constituée de routes unicast utilisées pour la recherche RPF multicast. RPF est un mécanisme anti-usurpation d’identité 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 de topologie d’état de lien. Si cette option est désactivée, les informations de topologie d’ingénierie de trafic ne sont plus distribuées dans la zone OSPF.

• shortcuts (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 entre le périphérique de routage entrant et le périphérique de routage sortant. L’adresse spécifiée dans l’instruction to au niveau hiérarchique [edit protocols mpls label-switched-path lsp-path-name] sur l’équipement de routage entrant doit correspondre à l’ID de routeur du périphérique de routage de sortie pour que le LSP fonctionne comme un lien direct vers le périphérique de routage de sortie et soit utilisé comme entrée pour les calculs OSPF SPF. Lorsqu’ils sont utilisés de cette manière, les LSP ne sont pas différents des circuits virtuels ATM (Asynchronous Transfer Mode) et Frame Relay (VC), sauf que les LSP ne transportent que 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, les routes IPv6 de raccourci calculées via OSPFv3 sont ajoutées à la table de routage inet6.3 . Par défaut, BGP n’utilise que des LSP dans ses calculs. Si vous configurez MPLS de manière à ce que BGP et IGP utilisent des LSP pour transférer le 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 des raccourcis IGP OSPF plutôt que des raccourcis d’ingénierie de trafic.

• lsp-metric-info-summary : annonce la métrique LSP dans les LSA récapitulatifs pour traiter le LSP comme un lien. Cette configuration permet aux autres périphériques de routage du réseau d’utiliser ce LSP. Pour ce faire, vous devez configurer l’ingénierie de trafic MPLS et OSPF afin d’annoncer la métrique LSP dans les LSA récapitulatifs.

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

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

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

En règle générale, les protocoles de routage intérieur tels qu’OSPF ne sont pas exécutés sur des liaisons entre des systèmes autonomes. Cependant, pour que l’ingénierie de trafic inter-AS fonctionne correctement, les 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 incluses ni dans les messages d’accessibilité BGP (EBGP) externes, ni dans les annonces de routage OSPF.

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

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

L’une des principales raisons de configurer des 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 publier des LSP dans OSPFv2 sous forme de liens point à point afin que tous les périphériques de routage participants puissent prendre en compte le LSP lors des calculs SPF. L’annonce contient une adresse locale (l’adresse de l’expéditeur du LSP), une adresse distante (l’adresse de destination du 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 aucune des options ci-dessus, utilisez la métrique OSPFv2 par défaut de 1.

Cet exemple montre comment publier des LSP dans OSPFv2.

La configuration d’un SID d’adjacence statique sur une interface entraîne la suppression du SID d’adjacence alloué dynamiquement existant ainsi que de l’itinéraire de transit pour celui-ci.

Pour les SID d’adjacence statique, les étiquettes sont sélectionnées 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 d’étiquettes à 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 attribuer une étiquette dans cette plage. Vous devez vous assurer qu’aucun protocole n’utilise la même étiquette statique. Les SID 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 :

SRGB est un espace d’étiquettes global qui est alloué au protocole en fonction de la configuration. Les étiquettes de l’ensemble du SRGB sont disponibles pour l’OSPF et ne sont pas attribuées à 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 du SRGB OSPF à l’aide du mot-clé « index » dans la configuration. Dans de tels cas, il convient de s’assurer que l’index Adj-SID n’entre pas en conflit avec un autre préfixe SID dans le domaine. Comme les préfixes-SID, les Adj-SID seront également configurés en mentionnant l’index par rapport au SRGB. Cependant, le subtlv Adj-SID aura toujours le SID comme valeur et les drapeaux L et V sont définis. Voici un exemple de configuration :

Les SID d’adjacence statique peuvent être configurés par zone et selon que la protection est requise ou non. 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 d’accès de secours et qu’un indicateur B est défini dans une annonce de SID d’adjacence.

• Non protégé : garantit qu’aucun chemin de secours n’est calculé pour un SID d’adjacence spécifique et qu’un indicateur B n’est pas défini dans une annonce de 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 le SID d’adjacence d’une interface LAN vers un voisin spécifique, vous devez configurer les SID d’adjacence sous 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 s’appuie sur le paradigme du routage source. Un nœud dirige un paquet à travers une liste ordonnée d’instructions, appelées segments. Un segment peut représenter n’importe quelle instruction, topologique ou basée sur un service. Un segment peut avoir une sémantique locale vers un nœud de routage de segments ou vers un nœud global au sein d’un domaine de routage de segments. Le routage de segments applique un flux à travers n’importe quel chemin topologique et toute chaîne de services tout en maintenant l’état par flux uniquement au niveau du nœud d’entrée dans 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é en tant qu’étiquette MPLS. Une liste ordonnée de segments est encodée sous la forme d’une pile d’étiquettes. Le segment à traiter se trouve en haut de la pile. À la fin d’un segment, l’étiquette associée est retirée 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 codé en tant qu’adresse IPv6. Une liste ordonnée de segments est codé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. À la fin d’un segment, le pointeur est incrémenté.

Les raccourcis d’ingénierie de trafic sont activés pour les routes de segment IS-IS étiquetées, lorsque vous 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, la dorsale et les périphériques d’appairage commutent les paquets MPLS avec une pile d’étiquettes construite par la source du trafic. par exemple, les serveurs de centres de données. Dans Junos OS version 17.4R1, le trafic acheminé à la source coexiste avec le trafic empruntant les chemins signalés RSVP, et le routage source est implémenté sous la forme d’une commutation d’étiquettes standard via une table MPLS.0 à l’aide des opérations d’étiquetage : pop, swap (à la même valeur d’étiquette) et swap-push (pour la protection de l’interface). Dans tous les cas, le trafic peut faire l’objet d’un équilibrage de charge 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 dans un réseau de routage de segments peuvent être enregistrées dans un format compatible 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 par interface sont comptabilisées séparément. Les statistiques SR incluent également les statistiques de trafic SPRING par membre du 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 instruction au niveau de la [edit protocol isis source-packet-routing] hiérarchie.

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

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

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

Vous pouvez afficher l’étiquette IS-IS route association 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 enregistrements des statistiques de routage de segments sont exportés vers un serveur. Vous pouvez afficher les données 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