Distribution d’état de liens via BGP
Présentation de la distribution d’état des liens à l’aide de BGP
- Rôle d’un protocole de passerelle intérieure
- Limites d’un protocole Interior Gateway
- Nécessité d’une distribution couvrant l’état des liens
- Utiliser BGP comme solution
- Fonctionnalités prises en charge et non prises en charge
- Extensions d’état de lien BGP pour le routage de paquets sources dans les réseaux (SPRING)
- Vérification du nœud NLRI appris via BGP avec OSPF comme IGP
- Vérification du préfixe NLRI appris via BGP avec OSPF comme IGP
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
Pour répondre aux besoins de distribution de l’état des liens sur plusieurs domaines, un protocole de passerelle extérieure (EGP) est nécessaire pour collecter les informations sur l’état des liens et l'ingénierie de trafic à partir d’une zone IGP, les partager avec un composant externe et les utiliser pour calculer les chemins des LSP MPLS interdomaines.
BGP est un EGP standardisé conçu pour échanger des informations de routage et d’accessibilité entre systèmes autonomes (AS). BGP est un protocole éprouvé qui possède de meilleures propriétés d’évolutivité, car il peut distribuer des millions d’entrées (par exemple, des préfixes VPN) de manière évolutive. BGP est le seul protocole de routage utilisé aujourd’hui qui soit adapté pour transporter toutes les routes sur Internet. Cela s’explique en grande partie par le fait que BGP s’exécute sur TCP et peut utiliser le contrôle de flux TCP. En revanche, les protocoles de passerelle interne (IGP) n’ont pas de contrôle de flux. Lorsque les IGP ont trop d’informations sur les itinéraires, ils commencent à se désabonner. Lorsque BGP a un haut-parleur voisin qui envoie des informations trop rapidement, BGP peut limiter le voisin en retardant les accusés de réception TCP.
Un autre avantage du BGP est qu’il utilise des tuples de type, de longueur, de valeur (TLV) et des informations d’accessibilité de la couche réseau (NLRI) qui offrent une extensibilité apparemment infinie sans qu’il soit nécessaire de modifier le protocole sous-jacent.
La distribution des informations sur l’état des liens entre les domaines est réglementée à l’aide de stratégies visant à protéger les intérêts du fournisseur de services. Cela nécessite de contrôler la distribution topologique à l’aide de stratégies. BGP, avec le cadre de stratégie qu’il a mis en place, est très efficace dans la distribution de routes interdomaines. Dans Junos OS, BGP est entièrement basé sur les stratégies. L’opérateur doit explicitement configurer les voisins à appairer et accepter explicitement les routes dans BGP. En outre, la stratégie de routage est utilisée pour filtrer et modifier les informations de routage. Ainsi, les stratégies de routage offrent un contrôle administratif complet sur les tables de routage.
Bien qu’au sein d’un AS, les protocoles IGP-TE et BGP-TE fournissent le même ensemble d’informations, le BGP-TE présente de meilleures caractéristiques de mise à l’échelle héritées du protocole BGP standard. BGP-TE est donc un choix plus évolutif pour l’acquisition d’informations topologiques multi-zones/multi-AS.
En utilisant BGP comme solution, les informations acquises par l’IGP sont utilisées pour être distribuées dans BGP. Les FAI peuvent exposer ces informations de manière sélective avec d’autres FAI, fournisseurs de services et réseaux de diffusion de contenu (CDN) par le biais d’un appairage BGP normal. Cela permet d’agréger les informations acquises par l’IGP sur plusieurs zones et AS, de sorte qu’une entité externe de calcul de chemin puisse accéder aux informations en écoutant passivement un réflecteur de route.
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 de l'ingénierie de 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 l’instruction de set igp-topology
configuration aux niveaux et [edit protocols ospf traffic-engineering]
de la [edit protocols isis traffic-engineering]
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 de l'ingénierie de trafic.

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 de l'ingénierie de 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 de l'ingénierie de trafic exportait uniquement les informations de topologie RSVP-TE. Vous pouvez désormais surveiller à la fois les informations IGP et les informations de topologie de l'ingénierie de 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 lsdist.0
table, qui est la 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 lsdist.0
table vers la base de données d’ingénierie 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.
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 de l'ingénierie de 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 mpls
niveaux , [edit protocols mpls label-switched-path lsp-name]
et [edit protocols rsvp]
hiérarchique. Au niveau hiérarchique, les [edit protocols rsvp]
impacts d’activation cross-credibility-cspf
contournent les LSP et l’expansion 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
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
Routage source des paquets dans les réseaux (SPRING)
SPRING est une architecture de plan de contrôle qui permet à un routeur entrant de diriger un paquet à travers un ensemble spécifique de nœuds et de liens dans le réseau sans dépendre des nœuds intermédiaires du réseau pour décider du chemin réel qu’il doit emprunter. SPRING fait appel à des IGP, tels que IS-IS et OSPF, pour les segments de réseau publicitaire. Les segments de réseau peuvent représenter n’importe quelle instruction, topologique ou basée sur des services. Dans les topologies IGP, les segments IGP sont annoncés par les protocoles de routage d’état de lien. Il existe deux types de segments IGP :
Adjacency segment |
Chemin à un saut sur une contiguïté spécifique entre deux noeuds dans l’IGP |
Prefix segment |
Un chemin le plus court à plusieurs sauts, à coût égal et sensible aux chemins multiples vers un préfixe, selon l’état de la topologie IGP |
Lorsque SPRING est activé dans un réseau BGP, la famille d’adresses d’état de lien BGP apprend les informations SPRING des protocoles de routage d’état de lien IGP et publie des segments sous la forme d’identificateurs de segment (SID). La famille d’adresses d’état de lien BGP a été étendue pour transporter les SID et d’autres informations SPRING vers les homologues BGP. Le réflecteur de route peut diriger un paquet à travers un ensemble souhaité de nuds et de liens en ajoutant au paquet une combinaison appropriée de tunnels. Cette fonctionnalité permet à la famille d’adresses d’état de lien BGP d’annoncer également les informations SPRING aux homologues BGP.
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.

-
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 l'ingénierie de trafic est désactivée au niveau IGP, aucun des attributs n’est envoyé à la base de données d'ingénierie de 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 de l'ingénierie de 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 de l'ingénierie de trafic.
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
L’état de lien BGP avec SPRING prend en charge les attributs et les TLV (type, longueur et valeurs) suivants qui sont originés, reçus et propagés dans le réseau :
Node attributes
-
Capacités de routage de segments
-
Algorithme de routage de segments
Link attributes
-
SID adjacent
-
LAN Adjacent-SID
Prefix descriptors
-
Informations sur l’accessibilité IP
Prefix attributes
-
Préfixe SID
La liste suivante prend en charge les TLV qui ne sont pas originaux, mais uniquement reçus et propagés dans le réseau :
Prefix descriptors
-
ID de multitopologie
-
Type de route OSPF
Prefix attributes
-
Gamme
-
Liaison SID
Junos OS ne prend pas en charge les fonctionnalités suivantes avec BGP link-state avec extensions SPRING :
-
Origine du préfixe IPv6
-
Identificateurs multitopologiques
-
Exportation de la base de données d’ingénierie du trafic pour les paramètres SPRING
-
Nouveaux TLV avec tcpdump (les TLV existants ne sont pas non plus pris en charge).
-
SPRING sur IPv6
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 :
But
Vérifiez les entrées de la table de routage lsdist.0.
Action
À partir du mode opérationnel, exécutez la show route table lsdist.0
commande.
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden) NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced) TSI: LINK-STATE attribute handle 0x61d5da0 *BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x61b07cc Next-hop reference count: 216 Source: 10.2.2.2 Protocol next hop: 10.2.2.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State:<Active Int Ext> Local AS: 65100 Peer AS: 65100 Age: 30:22 Metric2: 2 Validation State: unverified Task: BGP_65100.10.2.2.2 Announcement bits (1): 0-TED Export AS path: I Accepted Area border router: No External router: No Attached: No Overload: No SPRING-Capabilities: - SRGB block [Start: 900000, Range: 90000, Flags: 0x00] SPRING-Algorithms: - Algo: 0 Localpref: 100 Router ID: 10.2.2.2 Indirect next hops: 1 Protocol next hop: 10.2.2.2 Metric: 2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1 Session Id: 0x143 10.2.2.2/32 Originating RIB: inet.0 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.11.1.2 via et-0/0/0.1 Session Id: 143
Sens
Les routes apparaissent dans la table de routage lsdist.0.
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 :
But
Vérifiez les entrées de la table de routage lsdist.0.
Action
À partir du mode opérationnel, exécutez la show route table lsdist.0
commande.
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden) PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced) *BGP Preference: 170/-101 Next hop type: Indirect, Next hop index: 0 Address: 0x61b07cc Next-hop reference count: 216 Source: 10.2.2.2 Protocol next hop: 10.2.2.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Active Int Ext> Local AS: 65100 Peer AS: 65100 Age: 30:51 Metric2: 2 Validation State: unverified Task: BGP_65100.10.2.2.2 AS path: I Accepted Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0 Localpref: 65100 Router ID: 10.2.2.2 Indirect next hops: 1 Protocol next hop: 10.2.2.2 Metric: 2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1 Session Id: 0x143 10.2.2.2/32 Originating RIB: inet.0 Metric: 2 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.11.1.2 via et-0/0/0.1 Session Id: 143
Sens
Les routes apparaissent dans la table de routage lsdist.0.
Exemple : Configuration de la distribution de l’état des liens à l’aide de BGP
Cet exemple montre comment configurer BGP pour transporter les informations d’état de liaison sur plusieurs domaines, ce qui est utilisé pour calculer des chemins pour les LSP MPLS couvrant plusieurs domaines, tels que le LSP TE inter-zone, et fournit un moyen évolutif et contrôlé par des stratégies pour les entités de calcul de chemin externes, telles que ALTO et PCE, d’acquérir la topologie du réseau.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Quatre routeurs pouvant être une combinaison de routeurs M Series, MX Series ou T Series
-
Junos OS version 14.2 ou ultérieure s’exécutant sur tous les routeurs
Avant de commencer :
-
Configurez les interfaces de l’appareil.
-
Configurez les numéros de système autonome et les ID de routeur pour les appareils.
-
Configurez les protocoles suivants :
-
RSVP
-
MPLS
-
BGP
-
IS-IS
-
OSPF
-
Présentation
À partir de la version 14.2 de Junos OS, un nouveau mécanisme permettant de distribuer les informations de topologie sur plusieurs zones et systèmes autonomes (AS) est introduit en étendant le protocole BGP pour transporter les informations d’état de liaison, initialement acquises via IGP. Les protocoles IGP ont des limites d’évolutivité lorsqu’il s’agit de distribuer de grandes bases de données. BGP est non seulement un véhicule plus évolutif pour transporter des informations de topologie multi-zones et multi-AS, mais fournit également les contrôles de stratégie qui peuvent être utiles pour la distribution de topologies multi-AS. Les informations relatives à la topologie d’état de liaison BGP sont utilisées pour calculer les chemins des chemins de commutation d’étiquettes MPLS (LSP) couvrant plusieurs domaines, tels que le LSP TE inter-zone, et pour fournir un moyen évolutif et contrôlé par des stratégies permettant aux entités externes de calcul de chemin, telles qu’ALTO et PCE, d’acquérir la topologie du réseau.
À partir de Junos OS version 17.1R1, la distribution de l’état des liaisons via BGP est prise en charge sur les commutateurs QFX10000.
Topologie

En Figure 3, les routeurs R0 et R1 et les routeurs R2 et R3 appartiennent à des systèmes autonomes différents. Les routeurs R0 et R1 utilisent OSPF, tandis que les routeurs R2 et R3 utilisent IS-IS.
Configuration
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit]
hiérarchie, puis passez commit
en mode de configuration.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
Procédure
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode Configuration.
Pour configurer le routeur R1 :
-
Configurez les interfaces du routeur R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
Configurez l’ID de routeur et le système autonome du routeur R1.
[edit routing-options]
user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
Activez RSVP sur toutes les interfaces du routeur R1 (à l’exception de l’interface de gestion).
[edit protocols]
user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
Activez MPLS sur toutes les interfaces du routeur R1 (à l’exception de l’interface de gestion).
[edit protocols]
user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
Configurez le groupe BGP pour que le routeur R1 soit appairé avec le routeur R0 et attribuez l’adresse locale et l’adresse voisine.
[edit protocols]
user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
Incluez les informations d’accessibilité de la couche réseau (NLRI) de signalisation BGP-TE au groupe BGP ibgp.
[edit protocols]
user@R1# set bgp group ibgp family traffic-engineering unicast -
Activez l’exportation de la stratégie nlri2bgp sur le routeur R1.
[edit protocols]
user@R1# set bgp group ibgp export nlri2bgp -
Configurez le groupe BGP du routeur R1 pour qu’il soit appairé avec le routeur R2 et attribuez l’adresse locale et le système autonome voisin au groupe BGP ebgp.
[edit protocols]
user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
Incluez le NLRI de signalisation BGP-TE dans le groupe BGP ebgp.
[edit protocols]
user@R1# set bgp group ebgp family traffic-engineering unicast -
Activez les aspects techniques passifs du trafic sur la liaison inter-AS.
[edit protocols]
user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
Activez OSPF sur l’interface reliant le routeur R1 au routeur R0 et sur l’interface de bouclage du routeur R1 et activez les fonctionnalités d’ingénierie du trafic.
[edit protocols]
user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
Activez les aspects techniques passifs du trafic sur la liaison inter-AS.
[edit protocols]
user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
Configurez les stratégies pour accepter le trafic du BGP-TE NLRI.
[edit policy-options]
user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfaces
commandes , show routing-options
, show protocols
et show policy-options
. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R1# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.8.31.103/24; } family iso; family mpls; } } ge-0/0/1 { unit 0 { family inet { address 10.8.42.102/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.255.105.141/32; family iso { address 47.0005.0102.5501.8181:00; } } }
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols rsvp { interface all; interface fxp0.0 { disable; } } mpls { interface all; interface fxp0.0 { disable; } } bgp { group ibgp { type internal; local-address 10.255.105.141; family traffic-engineering { unicast; } export nlri2bgp; neighbor 10.255.105.137; } group ebgp { type external; family traffic-engineering { unicast; } neighbor 10.8.42.104 { local-address 10.8.42.102; peer-as 65534; } } } isis { interface ge-0/0/1.0 { passive { remote-node-iso 0102.5502.4211; remote-node-id 10.8.42.104; } } } ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0; interface ge-0/0/0.0; interface ge-0/0/1.0 { passive { traffic-engineering { remote-node-id 10.8.42.104; remote-node-router-id 10.255.105.139; } } } } }
user@R1# show policy-options policy-statement accept-all { from family traffic-engineering; then accept; } policy-statement nlri2bgp { term 1 { from family traffic-engineering; then { accept; } } }
Procédure
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation dans l’interface de ligne de commande, consultez Utilisation de l’éditeur CLI en mode Configuration.
Pour configurer le routeur R2 :
-
Configurez les interfaces du routeur R2.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
Configurez l’ID de routeur et le système autonome du routeur R2.
[edit routing-options]
user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
Activez RSVP sur toutes les interfaces du routeur R2 (à l’exception de l’interface de gestion).
[edit routing-options]
user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
Activez MPLS sur toutes les interfaces du routeur R2 (à l’exception de l’interface de gestion).
[edit routing-options]
user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
Activez l’importation des paramètres de base de données d’ingénierie du trafic à l’aide de la stratégie ted2nlri.
[edit protocols]
user@R2# set mpls traffic-engineering database import policy ted2nlri -
Configurez le groupe BGP du routeur R2 pour qu’il soit appairé avec le routeur R3 et attribuez l’adresse locale et l’adresse de voisinage.
[edit protocols]
user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
Incluez les informations d’accessibilité de la couche réseau (NLRI) de signalisation BGP-TE au groupe BGP ibgp.
[edit protocols]
user@R2# set bgp group ibgp family traffic-engineering unicast -
Activez l’exportation de la stratégie nlri2bgp sur le routeur R2.
[edit protocols]
user@R2# set bgp group ibgp export nlri2bgp -
Configurez le groupe BGP pour le routeur R2 afin qu’il soit appairé au routeur R1.
[edit protocols]
user@R2# set bgp group ebgp type external -
Incluez le NLRI de signalisation BGP-TE dans le groupe BGP ebgp.
[edit protocols]
user@R2# set bgp group ebgp family traffic-engineering unicast -
Attribuez l’adresse locale et le système autonome voisin au groupe BGP ebgp.
[edit protocols]
user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
Activez l’exportation de la stratégie nlri2bgp sur le routeur R2.
[edit protocols]
user@R2# set bgp group ebgp export nlri2bgp -
Activez IS-IS sur l’interface reliant le routeur R2 au routeur R3 et à l’interface de bouclage du routeur R2.
[edit protocols]
user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
Activez uniquement la publicité IS-IS sur l’interface reliant le routeur R2 au routeur R1.
[edit protocols]
user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
Configurez la fonctionnalité d’ingénierie du trafic sur le routeur R2.
[edit protocols]
user@R2# set ospf traffic-engineering -
Activez uniquement les annonces OSPF sur l’interface reliant le routeur R2 au routeur R1.
[edit protocols]
user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
Configurez les stratégies pour accepter le trafic provenant de l’IRNL BGP-TE.
[edit policy-options]
user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
Résultats
À partir du mode de configuration, confirmez votre configuration en saisissant les show interfaces
commandes , show routing-options
, show protocols
et show policy-options
. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R2# show interfaces ge-0/0/0 { unit 0 { family inet { address 10.8.64.104/24; } family iso; family mpls; } } ge-0/0/1 { unit 0 { family inet { address 10.8.42.104/24; } family iso; family mpls; } } lo0 { unit 0 { family inet { address 10.255.105.139/32; family iso { address 47.0005.0102.5502.4211.00; } family iso; } }
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols rsvp { interface all; interface fxp0.0 { disable; } } mpls { traffic-engineering { database { import { policy ted2nlri; } } } interface all; interface fxp0.0 { disable; } } bgp { group ibgp { type internal; local-address 10.255.105.139; family traffic-engineering { unicast; } export nlri2bgp; neighbor 10.255.105.135; } group ebgp { type external; family traffic-engineering { unicast; } export nlri2bgp; peer-as 65533; neighbor 10.8.42.102; } } isis { level 1 disable; interface ge-0/0/0.0; interface ge-0/0/1.0 { passive { remote-node-iso 0102.5501.8181; remote-node-id 10.8.42.102; } } interface lo0.0; } ospf { traffic-engineering; area 0.0.0.0 { interface ge-0/0/1.0 { passive { traffic-engineering { remote-node-id 10.8.42.102; remote-node-router-id 10.255.105.141; } } } } }
user@R2# show policy-options policy-statement accept-all { from family traffic-engineering; then accept; } policy-statement nlri2bgp { term 1 { from family traffic-engineering; then { accept; } } } policy-statement ted2nlri { term 1 { from protocol [ isis ospf ]; then accept; } term 2 { then reject; } }
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’état du récapitulatif BGP
- Vérification de l’état du LSP MPLS
- Vérification des entrées de la table de routage lsdist.0
- Vérification des entrées de la base de données Traffic Engineering
Vérification de l’état du récapitulatif BGP
But
Vérifiez que BGP est opérationnel sur les routeurs R0 et R1.
Action
À partir du mode opérationnel, exécutez la show bgp summary
commande.
user@R0> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending lsdist.0 10 10 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.255.105.141 65533 20 14 0 79 5:18 Establ lsdist.0: 10/10/10/0
À partir du mode opérationnel, exécutez la show bgp summary
commande.
user@R1> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending lsdist.0 10 10 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.8.42.104 65534 24 17 0 70 6:43 Establ lsdist.0: 10/10/10/0 10.255.105.137 65533 15 23 0 79 6:19 Establ lsdist.0: 0/0/0/0
Sens
Le routeur R0 est appairé au routeur R1.
Vérification de l’état du LSP MPLS
But
Vérifiez l’état du LSP MPLS sur le routeur R0.
Action
À partir du mode opérationnel, exécutez la show mpls lsp
commande.
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Sens
Le LSP MPLS du routeur R0 au routeur R3 est établi.
Vérification des entrées de la table de routage lsdist.0
But
Vérifiez les entrées de la table de routage lsdist.0 sur les routeurs R0, R1 et R2.
Action
À partir du mode opérationnel, exécutez la show route table lsdist.0
commande.
user@R0> show route table lsdist.0 lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:02:03, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0 LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152 *[BGP/170] 00:17:32, localpref 100, from 10.255.105.141 AS path: 65534 I, validation-state: unverified > to 10.8.31.103 via ge-0/0/0.0
À partir du mode opérationnel, exécutez la show route table lsdist.0
commande.
user@R1> show route table lsdist.0 lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:02:19, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0 LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152 *[BGP/170] 00:18:00, localpref 100 AS path: 65534 I, validation-state: unverified > to 10.8.42.104 via ge-0/0/1.0
À partir du mode opérationnel, exécutez la show route table lsdist.0
commande.
user@R2> show route table lsdist.0 lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152 *[IS-IS/18] 1d 00:24:39 Fictitious NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152 *[OSPF/10] 1d 00:24:39 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:58 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:02:34 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152 *[IS-IS/18] 00:20:45 Fictitious LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152 *[OSPF/10] 00:20:57 Fictitious
Sens
Les routes apparaissent dans la table de routage lsdist.0.
Vérification des entrées de la base de données Traffic Engineering
But
Vérifiez les entrées de la base de données d’ingénierie du trafic sur le routeur R0.
Action
À partir du mode opérationnel, exécutez la show ted database
commande.
user@R0> show ted database TED database: 5 ISIS nodes 5 INET nodes ID Type Age(s) LnkIn LnkOut Protocol 0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0) To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 0102.5501.8181.00 --- 1033 1 0 0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1) To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol Exported OSPF(2) To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1) To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1) To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0) To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 ID Type Age(s) LnkIn LnkOut Protocol 10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0) To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104 Local interface index: 0, Remote interface index: 0 To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0
Sens
Les itinéraires apparaissent dans la base de données de l'ingénierie de trafic.
Configuration de la distribution de l’état des liens à l’aide de BGP
Vous pouvez activer la distribution des informations de topologie sur plusieurs zones et systèmes autonomes (AS) en étendant le protocole BGP pour transporter les informations d’état de liaison initialement acquises à l’aide de l’IGP. Les protocoles IGP ont des limites d’évolutivité lorsqu’il s’agit de distribuer de grandes bases de données. BGP est non seulement un véhicule plus évolutif pour transporter des informations de topologie multi-zones et multi-AS, mais fournit également les contrôles de stratégie qui peuvent être utiles pour la distribution de topologies multi-AS. Les informations sur la topologie d’état de liaison BGP sont utilisées pour calculer les chemins des LSP MPLS couvrant plusieurs domaines, tels que le LSP TE inter-zone, et pour fournir un moyen évolutif et contrôlé par des stratégies aux entités externes de calcul de chemin, telles qu’ALTO et PCE, d’acquérir la topologie du réseau.
Avant de commencer :
Configurez les interfaces de l’appareil.
Configurez l’ID de routeur et le numéro du système autonome de l’appareil.
Configurez les protocoles suivants :
RSVP
MPLS
IS-IS
OSPF
Pour activer la distribution d’état de lien à l’aide de BGP :
Distribution d’état de liaison avec SRv6
Extensions d’état de lien BGP pour SRv6
À partir de Junos OS version 21.3R1, nous prenons en charge SRv6 dans BGP-LS et Traffic Engineering Database (TED). Les extensions BGP-LS exportent les informations de topologie SRv6 vers les contrôleurs SDN. Les contrôleurs reçoivent les informations de topologie en faisant partie d’un domaine IGP ou via BGP-LS. BGP LS fournit un mécanisme évolutif d’exportation des informations de topologie. Il peut également être utilisé pour les réseaux inter-domaines. En outre, vous pouvez désormais filtrer NLRI en fonction du préfixe IPv6 (localisateur SRv6) et du NLRI SID SRv6.
Flux de données SRv6 à état de liaison BGP
BGP LS récupère les données TE (Traffic Engineering) de la base de données TE (TED) et les distribue aux haut-parleurs BGP homologues. Pour cela, TED convertit ses entrées de liens, de nœuds et de préfixes (IPv4 et IPv6) sous forme de routes. La figure suivante illustre le flux de données dans BGP-LS.

-
Les attributs SRv6 échangés via ISIS IGP sont désormais pris en charge dans Junos, comme décrit dans la norme IETF [3].
-
Les attributs SRv6 sont ajoutés à la base de données TED (Traffic Engineering Database).
-
Les attributs SRv6 appris via ISIS IGP sont stockés dans TED lorsque les nœuds et les liens sont convertis en routes. Ces routes sont ensuite soumises à la stratégie d’importation TED et, si la politique le permet, elles sont installées dans une table de routage appelée lsdist.0.
-
BGP peut être configuré pour « exporter » ou annoncer des routes à partir de la table lsdist.0, sous réserve de la stratégie. BGP propage ensuite ces routes comme n’importe quel autre NLRI. C’est-à-dire que les homologues pour lesquels la famille BGP-LS est configurée et négociée reçoivent des NLRI BGP-LS. BGP stocke les NLRI BGP-LS reçus sous forme de routes dans la table « lsdist.0 », qui est la même table que celle qui stocke les routes BGP-LS d’origine locale. Les informations SRv6 nouvellement ajoutées sont propagées dans BGP en tant qu’attributs des NLRI (nœud, lien et préfixe) déjà existants et d’un nouveau NLRI du localisateur SRv6.
-
Les NLRI BGP-LS reçus qui sont installés sous la forme de routes dans la table « lsdist.0 » peuvent être soumis à une politique d’exportation TED et, si la politique le permet, les attributs SRv6 de ces routes sont ajoutés à l’instance locale de la base de données TE.
Préfixes IPv6 et SID d’adjacence IPv6 Prise en charge de MPLS dans la base de données d’ingénierie du trafic et l’état de lien BGP
Nous avons apporté les améliorations IPv6 suivantes.
- Prise en charge de l’ajout d’attributs et d’informations IPv6 à la base de données d’ingénierie du trafic (TED) d’un système intermédiaire à un système intermédiaire (IS-IS).
- Prise en charge de l’importation d’attributs IPv6 de la base de données d’ingénierie du trafic vers la table de routage lsdist.0.
- Prise en charge de l’exportation des attributs IPv6 vers BGP Link-State (BGP-LS).
- Prise en charge des informations d’accessibilité de la couche réseau (NLRI) BGP-LS IPv6 et exportation des attributs de la table de routage lsdist.0 vers la base de données d’ingénierie du trafic.
Nous prenons uniquement en charge le protocole de passerelle intérieure (IGP) IS-IS.
- Avantages des préfixes IPv6 et de la contiguïté IPv6 Prise en charge de SID MPLS dans les bases de données d’ingénierie du trafic et BGP-LS
- Implémentation
- Prise en charge de l’ajout d’attributs et d’informations IPv6 à la base de données d’ingénierie du trafic à partir d’IS-IS
- Prise en charge de l’importation d’attributs IPv6 de la base de données Traffic Engineering vers la table de routage lsdist.0
- Prise en charge de l’exportation des attributs IPv6 vers BGP-LS
- Prise en charge des NLRI et attributs IPv6 BGP-LS Exportation de la table de routage lsdist.0 vers la base de données Traffic Engineering
- Commande de configuration
Avantages des préfixes IPv6 et de la contiguïté IPv6 Prise en charge de SID MPLS dans les bases de données d’ingénierie du trafic et BGP-LS
Nous avons amélioré les sorties des commandes opérationnelles existantes et ajouté les commandes show pour afficher la liste des préfixes IPv6 et IPv4, respectivement, dans la base de données d’ingénierie du trafic.
show ted database extensive
: amélioration de la sortie pour inclure les attributs IPv6 segment routing (SR)-MPLS.show ted link detail
: amélioration de la sortie pour inclure les attributs SR-MPLS IPv6 correspondant aux liens de base de données d’ingénierie du trafic.show route table lsdist.0 [extensive | detail]
: amélioration de la sortie pour inclure les attributs NLRI IPv6 et SR-MPLS IPv6.show route
: ajout de paramètres supplémentaires pour filtrer les entrées à afficher dans la table lsdist.0. Nous avons ajouté des options supplémentaires pour inclure les préfixes IPv6. Les options sontte-ipv6-prefix-ipv6-addr
ette-ipv6-prefix-node-iso
.show ted ipv6-prefix
: ajout de la commande show pour afficher la liste des préfixes IPv6 dans la base de données d’ingénierie du trafic.show ted ipv4-prefix
: ajout de la commande show pour afficher la liste des préfixes IPv4 dans la base de données d’ingénierie du trafic.
Implémentation
BGP-LS récupère les données d’ingénierie du trafic (TE) de la base de données d’ingénierie du trafic et distribue les données à ses homologues BGP. Pour ce faire, la base de données d’ingénierie du trafic convertit ses liens, ses nœuds et ses entrées de préfixe (IPv4 et IPv6) sous forme de routes. La figure suivante illustre le flux d’informations entre BGP-LS et BGP-LS.

Prise en charge de l’ajout d’attributs et d’informations IPv6 à la base de données d’ingénierie du trafic à partir d’IS-IS
Junos OS prend en charge les attributs SR-MPLS pour le plan de données IPv6, échangés via IGP IS-IS. Grâce à cette amélioration, il est possible d’ajouter des attributs et des informations IPv6 à la base de données TED (Traffic Engineering Database).
Prise en charge de l’importation d’attributs IPv6 de la base de données Traffic Engineering vers la table de routage lsdist.0
Les attributs IPv6 reçus de l’IGP IS-IS et stockés dans la base de données d’ingénierie du trafic sous forme de nuds, de liens et de préfixes sont convertis en routes. Ces routes sont ensuite soumises à la stratégie d’importation de la base de données d’ingénierie du trafic. Si la stratégie le permet, les routes sont installées dans une table de routage appelée lsdist.0.
Prise en charge de l’exportation des attributs IPv6 vers BGP-LS
BGP est configuré pour exporter ou publier des routes à partir de la table lsdist.0, sous réserve de la stratégie. Il s’agit d’un scénario de routine pour toute origine de route dans BGP. BGP propage ensuite ces routes comme n’importe quel autre NLRI vers les homologues avec BGP-LS configuré et établi comme voisinage BGP. BGP stocke les NLRI BGP-LS reçus sous la forme de routes dans la table lsdist.0, qui est la même table que celle qui stocke les routes BGP-LS d’origine locale. Grâce à cette fonctionnalité, les informations IPv6 nouvellement ajoutées sont propagées au BGP en tant qu’attributs de NLRI de liaison déjà existant et en tant que nouveau NLRI de préfixe IPv6.
Prise en charge des NLRI et attributs IPv6 BGP-LS Exportation de la table de routage lsdist.0 vers la base de données Traffic Engineering
Sous Junos OS, les NLRI BGP-LS reçus installés sous la forme de routes dans la table lsdist.0 sont soumis à la stratégie d’exportation de la base de données d’ingénierie du trafic. Si la stratégie le permet, les attributs IPv6 et les informations provenant de ces routes sont ajoutés à l’instance locale de la base de données d’ingénierie du trafic.
Commande de configuration
La commande de stratégie BGP-TE a été améliorée pour permettre le filtrage des NLRI basés sur le préfixe IPv6 NLRI. Reportez-vous à la section ipv6-prefix.
Voir également
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.