Troubleshoot Make-Before-Break (MBB) for mLDP
Available Languages
Contents
Introduction
This document describes the behavior of Make-Before-Break (MBB) in Cisco IOS® XR.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
- This document is specific to Cisco IOS® XR, but it is not restricted to a specific software release or hardware.
- All devices used in this article run Cisco IOS XR 6.5.2. All line cards are third or fourth generation ASR9k line cards.
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. If your network is live, ensure that you understand the potential impact of any command.
Background Information
Make-Before-Break (MBB) has a purpose: to set up a new mLDP (multipoint Label Distribution Protocol) tree before tearing down the old tree and switching traffic from the old to the new tree without losing multicast traffic. This can be used in two scenarios:
- When rerouting occurs when a new path becomes available with a better IGP (Interior Gateway Protocol) metric: switch the traffic from the old to the new tree and then delete the old tree.
- When the multicast traffic is protected on a backup path: switch the traffic from the backup path to the newly signalled native mLDP tree and then delete the backup tree.
If the router knows that the old LSP (Label Switched Path) is broken, it must not wait to start using the new LSP. Waiting does not make sense here, as there is no traffic arriving any longer on the old tree. If the old tree is still working, then the router must not tear down the old tree until the new tree is fully set up.
Theory
MBB is driven by a Query and Ack mechanism as described in RFC 6388. This is the base RFC of mLDP. This Query and Ack mechanism signals when the new tree is ready to forward multicast traffic. In this way, there must not be any packet loss. If the router knows that the old LSP is broken, it must not wait to start using the new LSP. Waiting does not make sense here, as there is no traffic arriving any longer on the old tree. If the old tree is still working, then the router must not tear down the old tree until the new tree is fully set up.
The cases where MBB can help are:
- The existing tree is being rerouted due to a change in the topology, a link up event or a reduction in the IGP cost of a link occurs,
- Reverting back to a native mLDP tree, after receiving the multicast traffic on an actively protected TE tunnel/LFA (Loop-free Alternate), or Ti-LFA (Topology independent LFA) path.
Notice that these two represent good events. An example of a bad event would be a directly connected link going down on a router on the upstream path. MBB cannot help in this case. IP FRR (Fast ReRoute) is needed in this case.
When MBB occurs, there is temporarily more than one upstream neighbor and/or more than one downstream neighbor. In RFC 6388, it is specified that there can be multiple accepting elements. This means that there can be multiple upstream neighbors and upstream label values per tree. An "accepting element" means that the upstream mLDP neighbor is a candidate for accepting traffic on. One accepting element is the active element. The active element is the one for which the MPLS label is installed in the forwarding plane. The other accepting element is the inactive element. This element is the one for which the MPLS label is not yet installed in the forwarding plane. This inactive element is the one for the newly signalled part of the tree with the Query/Ack mechanism and must be short lived, before it transitions to becoming the active accepting element. There can be only two accepting elements per tree: one is the active one, the other is the inactive one. As soon as the Query/Ack signalling finishes or a fixed time delay is reached, the old neighbors are removed from the tree.
Instead of the Query/Ack mechanism, the other implementation choice could be to just delay the switchover to the new LSP by a fixed configurable delay.
It is important to note that mLDP shares the downstream assigned label space that unicast uses and hence for the MPLS forwarding plane there is in essence no difference between multicast packets or unicast packets. Since the forwarding plane is shared with unicast, certain unicast feature are inherited for multicast, like IP FRR.
The MBB procedures applies to P2MP (Point-to-Multipoint) and MP2MP (Multipoint-to-Multipoint) trees.
MBB Query and Ack Mechanism
MBB is optional (it is also optional in the RFC), so it must be configured for it to be enabled. When it is configured, there can be an MBB status attached to the Label Mapping Message sent upstream and it can also be attached to an LDP Notification message sent by an upstream router to the downstream router. A router can attach a MBB Status in a LDP MP Status TLV.
The MBB Status is a type of the LDP MP Status Value Element:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status Code is 1 for a MBB request and 2 for a MBB ack.
The LDP MP Status TLV is encoded as follows:
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 |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value field holds one or more LDP MP Status Value elements.
The LDP MP Status Value Element that is included in the LDP MP Status TLV Value has the next encoding:
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LDP MP Status TLV can appear either in a Label Mapping message or a LDP Notification message.
In a LDP Notification Message:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In a Label Mapping Message:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The previous describes the dynamic MBB behavior. Another option is to have a static behavior where the switchover to the new tree is only determined by a delay. In this case, the switchover occurs a certain amount of (milli)seconds after the new tree is ready.
Image 1 depicts a capture in Wireshark of the mLDP Label Mapping message. There is a LDP MP Status TLV attached.
Image 1
01000102 decodes to 1 for MBB Type 1, 0001 for Length 1, and 02 for MBB Ack.
Notice that the MBB mechanism applies to the P2MP mLDP FEC (Forwarding Equivalence Class), and the MP2MP Upstream or Downstream FECs.
MBB Capability
A router capable of performing MBB, advertises this in a MBB Capability advertisement on the LDP session to its neighbors.
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 is not enabled by default for Cisco IOS XR.
The command "make-before-break" enables the feature and the capability advertisement.
mpls ldp
mldp
logging notifications
address-family ipv4
make-before-break delay 0
The MBB does not have a delay by default. Only in a scaled setup, the delay must be increased. The reason is that with many mLDP database entries there can be many mLDP forwarding entries that need to be installed. The time to install these forwarding entries into the data plane of the line cards can take some time.
MBB Delay
Look at image 2.
Image 2
There is the old tree and the newly signalled tree. The router where the two trees branch is the Point of Local Repair (PLR). The router where the two trees merge again is the Merge Point (MP). The new part of the mLDP tree is signalled due to the routers discovering a better path. Either, the new link R4 – R2 became available, or the IGP metric on that link was lowered to produce a path with a lower overall metric.
You can configure two delay values for MBB. The first is the delay when MBB is used to have the MP switchover back to a native path. This is the time after the MBB ack is received.
RP/0/RP1/CPU0:Router(config-ldp-mldp-af)#make-before-break delay ?
<0-600> Forwarding delay in seconds
A delay of zero means that the newly signalled path is immediately used after the MBB Ack is received on the router where the old and new path diverse, the PLR. The second is the delay for the deletion of the backup path after the MP has switched over to the native path.
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>
Both the switchover delay and the delete delay are used on the MP.
MBB for Rerouting
MBB takes care of setting up a new mLDP tree before the old one is taken down. This only makes sense if the old tree is still present and forwarding traffic. An IGP convergence, such as a link up event, can produce a better path for the mLDP tree. This means a smaller IGP metric towards the root, or towards the leaf if it is a MP2MP mLDP tree.
Look at an example.
Image 3 shows a network before the routing convergence event.
Image 3
R5 is the root router of one mLDP tree and R6 is the leaf router. A P2MP mLDP Tree is signalled with a Label Mapping message (including a MPLS label), from every router towards the root. This LDP Label Mapping message does not carry a MBB Request.
The mLDP traffic goes left (root) to right (leaf) over the top path. At each link, the indicated MPLS label is on top of the multicast packet.
Image 4 shows the network after the routing convergence event (without MBB).
Image 4
The link R4 – R2 is now up. The metric of this link is of a low value so that the bottom path has a lower metric than the top path. Two things need to happen: the IGP adjacency needs to be established over the link and the LDP session needs to be established as well over this new link. Once this LDP session is up, the Label Mapping message is exchanged over this link in order to move the mLDP tree from the top to the bottom.
If MBB is not configured, then there is regular signalling with LDP Label Mapping messages on the bottom path. As soon as the Label Mapping message (without a MBB Request) reaches R1, R1 stops forwarding the multicast traffic on the top path and start forwarding the multicast traffic on the bottom path.
In the end, R1 never forwarded the multicast traffic over the two paths, but only over one: it switched the traffic from the top to the bottom path. The switchover is immediate which could lead to a short period of multicast traffic dropped due to the fact that the control plane signalling from R2 to R1 over R4 could be a bit faster than the time needed for the mLDP entries to be installed in the data plane on the routers on the new path.
There is mLDP logging notification enabled explicitely.
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
If MBB is configured, we have as follows.
Note that it is not sufficient to just configure MBB on R1.
This is an example configuration on R2:
mpls ldp
mldp
logging notifications
address-family ipv4
make-before-break delay 60
!
You would want R2 to delay the switchover from the old to the new path with 60 seconds when the LDP session across the link R4-R2 is up. It does not happen. You need to have MBB enabled on every router (or at least R1, R4, and R2) to have the MBB signalling working between R2 and R1 across R4.
You need to have this minimal configuration on every router in order to have MBB signalling enabled.
mpls ldp
mldp
logging notifications
address-family ipv4
make-before-break delay 0
!
Look at image 5.
Image 5
All the correct configuration is in place. We look at the events from the beginning, so the situation before the convergence event.
The top path active is the start. On R1, R3 is the only downstream client.
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
On R2, R3 is the only accepting element.
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
After the MBB signalling, R2 has two accepting elements, one active, one inactive.
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 has two downstream clients, R3 and 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 is forwarding over both paths:
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 now has two upstream neighbors, one active (R3), and one inactive (R4). This phase is there for 60 seconds, the forwarding delay time.
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
Notice that the local label for each mLDP tree is different. So, R2 has no issue differentiating the incoming mLDP traffic and identifying which incoming mLDP packet belongs to which mLDP tree. R2 only forwards the traffic from one tree at any time. The flag ED means 'Egress Drop' and means that packets arriving with label 24009 is dropped. These are the packets on the tree for which the accepting element is inactive. There is no duplicate traffic arriving at the receivers!
Notice that the outgoing label for each mLDP tree on R2 is the same. So, to R6, a downstream router of R2, it cannot distinguish if the traffic came over the original old (top) path or the new (bottom) path after rerouting.
After 60 seconds, R2 stops forwarding the traffic from the top path, and starts the traffic from the bottom path.
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 has only one downstream client, 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 has only one upstream neighbor:
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
The mLDP trace on R2 shows that the MBB signalling was used, that there was a 60 second delay before switching over from the old path to the new path and a subsequent 0 second delay for deleting the old path. After this, R2 sends a Label Withdraw message to R3 for the old path and receives a Label Release message from R3 as a response.
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 for Protection
The mLDP protection is composed of two main parts: the protection itself and MBB (Make-Before-Break).
Protection
The protection of mLDP traffic is similar to the protection mechanisms of unicast MPLS traffic. As soon as a link failure is detected, the PLR router switches the multicast traffic from trees crossing that link to the backup path. This backup path is a precomputed path that is installed in the forwarding plane. So, as soon as the failure occurs, the multicast traffic can be switched immediately to the backup path.
The protection is for link-down only. There is no node protection for mLDP.
The link-down event must be detected very quickly. This means that BFD (Bidirectional Forwarding Detection) must be used.
MBB
After the protection kicks in, the multicast traffic does not stay on the backup path forever. The traffic must be switched over to a newly calculated native mLDP tree/path. This switchover must occur in such a way that no multicast traffic is lost. MBB is used for this, so that the traffic is only switched over when the newly signalled tree is completely set up and is forwarding traffic. The MP router can then safely switch forwarding the traffic from the old backup tree to the newly signalled tree without traffic loss.
Theory of mLDP Protection
Look at image 6. It shows a network with a link R1 – R2 which is protected with Ti-LFA.
Image 6
The mLDP traffic is forwarded over the link R1 – R2. FRR calculates and installs a backup path via R3.
Look at image 7.
Image 7
Image 7 shows the situation when the protection is active.
When the link R1 – R2 goes down, the LDP session across it, is kept alive by LDP session protection. The LDP session - which is a TCP session – reroutes over R3. This avoid that the label bindings for LDP and mLDP between R1 and R2 are removed. For this LDP session to be able to be routed over R3 and be multi-hop, it must be a targeted LDP session. This is automatically done when LDP session protection is configured.
When the link R1 – R2 goes down, the mLDP traffic can be rerouted in a fast way over R3. For this to work, there must be some form of protection on R1 for the route towards the LDP router-ID of R2. This is achieved by either enabling MPLS Traffic Engineering tunnels, LFA (Loop-free Alternate), or Ti-LFA (Topology Independent LFA). The multicast traffic from R1 to R2 had one mLDP label. When the link R1 – 2 goes down, the multicast traffic gets an extra label when sent to R2. There is Penultimate Hop Popping (PHP), so the traffic is forwarded with one label towards R2. R2 receives this traffic with the same label as when the R1 – R2 link was up. R2 keeps on forwarding this multicast traffic.
This protection is fast. While there is protection for the mLDP traffic, R2 starts to signal a new native path from it towards R1 via R3. So, R2 sends an mLDP label mapping message to R3. R3 does the same towards R1. This is the same process/signalling as always when creating a new mLDP path. While this signalling is going on, R2 keeps forwarding the traffic from the backup mLDP path. When does R2 start forwarding the traffic from the newly created native path? The trigger can be two things: a timed delay or a signalling trigger. The timed delay is something configured. The signalling trigger is the Make-Before-Break behavior (MBB) introduced in mLDP and specified in RFC 6388. When R2 receives the signal from R1, it indicates that the newly native mLDP path is ready, so R2 can start forwarding the traffic from that new mLDP path and stop forwarding the traffic from the backup path.
R1 is called the PLR (Point-of-Local-Repair), it is the router where the protected path and the newly signalled native path branch off. R2 is the MP (Merge Point), the router where the protected path and the newly signalled native path merge again.
Look at image 8.
Image 8
Image 8 shows that there a mLDP Label Mapping message from R2 to R3, and from R3 to R1. This Label Mapping message has the MBB Request.
Look at image 9.
Image 9
R1 answers this signalling with a LDP Notification, carrying the MBB acknowledgement in the reverse direction. So, down the tree. This message travels from R1 to R3, and from R3 to R2. This signals R2, the MP router, that the new native mLDP path is ready. At this point R1 forwards the mLDP traffic twice, once on the backup path and once on the new native path
MBB is used here to have the MP (R2) switchover back to a native path (that was just created). When MBB has finished the signalling part, the MP stops forwarding the mLDP traffic arriving from the backup path and start forwarding the traffic from the newly signalled native path. The MBB is used here to indicate when this newly signalled path is ready. Another possibility is to configure a delay. In that case, the MP stops forwarding the mLDP traffic arriving from the backup path, and start forwarding the traffic from the newly signalled native path after the MBB has signalled that this new native path is ready and after the configured delay timer.
When R2 starts forwarding the traffic from the new native path, it stop forwarding the traffic from the backup path and signals the teardown of the backup path by sending a LDP Label Withdraw message for the tree (and a LDP Label Release message).
An additional delete delay can be added to remove the old tree in order to allow the platform to program all the forwarding state to the line cards.
After this, there is only the newly signalled native tree. Look at image 10 to see the forwarding of mLDP traffic in this case.
Image 10
Notice that the mLDP traffic has one MPLS label on top again.
Required Configuration
The next three configuration items are required for mLDP FRR (Fast ReRoute) to work.
You need:
- Recursive forwarding for mLDP enabled
- LDP session protection enabled
- LFA (Loop-free Alternate) or Ti-LFA (Topology Independent LFA) under the IGP (Ti-LFA requires Segment Routing). Point-to-Point Traffic Engineering is also possible.
If any of these three are missing, then there is no FRR protection for mLDP. mLDP protects only against link failures, not node failures.
Configuration example
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
!
!
!
The make-before-break command is optional.
Check that the outgoing interface is protected by LFA or 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
!
There is no impact on the protection of the multicast traffic if any of the routers along the new native path do not have MBB configured. The protection is only dependent on the configuration of LDP session protection, recursive forwarding, and FRR, on the PLR. The MBB configuration on the newly native path routers only have a consequence when the traffic is switched from the backup path to the newly signalled tree. If a mLDP router received a Label Mapping message with MBB Request from a downstream router and needs to send a Label Mapping message to an upstream router, but that upstream router does not have MBB enabled, then the mLDP router sends a LDP Notification message to this downstream router as soon as it has sent the Label Mapping message (without the MBB Request) to the upstream router. As such, a regular mLDP tree is the result.
MBB for FRR Example
Look at image 11 for the topology.
Image 11
When the Link fails between R1 and R2, then the mLDP session between them is protected by a LDP targeted session between them over R3. So, the mLDP session between R1 and R2 remains up even when the link between them is down. This protects the mLDP label bindings between them, they are kept. When the link R1-R2 goes down, the forwarding plane immediately switches over: the outgoing link R1-R2 switches to link R1-R3 in a very fast way, thanks to the Point-to-Point MPLS TE, LFA or Ti-LFA in place. This P2P MPLS TE, LFA or Ti-LFA must protect on R1 the route to the LDP router-ID of R2 in order to switch the forwarding entries for mLDP in a correct way. Finally, the recursive forwarding is needed because the mLDP session switches from a directly connected session, to a remote session, where the LDP router-ID is resolved in a recursive way.
R1 is called the PLR (Point-of-Local-Repair), it is the router where the protected path and the newly signalled native path branch off. R2 is the MP (Merge Point), the router where the protected path and the newly signalled native path merge again.
Check the three requirements:
-LDP protection
For the directly connected LDP (mLDP) neighbor over Bundle-Ethernet10362, there must also be targeted hello’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 or Ti-LFA under the IGP
Check that the route to the LDP neighbor router-id has a backup path. The RIB (Routing Information Base) and FIB (Forwarding Information Base or CEF) must have this backup path:
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}
-recursive forwarding for mLDP
The mLDP database entry does not have an outgoing interface in the LFIB if recursive forwarding is applied:
Without recursive forwarding:
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
With recursive forwarding:
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
Notice that there is no outgoing interface anymore for the mLDP forwarding entry. This makes troubleshoot a bit harder.
The MP has the next configuration for mLDP. Note the timers 600 sec and 60 sec. The PLR has the same timers. The PLR forwards the traffic over the backup path and the native path for 600 seconds. The 600 seconds delay means that the MP forwards the traffic from the backup path for 600 sec, while dropping the traffic arriving from the native path. 600 seconds is a long time for this timer. It was used in a lab environment in order to provide enough time to capture the output with show commands. The 60 sec delay means that the MP waits the deletion of the MBB path for 60 seconds after it starts forwarding the traffic arriving from the native path and dropping the traffic arriving over the backup path. The correct value for these two delays depends on the network. It needs to be derived from testing the specific network, software, and hardware.
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 in use
Look at image 12, it shows the forwarding while mLDP is in protecting mode.
Image 12
Before the outgoing interface is down, this is the LFIB entry for the remote LDP router-ID (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.
This is the mLDP tree database entry on the 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
This is the mLDP forwarding entry for the tree:
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)
This is the LFIB (Label Forwarding Instance Base) forwarding entry for the tree:
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
The mLDP forwarding entry is protected. The forwarding entry is protected via label 100010, the entry for the remote LDP router ID.
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
This is the forwarding entry in hardware. The routers are ASR9k routers.
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
…
There is the FGID (Fabric Group Index) and backup FGID. The FGID is used by the switch fabric to forward the multicast traffic to the correct line cards. There is also the MGID (Multicast Group Identifier). The MGID is used to forward the multicast traffic to the correct replication elements on the line cards.
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
This is how you can look up the MGID entry:
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
The outgoing interface is now down, and MBB is in use.
Image 13 shows the signalling.
Image 13
R1 now has two forwarding entries for this tree:
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
There are two downstream mLDP clients, R2 and 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)
The MP (R2) has two upstream neighbors, one is active, the other is inactive:
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
The backup interface is gone on 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
The MP switched over to the newly signalled native tree, and it is within the 60 seconds before deleting the old tree:
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
There is the state, after the old tree is deleted:
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
The PLR only has one downstream mLDP client:
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)
mLDP Trace
The mLDP trace shows the events in more detail.
On the PLR
The interface BE10362 goes down:
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
The link was lost, but the LDP adjacency is not lost, it is kept as a targeted session.
The next entries are the new branch over the P router (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
The rest is the clean-up. R3 sends the Label Withdraw message and Label Release message to 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
On the MP
The interface to the MP goes down. The adjacency is lost over the link, but the LDP adjacency is kept as a tarted session:
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
MBB kicks in: the 600 seconds is the configured switchover delay
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)
The new path via the P router is created:
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
The 600 seconds timer expires:
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
The entry is deleted after another 60 seconds.
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
The delete delay timer expires. R3 sends the Label Wtihdraw message and Label Release message to 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
Configure FRR timer for scale MLDP LSPs
In a scaled setup with more than 500 LSPs, when an FRR occurs, the unicast Internet Gateway Protocol (IGP) can converge faster than multicast updates (LMRIB to FIB) for mLDP label updates. As a result, FIB can mark off the FRR bit in 2 seconds after an FRR event, where mLDP label hardware programming is not complete on the egress line card, hosting the backup path. The FRR holdtime is by default 2 seconds.
It is advised to increase this FRR holdtime in a scaled setup.
The command frr-holdtime configures the FRR holdtime to be proportional to the scale number of LSPs. The recommended frr-holdtime value is either the same, or lesser than the MBB delay timer. This ensures that the egress line card is in FRR state after the primary path down event. When not configured, the default frr-holdtimer, in seconds, is set to 2.
This command was introduced in 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 can work to prevent multicast traffic loss for rerouting in the case of routing convergence and in the case of protecting traffic in the case of a link going down, when switching back the multicast traffic from the backup path to a native path.
MBB must be configured to enable it. It must be configured on all routers.
There must be a MBB forwarding delay configured of several seconds to allow the installation of the newly signalled mLDP tree in the forwarding plane before forwarding the traffic from that mLDP tree.
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
2.0 |
18-Oct-2022 |
IP Addressing Revision |
1.0 |
04-May-2021 |
Initial Release |
Feedback