Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BFD (Bidirectional Forwarding Detection) pour MPLS

Configuration de la détection de transfert bidirectionnel pour MPLS (procédure CLI)

Vous pouvez configurer le protocole BFD (Bidirectional Forwarding Detection) sur les commutateurs autonomes EX8200 et EX8200 Virtual Chassis pour détecter les défaillances dans le chemin d’accès MPLS label-switch (LSP). Le protocole BFD est un mécanisme hello simple qui détecte les défaillances dans un réseau. Les paquets Hello sont envoyés à un intervalle spécifié et régulier. Une défaillance du voisin est détectée lorsque le périphérique de routage cesse de recevoir une réponse du voisin après un intervalle spécifié. BFD fonctionne avec une grande variété d’environnements et de topologies réseau. Les temporisateurs de détection des défaillances pour BFD ont des limites de temps plus courtes que celles des mécanismes de détection des défaillances pour les routes statiques, ce qui permet une détection plus rapide. Ces minuteries sont également adaptatives. Par exemple, un minuteur peut s’adapter à une valeur plus élevée si une contiguïté échoue, ou un voisin peut négocier une valeur supérieure à celle configurée.

Cette rubrique décrit la configuration des commutateurs PE (Provider Edge) et des commutateurs fournisseurs afin de prendre en charge les LSP basés sur LDP et les LSP basés sur RSVP.

Cette rubrique comprend :

Configuration de BFD sur la périphérie du fournisseur et les commutateurs du fournisseur pour un LSP basé sur LDP

Vous pouvez activer BFD pour les LSP basés sur LDP ou les LSP basés sur RSVP associés à une classe d’équivalence de transfert (FEC) spécifique. Vous pouvez également configurer une stratégie d’entrée d’administration et de maintenance des opérations (OAM) pour activer BFD sur une plage d’adresses FEC.

Avant de configurer BFD pour un LSP basé sur LDP, vous devez configurer les composants de base d’un réseau MPLS :

Pour configurer BFD sur les commutateurs PE et fournisseur :

  1. Définir une stratégie OAM :
  2. Spécifiez la FEC sur laquelle vous souhaitez activer OAM :
  3. Spécifiez l’intervalle minimal d’émission et de réception pour la configuration BFD :
    REMARQUE :

    Si vous configurez l’instruction, vous n’avez pas besoin de configurer l’instruction ou l’instruction minimum-intervalminimum-receive-intervalminimum-transmit-interval .

    Ou

  4. Spécifiez le multiplicateur de temps de détection. L’intervalle d’émission négocié multiplié par cette valeur donne le temps de détection du système récepteur en mode asynchrone :
  5. Spécifiez l’intervalle d’émission minimal (ou l’intervalle de réception minimum).
  6. Spécifiez un seuil de détection de l’adaptation du temps de détection :
  7. Configurez l’action de routage et de saut suivant en cas d’échec de session BFD sur le LSP basé sur LDP :
    REMARQUE :

    Lorsqu’une session BFD tombe en panne, vous pouvez configurer Junos OS pour resignaler le chemin LSP ou simplement désactiver le chemin LSP. Vous pouvez configurer un chemin LSP de secours pour gérer le trafic lorsque le chemin LSP principal n’est pas disponible. Le commutateur peut automatiquement récupérer des défaillances LSP qui peuvent être détectées par BFD. Par défaut, en cas d’échec d’une session BFD, l’événement est simplement consigné.

  8. Spécifiez la durée pendant laquelle la session BFD doit être active avant d’ajouter l’itinéraire ou le tronçon suivant. La spécification d’une durée de 0 seconde entraîne l’ajout de l’itinéraire ou du saut suivant dès que la session BFD est rétablie.
  9. Activez le suivi des FEC pour les LSP basés sur LDP et spécifiez une adresse source pour l’envoi des sondes. Spécifiez ensuite un intervalle d’attente après lequel envoyer le paquet de sonde.
  10. Spécifiez la durée de l’intervalle ping LSP en secondes :
  11. Spécifiez l’action à effectuer pour la stratégie OAM :
  12. Appliquez les configurations BFD au niveau de la hiérarchie MPLS pour que la configuration hérite des instructions du groupe de configuration :

Configuration de BFD sur les commutateurs Provider Edge et Provider pour un LSP basé sur RSVP

Lorsque BFD est configuré pour un LSP basé sur RSVP sur le commutateur d’entrée, il est activé sur le chemin principal et sur tous les chemins secondaires de secours pour ce LSP. Vous pouvez activer BFD pour tous les LSP d’un commutateur ou pour des LSP spécifiques. Si vous configurez BFD pour un LSP spécifique, toutes les valeurs configurées globalement pour BFD sont remplacées sur ce LSP. Les sessions BFD commencent uniquement au niveau du commutateur d’entrée et se terminent au commutateur de sortie.

Avant de configurer BFD pour un LSP basé sur RSVP, vous devez configurer les composants de base d’un réseau MPLS :

Pour configurer BFD sur les commutateurs PE et fournisseur :

  1. Spécifiez l’intervalle minimal d’émission et de réception pour la configuration BFD :
    REMARQUE :

    Si vous configurez l’instruction, vous n’avez pas besoin de configurer l’instruction ou l’instruction minimum-intervalminimum-receive-intervalminimum-transmit-interval .

    Ou

  2. Spécifiez le multiplicateur de temps de détection. L’intervalle d’émission négocié multiplié par cette valeur donne le temps de détection du système récepteur en mode asynchrone :
  3. Spécifiez l’intervalle d’émission minimal (ou l’intervalle de réception minimum) :
  4. Configurez les actions de routage et de saut suivant en cas d’échec de session BFD sur le LSP basé sur RSVP :
    REMARQUE :

    Lorsqu’une session BFD tombe en panne, vous pouvez configurer Junos OS pour resignaler le chemin LSP ou simplement désactiver le chemin LSP. Vous pouvez configurer un chemin LSP de secours pour gérer le trafic lorsque le chemin LSP principal n’est pas disponible. Le commutateur peut automatiquement récupérer des défaillances LSP qui peuvent être détectées par BFD. Par défaut, en cas d’échec d’une session BFD, l’événement est simplement consigné si vous ne configurez pas spécifiquement une action d’échec.

Réparation locale déclenchée par BFD pour une convergence rapide

Comprendre la protection locale déclenchée par BFD

Le temps nécessaire à la convergence d’un réseau suite à une défaillance d’une liaison ou d’un nud peut varier considérablement en fonction de plusieurs facteurs, notamment la taille du réseau, les protocoles utilisés et la conception du réseau. Cependant, bien que chaque événement de convergence particulier soit différent, le processus de convergence est essentiellement cohérent. La défaillance est détectée, la défaillance est signalée (inondée) dans le réseau, un autre chemin est trouvé pour le trafic et le plan de transfert est mis à jour pour faire passer le trafic sur un nouveau chemin.

Cette présentation explique comment la réparation locale déclenchée par la détection de transfert bidirectionnel (BFD) contribue à accélérer le temps de restauration pour une convergence rapide dans un réseau MPLS.

Objectif de la réparation locale déclenchée par BFD

Dans Junos OS, la protection générale du trafic MPLS en cas de défaillance du chemin de commutation d’étiquettes (LSP) signalé par RSVP est assurée par plusieurs mécanismes complémentaires. Ces mécanismes de protection comprennent une protection locale (reroutage rapide, protection des liens et protection des liens de nud) et une protection des chemins (chemins principaux et secondaires). La protection locale, associée à la protection des chemins d’accès, peut minimiser la perte de paquets d’un LSP et contrôler la manière dont le LSP est réacheminé après une défaillance. Traditionnellement, les deux types de protection reposent sur la détection rapide des défaillances de connectivité au niveau physique. Toutefois, pour les supports de transmission sans détection rapide du niveau physique, Junos OS prend en charge BFD et MPLS ping pour une détection rapide des défaillances.

Avec les liaisons entre routeurs, lorsqu’une route tombe en panne, le processus du protocole de routage recalcule le meilleur chemin suivant. Lorsque le reroutage rapide MPLS (FRR) est activé, les messages ifl sont envoyés à tous les concentrateurs PIC flexibles (FPC). Le FPC de périphérie permet de contourner le tunnel MPLS LSP. Enfin, toutes les routes sont réparées et envoyées via le tunnel MPLS LSP de contournement. Le temps nécessaire à la réparation de toutes les routes est proportionnel au nombre d’itinéraires.

Ce scénario de réparation devient plus difficile lorsqu’un commutateur se trouve entre deux liaisons. Reportez-vous à la section Figure 1.

Figure 1 : Topologie avec réparation locale déclenchée par BFDTopologie avec réparation locale déclenchée par BFD

Lorsqu’une liaison tombe en panne à l’extrémité distante, la défaillance n’est pas détectée à l’extrémité locale tant que le protocole IGP (Interior Gateway Protocol) ne tombe pas en panne. Attendre que le processus du protocole de routage recalcule le meilleur chemin suivant prend trop de temps.

Lorsque la réparation locale déclenchée par BFD est activée, le moteur de transfert de paquets effectue d’abord la réparation à l’aide du tunnel LSP MPLS de contournement (préconfiguré et installé), puis informe le processus de protocole de routage pour recalculer un nouvel itinéraire. Ainsi, lorsque le tunnel MPLS LSP principal tombe en panne, le FPC peut immédiatement et par intermittence rediriger le trafic vers le FPC avec le tunnel MPLS LSP de contournement.

L’utilisation de la réparation locale de cette manière permet d’obtenir un temps de restauration plus rapide de moins de 50 ms.

Configuration de la réparation locale déclenchée par BFD

La réparation locale déclenchée par BFD n’est pas configurable, mais fait partie de la configuration par défaut.

La réparation locale déclenchée par BFD fonctionne avec les fonctionnalités héritées de Junos OS MPLS-FRR, BFD pour IGP et LFA (loop-free alternates).

Désactivation de la réparation locale déclenchée par BFD

Par défaut, la réparation locale déclenchée par BFD est activée pour toutes les interfaces de routage. Si vous le souhaitez, vous pouvez désactiver la réparation locale déclenchée par BFD au niveau de la hiérarchie [edit routing-options].

Pour désactiver explicitement la réparation locale déclenchée par BFD :

  1. Incluez l’instruction no-bfd-triggered-local-repair au niveau de la hiérarchie [edit routing-options] :

  2. (Facultatif) Vérifiez vos paramètres de configuration avant de les valider à l’aide de la show routing-options commande.

Confirmez votre configuration en exécutant la show routing-options commande.

REMARQUE :

Lorsque vous désactivez cette fonctionnalité, vous devez également redémarrer le routage en incluant l’instruction pour l’IGP graceful-restart . Par exemple, pour OSPF, cela est accompli en incluant l’instruction graceful-restart au niveau de la [edit protocols ospf] hiérarchie.

Configuration de BFD pour les LSP MPLS IPv4

Vous pouvez configurer le protocole BFD (Bidirectional Forwarding Detection) sur les LSP MPLS IPv4 comme indiqué dans le projet de draft-ietf-bfd-mpls-02.txt Internet, BFD pour les LSP MPLS. BFD est utilisé comme fonctionnalité OAM (Operation, Administration, and Maintenance) périodique permettant aux LSP de détecter les défaillances du plan de données LSP. Vous pouvez configurer BFD pour les LSP qui utilisent LDP ou RSVP comme protocole de signalisation.

REMARQUE :

BFD pour MPLS IPv4 LSP est basé sur le moteur de routage et n’est pas distribué. Par conséquent, l’intervalle de temporisation BFD minimal pris en charge est de (100 ms * 3) par session LSP, et pour les sessions LSP mises à l’échelle, l’intervalle de temporisation BFD minimal pris en charge est de (300 ms * 3). Au fur et à mesure que vous augmentez le nombre de sessions LSP avec BFD, vous devez également augmenter (mettre à l’échelle) les temporisateurs d’intervalle pour prendre en charge le réseau.

Pour les instances de basculement du moteur de routage avec prise en charge du routage actif continu (NSR), l’intervalle de temporisation BFD minimal pris en charge est de (2,5 secondes * 3).

Vous pouvez également utiliser les commandes LSP pour détecter les erreurs du plan de données LSP ping . Cependant, BFD présente quelques avantages : il nécessite moins de traitement informatique que les commandes LSP et peut détecter rapidement les défauts dans un grand nombre de LSP (les commandes LSP doivent être émises pour chaque LSP pingping individuellement). En revanche, BFD ne peut pas être utilisé pour vérifier le plan de contrôle par rapport au plan de données au niveau du LSR de sortie, ce qui est possible lorsqu’une demande d’écho LSP ping est associée à une classe d’équivalence de transfert (FEC).

Les minuteries de détection de défaillance BFD sont adaptatives et peuvent être ajustées pour être plus ou moins agressives. Par exemple, les temporisateurs peuvent s’adapter à une valeur plus élevée si la contiguïté échoue, ou un voisin peut négocier une valeur plus élevée pour un temporisateur que la valeur configurée. Les temporisateurs s’adaptent à une valeur plus élevée lorsqu’un battement de session BFD se produit plus de trois fois en l’espace de 15 secondes. Un algorithme d’interruption augmente l’intervalle de réception (Rx) de deux si l’instance BFD locale est à l’origine de l’interruption de session. L’intervalle de transmission (Tx) est augmenté de deux si l’instance BFD distante est à l’origine de l’interruption de session. Vous pouvez utiliser la clear bfd adaptation commande pour ramener les temporisateurs d’intervalle BFD à leurs valeurs configurées. La clear bfd adaptation commande est sans impact, ce qui signifie qu’elle n’affecte pas le flux de trafic sur le périphérique de routage.

À partir de Junos OS versions 13.2R4, 13.3R2 et 14.1, vous pouvez définir l’intervalle de temps entre les messages ping LSP et le nombre de réponses ping LSP, respectivement, après quoi la session BFD (Bidirectional Forwarding Detection) est arrêtée. Pour ce faire, vous devez configurer l’instruction et l’instruction lsp-ping-intervallsp-ping-multiplier au niveau de la [edit protocols mpls oam] hiérarchie.

Pour obtenir des instructions de configuration pour les LSP signalés par LDP, reportez-vous à la section Configuration de BFD pour les LSP LDP. Pour obtenir des instructions de configuration pour les LSP signalés par RSVP, reportez-vous à la section suivante.

Configuration de BFD pour les LSP avec signal RSVP

BFD for RSVP prend en charge les LSP IPv4 unicast. Lorsque BFD est configuré pour un LSP RSVP sur le routeur entrant, il est activé sur le chemin principal et sur tous les chemins secondaires de secours pour ce LSP. L’adresse IP source des paquets BFD sortants d’une session MPLS BFD est basée sur l’adresse IP de l’interface sortante. Vous pouvez activer BFD pour tous les LSP d’un routeur ou pour des LSP spécifiques. Si vous configurez BFD pour un LSP spécifique, toutes les valeurs configurées globalement pour BFD sont remplacées. Les sessions BFD commencent uniquement au routeur entrant et se terminent au routeur de sortie.

Une erreur est consignée chaque fois qu’une session BFD pour un chemin échoue. L’exemple suivant montre comment BFD pour les messages de journal LSP RSVP peuvent apparaître :

Vous pouvez configurer BFD pour tous les LSP RSVP sur le routeur, un LSP spécifique ou le chemin principal d’un LSP spécifique. Pour configurer BFD pour les LSP RSVP, incluez les oam instructions et bfd-liveness-detection .

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

La bfd-liveness-detection déclaration comprend les options suivantes :

  • minimum-interval: spécifie l’intervalle minimal d’émission et de réception.

  • minimum-receive-interval: spécifie l’intervalle de réception minimal. La plage est comprise entre 1 et 255 000 millisecondes.

  • minimum-transmit-interval: spécifie l’intervalle de transmission minimal. La plage est comprise entre 1 et 255 000 millisecondes.

  • lsp-ping-multiplier: spécifie le multiplicateur de temps de détection. La plage va de 1 à 255.

    REMARQUE :

    Pour éviter de déclencher des faux négatifs, configurez un temps de détection des erreurs BFD supérieur au temps de reroutage rapide.

Vous pouvez également configurer l’option permettant d’ajuster l’intervalle lsp-ping-interval de temps entre les pings LSP. La commande ping LSP pour les LSP signalés RSVP est ping mpls rsvp. Pour plus d’informations sur la ping mpls rsvp commande, consultez l’Explorateur CLI.

Configuration d’une action d’échec pour la session BFD sur un LSP RSVP

Lorsque la session BFD d’un LSP RSVP tombe en panne, le LSP est supprimé et resignalé. Le trafic peut être basculé vers un LSP de secours, ou vous pouvez simplement supprimer le chemin LSP. Toutes les actions effectuées sont enregistrées.

Lorsqu’une session BFD pour un chemin LSP RSVP tombe en panne, vous pouvez configurer Junos OS pour resignaler le chemin LSP ou simplement désactiver le chemin LSP. Un chemin LSP de secours peut être configuré pour gérer le trafic alors que le chemin LSP principal n’est pas disponible. Le routeur peut automatiquement récupérer des défaillances LSP qui peuvent être détectées par BFD. Par défaut, en cas d’échec d’une session BFD, l’événement est simplement consigné.

Pour permettre à Junos OS de supprimer un chemin LSP RSVP en cas d’événement BFD, incluez l’instruction failure-action suivante :

Pour obtenir la liste des niveaux hiérarchiques auxquels vous pouvez inclure cette instruction, reportez-vous à la section Résumé de cette instruction.

Vous pouvez configurer les teardown options ou make-before-break :

  • teardown: interrompt le chemin LSP et le signale à nouveau.

  • make-before-break: permet au Junos OS de tenter de signaler un nouveau chemin LSP avant de supprimer l’ancien chemin LSP. Vous pouvez également configurer l’option pour désactiver automatiquement le LSP après la période spécifiée si la tentative de resignal du LSP échoue dans l’intervalle teardown-timeout teardown-timeout . Si vous spécifiez une valeur de 0 pour l’intervalle, le LSP est retiré et resignalé immédiatement (le même comportement que lorsque vous configurez l’option teardown-timeoutteardown ).

Pour configurer une action d’échec pour tous les LSP RSVP, incluez l’instruction failure-action au niveau de la [edit protocols mpls oam bfd-liveness-detection] hiérarchie. Pour configurer une action d’échec pour un LSP RSVP spécifique, incluez l’instruction failure-action au niveau de la [edit protocols mpls label-switched-path lsp-name oam bfd-liveness-detection] hiérarchie.

Pour configurer une action d’échec pour un chemin principal spécifique, incluez l’instruction failure-action au niveau de la [edit protocols mpls label-switched path lsp-name primary path-name oam bfd-liveness-detection] hiérarchie. Pour configurer une action d’échec pour un chemin LSP secondaire spécifique, incluez l’instruction failure-action au niveau de la [edit protocols mpls label-switched-path lsp-name secondary path-name oam bfd-liveness-detection] hiérarchie.

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.

Version
Description
13.2R4
À partir de Junos OS versions 13.2R4, 13.3R2 et 14.1, vous pouvez définir l’intervalle de temps entre les messages ping LSP et le nombre de réponses ping LSP, respectivement, après quoi la session BFD (Bidirectional Forwarding Detection) est arrêtée.