Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[QFX] After an IGP route next-hop changed, the route table inet.3 converged 1 minute later than inet.0

1

0

Article ID: KB36058 KB Last Updated: 22 Jul 2020Version: 1.0
Summary:

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.

Symptoms:

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
Cause:

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.

Solution:

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'
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search