Configuration des aspects techniques du trafic MPLS

Utilisation de LSP pour le transfert de trafic BGP et IGP

Vous pouvez configurer BGP et les IGP pour qu’ils utilisent des LSP pour transférer le trafic destiné aux routeurs sortants en incluant l’option de l’instruction bgp-igptraffic-engineering . L’option bgp-igp entraîne le déplacement de toutes les routes inet.3 vers la table de routage inet.0.

Sur le routeur entrant, incluez bgp-igp l’option pour l’instruction traffic-engineering :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

  REMARQUE :

  L’option bgp-igp de l’instruction traffic-engineering ne peut pas être configurée pour VPN). Les VPN exigent que les routes figurent dans la table de routage inet.3.

Utilisation de LSP pour le transfert dans des réseaux privés virtuels

Les VPN exigent que les routes restent dans la table de routage inet.3 pour fonctionner correctement. Pour les VPN, configurez l’option de l’instruction bgp-igp-both-ribstraffic-engineering pour que BGP et les IGP utilisent des LSP pour transférer le trafic destiné aux routeurs sortants. Cette bgp-igp-both-ribs option installe les routes entrantes à la fois dans la table de routage inet.0 (pour les routes unicast IPv4) et dans la table de routage inet.3 (pour les informations de chemin MPLS).

Sur le routeur entrant, incluez l’instruction traffic-engineering bgp-igp-both-ribs suivante :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Lorsque vous utilisez l’instruction bgp-igp-both-ribs , les routes de la table inet.3 sont copiées dans la table inet.0. Les routes copiées sont signalées par LDP ou RSVP et sont susceptibles d’avoir une préférence inférieure à celle des autres routes dans inet.0. Les itinéraires avec une préférence inférieure sont plus susceptibles d’être choisis comme itinéraires actifs. Cela peut être un problème, car les stratégies de routage n’agissent que sur les routes actives. Pour éviter ce problème, utilisez plutôt l’option mpls-forwarding .

Utilisation des routes RSVP et LDP pour le transfert, mais pas pour la sélection de route

Si vous configurez les options ou bgp-igp-both-ribs pour l’instructiontraffic-engineering, les bgp-igp LSP de haute priorité peuvent remplacer les routes IGP dans la table de routage inet.0. Les routes IGP peuvent ne plus être redistribuées car elles ne sont plus les routes actives.

Si vous configurez l’option de l’instruction mpls-forwarding , les LSP sont utilisés pour le traffic-engineering transfert, mais sont exclus de la sélection de route. Ces routes sont ajoutées aux tables de routage inet.0 et inet.3. Les LSP de la table de routage inet.0 reçoivent une préférence inférieure lorsque la route active est sélectionnée. Toutefois, les LSP de la table de routage inet.3 reçoivent une préférence normale et sont donc utilisés pour sélectionner les sauts suivants de transfert.

Lorsque vous activez l’option, les routes dont l’état est sont préférées pour le mpls-forwarding transfert même si leur préférence est ForwardingOnlyinférieure à celle de la route actuellement active. Pour examiner l’état d’un itinéraire, exécutez une show route detail commande.

Pour utiliser des LSP pour le transfert, mais les exclure de la sélection d’itinéraire, incluez l’option de l’instruction mpls-forwardingtraffic-engineering :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Lorsque vous configurez l’option mpls-forwarding , les routes de raccourci IGP sont copiées dans la table de routage inet.0 uniquement.

Contrairement à cette option, cette mpls-forwarding option vous permet d’utiliser les routes signalées par LDP et RSVP pour le bgp-igp-both-ribs transfert, et de garder les routes BGP et IGP actives à des fins de routage afin que les stratégies de routage puissent agir sur elles.

Par exemple, supposons qu’un routeur exécute BGP et qu’il possède une route BGP de 10.10.10.1/32 qu’il doit envoyer à un autre interlocuteur BGP. Si vous utilisez cette bgp-igp-both-ribs option et que votre routeur possède également un chemin de commutation d’étiquettes (LSP) vers 10.10.10.1, la route MPLS pour 10.10.10.1 devient active dans la table de routage inet.0. Cela empêche votre routeur d’annoncer la route 10.10.10.1 à l’autre routeur BGP. En revanche, si vous utilisez l’option au lieu de l’option, la route BGP 10.10.10.1/32 est annoncée à l’autre mpls-forwardingbgp-igp-both-ribs interlocuteur BGP et le LSP est toujours utilisé pour transférer le trafic vers la destination 10.10.10.1.

Publicité de la métrique LSP dans les LSA récapitulatifs

Vous pouvez configurer MPLS et OSPF pour traiter un LSP comme une liaison. Cette configuration permet aux autres routeurs du réseau d’utiliser ce LSP. Pour atteindre cet objectif, vous devez configurer les aspects techniques du trafic MPLS et OSPF afin d’annoncer la métrique LSP dans les LSA récapitulatifs.

Pour MPLS, incluez les traffic-engineering bgp-igp instructions et label-switched-path :

Vous pouvez inclure ces instructions aux niveaux hiérarchiques suivants :

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Pour OSPF, incluez l’énoncé lsp-metric-into-summary suivant :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Pour plus d’informations sur l’ingénierie du trafic OSPF, reportez-vous à la bibliothèque de protocoles de routage Junos OS pour les périphériques de routage.

Exigences en matière d’ingénierie du trafic inter-AS

La mise en place et le bon fonctionnement des LSP d’ingénierie de trafic inter-AS dépendent des exigences réseau suivantes, qui doivent toutes être remplies :

• Tous les AS sont sous le contrôle d’un seul fournisseur de services.

• OSPF est utilisé comme protocole de routage au sein de chaque AS, et EBGP est utilisé comme protocole de routage entre les AS.

• Les informations ASBR sont disponibles à l’intérieur de chaque AS.

• Les informations de routage EBGP sont distribuées par OSPF, et un maillage complet IBGP est en place au sein de chaque AS.

• Les LSP de transit ne sont pas configurés sur les liaisons inter-AS, mais sont configurés entre les ASBR des points d’entrée et de sortie sur chaque AS.

• La liaison EBGP entre les ASBR de différents AS est une liaison directe et doit être configurée en tant que liaison passive d’ingénierie du trafic sous OSPF. C’est l’adresse de liaison distante elle-même, et non l’adresse de bouclage ou toute autre adresse de liaison, qui est utilisée comme identificateur de nud distant pour cette liaison passive. Pour plus d’informations sur la configuration du mode d’ingénierie passive du trafic OSPF, reportez-vous à la section Configuration du mode TE passif OSPF.

En outre, l’adresse utilisée pour le noeud distant de la liaison OSPF passive traffic engineering doit être la même que l’adresse utilisée pour la liaison EBGP. Pour plus d’informations sur OSPF et BGP en général, consultez la bibliothèque de protocoles de routage Junos OS pour les périphériques de routage.

Limites de l’ingénierie du trafic Inter-AS

Seule la signalisation hiérarchique, ou imbriquée, des LSP est prise en charge pour les LSP d’ingénierie de trafic inter-AS. Seuls les LSP point-à-point sont pris en charge (il n’y a pas de prise en charge point-à-multipoint).

De plus, les restrictions suivantes s’appliquent. N’importe laquelle de ces conditions est suffisante pour rendre impossibles les LSP d’ingénierie de trafic inter-AS, même si les exigences ci-dessus sont remplies.

• L’utilisation de BGP multi-sauts n’est pas prise en charge.

• L’utilisation de mécanismes de contrôle ou de topologies qui empêchent les routes BGP d’être connues à l’intérieur de l’AS n’est pas prise en charge.

• Plusieurs ASBR sur un LAN entre homologues EBGP ne sont pas pris en charge. Un seul ASBR sur un LAN entre homologues EBGP est pris en charge (d’autres ASBR peuvent exister sur le LAN, mais ne peuvent pas être annoncés).

• Les réflecteurs de route ou les stratégies qui masquent les informations ASBR ou empêchent la distribution d’informations ASBR à l’intérieur des AS ne sont pas pris en charge.

• Les LSP bidirectionnels ne sont pas pris en charge (les LSP sont unidirectionnels du point de vue des aspects techniques du trafic).

• Les topologies avec des chemins inter-AS et intra-AS vers la même destination ne sont pas prises en charge.

En outre, plusieurs fonctionnalités courantes de tous les LSP ne sont pas prises en charge par les aspects techniques du trafic inter-AS :

• Les couleurs des liens des groupes d’administrateurs ne sont pas prises en charge.

• La veille secondaire n’est pas prise en charge.

• La réoptimisation n’est pas prise en charge.

• Le démarrage par démarrage sur les routeurs de transit n’est pas pris en charge.

• Le calcul de chemins divers n’est pas pris en charge.

• Le redémarrage progressif n’est pas pris en charge.

Ces listes de limitations ou de fonctionnalités non prises en charge avec les LSP d’ingénierie de trafic inter-AS ne sont pas exhaustives.

Configuration du mode TE passif OSPF

Habituellement, les protocoles de routage interne tels qu’OSPF ne sont pas exécutés sur des liaisons entre AS. Toutefois, pour que l’ingénierie du trafic inter-AS fonctionne correctement, les informations relatives à la liaison inter-AS, en particulier l’adresse sur l’interface distante, doivent être mises à disposition à l’intérieur de l’AS. Ces informations ne sont normalement incluses ni dans les messages d’accessibilité EBGP ni dans les annonces 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 des aspects techniques du trafic.

Pour configurer le mode passif OSPF pour l’ingénierie du trafic sur une interface inter-AS, incluez l’instruction pour le passive lien au niveau de la [edit protocols ospf area area-id interface interface-name] hiérarchie :

OSPF doit être correctement configuré sur le routeur. L’exemple suivant configure la liaison so-1/1/0 inter-AS pour distribuer les informations d’ingénierie du trafic avec OSPF au sein de l’AS. L’adresse IP distante est 192.168.207.2.

Transfert de paquets basé sur l’échange d’étiquettes

Le processus de transfert de paquets au niveau de chaque routeur est basé sur le concept d’échange d’étiquettes. Ce concept est similaire à ce qui se produit au niveau de chaque commutateur de mode de transfert asynchrone (ATM) dans un circuit virtuel permanent (PVC). Chaque paquet MPLS comporte un en-tête d’encapsulation de 4 octets qui contient un champ d’étiquette de 20 bits de longueur fixe. Lorsqu’un paquet contenant une étiquette arrive à un routeur, celui-ci examine l’étiquette et la copie sous forme d’index dans sa table de transfert MPLS. Chaque entrée du table de transfert contient une paire d’étiquettes d’entrée d’interface mappées à un ensemble d’informations de transfert qui est appliqué à tous les paquets arrivant sur l’interface spécifique avec la même étiquette d’entrée.

Traversée d’un réseau dorsal MPLS par un paquet

Cette section décrit le traitement d’un paquet IP lorsqu’il traverse une dorsale MPLS.

Au niveau du périphérique d’entrée du réseau dorsal MPLS, l’en-tête IP est examiné par le routeur entrant. Sur la base de cette analyse, le paquet est classé, étiqueté, encapsulé dans un en-tête MPLS et transféré vers le saut suivant dans le LSP. MPLS offre un haut degré de flexibilité dans la manière dont un paquet IP peut être assigné à un LSP. Par exemple, dans l’implémentation Junos des aspects techniques du trafic, tous les paquets arrivant au routeur entrant et destinés à quitter le domaine MPLS au niveau du même routeur de sortie sont transférés via le même LSP.

Une fois que le paquet commence à traverser le LSP, chaque routeur utilise l’étiquette pour prendre la décision de transfert. La décision de transfert MPLS est prise indépendamment de l’en-tête IP d’origine : l’interface et l’étiquette entrantes sont utilisées comme clés de recherche dans la table de transfert MPLS. L’ancienne étiquette est remplacée par une nouvelle étiquette, et le paquet est transféré vers le saut suivant le long du LSP. Ce processus est répété sur chaque routeur du LSP jusqu’à ce que le paquet atteigne le routeur de sortie.

Lorsque le paquet arrive au routeur de sortie, l’étiquette est supprimée et le paquet quitte le domaine MPLS. Le paquet est ensuite transféré en fonction de l’adresse IP de destination contenue dans l’en-tête IP d’origine du paquet, selon le chemin le plus court traditionnel calculé par le protocole de routage IP.

Composante Distribution de l’information

Les aspects techniques du trafic nécessitent une connaissance détaillée de la topologie du réseau ainsi que des informations dynamiques sur la charge du réseau. Pour implémenter le composant de diffusion de l’information, des extensions simples aux IGP sont définies. Les attributs de lien sont inclus dans l’annonce de l’état du lien de chaque routeur. Les extensions IS-IS incluent la définition de nouvelles valeurs de longueur de type (TLV), tandis que les extensions OSPF sont implémentées avec des annonces d’état de lien (LSA) opaques. L’algorithme de flooding standard utilisé par les IGP à état de lien garantit que les attributs de lien sont distribués à tous les routeurs du domaine de routage. Parmi les extensions d’ingénierie du trafic à ajouter à l’annonce de l’état de lien IGP, citons la bande passante maximale de la liaison, la bande passante maximale de la liaison réservée, la réservation de la bande passante actuelle et la coloration des liens.

Chaque routeur gère les attributs de liaison réseau et les informations de topologie dans une base de données spécialisée sur les aspects techniques du trafic. La base de données d’ingénierie du trafic est utilisée exclusivement pour calculer les chemins explicites pour le placement des LSP sur la topologie physique. Une base de données distincte est gérée afin que le calcul ultérieur des aspects techniques du trafic soit indépendant de l’IGP et de la base de données d’état de lien de l’IGP. Pendant ce temps, l’IGP poursuit son fonctionnement sans modification, en effectuant le calcul traditionnel du chemin le plus court basé sur les informations contenues dans la base de données d’état des liens du routeur.

Composant de sélection de chemin

Une fois que les attributs de liaison réseau et les informations de topologie sont inondés par l’IGP et placés dans la base de données des aspects techniques du trafic, chaque routeur entrant utilise la base de données des aspects techniques du trafic pour calculer les chemins de son propre ensemble de LSP dans le domaine du routage. Le chemin d’accès de chaque LSP peut être représenté par une route explicite stricte ou vague. Une route explicite est une séquence préconfigurée de routeurs qui doit faire partie du chemin physique du LSP. Si le routeur entrant spécifie tous les routeurs dans le LSP, le LSP est dit identifié par une route explicite stricte. Si le routeur entrant spécifie seulement certains des routeurs dans le LSP, le LSP est décrit comme une route explicite lâche. La prise en charge de routes explicites strictes et lâches permet d’accorder une grande latitude au processus de sélection des chemins chaque fois que cela est possible, mais d’être limité si nécessaire.

Le routeur entrant détermine le chemin physique de chaque LSP en appliquant un algorithme CSPF (Constrained Shortest Path First) aux informations de la base de données des aspects techniques du trafic. CSPF est un algorithme qui privilégie le chemin le plus court qui a été modifié pour prendre en compte des restrictions spécifiques lors du calcul du chemin le plus court à travers le réseau. Les données d’entrée dans l’algorithme CSPF comprennent :

• Informations sur l’état des liens de topologie extraites de l’IGP et conservées dans la base de données des aspects techniques du trafic

• Attributs associés à l’état des ressources réseau (telles que la bande passante totale de la liaison, la bande passante de la liaison réservée, la bande passante disponible de la liaison et la couleur de la liaison) qui sont transportées par les extensions IGP et stockées dans la base de données des aspects techniques du trafic

• Attributs administratifs requis pour prendre en charge le trafic traversant le LSP proposé (tels que les exigences en matière de bande passante, le nombre maximal de sauts et les exigences de stratégie administrative) obtenus à partir de la configuration utilisateur

Lorsque CSPF prend en compte chaque nœud et lien candidats pour un nouveau LSP, il accepte ou rejette un composant de chemin spécifique en fonction de la disponibilité des ressources ou du fait que la sélection du composant viole les contraintes de stratégie utilisateur. Le résultat du calcul CSPF est une route explicite constituée d’une séquence d’adresses de routeur qui fournit le chemin le plus court à travers le réseau qui répond aux contraintes. Cette route explicite est ensuite transmise au composant de signalisation, qui établit l’état de transfert dans les routeurs le long du LSP.

Composant de signalisation

Un LSP n’est pas connu pour être fonctionnel tant qu’il n’est pas effectivement établi par le composant de signalisation. Le composant de signalisation, qui est responsable de l’établissement de l’état LSP et de la distribution des étiquettes, s’appuie sur un certain nombre d’extensions de RSVP :

• L’objet Explicit Route permet à un message de chemin RSVP de traverser une séquence explicite de routeurs indépendante du routage IP conventionnel du chemin le plus court. L’itinéraire explicite peut être strict ou vague.

• L’objet Label Request permet au message de chemin RSVP de demander aux routeurs intermédiaires de fournir une liaison d’étiquette pour le LSP qu’ils établissent.

• L’objet Label permet à RSVP de prendre en charge la distribution d’étiquettes sans modifier ses mécanismes existants. Étant donné que le message RSVP Resv suit le chemin inverse du message RSVP path, l’objet Label prend en charge la distribution des étiquettes des nœuds en aval vers les nœuds en amont.

Rôle d’un protocole de passerelle intérieure

Un protocole IGP (Interior Gateway Protocol) est un type de protocole utilisé pour échanger des informations de routage entre des appareils au sein d’un système autonome (AS). En fonction de la méthode de calcul du meilleur chemin vers une destination, les IGP sont divisés en deux catégories :

• Protocoles d’état de lien : publiez des informations sur la topologie du réseau (liens directement connectés et état de ces liens) à tous les routeurs à l’aide d’adresses de multidiffusion et de mises à jour de routage déclenchées jusqu’à ce que tous les routeurs exécutant le protocole d’état de lien disposent d’informations identiques sur l’interréseau. Le meilleur chemin vers une destination est calculé en fonction de contraintes telles que le délai maximal, la bande passante minimale disponible et l’affinité de classe de ressource.

  OSPF et IS-IS sont des exemples de protocoles à état de lien.

• Protocoles à vecteur de distance : publiez des informations complètes sur la table de routage aux voisins directement connectés à l’aide d’une adresse de diffusion. Le meilleur chemin est calculé en fonction du nombre de sauts vers le réseau de destination.

  RIP est un exemple de protocole à vecteur de distance.

Comme son nom l’indique, le rôle d’un IGP est de fournir une connectivité de routage au sein ou en interne à un domaine de routage donné. Un domaine de routage est un ensemble de routeurs sous contrôle administratif commun qui partagent un protocole de routage commun. Un AS peut être constitué de plusieurs domaines de routage, où IGP fonctionne pour annoncer et apprendre les préfixes de réseau (routes) des routeurs voisins afin de construire une table de routage qui contient finalement des entrées pour toutes les sources annonçant l’accessibilité pour un préfixe donné. IGP exécute un algorithme de sélection de route pour sélectionner le meilleur chemin entre le routeur local et chaque destination, et fournit une connectivité complète entre les routeurs constituant un domaine de routage.

En plus d’annoncer l’accessibilité du réseau interne, les IGP sont souvent utilisés pour annoncer des informations de routage externes à leur domaine de routage par le biais d’un processus connu sous le nom de redistribution de route. La redistribution de route est le processus d’échange d’informations de routage entre des protocoles de routage distincts afin de lier plusieurs domaines de routage lorsque la connectivité intra-AS est souhaitée.

Limites d’un protocole Interior Gateway

Bien que chaque IGP ait ses propres avantages et limites, les plus grandes limites de l’IGP en général sont les performances et l’évolutivité.

Les IGP sont conçus pour acquérir et distribuer des informations sur la topologie du réseau à des fins d’ingénierie du trafic. Bien que ce modèle ait bien fonctionné, les IGP ont des limites inhérentes à l’évolutivité lorsqu’il s’agit de distribuer de grandes bases de données. Les IGP peuvent détecter automatiquement les voisins, ce qui leur permet d’obtenir des informations sur la topologie du réseau au sein de la zone. Cependant, la base de données d’état de lien ou une base de données d’ingénierie du trafic a la portée d’une seule zone ou AS, ce qui limite les applications, telles que l’ingénierie du trafic de bout en bout, l’avantage d’avoir une visibilité externe pour prendre de meilleures décisions.

Pour les réseaux à commutation d’étiquettes, tels que MPLS et MPLS généralisé (GMPLS), la plupart des solutions existantes d’ingénierie du trafic fonctionnent dans un seul domaine de routage. Ces solutions ne fonctionnent pas lorsqu’une route entre le noeud entrant et le noeud sortant quitte la zone de routage ou l’AS du noeud entrant. Dans de tels cas, le problème de calcul du chemin devient compliqué en raison de l’indisponibilité des informations de routage complètes sur l’ensemble du réseau. En effet, les fournisseurs de services choisissent généralement de ne pas divulguer les informations de routage au-delà de la zone de routage ou de l’AS pour des raisons d’évolutivité et de confidentialité.

Nécessité d’une distribution couvrant l’état des liens

L’une des limites de l’IGP est son incapacité à couvrir la distribution d’états de liens en dehors d’une seule zone ou AS. Toutefois, la répartition des informations d’état de lien acquises par un IGP sur plusieurs zones ou AS présente les besoins suivants :

• Calcul du chemin LSP : ces informations sont utilisées pour calculer le chemin des LSP MPLS sur plusieurs domaines de routage, par exemple un LSP TE inter-zone.

• Entités de calcul de chemin externes : les entités de calcul de chemin externes, telles que l’optimisation du trafic couche applicative (ALTO) et les éléments de calcul de chemin (PCE), effectuent des calculs de chemin en fonction de la topologie du réseau et de l’état actuel des connexions au sein du réseau, y compris des informations d’ingénierie du trafic. Ces informations sont généralement distribuées par les IGP au sein du réseau.

  Toutefois, étant donné que les entités de calcul de chemin externes ne peuvent pas extraire ces informations des IGP, elles effectuent une surveillance du réseau pour optimiser les services réseau.

Utiliser BGP comme solution

• Présentation
• Implémentation

Implémentation

Dans Junos OS, les IGP installent les informations de topologie dans une base de données appelée base de données d’ingénierie du trafic. La base de données des aspects techniques du trafic contient les informations topologiques agrégées. Pour installer les informations de topologie IGP dans la base de données d’ingénierie du trafic, utilisez set igp-topology l’instruction de configuration aux niveaux [edit protocols isis traffic-engineering] et [edit protocols ospf traffic-engineering] de la hiérarchie. Le mécanisme de distribution des informations sur l’état des liens à l’aide de BGP inclut le processus d’annonce de la base de données d’ingénierie du trafic dans BGP-TE (importation) et l’installation des entrées de BGP-TE dans la base de données d’ingénierie du trafic (exportation).

À partir de Junos OS version 20.4R1, vous pouvez configurer l’ingénierie du trafic IS-IS pour stocker les informations IPv6 dans la base de données d’ingénierie du trafic (TED) en plus des adresses IPv4. BGP-LS distribue ces informations sous forme de routes de la base de données d’ingénierie du trafic à la table de routage lsdist.0 à l’aide des stratégies d’importation de la base de données d’ingénierie du trafic. Ces routes sont annoncées aux homologues BGP-TE sous forme d’informations d’accessibilité de la couche réseau (NLRI) avec type, longueur et valeur (TLV) d’ID de routeur IPv6. En ajoutant des informations IPv6, vous pouvez obtenir la topologie complète du réseau dans la base de données des aspects techniques du trafic.

Figure 1 : Implémentation par Junos OS de la distribution d’état des liens BGP

BGP-LS NLRI et ID de la Confédération

À compter de Junos OS version 23.1R1, Junos OS active les informations d’accessibilité de la couche réseau (NLRI) BGP Link State (BGP-LS) pour porter l’ID de confédération dans TLV 512 lorsque la confédération BGP est activée. Le NLRI porte l’ID de la confédération ainsi que le numéro du système autonome membre (numéro AS) dans TLV 517 tel que défini dans la RFC 9086. Le module de base de données d’ingénierie du trafic de Junos OS apporte les modifications nécessaires pour encoder l’ID de confédération et le numéro AS de membre dans TLV 512 et TLV 517 respectivement, tout en créant le BGP-LS NLRI (qui est injecté dans la table de routage lsdist.0). Dans les versions antérieures à Junos OS version 23.1R1, BGP-LS NLRI porte uniquement le numéro AS membre dans TLV 512 et l’ID de confédération n’est pas encodé dans la table de routage lsdist.0.

Importation de bases de données d’ingénierie du trafic

Pour publier la base de données d’ingénierie du trafic dans BGP-TE, les entrées de lien et de nœud dans la base de données d’ingénierie du trafic sont converties sous forme de routes. Ces routes converties sont ensuite installées par la base de données d’ingénierie du trafic pour le compte de l’IGP correspondant, dans une table de routage visible par l’utilisateur appelée lsdist.0, dans des conditions soumises aux stratégies de routage. La procédure de fuite des entrées de la base de données d’ingénierie du trafic vers lsdist.0 est appelée importation de base de données d’ingénierie du trafic, comme illustré à Figure 1la .

Il existe des stratégies pour régir le processus d’importation de la base de données d’ingénierie du trafic. Par défaut, aucune entrée n’est divulguée de la base de données d’ingénierie du trafic dans la lsdist.0 table.

À compter de Junos OS version 17.4R1, la base de données des aspects techniques du trafic installe les informations de topologie IGP (Interior Gateway Protocol) en plus des informations de topologie RSVP-TE dans la table de routage lsdist.0, comme illustré à Figure 1la . Avant Junos OS version 17.4R1, la base de données des aspects techniques du trafic exportait uniquement les informations de topologie RSVP-TE. Vous pouvez désormais surveiller à la fois les informations IGP et les informations de topologie des aspects techniques du trafic. Le BGP-LS lit les entrées IGP de lsdist.0 et les annonce aux homologues BGP. Pour importer des informations de topologie IGP dans BGP-LS à partir de lsdist.0, utilisez l’instruction de set bgp-ls configuration au niveau de la [edit protocols mpls traffic-engineering database import igp-topology] hiérarchie.

Exportation de la base de données Traffic Engineering

BGP peut être configuré pour exporter ou publier des routes à partir de la lsdist.0 table, sous réserve d’une stratégie. Ceci est commun pour tout type d’origine de route dans BGP. Pour publier BGP-TE dans la base de données d’ingénierie du trafic, le BGP doit être configuré avec la famille d’adresses BGP-TE et une stratégie d’exportation qui sélectionne les routes à redistribuer dans BGP.

BGP propage ensuite ces routes comme n’importe quel autre NLRI. Les homologues BGP pour lesquels la famille BGP-TE est configurée et négociée reçoivent des NLRI BGP-TE. BGP stocke les NLRI BGP-TE reçus sous la forme de routes dans la table, qui est la lsdist.0 même table que celle qui stocke les routes BGP-TE d’origine locale. Les routes installées par BGP sont lsdist.0 ensuite distribuées à d’autres homologues comme n’importe quelle autre route. Ainsi, la procédure standard de sélection de route s’applique aux NLRI BGP-TE reçus de plusieurs locuteurs.

Pour réaliser le TE interdomaine, les routes entrantes lsdist.0 sont divulguées dans la base de données d’ingénierie du trafic par le biais d’une stratégie. Ce processus est appelé exportation de base de données d’ingénierie du trafic, comme illustré à Figure 1la .

Il existe des stratégies pour régir le processus d’exportation de la base de données d’ingénierie du trafic. Par défaut, aucune entrée n’est divulguée de la table vers la base de données d’ingénierie lsdist.0 du trafic.

À partir de Junos OS version 22.4R1, vous pouvez distribuer les stratégies d’ingénierie du trafic (TE) provenant du protocole de routage de segments vers la base de données d’ingénierie du trafic (TED) et dans l’état de liaison BGP sous forme de routes. BGP link-state collecte les informations relatives aux stratégies TE, afin que les contrôleurs externes puissent effectuer des actions telles que le calcul de chemin, la réoptimisation et la visualisation du réseau au sein et entre les domaines.

Configurez set protocols source-packet-routing traffic-engineering database pour autoriser le stockage des stratégies de routage de segments (SR) dans TED.

REMARQUE :

Pour les applications SDN, telles que PCE et ALTO, les informations BGP-TE annoncées ne peuvent pas s’infiltrer dans la base de données d’ingénierie du trafic d’un routeur. Dans ce cas, un serveur externe qui s’apparie avec les routeurs à l’aide de BGP-TE est utilisé pour déplacer les informations topologiques vers le ciel/le système d’orchestration qui s’étend sur le réseau. Ces serveurs externes peuvent être considérés comme des consommateurs BGP-TE, c’est-à-dire qu’ils reçoivent des routes BGP-TE, mais qu’ils n’en font pas la publicité.

Attribution de valeurs de crédibilité

Une fois les entrées installées dans la base de données d’ingénierie du trafic, les informations apprises BGP-TE sont mises à disposition pour le calcul du chemin CSPF. La base de données des aspects techniques du trafic utilise un schéma de préférences de protocole basé sur des valeurs de crédibilité. Un protocole avec une valeur de crédibilité plus élevée est préféré à un protocole avec une valeur de crédibilité plus faible. BGP-TE a la capacité d’annoncer des informations apprises à partir de plusieurs protocoles en même temps, de sorte qu’en plus des entrées IGP installées dans la base de données d’ingénierie du trafic, il peut y avoir des entrées installées par BGP-TE qui correspondent à plusieurs protocoles. Le composant d’exportation de base de données d’ingénierie du trafic crée un protocole de base de données d’ingénierie du trafic et un niveau de crédibilité pour chaque protocole pris en charge par BGP-TE. Ces valeurs de crédibilité sont configurables dans l’interface de ligne de commande.

L’ordre de crédibilité des protocoles BGP-TE est le suivant :

• Inconnu : 80

• OSPF—81

• ISIS Niveau 1 à 82

• ISIS Niveau 2 – 83

• Statique : 84

• Direct—85

Calcul du chemin de crédibilité croisée

Une fois que vous avez attribué des valeurs de crédibilité, chaque niveau de crédibilité est traité comme un plan individuel. L’algorithme Constrained Shorted Path First commence avec la crédibilité attribuée la plus élevée à la plus faible, en trouvant un chemin à l’intérieur de ce niveau de crédibilité.

Avec BGP-TE, il est essentiel de calculer les chemins entre les niveaux de crédibilité pour calculer les chemins inter-AS. Par exemple, différents paramètres de crédibilité sont observés sur un périphérique de la zone 0 qui calcule le chemin à travers la zone 1, car les entrées de zone 0 sont installées par OSPF et les entrées de zone 1 sont installées par BGP-TE.

Pour activer le calcul de chemin d’accès à tous les niveaux de crédibilité, incluez l’instruction cross-credibility-cspf aux edit protocols mplsniveaux , [edit protocols mpls label-switched-path lsp-name]et [edit protocols rsvp] hiérarchique. Au niveau hiérarchique, les impacts d’activation contournent les [edit protocols rsvp] LSP et l’expansion cross-credibility-cspf des sauts lâches en transit.

La configuration cross-credibility-cspf active le calcul des chemins entre les niveaux de crédibilité à l’aide de l’algorithme Constrained Shortest Path First, dans lequel la contrainte n’est pas exécutée sur la base d’une crédibilité par crédibilité, mais en tant que contrainte unique ignorant les valeurs de crédibilité affectées.

NLRI et TLV BGP-TE

Comme les autres routes BGP, LES NLRI BGP-TE peuvent également être distribués via un réflecteur de route qui parle BGP-TE NLRI. Junos OS implémente la prise en charge de la réflexion de route pour la famille BGP-TE.

Voici la liste des NLRI pris en charge :

• Lien NLRI

• Nœud NLRI

• Préfixe IPv4 NLRI (réception et propagation)

• Préfixe IPv6 NLRI (réception et propagation)

• Politique TE NLRI

REMARQUE :

Junos OS ne prend pas en charge la forme de distinction de route des NRLI ci-dessus.

Voici la liste des champs pris en charge dans les NLRI de lien et de nœud :

• Protocol-ID : NLRI provient des valeurs de protocole suivantes :

  • ISIS-L1

  • ISIS-L2

  • OSPF

  • SPRING-TE

• Identifier (Identifier) : cette valeur est configurable. Par défaut, la valeur de l’identificateur est définie sur 0.

• Descripteur de noeud local/distant : il s’agit notamment des éléments suivants :

  • Système autonome

  • BGP-LS Identifier (Identificateur BGP-LS) : cette valeur est configurable. Par défaut, la valeur de l’identificateur BGP-LS est définie sur 0

  • ID de zone

  • ID routeur IGP

• Descripteurs de lien (uniquement pour le NLRI de lien) : cela inclut :

  • Identifier local/distant de liaison

  • Adresse d’interface IPv4

  • Adresse voisine IPv4

  • Adresse du voisin/de l’interface IPv6 : les adresses du voisin et de l’interface IPv6 ne proviennent pas, mais sont uniquement stockées et propagées lorsqu’elles sont reçues.

  • ID multi-topologie : cette valeur n’est pas d’origine, mais stockée et propagée lorsqu’elle est reçue.

Voici la liste des TLV d’attribut LINK_STATE prises en charge :

• Attributs de lien :

  • Groupe administratif

  • Bande passante maximale de la liaison

  • Bande passante maximale réservable

  • Bande passante non réservée

  • Métrique TE par défaut

  • SRLG (en anglais seulement)

  • Les TLV suivantes, qui ne sont pas d’origine, mais seulement stockées et propagées lorsqu’elles sont reçues :

    • Attributs de lien opaques

    • Masque de protocole MPLS

    • Métrique

    • Type de protection de liaison

    • Attribut de nom de lien

• Attributs de noeud :

  • ID routeur IPv4

  • Node flag bits (bits d’indicateur de nœud) : seul le bit de surcharge est défini.

  • Les TLV suivantes, qui ne sont pas d’origine, mais seulement stockées et propagées lorsqu’elles sont reçues :

    • Multi-topologie

    • Propriétés de noeud spécifiques à OSPF

    • Propriétés de noeud opaque

    • Nom du noeud

    • Identificateur de zone IS-IS

    • ID routeur IPv6

  • Prefix attributes (Attributs de préfixe) : ces TLV sont stockés et propagés comme n’importe quel autre TLV inconnu.

Fonctionnalités prises en charge et non prises en charge

Junos OS prend en charge les fonctionnalités suivantes avec la distribution d’état des liens via BGP :

• Annonce d’une capacité de transfert assurée multiprotocole

• Transmission et réception des NLRI BGP et BGP-TE à état de nud et de lien

• Routage actif ininterrompu pour les NLRI BGP-TE

• Stratégies

Junos OS prend not en charge les fonctionnalités suivantes pour la distribution d’état de liaison à l’aide de BGP :

• Topologies, liens ou nuds agrégés

• Prise en charge du séparateur de route pour les NLRI BGP-TE

• Identificateurs multi-topologiques

• Identifiants multi-instances (à l’exception de l’ID d’instance par défaut 0)

• Annonce de la TLV de la zone de liaison et de nœud

• Publicité pour les protocoles de signalisation MPLS

• Importation d’informations sur les nœuds et les liens avec des adresses qui se chevauchent

Extensions d’état de lien BGP pour le routage de paquets sources dans les réseaux (SPRING)

À compter de Junos OS version 17.2R1, la famille d’adresses d’état de lien BGP est étendue pour distribuer les informations topologiques SPRING (Source Packet Routing in Networking) aux contrôleurs SDN (Software-Defined Networking). BGP apprend généralement les informations sur l’état des liens à partir d’IGP et les distribue aux homologues BGP. Outre BGP, le contrôleur SDN peut obtenir des informations sur l’état des liens directement à partir d’IGP si le contrôleur fait partie d’un domaine IGP. Toutefois, la distribution de l’état des liens BGP fournit un mécanisme évolutif pour exporter les informations de topologie. Les extensions d’état de lien BGP pour SPRING sont prises en charge sur les réseaux interdomaines.

• Routage source des paquets dans les réseaux (SPRING)
• Flux de données SPRING d’état de lien BGP
• Attributs et TLV d’état de lien BGP pris en charge, et fonctionnalités non prises en charge pour l’état de lien BGP avec SPRING

Flux de données SPRING d’état de lien BGP

Figure 2 représente le flux de données SPRING à état de lien BGP qu’IS-IS envoie à la base de données d’ingénierie du trafic.

Figure 2 : Routage de paquets source à état de lien BGP dans les réseaux (SPRING)

• IGP envoie les attributs SPRING à la base de données d’ingénierie du trafic.

• Les fonctionnalités SPRING et les informations d’algorithme sont transférées en tant qu’attributs de nœud dans la base de données d’ingénierie du trafic.

• Les informations SID adjacentes et LAN adjacentes sont portées en tant qu’attributs de lien.

• Les informations de préfixe SID ou de node-SID sont portées en tant qu’attributs de préfixe.

• Un nouvel ensemble ou une modification d’attributs existants déclenche des mises à jour IGP de la base de données d’ingénierie du trafic avec de nouvelles données.

  ATTENTION :

  Si les aspects techniques du trafic sont désactivés au niveau IGP, aucun des attributs n’est envoyé à la base de données des aspects techniques du trafic.

• Tous les paramètres de l’IRLN d’ingénierie du trafic BGP, y compris les descripteurs de lien, de nud et de préfixe, sont dérivés des entrées de la base de données d’ingénierie du trafic.

• La base de données des aspects techniques du trafic importe les entrées de route dans la lsdist.0 table de routage à partir d’IGP soumis à stratégie.

• La stratégie par défaut de BGP consiste à exporter des routes connues de BGP uniquement. Vous configurez une stratégie d’exportation pour les routes non-BGP dans la lsdis.0 table de routage. Cette stratégie annonce une entrée apprise à partir de la base de données des aspects techniques du trafic.

Vérification du nœud NLRI appris via BGP avec OSPF comme IGP

Voici un exemple de sortie permettant de vérifier le nœud NLRI appris via BGP avec OSPF comme IGP :

Vérification du préfixe NLRI appris via BGP avec OSPF comme IGP

Voici un exemple de sortie permettant de vérifier le préfixe NLRI appris via BGP avec OSPF comme IGP :

Avantages des plans de transport de classe BGP

• Découplage du réseau : les couches de service et de transport sont découplées l’une de l’autre, ce qui constitue les bases du découpage et de la virtualisation du réseau, le découpage de bout en bout sur plusieurs domaines réduisant considérablement les dépenses d’investissement.

• Interopérabilité inter-domaines : étend le déploiement de la classe de transport à tous les domaines de coopération afin que les différents protocoles de signalisation de transport interagissent dans chaque domaine. Réconcilie toutes les différences entre les espaces de noms communautaires étendus qui peuvent être utilisés dans chaque domaine.

• Résolution colorée avec solution de secours : active la résolution sur des tunnels colorés (RSVP, IS-IS algorithme flexible) avec des options de récupération flexibles sur des tunnels au mieux ou tout autre tunnel de couleur.

• Qualité de service : personnalise et optimise le réseau pour respecter les exigences de niveau de service de bout en bout.
• Exploitation des déploiements existants : prend en charge des protocoles de tunnelisation bien déployés, tels que RSVP, ainsi que de nouveaux protocoles, tels que l’algorithme flexible IS-IS, ce qui permet de préserver le retour sur investissement et de réduire les OPEX.

Terminologie des plans de transport de classe BGP

Cette section fournit un résumé des termes couramment utilisés pour comprendre le plan de transport de classe BGP.

• Nœud de service : périphériques PE (Ingress Provider Edge) qui envoient et reçoivent des routes de service (Internet et VPN de couche 3).

• Nœud de bordure : appareil au point de connexion de différents domaines (zones IGP ou AS).

• Nœud de transport : appareil qui envoie et reçoit des routes de monodiffusion étiquetées BGP (LU).

• BGP-VPN : VPN construits à l’aide de mécanismes RFC4364.

• Route Target (RT) : type de communauté étendue utilisé pour définir l’appartenance VPN.

• Route Distinguisher (RD) : identificateur utilisé pour distinguer le VPN ou le service VPLS (Virtual Private LAN Service) auquel appartient une route. Chaque instance de routage doit être associée à un séparateur de route unique.

• Resolution scheme (Schéma de résolution) : utilisé pour résoudre l’adresse de saut suivant (PNH) de protocole dans les RIB de résolution fournissant une solution de secours.

  Ils mappent les itinéraires vers les différents semi-rigides de transport du système en fonction de la communauté de cartographie.

• Famille de services : famille d’adresses BGP utilisée pour les routes publicitaires pour le trafic de données, par opposition aux tunnels.

• Famille de transport : famille d’adresses BGP utilisée pour les tunnels publicitaires, qui sont à leur tour utilisés par les routes de service pour la résolution.

• Tunnel de transport : tunnel sur lequel un service peut placer le trafic, par exemple, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

• Domaine de tunnel : domaine du réseau contenant les nœuds de service et les nœuds de bordure sous un contrôle administratif unique qui est relié par un tunnel. Un tunnel de bout en bout s’étendant sur plusieurs domaines de tunnels adjacents peut être créé en assemblant les nœuds à l’aide d’étiquettes.

• Classe de transport : groupe de tunnels de transport offrant le même type de service.

• Classe de transport RT : nouveau format de cible d’itinéraire utilisé pour identifier une classe de transport spécifique.

  Nouveau format de Route Target utilisé pour identifier une classe de transport spécifique.

• Transport RIB : au niveau du nœud de service et du nœud de frontière, une classe de transport a un semi-rigide de transport associé qui contient ses itinéraires de tunnel.

• RTI de transport : instance de routage ; conteneur du semi-rigide de transport, et la classe de transport associée Route Target et Route Distinguisher.

• Plan de transport : ensemble de RTI de transport important de la même classe de transport RT. Ceux-ci sont à leur tour assemblés pour s’étendre à travers les limites du domaine de tunnel à l’aide d’un mécanisme similaire à l’option Inter-AS b pour échanger des étiquettes aux nœuds de bordure (nexthop-self), formant un plan de transport de bout en bout.

• Mappage de la communauté : communauté sur un itinéraire de service qui mappe à résoudre sur une classe de transport.

Comprendre les plans de transport avec classe BGP

Vous pouvez utiliser des plans de transport avec classe BGP pour configurer des classes de transport afin de classer un ensemble de tunnels de transport dans un réseau intra-AS en fonction des caractéristiques d’ingénierie du trafic, et utiliser ces tunnels de transport pour mapper les itinéraires de service avec le SLA souhaité et le plan de secours prévu.

Les plans de transport avec classe BGP peuvent étendre ces tunnels aux réseaux interdomaines qui s’étendent sur plusieurs domaines (AS ou zones IGP) tout en préservant la classe de transport. Pour ce faire, vous devez configurer la famille BGP de la couche de transport transport de classe BGP entre les nœuds de bordure et de service.

Dans les implémentations inter-AS et intra-AS, de nombreux tunnels de transport (LSP MPLS, IS-IS flexible algorithm, SR-TE) peuvent être créés à partir des nœuds de service et de frontière. Les LSP peuvent être signalés à l’aide de différents protocoles de signalisation dans différents domaines et peuvent être configurés avec différentes caractéristiques d’ingénierie du trafic (classe ou couleur). Le point de terminaison du tunnel de transport fait également office de point de terminaison de service et peut être présent dans le même domaine de tunnel que le nœud d’entrée de service, ou dans un domaine adjacent ou non adjacent. Vous pouvez utiliser des plans de transport avec classe BGP pour rechercher des services sur des LSP avec certaines caractéristiques d’ingénierie du trafic à l’intérieur d’un seul domaine ou sur plusieurs domaines.

Les plans de transport de classe BGP réutilisent la technologie BGP-VPN, ce qui permet de coupler et de coordonner les domaines de tunnelisation.

• Les informations d’accessibilité de la couche réseau (NLRI) sont RD :TunnelEndpoint utilisées pour le masquage des chemins d’accès.
• La cible de route indique la classe de transport des LSP et les routes fuient vers le RIB de transport correspondant sur l’équipement de destination.
• Chaque protocole de tunnelisation de transport installe une route entrante dans la table de routage transport-class.inet.3, modélise la classe de transport de tunnel en tant que cible de routage VPN et collecte les LSP de la même classe de transport dans la table de routage transport-rib transport-class.inet.3.

• Les routes de cette instance de routage sont annoncées dans le plan de transport de classe BGP (TRANSPORT INET) AFI-SAFI en suivant des procédures similaires à celles de la RFC-4364.

• Lorsque vous franchissez les limites d’une liaison inter-AS, vous devez suivre les procédures de l’option b pour assembler les tunnels de transport dans ces domaines adjacents.

  De même, lorsque vous traversez des régions intra-AS, vous devez suivre les procédures de l’option b pour assembler les tunnels de transport dans les différents domaines TE.

• Vous pouvez définir des schémas de résolution pour spécifier l’intention sur la variété des classes de transport dans un ordre de secours.

• Vous pouvez résoudre les routes de service et les routes de transport de classe BGP sur ces classes de transport, en transportant la communauté de mappage sur celles-ci.

La famille de transport de classe BGP s’exécute parallèlement à la famille de couches de transport BGP-LU. Dans un réseau MPLS homogène utilisant BGP-LU, il est difficile de répondre aux exigences strictes des SLA de la 5G, car les caractéristiques techniques du trafic des tunnels ne sont pas connues ou préservées au-delà des frontières du domaine. Les plans de transport de classe BGP offrent un moyen simple et évolutif sur le plan opérationnel d’annoncer plusieurs chemins pour les bouclages distants, ainsi que les informations sur la classe de transport dans l’architecture MPLS transparente. Dans les itinéraires de la famille de transport avec classe BGP, différents chemins SLA sont représentés à l’aide de la communauté étendue Transport Route-Target, qui porte la couleur de la classe de transport. Cette cible de route de transport est utilisée par les routeurs BGP de réception pour associer la route de transport de classe BGP à la classe de transport appropriée. Lors de la nouvelle publication des routes de transport de classe BGP, MPLS permute les routes et interconnecte les tunnels intra-AS de la même classe de transport, formant ainsi un tunnel de bout en bout qui préserve la classe de transport.

Implémentation intra-AS des plans de transport avec classe BGP

Figure 4 illustre une topologie de réseau avec des scénarios avant/après d’implémentation de plans de transport de classe BGP dans un domaine intra-AS. Les équipements PE11 et PE12 utilisent des LSP RSVP comme tunnel de transport et tous les itinéraires de tunnel de transport sont installés dans le RIB inet.3. L’implémentation de plans de transfert avec classe BGP permet aux tunnels de transport RSVP d’être sensibles aux couleurs, de la même manière que les tunnels de routage de segments.

Figure 4 : Domaine intra-AS : Scénarios avant/après pour l’implémentation de plans de transport avec classe BGP

Pour classer les tunnels de transport en classe de transport BGP dans une configuration intra-AS :

1. Définissez la classe de transport au niveau du nœud de service (équipements PE d’entrée), par exemple, or et bronze, et attribuez des valeurs de communauté de couleurs à la classe de transport définie.

   Exemple de configuration :

2. Associez le tunnel de transport à une classe de transport spécifique au niveau du nœud d’entrée des tunnels.

   Exemple de configuration :

Fonctionnalité de plan de transport avec classe BGP intra-AS :

• Le transport avec classe BGP crée des RIB de transport prédéfinis par classe de transport nommée (or et bronze) et dérive automatiquement la communauté de mappage à partir de sa valeur de couleur (100 et 200).
• Les routes de transport intra-AS sont renseignées dans les RIB de transport par le protocole de tunnelisation lorsqu’il est associé à une classe de transport.

  Dans cet exemple, les routes RSVP LSP associées à la classe de transport or (couleur 100) et à la classe de transport bronze (couleur 200) sont installées dans les RIB de transport junos-rti-tc-<100>.inet.3 et junos-rti-tc-<200>.inet.3, respectivement.

• Les nœuds de service (PE d’entrée) font correspondre la communauté de couleurs étendue (color :0 :100 et color :0 :200) de la route de service à la communauté de mappage dans des RIB de résolution prédéfinis et résolvent le saut suivant du protocole (PNH) dans les RIB de transport correspondants (soit junos-rti-tc-<100>.inet.3, soit junos-rti-tc-<200>.inet.3).
• Les routes BGP se lient à un schéma de résolution en transportant la communauté de mappage associée.
• Chaque classe de transport crée automatiquement deux schémas de résolution prédéfinis et dérive automatiquement la communauté de mappage.

  L’un des schémas de résolution permet de résoudre les routes de service qui utilisent Color :0 :<val> comme communauté de mappage.

  L’autre schéma de résolution permet de résoudre les itinéraires de transport qui utilisent Transport-Target :0 :<val> comme communauté de mappage.

• Si le PNH de la route de service ne peut pas être résolu à l’aide des RIB répertoriés dans le schéma de résolution prédéfini, il peut revenir à la table de routage inet.3.
• Vous pouvez également configurer une solution de secours entre des RIB de transport de couleurs différentes à l’aide des schémas de résolution définis par l’utilisateur dans la [edit routing-options resolution scheme] hiérarchie de configuration.

Implémentation inter-AS de plans de transport de classe BGP

Dans un réseau inter-AS, BGP-LU est converti en réseau de transport de classe BGP après avoir configuré au moins deux classes de transport (or et bronze) sur tous les nœuds de service ou équipements PE et nœuds de bordure (ABR et ASBR).

Pour convertir les tunnels de transport en transport de classe BGP :

1. Définissez la classe de transport au niveau des nœuds de service (équipements PE entrants) et des nœuds de bordure (ABR et ASBR), par exemple, gold et broze.

   Exemple de configuration :

2. Associez les tunnels de transport à une classe de transport spécifique au niveau du nœud d’entrée des tunnels (PE d’entrée, ABR et ASBR).

   Exemple de configuration :

   Pour les prestataires de services linguistiques RSVP

   Pour l’algorithme IS-IS flxible

3. Activez une nouvelle famille pour le transport de classe BGP (transport inet) et BGP-LU (inet labeled-unicast) dans le réseau.

   Exemple de configuration :

4. Annoncez les itinéraires de service à partir de l’équipement PE de sortie avec la communauté de couleurs étendue appropriée.

   Exemple de configuration :

Fonctionnalité de plan de transport avec classe BGP inter-AS :

1. Les plans de transport avec classe BGP créent des RIB de transport prédéfinis par classe de transport nommée (or et bronze) et dérivent automatiquement la communauté de mappage à partir de sa valeur de couleur.

2. Lorsqu’elles sont associées à une classe de transport, les routes de transport intra-AS sont renseignées dans les RIB de transport par des protocoles de tunnelisation.

   Par exemple, les voies de tunnel de transport associées à la classe de transport or et bronze sont installées dans les semi-rigides de transport junos-rti-tc-<100>.inet.3 et junos-rti-tc-<200>.inet.3, respectivement.

3. Les plans de transport de classe BGP utilisent un séparateur de route et une cible de route uniques lorsqu’ils copient les itinéraires de tunnel de transport de chaque RIB de transport vers la table de routage bgp.transport.3.
4. Les nœuds de bordure annoncent les routes de la table de routage bgp.transport.3 vers ses homologues dans d’autres domaines si le transport family inet est négocié dans la session BGP.
5. Le nœud de bordure de réception installe ces routes bgp-ct dans la table de routage bgp.transport.3 et copie ces routes en fonction de la cible de route de transport vers les RIB de transport appropriés.
6. Le nœud de service fait correspondre la communauté de couleurs dans l’itinéraire de service à une communauté de mappage dans les schémas de résolution et résout PNH dans le RIB de transport correspondant (soit junos-rti-tc-<100>.inet.3 ou junos-rti-tc-<200>. inet.3).
7. Les nœuds de bordure utilisent des schémas de résolution prédéfinis pour la résolution PNH de la route de transport.
8. Prédéfinis ou définis par l’utilisateur, les deux schémas de résolution prennent en charge la résolution PNH de la route de service. Le mode prédéfini utilise inet.3 comme solution de secours, et le schéma de résolution défini par l’utilisateur permet d’utiliser la liste des RIB de transport dans l’ordre spécifié lors de la résolution de PNH.
9. Si le PNH de la route de service ne peut pas être résolu à l’aide des RIB répertoriés dans le schéma de résolution défini par l’utilisateur, la route est ignorée.

Présentation du transport avec classe BGP-CT (BGP-CT) avec tunnels SR-TE colorés sous-jacents

Avantages de BGP-CT avec les tunnels SR-TE colorés sous-jacents

• Résout les problèmes d’échelle qui peuvent survenir à l’avenir avec la croissance du réseau.
• Assure l’interconnectivité des domaines qui utilisent différentes technologies.
• Découple les services et les couches de transport, ce qui donne un réseau entièrement distribué.
• Fournit une gestion indépendante de la bande passante par le biais d’un contrôleur d’ingénierie du trafic intra-domaine pour SR-TE.

Les grands réseaux en croissance et en constante évolution nécessitent une architecture de routage de segments transparente. À partir de la version 21.2,R1 de Junos OS, nous prenons en charge BGP-CT avec un transport sous-jacent sous forme de tunnels SR-TE colorés. BGP-CT peut résoudre les routes de service à l’aide des RIB de transport et calculer le saut suivant. Les services actuellement pris en charge via BGP-CT peuvent également utiliser les tunnels colorés SR-TE sous-jacents pour la résolution du routage. Les services peuvent désormais utiliser les tunnels colorés SR-TE sous-jacents, tels que les tunnels colorés statiques, BGP SR-TE, RPD programmable et PCEP. BGP-CT utilise l’accessibilité du saut suivant pour résoudre les itinéraires de service sur la classe de transport souhaitée.

Pour activer la résolution de route de service BGP-CT sur des tunnels colorés SR-TE sous-jacents, incluez l’instruction au niveau de la use-transport-class[edit protocols source-packet-routing] hiérarchie.

PathErr Messages

Les messages PathErr signalent une grande variété de problèmes au moyen de différents numéros de code et de sous-code. Vous pouvez trouver une liste complète de ces messages PathErr dans la RFC 2205, Resource Reservation Protocol (RSVP), Version 1, Functional Specification et la RFC 3209, RSVP-TE : Extensions de RSVP pour les tunnels LSP.

Lorsque vous configurez l’instruction rsvp-error-hold-time , deux catégories de messages PathErr, qui représentent spécifiquement les échecs de liaison, sont examinées :

• La bande passante de liaison est faible pour ce LSP : Bande passante demandée indisponible – code 1, sous-code 2

  Ce type de message PathErr représente un problème global qui affecte tous les LSP transitant par la liaison. Ils indiquent que la bande passante réelle de la liaison est inférieure à celle requise par le LSP et qu’il est probable que les informations sur la bande passante dans la base de données des aspects techniques du trafic soient surestimées.

  Lorsque ce type d’erreur est reçu, la bande passante de liaison disponible est réduite dans la base de données d’ingénierie du trafic local, ce qui affecte tous les futurs calculs LSP.

• Lien non disponible pour ce LSP :

  • Échec du contrôle d’admission : code 1, tout sous-code sauf 2

  • Échecs du contrôle des stratégies : code 2

  • Service préempté : code 12

  • Problème d’acheminement : pas d’itinéraire disponible vers la destination – code 24, sous-code 5

  Ces types de messages PathErr sont généralement pertinents pour le LSP spécifié. L’échec de ce LSP n’implique pas nécessairement que d’autres LSP pourraient également échouer. Ces erreurs peuvent indiquer des problèmes liés à l’unité de transfert maximale (MTU), une préemption de service (initiée manuellement par l’opérateur ou par un autre LSP avec une priorité plus élevée), qu’une liaison next-hop est inactive, qu’un voisin de next-hop est en panne ou un rejet de service pour des raisons de stratégie. Il est préférable d’éloigner ce LSP du lien.

Identification du lien problématique

Chaque message PathErr inclut l’adresse IP de l’expéditeur. Ces informations sont propagées sans modification vers le routeur entrant. Une recherche dans la base de données d’ingénierie du trafic permet d’identifier le nœud à l’origine du message PathErr.

Chaque message PathErr contient suffisamment d’informations pour identifier la session RSVP qui a déclenché le message. S’il s’agit d’un routeur de transit, il transfère simplement le message. Si ce routeur est le routeur entrant (pour cette session RSVP), il contient la liste complète de tous les nœuds et liens que la session doit traverser. Couplé aux informations du nœud d’origine, le lien peut être identifié de manière unique.

Configuration du routeur pour améliorer la précision de la base de données d’ingénierie du trafic

Pour améliorer la précision de la base de données d’ingénierie du trafic, configurez l’instruction rsvp-error-hold-time . Lorsque cette instruction est configurée, un nœud source (entrée d’un LSP RSVP) apprend des défaillances de son LSP en surveillant les messages PathErr transmis à partir des nœuds en aval. Les informations des messages PathErr sont incorporées dans les calculs LSP ultérieurs, ce qui peut améliorer la précision et la vitesse de configuration du LSP. Certains messages PathErr sont également utilisés pour mettre à jour les informations de bande passante de la base de données d’ingénierie du trafic, réduisant ainsi les incohérences entre la base de données d’ingénierie du trafic et le réseau.

Pour configurer la durée pendant laquelle MPLS doit mémoriser les messages RSVP PathErr et les prendre en compte dans le calcul CSPF, incluez l’instruction rsvp-error-hold-time suivante :

Vous pouvez inclure cette instruction aux niveaux hiérarchiques suivants :

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

La durée peut être comprise entre 1 et 240 secondes. La valeur par défaut est de 25 secondes. La configuration d’une valeur de 0 désactive la surveillance des messages PathErr.