Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS des ingénieries de trafic

MPLS et ingénierie du trafic

Les ingénieries de trafic vous permettent de contrôler le chemin que les paquets de données suivent, en contournant le modèle de routage standard qui utilise les tables de routage. Les ingénieries de trafic déplacent les flux des liaisons encombrées vers des liaisons alternatives qui ne seraient pas sélectionnées par le chemin de destination calculé automatiquement. Grâce aux ingénieries de trafic, vous pouvez:

  • Utilisez plus efficacement des fibres longue distances coûteuses.

  • Contrôlez la façon dont le trafic est redirigé en cas de défaillance simple ou multiple.

  • Classification du trafic critique et régulier par chemin.

Le cœur de la conception des ingénieries de trafic est basé sur la construction de chemins de commutage d’étiquettes (LSP) parmi les routeurs. Un LSP est orienté connexion, à l’image d’un circuit virtuel dans un relais de trames ou un ATM. Les LSP ne sont pas fiables: Les paquets entrant dans un LSP ne sont pas garantis de livraison, bien que le traitement préféré soit possible. Les LSP sont également similaires aux tunnels unidirectionnels dans les paquets entrant sur un chemin, qui sont encapsulés dans une enveloppe et commutés sur l’ensemble du chemin sans être atteints par des nodes intermédiaires. Les LSP offrent un contrôle fin sur la façon dont les paquets sont transmis dans un réseau. Pour offrir une fiabilité, un LSP peut utiliser un ensemble de chemins primaires et secondaires.

Les LSP peuvent être configurés pour BGP trafic uniquement (trafic dont la destination se trouve en dehors d’un système autonome [AS]). Dans ce cas, le trafic au sein du AS n’est pas affecté par la présence de LSP. Les LSP peuvent également être configurés pour le trafic de BGP et de passerelle intérieure (IGP). par conséquent, le trafic intra-AS’entre les AS est affecté par les LSP.

MPLS présentation des protocoles d’ingénierie de trafic et de signalisation

Les ingénieries de trafic facilitent l’efficacité et la fiabilité des opérations réseau, tout en optimisant les ressources réseau et les performances du trafic. Les ingénieries de trafic permet de déplacer le flux de trafic du chemin le plus court sélectionné par le protocole de passerelle intérieure (IGP) vers un chemin physique potentiellement moins congestionné à travers un réseau. Pour prendre en charge les ingénieries de trafic, en plus du routage source, le réseau doit:

  • Calculez un chemin à la source en prenant en compte toutes les contraintes, telles que la bande passante et les exigences administratives.

  • Distribuez les informations sur la topologie du réseau et les attributs de liaison sur l’ensemble du réseau une fois le chemin informatique computé.

  • Réserver des ressources réseau et modifier les attributs de liaison.

Lorsque le trafic de transit transite par un réseau IP, le trafic MPLS est souvent utilisé pour en ingénierie de passage. Même si le chemin exact du réseau de transit est peu important pour l’expéditeur ou le destinataire du trafic, les administrateurs réseau souhaitent souvent router le trafic plus efficacement entre certaines paires d’adresses source et de destination. En ajoutant un label avec des instructions de routage spécifiques à chaque paquet, MPLS commute les paquets du routeur au routeur via le réseau plutôt que le transfert de paquets en fonction des recherches du saut suivant. Les routes qui en résultent sont appelées chemins de commutation d’étiquettes (LSP). Les LSP contrôlent le passage du trafic à travers le réseau et accélèrent le forwarding du trafic.

Vous pouvez créer des LSP manuellement ou via l’utilisation de protocoles de signalisation. Les protocoles de signalisation sont utilisés dans un MPLS pour établir des LSP pour le trafic sur un réseau de transit. Junos OS deux protocoles de signalisation: LDP et RSVP (Resource Reservation Protocol).

aspects techniques du trafic MPLS utilise les composants suivants:

  • MPLS LSP pour le forwarding de paquets

  • IGP extensions pour la diffusion d’informations sur la topologie du réseau et les attributs de liaison

  • CSPF (Constrained Shortest Path First) pour le calcul de chemin et la sélection de chemins

  • Extensions RSVP pour établir l’état de la forwarding le long du chemin et réserver des ressources le long du chemin

Junos OS prend également en charge les ingénieries de trafic sur différentes OSPF régions.

Fonctionnalités d’ingénierie de trafic

La mise en correspondance des flux de trafic sur une topologie physique existante s’appelle « ingénierie du trafic». Les ingénieries de trafic offrent la possibilité de déplacer le flux de trafic du chemin le plus court sélectionné par le protocole de passerelle intérieure (IGP) et sur un chemin physique potentiellement moins congestionné à travers un réseau.

Les fonctions techniques du trafic offrent les fonctionnalités suivantes:

  • Routez les chemins principaux autour des goulots d’étranglement ou des points d’encombrement connus du réseau.

  • Contrôle précis de la façon dont le trafic est redirigé lorsque le chemin principal est confronté à une ou plusieurs défaillances.

  • Garantir une utilisation plus efficace de la bande passante agrégée et de la fibre long-courrier disponible en veillant à ce que les sous-ensembles du réseau ne soient pas surutilisés tandis que les autres sous-ensembles du réseau le long de chemins alternatifs potentiels sont sous-utilisés.

  • Optimisez votre efficacité opérationnelle.

  • Améliorer les caractéristiques de performance du réseau axées sur le trafic en limitant les pertes de paquets, en minimisant les périodes d’insurgestion et en optimisant le débit.

  • Améliorez statistiquement les caractéristiques de performance du réseau (tels que le rapport de perte, la variation des délais et le délai de transfert) requis pour prendre en charge un Internet multiservices.

Composants des ingénieries de trafic

Dans le système d® d’exploitation (OS) Junos, les ingénieries de trafic sont implémentées avec MPLS et RSVP. L’ingénierie du trafic se compose de quatre composants fonctionnels:

Configuration des ingénieries de trafic pour les LSP

Lorsque vous configurez un LSP, un routeur hôte (un masque de 32 bits) est installé dans le routeur d’entrée vers le routeur de sortie ; l’adresse de la route hôte est l’adresse de destination du LSP. L’option d’instruction au niveau de la hiérarchie est activée par défaut (vous pouvez également configurer l’option de manière explicite), ce qui permet à BGP d’utiliser les bgp LSP dans ses calculs de traffic engineering[edit protocols mpls]bgp route. Les autres traffic-engineering options d’instruction vous permettent de modifier ce comportement dans l’instance de routage principale. Cette fonctionnalité n’est pas disponible pour des instances de routage spécifiques. En outre, vous pouvez activer une seule traffic-engineering des options d’instruction ( , ou ) à la bgpbgp-igpbgp-igp-both-ribsmpls-forwarding fois.

Remarque :

L’activation ou la désactivation de l’une des options d’instruction permet de supprimer toutes les MPLS, puis de les réinsérer dans les traffic-engineering tables de routage.

Vous pouvez configurer la OSPF et les ingénieries de trafic pour promouvoir la métrique LSP dans des publicités d’état de lien (LSA) résumées comme décrits dans la section Affichage de la métrique LSP dans les LSA résumés .

Les sections suivantes décrivent comment configurer les ingénieries de trafic pour les LSP:

Utilisation de LSP pour le BGP et le IGP trafic

Vous pouvez configurer BGP et les IGP afin d’utiliser les LSP pour le transport du trafic destiné aux routeurs de sortie en incluant l’option de bgp-igptraffic-engineering l’instruction. Cette option permet de déplacer tous les routes inet.3 vers la table de bgp-igp routage inet.0.

Sur le routeur d’entrée, inclure bgp-igp l’option pour traffic-engineering l’énoncé:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

    Remarque :

    bgp-igpL’option de cette instruction ne peut pas être traffic-engineering configurée pour VPN). Les VPN nécessitent que les routes soient dans la table de routage inet.3.

Utilisation des LSP pour le forwarding dans les réseaux privés virtuels

Les VPN nécessitent que les routes restent dans la table de routage inet.3 pour fonctionner correctement. Pour les VPN, configurez l’option de l’énoncé pour que BGP et les IGP utilisent des LSP pour le trafic de destination des routeurs de bgp-igp-both-ribstraffic-engineering sortie. Cette option installe les routes d’entrée dans la table de bgp-igp-both-ribs routage inet.0 (pour les routes unicast IPv4) et dans la table de routage inet.3 (pour MPLS chemins).

Sur le routeur d’entrée, inclure traffic-engineering bgp-igp-both-ribs l’énoncé:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

Lorsque vous utilisez l’instruction, les routes de la bgp-igp-both-ribs table inet.3 sont copiées dans le tableau inet.0. Les routes copiées sont à signaux LDP ou RSVP et sont susceptibles d’avoir une préférence plus faible que les autres routes inet.0. Les routes avec une préférence moindre sont plus susceptibles d’être choisies comme routes actives. Cela peut être problématique, car les stratégies de routage agissent uniquement sur les routes actives. Pour éviter ce problème, utilisez mpls-forwarding plutôt l’option.

Utilisation de routes RSVP et LDP pour le transport, mais pas pour la sélection du routeur

Si vous configurez les ou les options de l’énoncé, les LSP prioritaires peuvent prendre le pas sur les IGP routages dans la table de bgp-igpbgp-igp-both-ribstraffic-engineering routage inet.0. IGP routes ne peuvent plus être redistribuées car elles ne sont plus actives.

Si vous configurez l’option de l’instruction, les LSP sont utilisés pour le forwarding mais n’ont pas été mpls-forwardingtraffic-engineering sélectionnés. Ces routes sont ajoutées aux tables de routage inet.0 et inet.3. Les LSP de la table de routage inet.0 ont une faible préférence lors de la sélection de la route active. Cependant, les LSP de la table de routage inet.3 ont une préférence normale et sont donc utilisés pour sélectionner le saut suivant.

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

Pour utiliser les LSP pour le forwarding mais les exclure de la sélection de route, inclure mpls-forwarding l’option pour traffic-engineering l’instruction:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

Lorsque vous configurez l’option, IGP routages raccourcis sont copiés uniquement sur la table de mpls-forwarding routage inet.0.

Contrairement à l’option, cette option vous permet d’utiliser les routes de routage signalés par LDP et RSVP pour le routage, et de maintenir les routes BGP et IGP actives à des fins de routage afin que les stratégies de routage s’en bgp-igp-both-ribsmpls-forwarding chargent.

Par exemple, imaginons qu’un routeur exécute une BGP et qu’il dispose d’un BGP 10.10.10.1/32 qu’il doit envoyer à un autre BGP interlocuteur. Si vous utilisez l’option et que votre routeur dispose également d’un chemin de commuté d’étiquettes bgp-igp-both-ribs (LSP) vers 10.10.10.1, le routeur MPLS pour 10.10.10.1 devient actif dans la table de routage inet.0. Cela empêche votre routeur de faire de la publicité sur le routeur 10.10.10.1 vers l’BGP réseau. D’autre part, si vous utilisez l’option plutôt que l’option, le mpls-forwarding routeur BGP 10.10.10.1/32 est annoncé par l’autre interlocuteur BGP et le LSP est toujours utilisé pour avancer le trafic vers la bgp-igp-both-ribs destination 10.10.10.1.

Affichage de la métrique LSP dans les LSA résumés

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 MPLS et les OSPF du trafic pour mettre en avant la métrique LSP dans les LSA résumés.

Pour les MPLS, inclure les traffic-engineering bgp-igplabel-switched-path déclarations et:

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

  • [edit protocols mpls]

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

Pour les OSPF, inclure lsp-metric-into-summary l’énoncé:

Vous pouvez inclure cet énoncé 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 les OSPF techniques du trafic, consultez la bibliothèque Junos OS Routing Protocols Library for Routing Devices.

Activation des ingénieries de trafic inter-zone

L Junos OS réseau peut signaler un LSP contigu entre plusieurs zones d’ingénierie OSPF trafic. La signalisation LSP doit être effectuée à l’aide d’une imbrique ou d’une signalisation contiguïté, comme décrit dans le RFC 4206, La hiérarchie des chemins de commutation d’étiquettes (LSP) avec la commutation d’étiquettes multi-protocoles généralisées (GMPLS)ingénierie du trafic (TE). Toutefois, la prise en charge de la signalisation contiguïté est limitée à la simple signalisation de base. La reoptimisation n’est pas prise en charge avec une signalisation contiguïté.

Les présentes décrivent certaines des fonctionnalités techniques du trafic inter-zone:

  • L’ingénierie du trafic inter-espace peut être activée lorsque les routeurs de bordure de zone de saut lâche (ABR) sont configurés sur le routeur d’entrée à l’aide de CSPF pour le calcul de l’objet de route explicite (ERO) dans une zone OSPF. L’extension de l’ERO est terminée sur les ABR.

  • L’ingénierie du trafic inter-zones peut être activée lorsque CSPF est activé, mais sans AAB spécifiées dans la configuration LSP du routeur d’entrée (les ABR peuvent être automatiquement désignés).

  • Les aspects techniques du trafic Differentiated Services (DiffServ) sont pris en charge tant que les mappages de types de classe sont uniformes sur plusieurs zones.

Pour activer l’ingénierie du trafic inter-zone, inclure l’instruction dans la configuration de chaque routeur de expand-loose-hop transit LSP:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

Activation des ingénieries AS trafic inter-réseau pour les LSP

En règle générale, les LSP respectant les conditions suivantes peuvent faire des ingénieries de trafic:

  • Les deux extrémités du LSP sont dans la même zone OSPF ou au même IS-IS niveau.

  • Les deux extrémités du LSP sont dans différentes OSPF au sein d’un même système autonome (AS). Les LSP qui se terminent par des niveaux de IS-IS différents ne sont pas pris en charge.

  • Les deux extrémités d’un LSP à chemin explicite sont dans des points d’accès OSPF différents et les routeurs de bordure du système autonome (ASBR) sont configurés de façon statique en tant que sauts lâches pris en charge sur le LSP à chemin explicite. Pour plus d’informations, consultez la référence Configuring Explicit-Path LSP.

Sans ASBR statiquement définis sur les LSP, les ingénieries de trafic ne sont pas possibles entre un domaine de routage, AS et un autre. Toutefois, lorsque les AS sont sous le contrôle d’un seul fournisseur de services, il est possible dans certains cas d’avoir des LSP conçus pour le trafic s’étendre sur les AS et de découvrir de manière dynamique les ASBR OSPF qui les relient (IS-IS n’est pas prise en charge par cette fonctionnalité).

Des LSP inter-AS sont possibles dès lors que certaines exigences réseau sont satisfaites, qu’aucune des conditions de limitation ne s’applique et que le mode passif OSPF est configuré avec EBGP. Les détails sont fournis dans les sections suivantes:

Exigences des ingénieries AS trafic inter-réseaux

La mise en place et le fonctionnement adéquats des AS réseaux LSP inter-réseau doivent être satisfaits aux exigences suivantes:

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

  • OSPF sert de protocole de routage au sein de chaque AS, et EBGP est utilisé comme protocole de routage entre les système d’aas.

  • Les informations sur l’ASBR sont disponibles dans chaque AS.

  • Les informations de routage EBGP sont 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 ils sont configurés entre les points d’entrée et de sortie ASBR sur chaque AS.

  • La liaison EBGP entre ASBR dans différents ASS est une liaison directe et doit être configurée en tant que liaison passive des ingénieries de trafic sous OSPF. L’adresse de liaison distante elle-même , et non la boucle ou toute autre adresse de liaison, est utilisée comme identifiant de nœud distant pour cette liaison passive. Pour plus d’informations sur la configuration OSPF des techniques du trafic passives, Configuration d OSPF mode TE passif consultez.

En outre, l’adresse utilisée pour le nœud distant de la liaison d’ingénierie du trafic passif OSPF 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 Junos OS Routing Protocols library for Routing Devices.

Limites des AS techniques du trafic entre les réseaux

Seule la signalisation LSP hiérarchique ou imbrique est prise en charge pour les AS réseaux LSP inter-réseaux. Seules les LSP point à point sont pris en charge (il n’y a pas de prise en charge point à multipoint).

En outre, les restrictions suivantes s’appliquent. Toutes ces conditions suffit à rendre impossible l’interconnexion des AS LSP du trafic inter-réseau, même si les exigences ci-dessus sont satisfaites.

  • L’utilisation de plusieurshop BGP n’est pas prise en charge.

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

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

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

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

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

En outre, plusieurs fonctionnalités de routine avec tous les LSP ne sont pas prise en charge par les AS trafic inter-réseau:

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

  • Le support secondaire n’est pas pris en charge.

  • La reoptimisation n’est pas prise en charge.

  • La récupération des routeurs de transit n’est pas prise en charge.

  • Le calcul diversifié des chemins n’est pas pris en charge.

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

Ces listes de limitations ou de fonctionnalités non pris en compte, avec des fonctionnalités inter-AS trafic conçus par LSP, ne sont pas exhaustives.

Configuration d OSPF mode TE passif

Normalement, les protocoles de routage intérieur comme OSPF ne sont généralement pas exécutés sur des liaisons entre les AS. Toutefois, pour que les ingénieries de trafic entre AS fonctionnent correctement, des informations sur la liaison inter-AS, en particulier l’adresse sur l’interface distante, doivent être disponibles dans le AS. En temps normal, ces informations ne sont pas incluses dans les messages d’accessibilité EBGP OSPF publicités de routage.

Pour inonder cette information d’adresse de liaison dans le AS et la mettre à disposition pour calcul des ingénieries de trafic, vous devez configurer un mode passif OSPF pour les ingénieries de trafic sur chaque interface AS réseau. Vous devez également fournir l’adresse à distance que les OSPF distribuer et d’inclure dans la base de données des ingénieries de trafic.

Pour configurer un mode OSPF passif pour les ingénieries de trafic sur une interface inter-AS, inclure l’instruction de la liaison au niveau de passive[edit protocols ospf area area-id interface interface-name] la hiérarchie:

OSPF doit être correctement configuré sur le routeur. L’exemple suivant configure le lien inter-AS pour distribuer les informations des ingénieries de trafic OSPF so-1/1/0 dans le AS. L’adresse IP distante est 192.168.207.2 .

Composant de commutation de paquets

Le composant de passation de paquets de l’architecture des ingénieries de trafic Junos est MPLS, chargée de diriger un flux de paquets IP sur un chemin prédéfinie sur un réseau. Ce chemin s’appelle un chemin de commuté d’étiquettes (LSP). Les LSP sont des outils simples: c’est-à-dire que le trafic circule dans une direction, du routeur head-end (entrée) au routeur de queue (sortie). Le trafic duplex nécessite deux LSP: un LSP pour transporter le trafic dans chaque direction. Un LSP est créé à la suite de la concamétisation d’un ou plusieurs sauts de commutation d’étiquettes, ce qui permet de faire passer un paquet d’un routeur à un autre dans MPLS domaine.

Lorsqu’un routeur d’entrée reçoit un paquet IP, il ajoute un en-MPLS au paquet et le dirige vers le routeur suivant dans le LSP. Le paquet marqué est transmis le long du LSP par chaque routeur jusqu’à ce qu’il atteigne la queue du LSP, le routeur de sortie. À ce stade, MPLS l’en-tête de l’adresse IP est supprimé et le paquet est transmis en fonction des informations de couche 3, telles que l’adresse IP de destination. La valeur de ce modèle est que le chemin physique du LSP ne se limite pas à ce que le IGP choisirait comme chemin le plus court pour atteindre l’adresse IP de destination.

Forwarding de paquets basé sur le permutation d’étiquettes

Au niveau de chaque routeur, le processus de paquets est basé sur le concept de swap d’étiquettes. Ce concept est similaire à ce qui se produit au niveau de chaque commutateur ASynchrone Transfer Mode (ATM) dans un circuit virtuel permanent (PVC). Chaque MPLS transporte un en-tête d’encapsulation de 4 to/s contenant un champ d’étiquettes fixes de 20 bits. Lorsqu’un paquet contenant un label arrive à un routeur, le routeur examine le label et le copie en tant qu’index vers sa table de MPLS de données. Chaque entrée de la table de forwarding contient une paire d’étiquettes entrantes d’interface associé à un ensemble d’informations de forwarding appliquées à tous les paquets arrivant sur l’interface spécifique avec le même label entrant.

Comment un paquet traverse un MPLS dorsale

Cette section décrit la façon dont un paquet IP est traitement alors qu’il traverse MPLS réseau central.

À l’entrée de la MPLS dorsale, l’en-tête IP est examiné par le routeur d’entrée. Sur la base de cette analyse, le paquet est classifié, attribué à un label, encapsulé dans un en-MPLS et avancé vers le saut suivant dans le LSP. MPLS offre un niveau élevé de flexibilité dans la façon dont un paquet IP peut être attribué à un LSP. Par exemple, dans le cas de l’implémentation des ingénieries de trafic Junos, tous les paquets arrivant au routeur d’entrée qui sont destinés à quitter le domaine MPLS au même routeur de sortie sont dirigés vers le même LSP.

Une fois que le paquet commence à traverser le LSP, chaque routeur utilise le label pour prendre la décision de le faire. La MPLS de l’adresse IP 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 MPLS table de transfert. L’ancien label est remplacé par un nouveau label, puis le paquet est transmis vers le saut suivant, le long du LSP. Ce processus est répétée sur chaque routeur du LSP jusqu’à ce que le paquet atteigne le routeur de sortie.

Lorsque le paquet arrive au routeur sortant, le label est retiré et le paquet MPLS domaine. Le paquet est ensuite transmis 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.

Composant de distribution de l’information

Les ingénieries de trafic nécessitent des connaissances détaillées sur la topologie du réseau ainsi que des informations dynamiques sur le chargement du réseau. Pour implémenter le composant de distribution des informations, de simples extensions vers les IGP sont définies. Les attributs de lien sont inclus dans la publicité d’état de liens de chaque routeur. IS-IS extensions incluent la définition de valeurs de longueur de nouveau type (TV), tandis que OSPF sont implémentées avec des publicités opaques d’état de lien (LSA). L’algorithme d’inondage standard utilisé par les IGP d’état de liaison garantit que les attributs de liaison sont distribués à tous les routeurs du domaine de routage. Certaines des extensions d’ingénierie de trafic à ajouter à la publicité d’état de liens IGP incluent une bande passante maximale, une bande passante maximale réservée pour les liaisons, une réservation de bande passante actuelle et une coloration des liens.

Chaque routeur conserve des attributs de liaison réseau et des informations sur la topologie dans une base de données spécialisée des ingénieries de trafic. La base de données des ingénieries de trafic est exclusivement utilisée pour calculer les chemins explicites pour la position des LSP sur la topologie physique. Une base de données distincte est conservée afin que le calcul des ingénieries de trafic qui s’ens suivit soit indépendant du IGP et de la base de données d’état de IGP liaisons du réseau. Pendant ce temps, le IGP poursuit son fonctionnement sans modification, en effectuer le calcul de chemin le plus court traditionnel en se basant sur les informations contenues dans la base de données d’état de liaison du routeur.

Composant de sélection de chemin

Une fois que les attributs de liaison réseau et les informations sur la topologie ont été submergés par le IGP et placés dans la base de données des ingénieries de trafic, chaque routeur d’entrée utilise la base de données des ingénieries de trafic pour déterminer les chemins de ses propres LSP dans le domaine du routage. Le chemin de chaque LSP peut être représenté par un chemin explicite strict 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 d’entrée spécifie tous les routeurs du LSP, le LSP est identifié par un routeur explicite strict. Si le routeur d’entrée ne spécifie que certains routeurs du LSP, ce dernier est décrit comme un routeur explicite vague. La prise en charge de routes explicites strictes et lâches permet de donner au processus de sélection des chemins une grande latitude dans la mesure du possible, mais d’être limitée lorsque cela est nécessaire.

Le routeur d’entrée 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 ingénieries de trafic. CSPF est un algorithme de chemin-first le plus court qui a été modifié pour prendre en compte des restrictions spécifiques lorsque le chemin le plus court sur le réseau est calculé. L’entrée dans l’algorithme CSPF inclut:

  • Informations sur l’état des liaisons topologie tirées des IGP et conservées dans la base de données des ingénieries de trafic

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

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

Dans la mesure où CSPF considère chaque nœud et lien de candidat pour un nouveau LSP, il accepte ou rejette un composant de chemin spécifique en fonction de la disponibilité des ressources ou de la possibilité que le choix du composant enfreigne les contraintes imposées par la stratégie de l’utilisateur. Le résultat du calcul CSPF est un routeur explicite constitué d’une séquence d’adresses de routeur qui fournit le chemin le plus court à travers le réseau et qui répond aux contraintes. Cette route explicite est ensuite transmise au composant de signalisation, qui établit l’état de forwarding dans les routeurs le long du LSP.

Composant de signalisation

Il est établi qu’un LSP ne peut pas fonctionner tant que le composant de signalisation ne l’a pas établie. Le composant de signalisation, responsable de la mise en place de l’état LSP et de la distribution des étiquettes, s’appuie sur un certain nombre d’extensions pour RSVP:

  • L’objet Route explicite permet à un message de chemin RSVP de passer par une séquence explicite de routeurs, indépendante du routage IP classique le plus court. La route explicite peut être soit stricte, soit vague.

  • L’objet Demande d’étiquettes permet au message de chemin RSVP de demander que les routeurs intermédiaires fournissent un label contraignante pour le LSP qu’il établit.

  • L’objet d’étiquettes permet à RSVP de prendre en charge la distribution des labels sans modifier ses mécanismes existants. Étant donné que le message resv RSVP suit le chemin inverse du message de chemin RSVP, l’objet de l’étiquette prend en charge la distribution des étiquettes entre les nodes en aval et les nodes en amont.

Planification et analyse hors ligne des chemins

Malgré les efforts de gestion réduits résultant du calcul en ligne des chemins, un outil de planification et d’analyse hors ligne reste nécessaire pour optimiser les ingénieries de trafic à l’échelle mondiale. Le calcul en ligne tient compte des contraintes de ressources et calcule un LSP à la fois. Le problème avec cette approche, c’est qu’elle n’est pas déterministe. L’ordre dans lequel sont calculés les LSP joue un rôle essentiel pour déterminer le chemin physique de chaque LSP sur le réseau. Les LSP qui sont calculés en début de processus disposent d’un plus grand nombre de ressources à leur disposition que les LSP calculés plus tard, car les LSP précédemment calculés consomment des ressources réseau. Si l’ordre dans lequel les LSP sont calculés est modifié, l’ensemble des chemins physiques qui en résulte peut également changer.

Un outil d’analyse et de planification hors ligne examine simultanément les contraintes de ressources de chaque liaison et les exigences de chaque LSP. Bien que l’approche hors ligne puisse prendre plusieurs heures, elle effectue des calculs globaux, compare les résultats de chaque calcul et sélectionne la meilleure solution pour l’ensemble du réseau. Le calcul hors ligne se base sur un ensemble de LSP qui optimisent l’utilisation des ressources réseau. Une fois le calcul terminé, les LSP peuvent être établis dans n’importe quel ordre car chacun d’entre eux est installé conformément aux règles de la solution optimisée à l’échelle mondiale.

Calcul et configuration LSP flexibles

Les ingénieries de trafic impliquent de ma mappage des flux de trafic sur une topologie physique. Vous pouvez déterminer les chemins en ligne à l’aide d’un routage basé sur les contraintes. Quel que soit le niveau de calcul du chemin physique, l’état de forwarding est installé sur le réseau via RSVP.

Le Junos OS prend en charge les méthodes de route et de configuration des LSP suivantes:

  • Vous pouvez calculer le chemin complet du LSP hors ligne et configurer individuellement chaque routeur dans le LSP avec l’état de forwarding statique nécessaire. Ceci est comparable à la façon dont certains fournisseurs de services Internet (FAI) configurent leurs cœurs IP sur ATM.

  • Vous pouvez calculer le chemin complet du LSP hors ligne et configurer le routeur d’entrée de façon statique avec l’intégralité du chemin. Le routeur d’entrée utilise ensuite RSVP comme protocole de signalisation dynamique pour installer un état de forwarding sur chaque routeur le long du LSP.

  • Vous pouvez compter sur le routage basé sur les contraintes pour réaliser un calcul LSP en ligne dynamique. Vous configurez les contraintes de chaque LSP ; le réseau détermine alors le chemin qui répond le mieux à ces contraintes. Le routeur d’entrée calcule l’ensemble du LSP en fonction des contraintes, puis lance la signalisation sur le réseau.

  • Vous pouvez calculer un chemin partiel pour un LSP hors ligne et configurer le routeur d’entrée de façon statique avec un sous-ensemble de routeurs dans le chemin ; vous pouvez ensuite effectuer un calcul en ligne pour déterminer le chemin complet.

    Prenons une topologie comprenant deux chemins est-ouest à travers les États-Unis: une dans le nord par Chicago et une dans le sud par Dessé. Si vous souhaitez établir un LSP entre un routeur de New York et un routeur de San Francisco, vous pouvez configurer le chemin partiel pour le LSP en l’instaurant comme un seul saut à itinéraire lâche d’un routeur dans UnesaS. Il en résulte un LSP acheminé sur le chemin sud. Le routeur d’entrée utilise CSPF pour calculer le chemin complet et RSVP pour installer l’état de forwarding sur le LSP.

  • Vous pouvez configurer le routeur d’entrée sans aucune contrainte. Dans ce cas, le routage IGP le plus court chemin est utilisé pour déterminer le chemin du LSP. Cette configuration n’a aucune valeur en termes d’ingénierie de trafic. Toutefois, il s’agit d’une solution simple qui peut s’avérer utile lorsque des services tels que des réseaux privés virtuels (VPN) sont nécessaires.

Dans tous ces cas, vous pouvez spécifier un nombre quelconque de LSP comme sauvegardes pour le LSP principal, vous permettant ainsi de combiner plusieurs approches de configuration. Par exemple, vous pouvez définir explicitement le chemin principal hors ligne, définir le chemin secondaire selon des contraintes et ne pas être contrainte pour le chemin qui va de l’avant. Si un circuit sur lequel le LSP principal est acheminé échoue, le routeur d’entrée remarque la panne provenant de notifications d’erreur reçues d’un routeur en aval ou par l’expiration des informations d’état faible RSVP. Le routeur puis, de manière dynamique, le trafic est transmis à un LSP en veille à chaud ou appelle RSVP pour créer un état de forwarding pour un nouveau LSP de secours.

BGP présentation des plans de transport classables

Avantages des plans BGP de transport haut de BGP classe

  • Le slicagedu réseau: les couches de service et de transport sont découplées les unes des autres, ce qui pose les bases d’un réseau en tranches et en virtualisation, grâce à un slicage de bout en bout entre plusieurs domaines, ce qui réduit considérablement le capex.

  • Interopérabilité inter-domaines:étend le déploiement des classes de transport sur des domaines coopérables pour assurer l’interopérabilité des différents protocoles de signalisation de transport de chaque domaine. Rapprochement des différences entre les espaces de noms de la communauté étendus qui peuvent être utilisés dans chaque domaine.
  • Résolutionde l’effet de récupération : permet de résoudre les tunnels insévables (RSVP, IS-IS algorithme flexible) avec des options de repli flexibles par rapport à des tunnels au meilleur effort ou tout autre tunnel couleur.

  • Qualité de service: personnaliseet optimise le réseau pour atteindre les exigences des SLA de bout en bout.
  • Exploitation des déploiements existants:prend en charge des protocoles de tunneling bien déployés comme RSVP ainsi que de nouveaux protocoles, tels que l’algorithme flexible IS-IS, préservant le retour sur investissement et réduisant les dépenses d’exploitation.

Terminologie sur les BGP de transport classables

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

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

  • Nœud de bordure:équipement au point de connexion de différents domaines (IGP zones ou points d’accès).

  • Nœud de transport:équipement qui envoie et reçoit BGP routes unicast (UNIcast) étiquetées.

  • BGP-VPN– VPNcréés à l’aide de mécanismes RFC4364.

  • Rt (Route Target):type de communauté étendue utilisée pour définir l’adhésion au VPN.

  • Route Distinguisher (RD):identifiant utilisé pour distinguer le VPN ou le service VPLS d’un routeur. Chaque instance de routage doit avoir un distinguisher de routage unique qui lui est associé.

  • Schéma derésolution – Utilisé pour résoudre les adresses PNH (Protocol Next-Hop Address) en résolution et en arrière-plan.

    Ils mappagent les routes vers les différentes RIB de transport du système basées sur la communauté de mappage.

  • Famille de services: BGP d’adresses utilisées pour les routes publicitaires pour le trafic de données, au lieu des tunnels.

  • Famille de transport – BGP d’adresses utilisées pour les tunnels publicitaires, qui sont à leur tour utilisées 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 des nodes de service et des nodes de bordure sous un seul contrôle administratif, qui dispose d’un tunnel entre eux. Un tunnel de bout en bout s’étendant à plusieurs domaines de tunnel adjacents peut être créé en assemblage de points de données à l’aide de labels.

  • Classe de transport:un groupe de tunnels de transport offrant les mêmes type de service.

  • Transport Class RT –Nouveau format de cible de route utilisé pour identifier une classe de transport spécifique.

    Un nouveau format de Cible de route a été utilisé pour identifier une classe de transport spécifique.
  • RIB detransport– Au niveau du nœud de service et du nœud de bordure, une classe de transport possède une RIB de transport associée qui maintient ses routes de tunnel.

  • RTI de transport :une instance de routage ; conteneur de RIB de transport, ainsi que les routeurs Route Target et Route Distinguisher associés.

  • Plan de transport–Ensemble d’I RT de transport importation de la même classe de transport RT. Ces derniers sont ensuite rassemblés pour s’étendre sur toutes les limites du domaine du tunnel à l’aide d’un mécanisme similaire à l’option b d’inter-AS pour permuter les étiquettes au niveau des points d’accès (nexthop-self), formant un plan de transport de bout en bout.

  • Mappage de lacommunauté: communauté sur un chemin de service qui se maurait pour se résoudre par une classe de transport.

Comprendre BGP de transport classables

Vous pouvez utiliser des plans de transport BGP classes de transport pour classifier un ensemble de tunnels de transport dans un réseau intra-AS en fonction des caractéristiques des ingénieries de trafic. Vous pouvez également utiliser ces tunnels de transport pour malaviser les routes de service avec les SLA souhaités et la récupération prévue.

BGP plans de transport classieux peuvent étendre ces tunnels aux réseaux inter-domaines qui couvrent plusieurs domaines (points d’accès ou IGP zones) tout en préservant la classe de transport. Pour ce faire, vous devez configurer la BGP de transport de BGP entre la bordure et les nodes de service.

Dans les implémentations inter-AS et intra-AS, de nombreux tunnels de transport (MPLS LSP, algorithme flexible IS-IS SR-TE) peuvent être créés à partir du service et des nodes de bordure. 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 des ingénieries de trafic (classe ou couleur). Le point de terminaison du tunnel de transport joue également le rôle 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 du service ou dans un domaine adjacent ou non adjacent. Vous pouvez utiliser BGP plans de transport classieux pour ressurer les services sur LSP avec certaines techniques d’ingénierie de trafic, que ce soit à l’intérieur d’un même domaine ou entre plusieurs domaines.

BGP plans de transport classieux réutilisant la technologie BGP-VPN, en conservant un couplé et une coordination lâches entre les domaines de tunneling.

  • L’information sur l’accessibilité de la couche réseau (NLRI) est RD:TunnelEndpoint utilisé pour masquer les chemins.
  • La cible de route indique la classe de transport des LSP et révèle des routes vers la RIB de transport correspondante sur l’équipement de destination.
  • Chaque protocole de tunneling de transport installe une route d’entrée dans la table de routage transport-class.inet.3, modèle la classe de transport en tunnel comme cible de routage VPN et collecte les LSP de la même classe de transport dans la table de routage transport-rib.inet.3.
  • Les routes de cette instance de routage sont annoncées dans le plan de transport BGP (transport inet) AFI-SAFI suivant des procédures similaires à la RFC-4364.

  • Lors du franchissement des frontières AS limites des liaisons, vous devez suivre les procédures Option-b pour pointer les tunnels de transport dans ces domaines adjacents.

    De même, lors de la franchissement de AS-zones, vous devez suivre les procédures Option-b pour pointer les tunnels de transport dans les différents TE-domaines.

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

  • Vous pouvez résoudre les routes de service et BGP routes de transport classes sur ces classes de transport, en resserrez la communauté de mappage sur ces routes.

La BGP de transport haut de BGP de transport de grande classe qui s’exécute à côté de BGP-LU. Dans un réseau MPLS transparent fonctionnant sous BGP-LU, le fait de répondre aux exigences strictes des SLA de la 5G constitue un défi, car les caractéristiques des ingénieries de trafic des tunnels ne sont pas connues ni conservées au-delà des limites des domaines. BGP plans de transport extrêmement évolutifs offrent des moyens opérationnels simples et évolutifs de promouvoir plusieurs chemins pour les boucles à distance ainsi que les informations sur les classes de transport dans l’architecture de MPLS transparente. Dans BGP routeurs de la famille de transports, différents chemins SLA sont représentés au moyen de la communauté étendue Transport Route-Target, qui transporte la couleur de la classe transport. Cette cible de route de transport est utilisée par les routeurs BGP qui associent la route de transport BGP classe transport adaptée. Lors de la nouvelle publicité des routes de transport BGP, MPLS remplace les routes, inter connecte 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 de BGP de transport classables

Figure 4 illustre une topologie de réseau avec des scénarios avant et après d’implémenter des plans de transport BGP haut de AS interne. Les équipements PE11 et PE12 utilisent les LSP RSVP comme tunnel de transport et sont installés dans une RIB inet.3. La mise en œuvre BGP de transorts haut de gamme permet aux tunnels de transport RSVP d’être color-aware à la manière des tunnels de routage de segments.

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

Pour classer les tunnels de transport en BGP classe de transport dans un AS interne:

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

    Exemple de configuration:

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

    Exemple de configuration:

Fonctionnalités de AS BGP de transport à l’intérieur de la AS BGP classe:

  • BGP transport classable crée des RIB de transport prédéfinis par classe de transport nommée (or et bronze) et tire automatiquement la communauté de mappage de sa valeur couleur (100 et 200).
  • Les routes de transport intra-AS sont peuplées dans les ER DE transport par le protocole de tunneling lorsqu’elles sont associées à une classe de transport.

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

  • Nœuds de service (PE d’entrée) correspondance avec la communauté de couleurs étendue (couleur:0:100 et couleur:0:200) du routeur de service contre la communauté de mappage dans une résolution prédéfinies RIB et résolution du protocole prochain saut (PNH) dans les RIB de transport correspondantes (junos-rti-tc-<100>.inet.3, ou junos-rti-tc-<200>.inet.3).
  • BGP routes se lient à un modèle de résolution en s’adribuant à la communauté de mappage assiocaitée.
  • Chaque classe de transport crée automatiquement deux schémas de résolution prédéfinies pour définir automatiquement la communauté de mappage.

    Un des processus de résolution consiste à résoudre les routes de service qui utilisent Color:0:<val> en tant que communauté de mappage.

    L’autre modèle de résolution consiste à résoudre les routes de transport qui utilisent Transport-Target:0:<val> en tant que communauté de mappage.

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

Implémentation inter-AS de BGP de transport classables

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

Pour convertir les tunnels de transport en BGP transport classable:

  1. Définir la classe de transport au niveau des nodes de service (équipements PE d’entrée) et des nodes de bordure (ABR et ASBR), par exemple, or et broze.

    Exemple de configuration:

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

    Exemple de configuration:

    Pour les LSP RSVP

    Pour IS-IS algorithme flxible

  3. Offrez à votre réseau une nouvelle famille BGP transport haut de BGP-LU (inet labeled-unicast).

    Exemple de configuration:

  4. Faites la publicité des routes de service à partir de l’équipement PE de sortie avec la communauté de couleurs étendue appropriée.

    Exemple de configuration:

Fonctionnalités de AS BGP de transport haut de AS BGP classes:

  1. BGP plans de transport classieux créent des RIB de transport prédéfinis par classe de transport nommée (or et bronze) et tirent automatiquement la communauté de mappage de sa valeur couleur.
  2. Les routes de transport intra-AS sont peuplées par des PROTOCOLEs de tunneling associés à une classe de transport.

    Par exemple, les routes de tunnel de transport associées aux classes transport or et bronze sont installées dans le RIB de transport junos-rti-tc-<100>.inet.3 et junos-rti-tc-<200>.inet.3, respectivement.

  3. BGP de transport de grande classe utilisent un routeur et une cible de routage uniques lorsqu’ils copient les routes du tunnel de transport entre chaque RIB de transport et la table de routage bgp.transport.3.
  4. Les nodes de bordure font la publicité des routes de la table de routage bgp.transport.3 vers leurs pairs dans d’autres domaines si le transport inet de la famille est négocié lors BGP session de routage.
  5. Un nœud de bordure de bordure installe ces routes bgp-ct dans la table de routage bgp.transport.3 et copie ces routes en fonction de la cible de routage de transport vers les TABLES de routage de transport appropriées.
  6. Le nœud de service correspond à la communauté des couleurs du routeur de service par rapport à une communauté de mappage dans les schémas de résolution et résout l’PNH dans la RIB de transport correspondante (junos-rti-tc-<100>.inet.3ou junos-rti-tc-<200>.inet.3).
  7. Les nœuds de bordure utilisent des modèles de résolution prédéfinies pour la résolution PNH du routeur de transport.
  8. Prédéfinies ou définies par l’utilisateur, les deux schémas de résolution soutiennent la résolution de l’HNH de route de service. L’utilisation prédéfinies d’inet.3 comme modèle de repli et de résolution définie par l’utilisateur permet d’utiliser la liste de RIB de transport dans l’ordre spécifié tout en résolvant le PNH.
  9. Si le PNH de route de service ne peut pas être résolu à l’aide de RIB répertoriés dans le schéma de résolution défini par l’utilisateur, alors le routeur est éliminé.

Amélioration de la précision de la base de données des ingénieries de trafic avec les messages de RSVP PathErr

La base de données des ingénieries de trafic est un élément essentiel des ingénieries de trafic basées sur RSVP. La base de données des ingénieries de trafic contient une liste complète de tous les nodes et liaisons réseau participant aux ingénieries de trafic, ainsi qu’un ensemble d’attributs chacun de ces liens peut être conserver. (Pour plus d’informations sur la base de données des ingénieries de trafic, consultez le calcul LSP Constrained-Path .) La bande passante est l’un des attributs de liaison les plus importants.

La disponibilité de la bande passante sur les liaisons change rapidement à mesure que les LSP RSVP sont établis et résiliés. Il est probable que la base de données des ingénieries de trafic développe des incohérences par rapport au réseau réel. Ces incohérences ne peuvent pas être résolus par l’augmentation du taux IGP mises à jour.

La disponibilité des liaisons peut partager le même problème d’incohérence. Une liaison indisponible peut rompre tous les LSP RSVP existants. Toutefois, son indisponibilité peut ne pas être facilement connue par le réseau.

Lorsque vous configurez l’instruction, un nœud source (sortie d’un LSP RSVP) apprend des défaillances de son LSP en surveillant les messages PathErr transmis à partir de nœuds en rsvp-error-hold-time aval. Les informations des messages PathErr sont intégrées aux calculs LSP ultérieurs, ce qui permet d’améliorer la précision et la vitesse de configuration LSP. Certains messages PathErr sont également utilisés pour mettre à jour les informations de bande passante des ingénieries de trafic, ce qui limite les incohérences entre la base de données des ingénieries de trafic et le réseau.

Vous pouvez contrôler la fréquence des mises à jour IGP via update-threshold l’instruction. Voir Configurer le seuil de mise à jour RSVP sur une interface.

Cette section aborde les sujets suivants:

PathErr Messages

Les messages PathErr signalent une grande variété de problèmes à l’utilisation de code et de numéros de sous-code différents. Vous trouverez la liste complète de ces messages PathErr dans les messages RFC 2205, RSVP (Resource Reservation Protocol), version 1, spécification fonctionnelle et RFC 3209, RSVP-TE: Extensions vers RSVP pour les tunnels LSP .

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

  • La bande passante des liaisons est faible pour ce LSP: Bande passante requise 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 des liaisons 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 ingénieries de trafic sont trop importantes.

    Lorsque ce type d’erreur est reçu, la bande passante de liaison disponible est réduite dans la base de données des ingénieries de trafic locales, ce qui affecte toutes les futures puissances de calcul LSP.

  • Liaison indisponible pour ce LSP:

    • Échec du contrôle des admissions: code 1, tout sous-code, sauf 2

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

    • Service préempté— code 12

    • Problème de routage :aucun routage disponible vers la destination: code 24, sous-code 5

    Ces types de messages PathErr sont généralement pertinents pour le LSP spécifié. La défaillance de ce LSP n’implique pas nécessairement que d’autres LSP pourraient également échouer. Ces erreurs peuvent indiquer un maximum de problèmes d’unité de transfert (MTU), de préemption de service (lancée manuellement par l’opérateur ou par un autre LSP avec une priorité plus élevée), qu’une liaison du saut suivant est en panne, qu’un voisin du saut suivant est en panne ou que la raison de la politique peut être rejetée. Il est préférable d’éloigner ce LSP de la liaison.

Identifier la liaison problème

Chaque message PathErr contient l’adresse IP de l’expéditeur. Ces informations sont propagées sans changement vers le routeur d’entrée. Une recherche dans la base de données des ingénieries de trafic permet d’identifier le nœud à l’origine du message PathErr.

Chaque message PathErr contient assez d’informations pour identifier la session RSVP qui a déclenché le message. S’il s’agit d’un routeur de transit, il envoie simplement le message. Si ce routeur est le routeur d’entrée (pour cette session RSVP), il possède la liste complète de tous les contacts et liens que la session doit traverser. En plus des informations issues du nœud, la liaison peut être identifiée de manière unique.

Configuration du routeur pour améliorer la précision de la base de données des ingénieries de trafic

Pour améliorer la précision de la base de données des ingénieries de trafic, configurez rsvp-error-hold-time l’énoncé. Lors de la configuration de cet énoncé, un nœud source (sortie d’un LSP RSVP) apprend des défaillances de son LSP en surveillant les messages PathErr transmis à partir de nœuds en aval. Les informations des messages PathErr sont intégrées aux calculs LSP ultérieurs, ce qui permet d’améliorer la précision et la vitesse de configuration LSP. Certains messages PathErr sont également utilisés pour mettre à jour les informations de bande passante des données d’ingénierie de trafic, ce qui limite les incohérences entre la base de données des ingénieries de trafic et le réseau.

Pour configurer la durée pendant MPLS de mémoriser les messages RSVP PathErr et les considérer dans le calcul CSPF, indiquez rsvp-error-hold-time l’instruction suivante:

Vous pouvez inclure cet énoncé aux niveaux hiérarchiques suivants:

  • [edit protocols mpls]

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

L’heure peut être une valeur de 1 à 240 secondes. Le par défaut est de 25 secondes. La configuration d’une valeur de 0 désactive la surveillance des messages PathErr.

Tableau de l'historique des versions
Version
Description
20.4R1
À partir de Junos OS version 20.4R1, vous pouvez configurer les ingénieries de trafic IS-IS pour stocker les informations IPv6 dans la base de données des ingénieries de trafic (TED) en plus des adresses IPv4.
17.4R1
À partir de Junos OS Version 17.4R1, la base de données des ingénieries de trafic installe des informations sur la topologie du protocole de passerelle intérieure (IGP) en plus des informations sur la topologie RSVP-TE dans la table de routage lsdist.0.
17.2R1
Depuis Junos OS Version 17.2R1, la famille d’adresses d’état de liens BGP est étendue pour distribuer les informations de topologie du routage des paquets source dans le réseau (SPRING) aux contrôleurs de mise en réseau définie par logiciel (SDN).
17.1R1
À partir de Junos OS version 17.1R1, la distribution de l’état de lien BGP est prise en charge QFX10000 commutateurs.