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, 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?

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. 

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:

Example: 

To change label-withdrawal-delay timer to 10 seconds, set the timer to 10.

For inet.3 route to converge immediately, set the timer to 0.