Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Théorie

Mécanisme de requête et d'accusé de réception MBB

Capacité MBB

Délai MBB

MBB pour le réacheminement

MBB pour la protection

Théorie de la protection mLDP

Configuration requise

Exemple MBB pour FRR

MBB utilisé

Suivi mLDP

Configurer le minuteur FRR pour faire évoluer les LSP MLDP

Conclusion

Introduction

Ce document décrit le comportement du MBB (Make-Before-Break) dans Cisco IOS® XR.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

- Ce document est spécifique à Cisco IOS® XR, mais il n'est pas limité à une version logicielle ou matérielle spécifique.

- Tous les périphériques utilisés dans cet article exécutent Cisco IOS XR 6.5.2. Toutes les cartes de ligne sont des cartes de ligne ASR9k de troisième ou quatrième génération.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Le protocole MBB (Make-Before-Break) a pour but de configurer une nouvelle arborescence mLDP (multipoint Label Distribution Protocol) avant de supprimer l'ancienne arborescence et de basculer le trafic de l'ancienne vers la nouvelle sans perdre le trafic de multidiffusion. Il peut être utilisé dans deux scénarios :

1. Lors d'un réacheminement, lorsqu'un nouveau chemin devient disponible avec une meilleure métrique IGP (Interior Gateway Protocol) : faites basculer le trafic de l'ancienne vers la nouvelle arborescence, puis supprimez l'ancienne.

2. Lorsque le trafic de multidiffusion est protégé sur un chemin de sauvegarde : faites passer le trafic du chemin de sauvegarde à l'arborescence mLDP native nouvellement signalée, puis supprimez l'arborescence de sauvegarde.

Si le routeur sait que l'ancien LSP (Label Switched Path) est rompu, il ne doit pas attendre pour commencer à utiliser le nouveau LSP. L'attente n'a pas de sens ici, car il n'y a plus de trafic sur le vieil arbre. Si l'ancienne arborescence fonctionne toujours, le routeur ne doit pas la supprimer tant que la nouvelle n'est pas entièrement configurée.

Théorie

MBB est piloté par un mécanisme de requête et d'accusé de réception, comme décrit dans la RFC 6388. Il s'agit du RFC de base de mLDP. Ce mécanisme de requête et d'accusé de réception signale lorsque la nouvelle arborescence est prête à transférer le trafic de multidiffusion. De cette manière, il ne doit pas y avoir de perte de paquets. Si le routeur sait que l'ancien LSP est endommagé, il ne doit pas attendre pour commencer à utiliser le nouveau LSP. L'attente n'a pas de sens ici, car il n'y a plus de trafic sur le vieil arbre. Si l'ancienne arborescence fonctionne toujours, le routeur ne doit pas la supprimer tant que la nouvelle n'est pas entièrement configurée.

Voici les cas où MBB peut vous aider :

- L'arborescence existante est en cours de réacheminement en raison d'une modification de la topologie, d'un événement de liaison active ou d'une réduction du coût IGP d'une liaison,

- Retour à une arborescence mLDP native, après réception du trafic de multidiffusion sur un chemin TE tunnel/LFA (Loop-Free Alternate) ou Ti-LFA (Topology Independent LFA) protégé activement.

Notez que ces deux événements représentent de bons événements.  Un exemple d’événement indésirable est une liaison connectée directement qui descend sur un routeur sur le chemin en amont. MBB ne peut pas vous aider dans ce cas. IP FRR (Fast ReRoute) est nécessaire dans ce cas.

Lorsque MBB se produit, il y a temporairement plus d'un voisin en amont et/ou plus d'un voisin en aval.  Dans la RFC 6388, il est spécifié qu'il peut y avoir plusieurs éléments accepteurs. Cela signifie qu'il peut y avoir plusieurs voisins en amont et des valeurs d'étiquette en amont par arborescence. Un « élément accepteur » signifie que le voisin mLDP en amont est un candidat pour accepter le trafic sur. Un élément acceptant est l'élément actif. L'élément actif est celui pour lequel l'étiquette MPLS est installée dans le plan de transfert. L'autre élément acceptant est l'élément inactif. Cet élément est celui pour lequel l'étiquette MPLS n'est pas encore installée dans le plan de transfert. Cet élément inactif est celui de la partie nouvellement signalée de l'arborescence avec le mécanisme Requête/Accusé de réception et doit être de courte durée, avant de devenir l'élément acceptant actif. Il ne peut y avoir que deux éléments accepteurs par arbre : l'un est actif, l'autre est inactif. Dès que la signalisation Requête/Accusé de réception se termine ou qu'un délai fixe est atteint, les anciens voisins sont supprimés de l'arborescence.

Au lieu du mécanisme Requête/Accusé de réception, l'autre choix d'implémentation pourrait consister à simplement retarder le basculement vers le nouveau LSP d'un délai configurable fixe.

Il est important de noter que mLDP partage l'espace d'étiquette assigné en aval que la monodiffusion utilise et par conséquent, pour le plan de transfert MPLS, il n'y a pratiquement aucune différence entre les paquets de multidiffusion et les paquets de monodiffusion. Comme le plan de transfert est partagé avec la monodiffusion, certaines fonctions de monodiffusion sont héritées pour la multidiffusion, comme IP FRR.

Les procédures MBB s'appliquent aux arborescences P2MP (point à multipoint) et MP2MP (multipoint à multipoint).

Mécanisme de requête et d'accusé de réception MBB

Le MBB est facultatif (il est également facultatif dans la RFC), il doit donc être configuré pour être activé. Lorsqu'il est configuré, un état MBB peut être associé au message de mappage d'étiquette envoyé en amont et il peut également être associé à un message de notification LDP envoyé par un routeur en amont au routeur en aval. Un routeur peut associer un état MBB dans un TLV d’état LDP MP.

L'élément de valeur État du MBB est un type de l'élément de valeur État du point de gestion du protocole LDP :

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MBB Type = 1  |      Length = 1               | Status Code   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le code d'état est 1 pour une demande MBB et 2 pour un retour MBB.

Le TLV d'état du LDP MP est codé comme suit :

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1|0| LDP MP Status Type(0x096F)|            Length             |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                           Value                               |

~                                                               ~

|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le champ Valeur contient un ou plusieurs éléments Valeur d'état du point de gestion LDP.

L’élément de valeur État du point de gestion du protocole LDP inclus dans la valeur TLV État du point de gestion du protocole LDP présente le codage suivant :

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type          | Length                        | Value ...     |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |

~                                                               ~

|                                                               |

|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le TLV d'état du point de gestion LDP peut apparaître dans un message de mappage d'étiquette ou dans un message de notification LDP.

Dans un message de notification LDP :

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|   Notification (0x0001)     |      Message Length           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       Message ID                              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                       Status TLV                              |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                   LDP MP Status TLV                           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                 Optional LDP MP FEC TLV                       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                 Optional Label TLV                            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dans un message de mappage d'étiquette :

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|   Label Mapping (0x0400)    |      Message Length           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Message ID                                |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     FEC TLV                                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Label TLV                                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Optional LDP MP Status TLV                |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                     Additional Optional Parameters            |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

La section précédente décrit le comportement du MBB dynamique. Une autre option est d'avoir un comportement statique où le basculement vers la nouvelle arborescence n'est déterminé que par un délai. Dans ce cas, le basculement se produit pendant une certaine durée de (milli)secondes après que la nouvelle arborescence soit prête.

L’image 1 représente une capture dans Wireshark du message de mappage d’étiquette mLDP. Un TLV d'état LDP MP est associé.

Image 1

01000102 décode à 1 pour MBB Type 1, 0001 pour Length 1 et 02 pour MBB Ack.

Notez que le mécanisme MBB s'applique à la FEC mLDP P2MP (Forwarding Equivalence Class) et aux FEC MP2MP en amont ou en aval.

Capacité MBB

Un routeur capable d’exécuter MBB l’annonce à ses voisins dans une annonce de capacité MBB sur la session LDP.

RP/0/RSP1/CPU0:R2#show mpls mldp neighbors

MLDP peer ID      : 10.79.196.14:0, uptime 22:32:06 Up,

Capabilities     : Typed Wildcard FEC, P2MP, MP2MP, MBB

Target Adj       : No

Upstream count   : 0

Branch count     : 0

Label map timer  : never

Policy filter in :

Path count       : 1

Path(s)          : 10.159.248.201    Bundle-Ether120 No LDP

Adj list         : 10.254.3.36      Bundle-Ether10362

Peer addr list   : 10.79.196.14

: 10.55.55.1

: 10.196.91.134

: 10.200.30.1

MBB n'est pas activé par défaut pour Cisco IOS XR.

La commande « make-before-break » active la fonction et l'annonce de capacité.

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 0

Le MBB n'a pas de délai par défaut. Le délai doit être augmenté uniquement dans une configuration à l'échelle. La raison en est qu'avec de nombreuses entrées de base de données mLDP, il peut y avoir de nombreuses entrées de transfert mLDP qui doivent être installées. Le temps nécessaire à l'installation de ces entrées de transfert dans le plan de données des cartes de ligne peut prendre un certain temps.

Délai MBB

Regardez l'image 2.

Image 2

Il y a l'ancien arbre et l'arbre nouvellement signalé. Le routeur où les deux arborescences se ramifient est le point de réparation local (PLR). Le routeur où les deux arbres fusionnent à nouveau est le point de fusion (MP). La nouvelle partie de l’arborescence mLDP est signalée en raison de la découverte par les routeurs d’un meilleur chemin. Soit la nouvelle liaison R4 - R2 est devenue disponible, soit la métrique IGP sur cette liaison a été abaissée pour produire un chemin avec une métrique globale inférieure.

Vous pouvez configurer deux valeurs de délai pour le MBB. Le premier est le délai lorsque MBB est utilisé pour que le MP commute à nouveau vers un chemin natif. Il s'agit de l'heure après la réception du MBB ack.

RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay ?

<0-600> Forwarding delay in seconds

Un retard de zéro signifie que le nouveau chemin signalé est immédiatement utilisé après la réception de l'accusé de réception MBB sur le routeur où l'ancien et le nouveau chemin sont différents, le PLR. Le second est le délai de suppression du chemin de secours après que le point de gestion a basculé sur le chemin natif.

RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay 10 ?

<0-60> Delete delay in seconds

<cr>

RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay 10 10 ?

<cr>

Le délai de commutation et le délai de suppression sont tous deux utilisés sur le point de gestion.

MBB pour le réacheminement

MBB s'occupe de la configuration d'une nouvelle arborescence mLDP avant que l'ancienne ne soit supprimée. Cela n'a de sens que si l'ancien arbre est toujours présent et transfère le trafic. Une convergence IGP, telle qu'un événement de liaison active, peut produire un meilleur chemin pour l'arborescence mLDP. Cela signifie une métrique IGP plus petite vers la racine, ou vers la feuille s'il s'agit d'une arborescence MP2MP mLDP.

Regardez un exemple.

L'image 3 montre un réseau avant l'événement de convergence de routage.

Image 3

R5 est le routeur racine d’une arborescence mLDP et R6 est le routeur leaf. Une arborescence mLDP P2MP est signalée par un message de mappage d'étiquette (y compris une étiquette MPLS), de chaque routeur vers la racine. Ce message de mappage d'étiquette LDP ne transporte pas de requête MBB.

Le trafic mLDP passe de gauche (racine) à droite (feuille) sur le chemin supérieur. À chaque liaison, l’étiquette MPLS indiquée est placée au-dessus du paquet de multidiffusion.

L'image 4 montre le réseau après l'événement de convergence de routage (sans MBB).

Image 4

La liaison R4 - R2 est maintenant active. La métrique de ce lien est de faible valeur, de sorte que le chemin inférieur a une métrique inférieure à celle du chemin supérieur. Deux choses doivent se produire : la contiguïté IGP doit être établie sur la liaison et la session LDP doit également être établie sur cette nouvelle liaison. Une fois cette session LDP terminée, le message de mappage d'étiquette est échangé sur cette liaison afin de déplacer l'arborescence mLDP du haut vers le bas.

Si MBB n'est pas configuré, alors il y a une signalisation régulière avec les messages de mappage d'étiquette LDP sur le chemin inférieur. Dès que le message de mappage d'étiquette (sans demande MBB) atteint R1, R1 arrête de transférer le trafic de multidiffusion sur le chemin supérieur et commence à transférer le trafic de multidiffusion sur le chemin inférieur.

En fin de compte, R1 n’a jamais transféré le trafic de multidiffusion sur les deux chemins, mais uniquement sur un seul : il a commuté le trafic du chemin supérieur vers le chemin inférieur. La commutation est immédiate, ce qui peut entraîner une perte de trafic multicast sur une courte période en raison du fait que la signalisation du plan de contrôle de R2 à R1 sur R4 peut être un peu plus rapide que le temps nécessaire pour que les entrées mLDP soient installées dans le plan de données sur les routeurs sur le nouveau chemin.

La notification de journalisation mLDP est explicitement activée.

RP/0/0/CPU0:Jan  1 16:06:49.778 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Add LDP 10.0.0.4:0 branch remote label 24009

RP/0/0/CPU0:Jan  1 16:06:49.838 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_DELETE : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Delete LDP 10.0.0.3:0 branch remote label 24009

Si MBB est configuré, nous avons comme suit.

Notez qu'il ne suffit pas de configurer le MBB sur R1.

Voici un exemple de configuration sur R2 :

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 60

!

Vous souhaiteriez que R2 retarde la commutation de l’ancien vers le nouveau chemin de 60 secondes lorsque la session LDP sur la liaison R4-R2 est active. Ça n'arrive pas. Vous devez avoir activé le MBB sur chaque routeur (ou au moins R1, R4 et R2) pour que la signalisation MBB fonctionne entre R2 et R1 sur R4.

Vous devez disposer de cette configuration minimale sur chaque routeur pour que la signalisation MBB soit activée.

mpls ldp

mldp

logging notifications

address-family ipv4

make-before-break delay 0

!

Regardez l'image 5.

Image 5

Toute la configuration correcte est en place. Nous examinons les événements depuis le début, donc la situation avant l'événement de convergence.

Le chemin supérieur actif est le début. Sur R1, R3 est le seul client en aval.

RP/0/0/CPU0:R1#show mpls mldp database

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:19:43

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

Features           : MBB

Upstream neighbor(s) :

10.0.0.5:0 [Active] [MBB] Uptime: 00:19:43

Local Label (D) : 24008

Downstream  client(s):

LDP 10.0.0.3:0     Uptime: 00:03:28

Next Hop         : 10.1.3.3

Interface        : GigabitEthernet0/0/0/0

Remote label (D) : 24009

RP/0/0/CPU0:R1#show mpls mldp forwarding

mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None

24009, NH: 10.1.3.3, Intf: GigabitEthernet0/0/0/0 Role: M

Sur R2, R3 est le seul élément acceptant.

RP/0/0/CPU0:R2#show mpls mldp database

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:23:58

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

Features           : MBB

Upstream neighbor(s) :

10.0.0.3:0 [Active] [MBB] Uptime: 00:03:19

Local Label (D) : 24008

Downstream  client(s):

LDP 10.0.0.6:0     Uptime: 00:23:58

Next Hop         : 10.2.6.6

Interface        : GigabitEthernet0/0/0/2

Remote label (D) : 24010

RP/0/0/CPU0:R2#show mpls mldp forwarding

mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None

24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

Après la signalisation MBB, R2 a deux éléments accepteurs, un actif et un inactif.

Jan  1 16:52:43.700 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Add LDP 10.0.0.4:0 branch remote label 240

R1 a deux clients en aval, R3 et R4 :

RP/0/0/CPU0:R1#show mpls mldp database

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:22:35

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

Features           : MBB

Upstream neighbor(s) :

10.0.0.5:0 [Active] [MBB] Uptime: 00:22:35

Local Label (D) : 24008

Downstream  client(s):

LDP 10.0.0.3:0     Uptime: 00:06:20

Next Hop         : 10.1.3.3

Interface        : GigabitEthernet0/0/0/0

Remote label (D) : 24009

LDP 10.0.0.4:0     Uptime: 00:00:36

Next Hop         : 10.1.4.4

Interface        : GigabitEthernet0/0/0/1

Remote label (D) : 24009

R1 effectue le transfert sur les deux chemins :

RP/0/0/CPU0:R1#show mpls mldp forwarding

mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None

24009, NH: 10.1.3.3, Intf: GigabitEthernet0/0/0/0 Role: M

24009, NH: 10.1.4.4, Intf: GigabitEthernet0/0/0/1 Role: M

R2 a maintenant deux voisins en amont, un actif (R3) et un inactif (R4). Cette phase est là pendant 60 secondes, le délai de transmission.

RP/0/0/CPU0:R2#show mpls mldp database

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:27:00

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

MBB nbr evaluate   : 00:00:21

Features           : MBB

Upstream neighbor(s) :

10.0.0.4:0 [Inactive] [MBB] Uptime: 00:00:38

Local Label (D) : 24009

10.0.0.3:0 [Active] [Delete] [MBB] Uptime: 00:06:22

Local Label (D) : 24008

Downstream  client(s):

LDP 10.0.0.6:0     Uptime: 00:27:00

Next Hop         : 10.2.6.6

Interface        : GigabitEthernet0/0/0/2

Remote label (D) : 24010

RP/0/0/CPU0:R2#show mpls mldp forwarding

mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None

24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

24009  LSM-ID: 0x00001 flags: ED

24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

Notez que l'étiquette locale de chaque arborescence mLDP est différente. Ainsi, R2 n’a aucun problème à différencier le trafic entrant mLDP et à identifier quel paquet entrant mLDP appartient à quelle arborescence mLDP. R2 ne transfère le trafic qu’à partir d’une arborescence à la fois. L'indicateur ED signifie « Egress Drop » et signifie que les paquets arrivant avec l'étiquette 24009 sont abandonnés. Il s'agit des paquets de l'arborescence pour lesquels l'élément acceptant est inactif. Il n'y a pas de trafic en double arrivant aux récepteurs !

Notez que l'étiquette sortante pour chaque arborescence mLDP sur R2 est la même. Par conséquent, pour R6, un routeur en aval de R2, il ne peut pas distinguer si le trafic a emprunté l’ancien chemin (supérieur) d’origine ou le nouveau chemin (inférieur) après le réacheminement.

Après 60 secondes, R2 arrête de transférer le trafic du chemin supérieur et démarre le trafic du chemin inférieur.

RP/0/0/CPU0:R1 Jan  1 16:53:44.236 : mpls_ldp[1180]: %ROUTING-MLDP-5-BRANCH_DELETE : 0x00001 [ipv4 10.0.0.105 232.1.1.1] P2MP 10.0.0.5, Delete LDP 10.0.0.3:0 branch remote label 24009

R1 n’a qu’un seul client en aval, R4.

RP/0/0/CPU0:R1#show mpls mldp database

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:25:21

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

Features           : MBB

Upstream neighbor(s) :

10.0.0.5:0 [Active] [MBB] Uptime: 00:25:21

Local Label (D) : 24008

Downstream  client(s):

LDP 10.0.0.4:0     Uptime: 00:03:22

Next Hop         : 10.1.4.4

Interface        : GigabitEthernet0/0/0/1

Remote label (D) : 24009

RP/0/0/CPU0:R1#show mpls mldp forwarding

mLDP MPLS forwarding database

24008  LSM-ID: 0x00001 flags: None

24009, NH: 10.1.4.4, Intf: GigabitEthernet0/0/0/1 Role: M

R2 n’a qu’un seul voisin en amont :

RP/0/0/CPU0:R2#show mpls mldp database

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 00:29:54

FEC Root           : 10.0.0.5

Opaque decoded     : [ipv4 10.0.0.105 232.1.1.1]

Features           : MBB

Upstream neighbor(s) :

10.0.0.4:0 [Active] [MBB] Uptime: 00:03:31

Local Label (D) : 24009

Downstream  client(s):

LDP 10.0.0.6:0     Uptime: 00:29:54

Next Hop         : 10.2.6.6

Interface        : GigabitEthernet0/0/0/2

Remote label (D) : 24010

RP/0/0/CPU0:R2#show mpls mldp forwarding

mLDP MPLS forwarding database

24009  LSM-ID: 0x00001 flags: None

24010, NH: 10.2.6.6, Intf: GigabitEthernet0/0/0/2 Role: M

La trace mLDP sur R2 indique que la signalisation MBB a été utilisée, qu’il y a eu un délai de 60 secondes avant la commutation de l’ancien chemin vers le nouveau chemin et un délai de 0 seconde suivant pour supprimer l’ancien chemin. Ensuite, R2 envoie un message de retrait d’étiquette à R3 pour l’ancien chemin et reçoit un message de libération d’étiquette de R3 en réponse.

RP/0/0/CPU0:R2#show mpls mldp trace

Jan  1 16:52:43.370 MLDP GLO 0/0/CPU0 t21 NBR  : New LDP peer 10.0.0.4:0 UP cap: f

Jan  1 16:52:43.370 MLDP GLO 0/0/CPU0 t21 NBR  : 10.0.0.4:0 LDP Adjacency addr: 10.2.4.4, Interface: GigabitEthernet0/0/0/1 Add

Jan  1 16:52:43.660 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.4:0 installed local label 24009

Jan  1 16:52:43.660 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP label mappping MBB Request msg to 10.0.0.4:0 Success

Jan  1 16:52:43.660 MLDP LSP 0/0/CPU0 t21 FWD  : 0x00001 Label 24009 add path label 24010 intf GigabitEthernet0/0/0/2 nexthop 10.2.6.6 id 0x00001 Success

Jan  1 16:52:43.660 MLDP GLO 0/0/CPU0 t21 GEN  : Root 10.0.0.5 path 10.2.4.4 php nh 10.2.4.4 peer 134a338c:10.0.0.4:0

Jan  1 16:52:43.910 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP notification from 10.0.0.4:0 root 10.0.16.0 Opaque Len: 83886090 MBB Ack

Jan  1 16:52:43.910 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 Start MBB Notification timer 100 msec (MBB ack)

Jan  1 16:52:43.910 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL selection delayed for 60 seconds (MBB)

Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 start delete pending timer at 0 sec

Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.4:0 activate

Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 update active ident from 10.0.0.3:0 to 10.0.0.4:0

Jan  1 16:53:44.156 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 deactivate

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 delete delay timer expired, delete pending TRUE

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 FWD  : 0x00001 Label 24008 delete, Success

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 binding list Local Delete

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 Released label 24008 to LSD

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP label withdraw msg to 10.0.0.3:0 Success

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 ACEL 10.0.0.3:0 remove

Jan  1 16:53:44.256 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 P2MP label release from 10.0.0.3:0 label 24008 root 10.0.0.5 Opaque Len 11

Jan  1 16:53:44.356 MLDP LSP 0/0/CPU0 t21 DB   : 0x00001 MBB notification delay timer expired

MBB pour la protection

La protection mLDP se compose de deux parties principales : la protection elle-même et MBB (Make-Before-Break).

Protection

La protection du trafic mLDP est similaire aux mécanismes de protection du trafic MPLS de monodiffusion. Dès qu’une défaillance de liaison est détectée, le routeur PLR commute le trafic de multidiffusion des arborescences qui traversent cette liaison vers le chemin de secours. Ce chemin de secours est un chemin pré-calculé qui est installé dans le plan de transfert. Ainsi, dès que la panne se produit, le trafic de multidiffusion peut être commuté immédiatement vers le chemin de secours.

La protection est réservée à la liaison inactive. Il n'y a aucune protection de noeud pour mLDP.

L'événement de liaison inactive doit être détecté très rapidement. Cela signifie que BFD (Bidirectional Forwarding Detection) doit être utilisé.

MBB

Une fois la protection activée, le trafic de multidiffusion ne reste pas indéfiniment sur le chemin de secours. Le trafic doit être commuté vers une arborescence/un chemin mLDP natif nouvellement calculé. Ce basculement doit se produire de telle sorte qu'aucun trafic de multidiffusion ne soit perdu. MBB est utilisé pour cela, de sorte que le trafic est seulement commuté quand l'arborescence nouvellement signalée est complètement configurée et transfère le trafic. Le routeur MP peut alors commuter en toute sécurité le transfert du trafic de l'ancienne arborescence de secours vers l'arborescence nouvellement signalée sans perte de trafic.

Théorie de la protection mLDP

Regardez l'image 6. Elle montre un réseau avec une liaison R1 - R2 qui est protégée par Ti-LFA.

Image 6

Le trafic mLDP est transféré sur la liaison R1 - R2. FRR calcule et installe un chemin de sauvegarde via R3.

Regardez l'image 7.

Image 7

L'image 7 montre la situation lorsque la protection est active.

Lorsque la liaison R1 - R2 tombe en panne, la session LDP qui la traverse est maintenue active par la protection de session LDP. La session LDP, qui est une session TCP, réachemine sur R3. Cela évite que les liaisons d'étiquette pour LDP et mLDP entre R1 et R2 soient supprimées. Pour que cette session LDP puisse être routée sur R3 et être multisaut, il doit s’agir d’une session LDP ciblée. Cette opération est effectuée automatiquement lorsque la protection de session LDP est configurée.

Lorsque la liaison R1 - R2 tombe en panne, le trafic mLDP peut être réacheminé rapidement sur R3. Pour que cela fonctionne, il doit y avoir une forme de protection sur R1 pour la route vers l'ID de routeur LDP de R2. Pour ce faire, activez les tunnels MPLS Traffic Engineering, LFA (Loop-Free Alternate) ou Ti-LFA (Topology Independent LFA). Le trafic de multidiffusion de R1 vers R2 avait une étiquette mLDP. Lorsque la liaison R1-2 tombe en panne, le trafic de multidiffusion reçoit une étiquette supplémentaire lorsqu'il est envoyé à R2. Il y a Penultimate Hop Popping (PHP), donc le trafic est transféré avec une étiquette vers R2. R2 reçoit ce trafic avec la même étiquette que lorsque la liaison R1 - R2 était active. R2 continue à transférer ce trafic de multidiffusion.

Cette protection est rapide. Bien que le trafic mLDP soit protégé, R2 commence à signaler un nouveau chemin natif à partir de celui-ci vers R1 via R3. Ainsi, R2 envoie un message de mappage d’étiquette mLDP à R3. R3 fait de même pour R1. Il s’agit du même processus/signal que lors de la création d’un nouveau chemin mLDP. Pendant que cette signalisation est en cours, R2 continue à transférer le trafic à partir du chemin mLDP de secours. Quand R2 commence-t-il à transférer le trafic à partir du chemin natif nouvellement créé ? Le déclencheur peut être deux choses : un délai temporisé ou un déclencheur de signalisation. Le délai temporisé est configuré. Le déclencheur de signalisation est le comportement MBB (Make-Before-Break behavior) introduit dans mLDP et spécifié dans la RFC 6388. Lorsque R2 reçoit le signal de R1, il indique que le nouveau chemin mLDP natif est prêt, de sorte que R2 peut commencer à transférer le trafic à partir de ce nouveau chemin mLDP et arrêter le transfert du trafic à partir du chemin de sauvegarde.

R1 est appelé PLR (Point-of-Local-Repair), c'est le routeur où le chemin protégé et le chemin natif nouvellement signalé se ramifient. R2 est le point de fusion (MP), le routeur où le chemin protégé et le chemin natif nouvellement signalé fusionnent à nouveau.

Regardez l'image 8.

Image 8

L'image 8 montre qu'il existe un message de mappage d'étiquette mLDP de R2 vers R3 et de R3 vers R1. Ce message de mappage d'étiquette contient la requête MBB.

Regardez l'image 9.

Image 9

R1 répond à cette signalisation par une notification LDP, portant l’accusé de réception MBB dans le sens inverse. Donc, descends de l'arbre. Ce message circule de R1 à R3 et de R3 à R2. Cela indique à R2, le routeur MP, que le nouveau chemin mLDP natif est prêt. À ce stade, R1 transfère le trafic mLDP deux fois, une fois sur le chemin de secours et une fois sur le nouveau chemin natif

MBB est utilisé ici pour que le MP (R2) repasse à un chemin natif (qui vient d’être créé). Lorsque MBB a terminé la partie signalisation, le point de gestion arrête de transférer le trafic mLDP arrivant du chemin de secours et commence à transférer le trafic du chemin natif nouvellement signalé. Le MBB est utilisé ici pour indiquer quand ce nouveau chemin signalé est prêt. Une autre possibilité consiste à configurer un délai. Dans ce cas, le point de gestion arrête de transférer le trafic mLDP arrivant du chemin de secours, et commence à transférer le trafic du chemin natif nouvellement signalé après que le MBB a signalé que ce nouveau chemin natif est prêt et après le temporisateur de délai configuré.

Lorsque R2 commence à transférer le trafic à partir du nouveau chemin natif, il arrête de transférer le trafic à partir du chemin de secours et signale le démontage du chemin de secours en envoyant un message LDP Label Withdraw pour l'arborescence (et un message LDP Label Release).

Un délai de suppression supplémentaire peut être ajouté pour supprimer l'ancienne arborescence afin de permettre à la plate-forme de programmer tout l'état de transfert vers les cartes de ligne.

Après cela, il n'y a que l'arborescence native nouvellement signalée. Examinez l'image 10 pour voir le transfert du trafic mLDP dans ce cas.

Image 10

Notez que le trafic mLDP comporte à nouveau une étiquette MPLS.

Configuration requise

Les trois éléments de configuration suivants sont requis pour que mLDP FRR (Fast ReRoute) fonctionne.

Vous avez besoin de :

- Transfert récursif pour mLDP activé

- Protection de session LDP activée

- LFA (Loop-Free Alternate) ou Ti-LFA (Topology Independent LFA) sous IGP (Ti-LFA requiert le routage de segment). L'ingénierie du trafic point à point est également possible.

Si l’un de ces trois éléments est manquant, il n’y a pas de protection FRR pour mLDP. mLDP protège uniquement contre les défaillances de liaison, pas contre les défaillances de noeud.

Exemple de configuration

mpls ldp

log

neighbor

nsr

graceful-restart

session-protection

!

igp sync delay on-session-up 25

mldp

logging notifications

address-family ipv4

make-before-break delay 600 60      <<<<<<

forwarding recursive                <<<<<<

!

!

router-id 10.79.196.14

neighbor

dual-stack transport-connection prefer ipv4

!

session protection for LDP-PEERS     <<<<<<

address-family ipv4

label

local

allocate for host-routes

!

!

!

La commande make-before-break est facultative.

Vérifiez que l'interface sortante est protégée par LFA ou Ti-LFA :

router isis IGP

set-overload-bit on-startup 600

net 49.0010.0000.0000.0001.00

segment-routing global-block 100000 150000

nsf cisco

log adjacency changes

lsp-gen-interval maximum-wait 5000 initial-wait 1 secondary-wait 50

lsp-refresh-interval 1800

max-lsp-lifetime 1880

address-family ipv4 unicast

metric-style wide

fast-reroute per-prefix priority-limit critical

fast-reroute per-prefix tiebreaker lowest-backup-metric index 20

fast-reroute per-prefix tiebreaker node-protecting index 30

fast-reroute per-prefix tiebreaker srlg-disjoint index 10

mpls traffic-eng level-2-only

mpls traffic-eng router-id Loopback145

mpls traffic-eng multicast-intact

spf-interval maximum-wait 7000 initial-wait 1 secondary-wait 50

segment-routing mpls sr-prefer

segment-routing prefix-sid-map advertise-local

spf prefix-priority critical tag 17

mpls ldp auto-config

!

address-family ipv6 unicast

metric-style wide

fast-reroute per-prefix priority-limit critical

fast-reroute per-prefix tiebreaker lowest-backup-metric index 20

fast-reroute per-prefix tiebreaker node-protecting index 30

fast-reroute per-prefix tiebreaker srlg-disjoint index 10

spf-interval maximum-wait 7000 initial-wait 1 secondary-wait 50

segment-routing mpls sr-prefer

spf prefix-priority critical tag 17

!

interface Bundle-Ether10362

circuit-type level-2-only

point-to-point

address-family ipv4 unicast

fast-reroute per-prefix            <<<<<<

fast-reroute per-prefix ti-lfa     <<<<<<

metric 420 level 2

mpls ldp sync level 2

!

address-family ipv6 unicast

fast-reroute per-prefix

fast-reroute per-prefix ti-lfa

metric 420 level 2

!

Il n'y a aucun impact sur la protection du trafic de multidiffusion si l'un des routeurs le long du nouveau chemin natif n'a pas MBB configuré. La protection dépend uniquement de la configuration de la protection de session LDP, du transfert récursif et du FRR, sur le PLR. La configuration MBB sur les routeurs de chemin nouvellement natifs n'a de conséquence que lorsque le trafic est commuté du chemin de secours à l'arborescence nouvellement signalée. Si un routeur mLDP a reçu un message de mappage d'étiquette avec une demande MBB d'un routeur aval et doit envoyer un message de mappage d'étiquette à un routeur amont, mais que le MBB n'est pas activé sur ce routeur amont, alors le routeur mLDP envoie un message de notification LDP à ce routeur aval dès qu'il a envoyé le message de mappage d'étiquette (sans la demande MBB) au routeur amont. En tant que tel, une arborescence mLDP normale est le résultat.

Exemple MBB pour FRR

Recherchez la topologie dans l’image 11.

Image 11

Lorsque la liaison échoue entre R1 et R2, la session mLDP entre eux est protégée par une session ciblée LDP entre eux sur R3. Par conséquent, la session mLDP entre R1 et R2 reste active même lorsque la liaison entre les deux routeurs est désactivée. Cela protège les liaisons d'étiquette mLDP entre elles, elles sont conservées. Lorsque la liaison R1-R2 tombe en panne, le plan de transfert bascule immédiatement : la liaison sortante R1-R2 bascule vers la liaison R1-R3 de façon très rapide, grâce aux MPLS point à point TE, LFA ou Ti-LFA en place. Ce MPLS P2P TE, LFA ou Ti-LFA doit protéger sur R1 la route vers l'ID de routeur LDP de R2 afin de commuter les entrées de transfert pour mLDP de manière correcte. Enfin, le transfert récursif est nécessaire car la session mLDP passe d’une session directement connectée à une session distante, où l’ID de routeur LDP est résolu de manière récursive.

R1 est appelé PLR (Point-of-Local-Repair), c'est le routeur où le chemin protégé et le chemin natif nouvellement signalé se ramifient. R2 est le point de fusion (MP), le routeur où le chemin protégé et le chemin natif nouvellement signalé fusionnent à nouveau.

Vérifiez les trois conditions requises :

-Protection LDP

Pour le voisin LDP directement connecté (mLDP) sur Bundle-Ethernet10362, il doit également y avoir des hello ciblés :

RP/0/RP0/CPU0:R1#show mpls ldp discovery 10.79.196.10

Local LDP Identifier: 10.79.196.14:0

Discovery Sources:

Interfaces:

Bundle-Ether10362 : xmit/recv

VRF: 'default' (0x60000000)

LDP Id: 10.79.196.10:0, Transport address: 10.79.196.10

Hold time: 15 sec (local:15 sec, peer:15 sec)

Established: Dec 28 10:23:16.144 (00:02:13 ao)

Targeted Hellos:

10.79.196.14 -> 10.79.196.10 (active), xmit/recv

LDP Id: 10.79.196.10:0

Hold time: 90 sec (local:90 sec, peer:90 sec)

Established: Dec 28 10:23:30.008 (00:01:59 ago)

-LFA ou Ti-LFA dans le cadre du protocole IGP

Vérifiez que la route vers le voisin LDP router-id possède un chemin de secours. Les bases RIB (Routing Information Base) et FIB (Forwarding Information Base ou CEF) doivent disposer du chemin de sauvegarde suivant :

RP/0/RP0/CPU0:R1#show route 10.79.196.10

Routing entry for 10.79.196.10/32

Known via "isis IGP", distance 115, metric 420, labeled SR

Tag 17, type level-2

Installed Dec 28 10:23:42.659 for 00:07:58

Routing Descriptor Blocks

10.254.1.144, from 10.79.196.10, via Bundle-Ether10301, Backup (Local-LFA)

Route metric is 2000

10.254.3.37, from 10.79.196.10, via Bundle-Ether10362, Protected

Route metric is 420

No advertising protos.

RP/0/RP0/CPU0:R1#show cef 10.79.196.10

10.79.196.10/32, version 7364, labeled SR, internal 0x1000001 0x83 (ptr 0x788e1f78) [1], 0x0 (0x788ab5a8), 0xa28 (0x79dd1138)

Updated Oct 25 11:32:44.299

Prefix Len 32, traffic index 0, precedence n/a, priority 1

via 10.254.1.144/32, Bundle-Ether10301, 11 dependencies, weight 0, class 0, backup (Local-LFA) [flags 0x300]

path-idx 0 NHID 0x0 [0x78f4e9b0 0x0]

next hop 10.254.1.144/32

local adjacency

local label 100010      labels imposed {100010}

via 10.254.3.37/32, Bundle-Ether10362, 11 dependencies, weight 0, class 0, protected [flags 0x400]

path-idx 1 bkup-idx 0 NHID 0x0 [0x7905e510 0x7905e350]

next hop 10.254.3.37/32

local label 100010      labels imposed {ImplNull}

-récursive forwarding pour mLDP

L'entrée de base de données mLDP n'a pas d'interface sortante dans la LFIB si le transfert récursif est appliqué :

Sans transfert récursif :

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426  24440       mLDP/IR: 0x00001   BE10362      10.254.3.37    7893474

Avec transfert récursif :

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426  24440       mLDP/IR: 0x00001                10.79.196.10    2516786878

Notez qu'il n'y a plus d'interface sortante pour l'entrée de transfert mLDP. Cela rend le dépannage un peu plus difficile.

Le point de gestion dispose de la configuration suivante pour mLDP. Notez les compteurs 600 sec et 60 sec. Le PLR a les mêmes minuteurs. Le PLR transfère le trafic sur le chemin de secours et le chemin natif pendant 600 secondes. Le délai de 600 secondes signifie que le point de gestion transmet le trafic du chemin de sauvegarde pendant 600 secondes, tout en abandonnant le trafic arrivant du chemin natif. 600 secondes est un temps long pour ce minuteur. Il a été utilisé dans un environnement de travaux pratiques afin de fournir suffisamment de temps pour capturer le résultat avec les commandes show. Le délai de 60 secondes signifie que le point de gestion attend la suppression du chemin MBB pendant 60 secondes après avoir commencé à transférer le trafic arrivant du chemin natif et à rejeter le trafic arrivant sur le chemin de secours. La valeur correcte de ces deux délais dépend du réseau. Elle doit être dérivée du test du réseau, des logiciels et du matériel spécifiques.

mpls ldp

log

neighbor

nsr

graceful-restart

session-protection

!

igp sync delay on-session-up 25

mldp

logging notifications

address-family ipv4

make-before-break delay 600 60

forwarding recursive

!

!

router-id 10.79.196.10

neighbor

dual-stack transport-connection prefer ipv4

!

session protection for LDP-PEERS

address-family ipv4

label

local

allocate for LDP-PEERS

!

!

!

MBB utilisé

Regardez l'image 12, elle montre le transfert alors que mLDP est en mode de protection.

Image 12

Avant que l'interface sortante ne soit désactivée, voici l'entrée LFIB pour l'ID de routeur LDP distant (R2) :

RP/0/RP0/CPU0:R1#show mpls forwarding labels 100010

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

100010 Pop         SR Pfx (idx 10)    BE10362      10.254.3.37    355616309429

100010      SR Pfx (idx 10)    BE10301      10.254.1.144   0            (!)

The (!) indicates a backup path.

Voici l'entrée de base de données de l'arborescence mLDP sur le PLR :

RP/0/RP0/CPU0:R1#show mpls mldp database details

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 3d03h

FEC Root           : 10.79.196.14 (we are the root)

FEC Length         : 12 bytes

FEC Value internal : 02010004000000015C4FC40E

Opaque length      : 4 bytes

Opaque value       : 01 0004 00000001

Opaque decoded     : [global-id 1]

Features           : MBB RFWD Trace

Upstream neighbor(s) :

None

Downstream  client(s):

LDP 10.79.196.10:0 Uptime: 02:09:09

Rec Next Hop     : 10.79.196.10

Remote label (D) : 24440

LDP MSG ID       : 254705

PIM MDT            Uptime: 3d03h

Egress intf     : Lmdtvrfone

Table ID        : IPv4: 0xe0000014 IPv6: 0xe0800014

HLI             : 0x00001

Ingress         : Yes

Peek            : Yes

PPMP            : Yes

Il s'agit de l'entrée de transfert mLDP pour l'arborescence :

RP/0/RP0/CPU0:R1#show mpls mldp forwarding label 25426

mLDP MPLS forwarding database

25426  LSM-ID: 0x00001 HLI: 0x00001 flags: In Pk

Lmdtvrfone, RPF-ID: 0, TIDv4: E0000014, TIDv6: E0800014

24440, NH: 10.79.196.10, Intf:  Role: H, Flags: 0x4      Local Label     : 25426 (internal)

Il s'agit de l'entrée de transfert LFIB (Label Forwarding Instance Base) pour l'arborescence :

RP/0/RP0/CPU0:R1#show mpls for labels 25426

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426  24440       mLDP/IR: 0x00001                10.79.196.10    0

L'entrée de transfert mLDP est protégée. L’entrée de transfert est protégée par l’étiquette 100010, l’entrée correspondant à l’ID du routeur LDP distant.

RP/0/RP0/CPU0:R1#show mpls for labels 25426 detail

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426              mLDP/IR: 0x00001 (0x00001)

Updated Dec 28 10:23:42.669

mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001

IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014

Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set

Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set

Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set

Ingress Drop:not-set, Egress Drop:not-set

RPF-ID:0, Encap-ID:0

Disp-Tun:[ifh:0x0, label:-]

Platform Data [64]:

{ 0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 2 9 0 0 2 10

0 0 0 1 0 0 0 1

}

mpls paths: 1, local mpls paths: 0, protected mpls paths:

24440       mLDP/IR: 0x00001 (0x00001)   \

10.79.196.10    0

Updated: Dec 28 10:23:42.670

My Nodeid:0x20

Interface Nodeids:

[ 0x8620 - - - - - - - - -  ]

Interface Handles:

[ 0xc0001c0 - - - - - - - - -  ]

Backup Interface Nodeids:

[ 0x8520 - - - - - - - - - ]

Backup Interface Handles:

[ 0xa000400 - - - - - - - - - ]

via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]

Packets Switched: 0

Il s'agit de l'entrée de transfert dans le matériel. Les routeurs sont des routeurs ASR9k.

RP/0/RP0/CPU0:R1#show mpls for labels 25426 detail hardware ingress location 0/2/CPU0

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426              mLDP/IR: 0x00001 (0x00001)

Updated Dec 28 10:23:42.674

mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001

IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014

Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set

Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set

Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set

Ingress Drop:not-set, Egress Drop:not-set

RPF-ID:0, Encap-ID:0

Disp-Tun:[ifh:0x0, label:-]

Platform Data [64]:

{ 0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 2 9 0 0 2 10

0 0 0 1 0 0 0 1

}

mpls paths: 1, local mpls paths: 0, protected mpls paths: 1

24440       mLDP/IR: 0x00001 (0x00001)   \

10.79.196.10    N/A

Updated: Dec 28 10:23:42.674

My Nodeid:0x8420

Interface Nodeids:

[ 0x8620 - - - - - - - - -  ]

Interface Handles:

[ 0xc0001c0 - - - - - - - - -  ]

Backup Interface Nodeids:

[ 0x8520 - - - - - - - - - ]

Backup Interface Handles:

[ 0xa000400 - - - - - - - - - ]

via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]

Packets Switched: 0

LEAF - HAL pd context :

sub-type : MPLS_P2MP, ecd_marked:0, has_collapsed_ldi:0

collapse_bwalk_required:0, ecdv2_marked:0,

Leaf H/W Result

Leaf H/W Result on NP:0

09000014000000921806352100020900006000020a0000600000a00001010400

vpn_special                        =           0 (0x0)

vc_label_vpws                      =           0 (0x0)

vc_label_vpls                      =           0 (0x0)

pwhe                               =           0 (0x0)

p2mp                               =           1 (0x1)

tp                                 =           0 (0x0)

recursive                          =           0 (0x0)

non_recursive                      =           1 (0x1)

flow_label_dispose                 =           0 (0x0)

receive_entry_type                 =           0 (0x0)

control_word_enabled               =           0 (0x0)

imp_ttl_255                        =           0 (0x0)

collapsed                          =           0 (0x0)

recursive_lsp_stats                =           0 (0x0)

vpn_key                            =          20 (0x14)

Non-recursive:

rpf_id                           =           0 (0x0)

nrldi_ptr                        =      406817 (0x63521)

P2MP:

rpf_id                           =         146 (0x92)

nrldi_ptr                        =         146 (0x92)

mldp_egr_drop                    =           0 (0x0)

mldp_ing_drop                    =           0 (0x0)

mldp_signal                      =           0 (0x0)

mldp_peek                        =           1 (0x1)

mldp_tunnel                      =           1 (0x1)

p2mp_bud_node                    =           0 (0x0)

p2mp_ip_lookup                   =           0 (0x0)

per_lc_receivers                 =           0 (0x0)

igp_local_label: eos             =           1 (0x1)

igp_local_label: exp             =           0 (0x0)

igp_local_label: label           =       25426 (0x6352)

fab_info: fab_mgid               =         521 (0x209)

fab_info: fab_slotmask           =          96 (0x60)

fab_info: fab_fgid               =   150995040 (0x9000060)

backup_fab_info: backup_fab_mgid =         522 (0x20a)

backup_fab_info: backup_fab_slotmask=          96 (0x60)

backup_fab_info: backup_fab_fgid =   167772256 (0xa000060)

rep_node_ndx                     =       40960 (0xa000)

ecmp_size                        =           1 (0x1)

stats_ptr                        =       66560 (0x10400)

Leaf H/W Result on NP:1

09000014000000921806352100020900006000020a0000600000a00001010400

…

Il y a le FGID (Fabric Group Index) et le FGID de sauvegarde. Le FGID est utilisé par la matrice de commutation pour transférer le trafic de multidiffusion vers les cartes de ligne appropriées. Il existe également le MGID (Multicast Group Identifier). Le MGID est utilisé pour transférer le trafic de multidiffusion vers les éléments de réplication appropriés sur les cartes de ligne.

RP/0/RP0/CPU0:R1#show mrib encap-id

Encap ID Key    : 00000101000000600600020100000000000002

Encap ID Length : 19

Encap ID Value  : 262145

Platform Annotation:

Slotmask: Primary: 0x40, Backup: 0x60

MGID:     Primary: 64059,   Backup: 64060

Flags (Vrflite(v4/v6),Stale,v6): N/N, N, N

Oles:

[1] type: 0x5, len: 12

LSM-ID: 0x00001      MDT: 0x2000660   Turnaround: TRUE

Primary: 0/4/CPU0[1]

Backup: 0/3/CPU0[1]

TableId: 0xe0000014[1001]

Redist History:

client id 31 redist time: 02:01:27 redist flags 0x0

Voici comment vous pouvez rechercher l'entrée MGID :

RP/0/RP0/CPU0:R1#show controllers mgidprgm mgidindex 521 location 0/2/CPU0

Device         MGID-Bits       Client-Last-Modified

=======================================================

XBAR-0         1               P2MP

XBAR-1         1               P2MP

FIA-0          1               P2MP

FIA-1          0               None

FIA-2          0               None

FIA-3          0               None

FIA-4          0               None

FIA-5          0               None

FIA-6          0               None

FIA-7          0               None

========================================================

Client         Mask

========================================================

MFIBV4         0x0

MFIBV6         0x0

L2FIB          0x0

sRP-pseudo-mc  0x0

UT             0x0

Prgm-Svr       0x0

P2MP           0x1

xbar           0x0

UT1            0x0

UT2            0x0

punt_lib       0x0

RP/0/RP0/CPU0:R1#show controllers mgidprgm mgidindex 522 location 0/2/CPU0

Device         MGID-Bits       Client-Last-Modified

=======================================================

XBAR-0         1               P2MP

XBAR-1         1               P2MP

FIA-0          1               P2MP

FIA-1          0               None

FIA-2          0               None

FIA-3          0               None

FIA-4          0               Non

FIA-5          0               None

FIA-6          0               None

FIA-7          0               None

========================================================

Client         Mask

========================================================

MFIBV4         0x0

MFIBV6         0x0

L2FIB          0x0

sRP-pseudo-mc  0x0

UT             0x0

Prgm-Svr       0x0

P2MP           0x1

xbar           0x0

UT1            0x0

UT2            0x0

punt_lib       0x0

L'interface sortante est maintenant désactivée et le MBB est en cours d'utilisation.

L'image 13 montre la signalisation.

Image 13

R1 dispose désormais de deux entrées de transfert pour cette arborescence :

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426  24440       mLDP/IR: 0x00001                10.79.196.10    1834250032

24033       mLDP/IR: 0x00001                10.79.196.13    1825230386

RP/0/RP0/CPU0:R1#show mpls forwarding labels 25426 detail

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426              mLDP/IR: 0x00001 (0x00001)

Updated Dec 28 13:07:03.417

mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001

IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014

Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set

Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set

Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set

Ingress Drop:not-set, Egress Drop:not-set

RPF-ID:0, Encap-ID:0

Disp-Tun:[ifh:0x0, label:-]

Platform Data [64]:

{ 0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 2 9 0 0 2 10

0 0 0 1 0 0 0 1

}

mpls paths: 2, local mpls paths: 0, protected mpls paths:

24440       mLDP/IR: 0x00001 (0x00001)   \

10.79.196.10    2230150704

Updated: Dec 28 13:07:03.245

My Nodeid:0x20

Interface Nodeids:

[ 0x8520 - - - - - - - - -  ]

Interface Handles:

[ 0xa000400 - - - - - - - - -  ]

Backup Interface Nodeids:

[ - - - - - - - - - - ]

Backup Interface Handles:

[ - - - - - - - - - - ]

via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]

Packets Switched: 21039158

24033       mLDP/IR: 0x00001 (0x00001)   \

10.79.196.13    2221131058

Updated: Dec 28 13:07:03.417

My Nodeid:0x20

Interface Nodeids:

[ 0x8520 - - - - - - - - -  ]

Interface Handles:

[ 0xa000400 - - - - - - - - -  ]

Backup Interface Nodeids:

[ - - - - - - - - - - ]

Backup Interface Handles:

[ - - - - - - - - - - ]

via-label:100013, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]

Packets Switched: 20954067

Il existe deux clients mLDP en aval, R2 et R3 :

RP/0/RP0/CPU0:R1#show mpls mldp database details

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 3d04h

FEC Root           : 10.79.196.14 (we are the root)

FEC Length         : 12 bytes

FEC Value internal : 02010004000000015C4FC40E

Opaque length      : 4 bytes

Opaque value       : 01 0004 00000001

Opaque decoded     : [global-id 1]

Features           : MBB RFWD Trace

Upstream neighbor(s) :

None

Downstream  client(s):

LDP 10.79.196.10:0 Uptime: 02:44:09

Rec Next Hop     : 10.79.196.10

Remote label (D) : 24440

LDP MSG ID       : 254705

LDP 10.79.196.13:0 Uptime: 00:00:48

Rec Next Hop     : 10.79.196.13

Remote label (D) : 24033

LDP MSG ID       : 98489

PIM MDT            Uptime: 3d04h

Egress intf     : Lmdtvrfone

Table ID        : IPv4: 0xe0000014 IPv6: 0xe0800014

HLI             : 0x00001

Ingress         : Yes

Peek            : Yes

PPMP            : Yes

Local Label     : 25426 (internal)

Le point de gestion (R2) a deux voisins en amont, l'un est actif, l'autre est inactif :

P/0/RSP1/CPU0:R2#show mpls mldp database details

LSM-ID: 0x00002  Type: P2MP  Uptime: 03:45:22

FEC Root           : 10.79.196.14

FEC Length         : 12 bytes

FEC Value internal : 02010004000000015C4FC40E

Opaque length      : 4 bytes

Opaque value       : 01 0004 00000001

Opaque decoded     : [global-id 1]

MBB nbr evaluate   : 00:08:18

Features           : MBB RFWD Trace

Upstream neighbor(s) :

Is CSI accepting    : N

10.79.196.13:0 [Inactive] [MBB] Uptime: 00:01:42

Local Label (D) : 24441

Is CSI accepting    : N

10.79.196.14:0 [Active] [Delete] [MBB] Uptime: 02:45:02

Local Label (D) : 24440

Downstream  client(s):

PIM MDT            Uptime: 03:45:22

Egress intf     : Lmdtvrfone

Table ID        : IPv4: 0xe0000013 IPv6: 0xe0800013

RPF ID          : 3

Peek            : Yes

RD              : 3209:92722001

L'interface de sauvegarde a disparu sur R1 :

RP/0/RP0/CPU0:R1#show mpls for labels 25426 detail hardware ingress location 0/2/CPU0

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

------ ----------- ------------------ ------------ --------------- ------------

25426              mLDP/IR: 0x00001 (0x00001)

Updated Dec 28 13:07:03.418

mLDP/IR LSM-ID: 0x00001, MDT: 0x2000660, Head LSM-ID: 0x00001

IPv4 Tableid: 0xe0000014, IPv6 Tableid: 0xe0800014

Flags:IP Lookup:set, Expnullv4:not-set, Expnullv6:not-set

Payload Type v4:not-set, Payload Type v6:not-set, l2vpn:not-set

Head:set, Tail:not-set, Bud:not-set, Peek:set, inclusive:not-set

Ingress Drop:not-set, Egress Drop:not-set

RPF-ID:0, Encap-ID:0

Disp-Tun:[ifh:0x0, label:-]

Platform Data [64]:

{ 0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 96 0 0 0 96

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 2 9 0 0 2 10

0 0 0 1 0 0 0 1

}

mpls paths: 2, local mpls paths: 0, protected mpls paths:

24440       mLDP/IR: 0x00001 (0x00001)   \

10.79.196.10    N/A

Updated: Dec 28 13:07:03.255

My Nodeid:0x8420

Interface Nodeids:

[ 0x8520 - - - - - - - - -  ]

Interface Handles:

[ 0xa000400 - - - - - - - - -  ]

Backup Interface Nodeids:

[ - - - - - - - - - - ]

Backup Interface Handles:

[ - - - - - - - - - - ]

via-label:100010, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]

Packets Switched: 0

24033       mLDP/IR: 0x00001 (0x00001)   \

10.79.196.13    N/A

Updated: Dec 28 13:07:03.418

My Nodeid:0x8420

Interface Nodeids:

[ 0x8520 - - - - - - - - -  ]

Interface Handles:

[ 0xa000400 - - - - - - - - -  ]

Backup Interface Nodeids:

[ - - - - - - - - - - ]

Backup Interface Handles:

[ - - - - - - - - - - ]

via-label:100013, mpi-flags:0x0 tos_masks:[ primary:0x0 backup:0x0]

Packets Switched: 0

RP/0/RP0/CPU0:R1#show mrib encap-id

Encap ID Key    : 00000101000000600600020100000000000002

Encap ID Length : 19

Encap ID Value  : 262145

Platform Annotation:

Slotmask: Primary: 0x20, Backup: 0x20

MGID:     Primary: 64059,   Backup: 64060

Flags (Vrflite(v4/v6),Stale,v6): N/N, N, N

Oles:

[1] type: 0x5, len: 12

LSM-ID: 0x00001      MDT: 0x2000660   Turnaround: TRUE

Primary: 0/3/CPU0[1]

Backup:

TableId: 0xe0000014[1001]

Redist History:

client id 31 redist time: 00:01:22 redist flags 0x0

Le point de gestion a basculé vers l'arborescence native nouvellement signalée, et il est dans les 60 secondes avant de supprimer l'ancienne arborescence :

RP/0/RSP1/CPU0:R2#show mpls mldp database details

LSM-ID: 0x00002  Type: P2MP  Uptime: 03:53:56

FEC Root           : 10.79.196.14

FEC Length         : 12 bytes

FEC Value internal : 02010004000000015C4FC40E

Opaque length      : 4 bytes

Opaque value       : 01 0004 00000001

Opaque decoded     : [global-id 1]

Features           : MBB RFWD Trace

Upstream neighbor(s) :

Is CSI accepting    : N

10.79.196.13:0 [Active] [MBB] Uptime: 00:10:16

Local Label (D) : 24441

Is CSI accepting    : N

10.79.196.14:0 [Inactive] [Delete 00:00:44] [MBB] Uptime: 02:53:37

Local Label (D) : 24440

Downstream  client(s):

PIM MDT            Uptime: 03:53:56

Egress intf     : Lmdtvrfone

Table ID        : IPv4: 0xe0000013 IPv6: 0xe0800013

RPF ID          : 3

Peek            : Yes

RD              : 3209:92722001

Il y a l'état, après la suppression de l'ancienne arborescence :

RP/0/RSP1/CPU0:R2#show mpls mldp database details

mLDP database

LSM-ID: 0x00002  Type: P2MP  Uptime: 03:58:03

FEC Root           : 10.79.196.14

FEC Length         : 12 bytes

FEC Value internal : 02010004000000015C4FC40E

Opaque length      : 4 bytes

Opaque value       : 01 0004 00000001

Opaque decoded     : [global-id 1]

Features           : MBB RFWD Trace

Upstream neighbor(s) :

Is CSI accepting    : N

10.79.196.13:0 [Active] [MBB] Uptime: 00:14:23

Local Label (D) : 24441

Downstream  client(s):

PIM MDT            Uptime: 03:58:03

Egress intf     : Lmdtvrfone

Table ID        : IPv4: 0xe0000013 IPv6: 0xe0800013

RPF ID          : 3

Peek            : Yes

RD              : 3209:92722001

Le PLR n'a qu'un client mLDP en aval :

RP/0/RP0/CPU0:R1#show mpls mldp database details

mLDP database

LSM-ID: 0x00001  Type: P2MP  Uptime: 3d04h

FEC Root           : 10.79.196.14 (we are the root)

FEC Length         : 12 bytes

FEC Value internal : 02010004000000015C4FC40E

Opaque length      : 4 bytes

Opaque value       : 01 0004 00000001

Opaque decoded     : [global-id 1]

Features           : MBB RFWD Trace

Upstream neighbor(s) :

None

Downstream  client(s):

LDP 10.79.196.13:0 Uptime: 00:11:13

Rec Next Hop     : 10.79.196.13

Remote label (D) : 24033

LDP MSG ID       : 98489

PIM MDT            Uptime: 3d04h

Egress intf     : Lmdtvrfone

Table ID        : IPv4: 0xe0000014 IPv6: 0xe0800014

HLI             : 0x00001

Ingress         : Yes

Peek            : Yes

PPMP            : Yes

Local Label     : 25426 (internal)

Suivi mLDP

La trace mLDP montre les événements plus en détail.

Sur le PLR

L'interface BE10362 tombe en panne :

Dec 28 13:07:03.220 MLDP GLO 0/RP0/CPU0 t10704 RIB  : Read notification

Dec 28 13:07:03.225 MLDP GLO 0/RP0/CPU0 t10706 RIB  : Notify client 'Peer' for prefix: 10.79.196.10/32

Dec 28 13:07:03.225 MLDP GLO 0/RP0/CPU0 t10706 GEN  : Checkpoint save neighbor 10.79.196.10:0 canceled, no GR or NSR

Dec 28 13:07:03.227 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 delete adj 2000460/10.254.3.37

Dec 28 13:07:03.227 MLDP GLO 0/RP0/CPU0 t10706 GEN  : Checkpoint delete neighbor adj 2000460/10.254.3.37 objid 0 version 0 Failed

Dec 28 13:07:03.227 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 LDP Adjacency addr: 10.254.3.37, Interface: Bundle-Ether10362 Delete

Dec 28 13:07:03.325 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 Check branches for path change

La liaison a été perdue, mais la contiguïté LDP n'est pas perdue, elle est conservée en tant que session ciblée.

Les entrées suivantes correspondent à la nouvelle branche sur le routeur IP (10.79.196.13) :

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : P2MP Label mapping from 10.79.196.13:0 label 24033 root 10.79.196.14 Opaque Len 7

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Add branch LDP 10.79.196.13:0 Label 24033

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Branch LDP 10.79.196.13:0 binding list Remote Add

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Changing branch LDP 10.79.196.13:0 from None/0.0.0.0 to None/10.79.196.13

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Notify client Add event: 6 root TRUE

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Add update to PIM Root TRUE Upstream TRUE Ingress TRUE

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 add path label 24033 intf None nexthop 10.79.196.13 id 0x00001 Success

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 set HLI 0x00001 Success

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Notify client Add event: 6 root TRUE

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Add update to PIM Root TRUE Upstream TRUE Ingress TRUE

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 add path label 24033 intf None nexthop 10.79.196.13 id 0x00001 Success

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 set HLI 0x00001 Success

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10705 DB   : 0x00001 Add event from mLDP to PIM, ready TRUE root TRUE csc_rd 0:0 csc_umh 0.0.0.0, msg_len 50

Dec 28 13:07:03.401 MLDP LSP 0/RP0/CPU0 t10705 DB   : 0x00001 Add event from mLDP to PIM, ready TRUE root TRUE csc_rd 0:0 csc_umh 0.0.0.0, msg_len 50

Dec 28 13:07:05.296 MLDP GLO 0/RP0/CPU0 t10706 NBR  : 10.79.196.10:0 to address: 10.254.3.37 mapping deleted

Le reste, c'est le nettoyage. R3 envoie le message de retrait d'étiquette et le message de libération d'étiquette à R1 :

Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 P2MP label withdraw from 10.79.196.10:0 label 24440 root 10.79.196.14 Opaque Len 7

Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 P2MP label release msg to 10.79.196.10:0 Success

Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 FWD  : 0x00001 Label 25426 delete path label 24440 intf None nexthop 10.79.196.10 id 0x00001 Success

Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Branch LDP 10.79.196.10:0 binding list Remote Delete

Dec 28 13:18:04.635 MLDP LSP 0/RP0/CPU0 t10706 DB   : 0x00001 Deleting branch entry LDP 10.79.196.10:0

Sur le MP

L’interface vers le point de gestion est désactivée. La contiguïté est perdue sur la liaison, mais la contiguïté LDP est conservée en tant que session démarrée :

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 delete adj 20003a0/10.254.3.36

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint delete neighbor adj 20003a0/10.254.3.36 objid 0 version 0 Failed

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 LDP Adjacency addr: 10.254.3.36, Interface: Bundle-Ether10362 Delete

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Start path timer for root: 10.79.196.14

Dec 28 13:05:27.134 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint save neighbor 10.79.196.14:0 canceled, no GR or NSR

Dec 28 13:05:27.152 MLDP GLO 0/RSP1/CPU0 t31488 RIB  : Read notification

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Root paths count 1

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 None 10.79.196.13

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 added (chkpt FALSE)

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 binding list Local Add

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 path changed from None:0.0.0.0 to None:10.79.196.13

Dec 28 13:05:27.152 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Request label type ACEL ident 10.79.196.13:0 LSD Success

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 RIB  : Notify client 'Root' for prefix: 10.79.196.14/32

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Root 10.79.196.14 path 10.254.1.184 php nh 10.254.1.184 peer 72d83798:10.79.196.13:0

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : mldp_root_get_path: tid e0100000 ifh 0  php_nh 0.0.0.0

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Failed to get intf type for ifh 0x0

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 RIB  : Notify client 'Peer' for prefix: 10.79.196.14/32

Dec 28 13:05:27.153 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checkpoint save neighbor 10.79.196.14:0 canceled, no GR or NSR

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Main Entry LSD label 24441 type ACEL ident 10.79.196.13:0 assigned

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 installed local label 24441

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Neighbor 10.79.196.13:0 not MBB capable or worse metric, ignore MBB code 0

Le MBB intervient : le délai de commutation configuré est de 600 secondes

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Start MBB Notification timer 100 msec (MBB ack)

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL selection delayed for 600 seconds (MBB)

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 P2MP label mappping  msg to 10.79.196.13:0 Success

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL selection delayed for 600 seconds (MBB)

Le nouveau chemin via le routeur IP est créé :

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 create, Flags: 5 Success

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 add path lspvif Lmdtvrfone rpf-id 3 tid v4 0xe0000013 v6 0xe0800013 Success

Dec 28 13:05:27.153 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 id_val 0 id_type 0

Dec 28 13:05:27.154 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : ACEL for local label 24441 label up 1048577

Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Root paths count 1

Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 None 10.79.196.13

Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 found, retain TRUE, to front TRUE

Dec 28 13:05:27.233 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL selection delayed for 600 seconds (MBB)

Dec 28 13:05:27.234 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 Check branches for path change

Dec 28 13:05:27.234 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : Checking paths for root: 10.79.196.14

Dec 28 13:05:27.234 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : mldp_root_get_path: tid e0100000 ifh 0  php_nh 0.0.0.0

Dec 28 13:05:27.350 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 MBB notification delay timer expired

Dec 28 13:05:29.275 MLDP GLO 0/RSP1/CPU0 t31491 NBR  : 10.79.196.14:0 to address: 10.254.3.36 mapping deleted

Le minuteur de 600 secondes expire :

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Peer change delay timer expired

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL evaluate

L'entrée est supprimée après 60 secondes supplémentaires.

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 start delete pending timer at 60 sec

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.13:0 activate

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24441 create, Flags: 1 Success

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 update active ident from 10.79.196.14:0 to 10.79.196.13:0

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save Main Entry active 10.79.196.13:0 rec_nh 0.0.0.0 rec_rd 0:0 cont...

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save lbl no_label length: 88 obj 80002f60 version 136 Success

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 deactivate

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24440 create, Flags: 5 Success

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 update active ident from 10.79.196.13:0 to 0.0.0.0:0

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save Main Entry active 0.0.0.0:0 rec_nh 0.0.0.0 rec_rd 0:0 cont...

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save lbl no_label length: 88 obj 80002f60 version 137 Success

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 update active ident from 0.0.0.0:0 to 10.79.196.13:0

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save Main Entry active 10.79.196.13:0 rec_nh 0.0.0.0 rec_rd 0:0 cont...

Dec 28 13:15:28.352 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Checkpoint save lbl no_label length: 88 obj 80002f60 version 138 Success

Dec 28 13:15:28.352 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : ACEL for local label 24441 label up 1048577

Dec 28 13:15:28.352 MLDP GLO 0/RSP1/CPU0 t31491 GEN  : ACEL for local label 24440 label up 1048577

Le délai de suppression expire. R3 envoie le message de retrait d'étiquette et le message de libération d'étiquette à R1 :

Dec 28 13:15:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 MBB notification delay timer expired

Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 delete delay timer expired, delete pending TRUE

Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 FWD  : 0x00002 Label 24440 delete, Success

Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 binding list Local Delete

Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 Released label 24440 to LSD

Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 P2MP label withdraw msg to 10.79.196.14:0 Success

Dec 28 13:16:28.552 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 ACEL 10.79.196.14:0 remove

Dec 28 13:16:28.557 MLDP LSP 0/RSP1/CPU0 t31491 DB   : 0x00002 P2MP label release from 10.79.196.14:0 label 24440 root 10.79.196.14 Opaque Len 7

Configurer le minuteur FRR pour faire évoluer les LSP MLDP

Dans une configuration évolutive avec plus de 500 LSP, lorsqu'un FRR se produit, le protocole IGP (Internet Gateway Protocol) de monodiffusion peut converger plus rapidement que les mises à jour de multidiffusion (LMRIB vers FIB) pour les mises à jour d'étiquettes mLDP. Par conséquent, FIB peut marquer le bit FRR dans 2 secondes après un événement FRR, où la programmation matérielle d'étiquette mLDP n'est pas complète sur la carte de ligne de sortie, hébergeant le chemin de sauvegarde. Le temps d'attente FRR est de 2 secondes par défaut.

Il est conseillé d'augmenter ce temps de rétention FRR dans une configuration adaptée.

La commande frr-holdtime configure le FRR holdtime pour qu'il soit proportionnel au nombre de LSP à l'échelle. La valeur recommandée pour le délai d'attente est soit identique, soit inférieure au temporisateur de délai MBB. Cela permet de s'assurer que la carte de ligne de sortie est à l'état FRR après l'événement de désactivation du chemin principal. Lorsqu'elle n'est pas configurée, la valeur par défaut de frr-holdtimer, en secondes, est 2.

Cette commande a été introduite dans la section 5.3.2.

RP/0/RSP1/CPU0:ASR-9906#conf t

RP/0/RSP1/CPU0:ASR-9906(config)#cef platform ?

lsm  Label-switched-multicast parameters

RP/0/RSP1/CPU0:ASR-9906(config)#cef platform lsm ?

frr-holdtime  Time to keep FRR slots programmed post FRR

RP/0/RSP1/CPU0:ASR-9906(config)#cef platform lsm frr-holdtime ?

<3-180>  Time in seconds

Conclusion

MBB peut empêcher la perte de trafic de multidiffusion pour le réacheminement dans le cas de la convergence de routage et dans le cas de la protection du trafic dans le cas d'une liaison en panne, lors de la commutation du trafic de multidiffusion du chemin de secours vers un chemin natif.

Le MBB doit être configuré pour l'activer. Il doit être configuré sur tous les routeurs.

Un délai de transfert MBB de plusieurs secondes doit être configuré pour permettre l'installation de l'arborescence mLDP nouvellement signalée dans le plan de transfert avant le transfert du trafic à partir de cette arborescence mLDP.