In an MPLS VPN network environment, after an IGP route next-hop changed, the route table inet.0 converged immediately after an IGP route next-hop changed. However, the route table inet.3 converged after approximately 1 minute.
In an MPLS VPN network environment, after an IGP route next-hop changed, both route table inet.0 and inet.3 should converge immediately at the same time, which is expected. However in this case, inet.3 converged 1 minute later than inet.0.
Example Topology:
R1, R2, R3 and R4 are running OSPF and advertise all the direct routes.
R1, R3 and R4 enabled MPLS and LDP function.

Route 4.4.4.4 information in R1:
root@qfx10002# run show route 4.4.4.4
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[OSPF/10] 00:01:57, metric 60
> to 13.1.1.3 via et-0/0/2.0
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[LDP/9] 00:01:57, metric 1
> to 13.1.1.3 via et-0/0/2.0, Push 19
In R1, because the OSPF metric of et-0/0/2 is lower than et-0/0/0, the next-hop of route 4.4.4.4 is R3 in this situation:
root@qfx10002# show protocols ospf | display set
set protocols ospf lsa-refresh-interval 30
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface et-0/0/2.0 metric 50
set protocols ospf area 0.0.0.0 interface et-0/0/0.0 metric 100
After changing the OSPF metric of et-0/0/2 to 200, the inet.0 converged immediately, the next-hop of route 4.4.4.4 changed to R2. But inet.3 did not converge until 1 minute later.
root@qfx10002# set protocols ospf area 0.0.0.0 interface et-0/0/2.0 metric 200
Jun 30 06:22:28
[master:0][edit]
root@qfx10002# commit
Jun 30 06:22:32 <--- metric was changed at 06:22:32
commit complete
root@qfx10002# run show route 4.4.4.4
Jun 30 06:22:43
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[OSPF/10] 00:00:10, metric 110
> to 12.1.1.2 via et-0/0/0.0 <--- inet.0 converged immediately, next-hop changed to R2
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[LDP/9] 00:01:14, metric 1
> to 13.1.1.3 via et-0/0/2.0, Push 19 <--- inet.3 did not converge
The inet.3 converged after one minute because R2 did not enable MPLS and LDP, route 4.4.4.4 of inet.3 was deleted after 1 minute.
root@qfx10002# run show route 4.4.4.4
Jun 30 06:23:33
inet.0: 15 destinations, 16 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4.4.4.4/32 *[OSPF/10] 00:01:01, metric 110
> to 12.1.1.2 via et-0/0/0.0
Why did the inet.3 converge after 1 minute?
There is a label-withdrawal-delay timer in LDP protocol. By default, LDP waits for 60 seconds before withdrawing labels to avoid re-signaling LSPs multiple times while the IGP is re-converging.
When an IGP link to a neighbor fails, the label associated with the FEC has to be withdrawn from all the upstream routers if the neighbor is the next hop for the FEC. After the IGP converges and a label is received from a new next hop, the label is re-advertised to all the upstream routers. This is the typical network behavior.
But if the new label is not received, FEC will keep the original label 60 seconds by default and do not send a label withdrawal message for a FEC to a neighbor until the a new label received. Refer to the technical documentation on
label-withdrawal-delay timer for more details.
In the topology above, because there is no MPLS and LDP enabled in R2, R1 could not receive a new label from R2. Hence, the route 4.4.4.4 of inet.3 could not converge. Then the LDP label-withdrawal-delay timer 60s (default) was exceeded.
If you encounter a similar issue, check whether the new next-hop device sent a new label.
For inet.3 route to converge immediately or faster, configure label-withdrawal-delay timer. By default, LDP waits for 60 seconds before withdrawing labels to avoid re-signaling LSPs multiple times while the IGP is re-converging.
To configure the label withdrawal delay time in seconds, include the label-withdrawal-delay statement:
[set protocols ldp label-withdrawal-delay <seconds>]
Example:
To change label-withdrawal-delay timer to 10 seconds, set the timer to 10.
'set protocols ldp label-withdrawal-delay 10'
For inet.3 route to converge immediately, set the timer to 0.
'set protocols ldp label-withdrawal-delay 0'