Dépannage de MBB (Make-Before-Break) pour mLDP
Table des matières
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 :
- 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.
- 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.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
18-Oct-2022 |
Révision de l’adressage IP |
1.0 |
04-May-2021 |
Première publication |
Commentaires