Knowledge Search


×
 

[Junos Platform/MX] LDP metric not in sync with OSPF metric in LDP tunneling scenario

  [KB34551] Show Article Properties


Summary:

In an OSPF--ISIS--OSPF redistribution scenario with the LDP track-igp-metric configured, it may be observed that the Label Distribution Protocol (LDP) metric is out of sync with the Open Shortest Path First (OSPF) protocol, which results in the selection of a sub-optimal labeled path and consequent traffic impact.

This article outlines the reason for the metric inconsistency on MX routers, while providing a workaround and also listing the Junos OS releases in which the issue is resolved.

 

Symptoms:

The following example explains the issue in detail:

 

Topology

 
R1 --- ospf/ldp --- R2 --- ospf/ldp --- R3 --- ospf/ldp --- R4 --- isis/rsvp/ldp-tunneling --- R5 --- ospf --- R7 (router with issue)
 

The prefix 192.168.0.1/32 is the lo0 address of R1, which is learned via R7 through OSPF--ISIS--OSPF redistribution. Note that R1 has the metric 16842749, which is consistent with OSPF and LDP.

R1> show route 192.168.0.1   
 
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
192.168.0.1/32     *[OSPF/150] 00:09:17, metric 16842749, tag 0 ----- >>>>>>> Consistent metric
                      to 5.5.5.1 via xe-1/0/4.1
                      to 5.5.5.5 via xe-1/0/4.2
                    > to 5.5.5.9 via xe-1/0/4.3
                      to 5.5.5.13 via xe-1/0/4.4
 
inet.3: 18 destinations, 39 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
192.168.0.1/32     *[LDP/9] 00:08:55, metric 16842749 ------- >>>>>>>>> Same as LDP metric
                      to 5.5.5.1 via xe-1/0/4.1, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.5 via xe-1/0/4.2, label-switched-path R5_TO_R4_COR1
                    > to 5.5.5.9 via xe-1/0/4.3, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.13 via xe-1/0/4.4, label-switched-path R5_TO_R4_COR1
                    [OSPF/150] 00:08:55, metric 16842749, tag 0
                      to 5.5.5.1 via xe-1/0/4.1, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.5 via xe-1/0/4.2, label-switched-path R5_TO_R4_COR1
                    > to 5.5.5.9 via xe-1/0/4.3, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.13 via xe-1/0/4.4, label-switched-path R5_TO_R4_COR1
 

When the metric on the export policy ISIS-TO-OSPF-REDIST is changed and applied on router R5, observe the issue as shown below:

R5# show policy-options policy-statement ISIS-TO-OSPF-REDIST 
term loopbacks {
    from {
        protocol isis;
        prefix-list ISIS-LOOPBACK-REDIST;
    }
    then {
        external {
            type 1;
        }
        accept;
    }
}
 
R5# set  policy-options policy-statement ISIS-TO-OSPF-REDIST term loopbacks then metric 100    
 
[edit]
R5# commit 
commit complete
 
R5# show  policy-options policy-statement ISIS-TO-OSPF-REDIST                                       
term loopbacks {
    from {
        protocol isis;
        prefix-list ISIS-LOOPBACK-REDIST;
    }
    then {
        metric 100; ----------- >>>>> This is added now.
        external {
            type 1;
        }
        accept;
    }
}
 

Following the metric change, on router R7 at the extreme right, the OSPF metric has changed to 65635. However, the LDP metric is still showing the old value of 16842749.

R7> show route 192.168.0.1   
 
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
192.168.0.1/32     *[OSPF/150] 00:01:57, metric 65635, tag 0
                      to 5.5.5.1 via xe-1/0/4.1
                      to 5.5.5.5 via xe-1/0/4.2
                    > to 5.5.5.9 via xe-1/0/4.3
                      to 5.5.5.13 via xe-1/0/4.4
 
inet.3: 18 destinations, 39 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
192.168.0.1/32     *[LDP/9] 00:20:20, metric 16842749 ------------- >>>>>> Metric inconsistency 
                      to 5.5.5.1 via xe-1/0/4.1, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.5 via xe-1/0/4.2, label-switched-path R5_TO_R4_COR1
                    > to 5.5.5.9 via xe-1/0/4.3, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.13 via xe-1/0/4.4, label-switched-path R5_TO_R4_COR1

                    [OSPF/150] 00:01:57, metric 65635, tag 0 ------------- >>>>>> Metric inconsistency
                      to 5.5.5.1 via xe-1/0/4.1, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.5 via xe-1/0/4.2, label-switched-path R5_TO_R4_COR1
                    > to 5.5.5.9 via xe-1/0/4.3, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.13 via xe-1/0/4.4, label-switched-path R5_TO_R4_COR1
 

When the LDP sessions are cleared, however, the metric inconsistency is no longer seen.

R5> show ldp neighbor 
Mar 05 15:53:42
Address                             Interface       Label space ID     Hold time
192.168.0.14                        lo0.17          192.168.0.14:0       32
192.168.0.15                        lo0.17          192.168.0.15:0       35
192.168.0.16                        lo0.17          192.168.0.16:0       42
192.168.0.17                        lo0.17          192.168.0.17:0       37
 
R5> clear ldp session all                                                                  
Mar 05 15:54:50
 
R7> show ldp neighbor logical-system R5_TO_R4_COR1    
Mar 05 15:55:01
Address                             Interface       Label space ID     Hold time
192.168.0.14                        lo0.17          192.168.0.14:0       44
192.168.0.15                        lo0.17          192.168.0.15:0       36
192.168.0.16                        lo0.17          192.168.0.16:0       44
192.168.0.17                        lo0.17          192.168.0.17:0       40
 
R5> show route 192.168.0.1 
Mar 05 15:55:59
 
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
192.168.0.1/32     *[OSPF/150] 00:38:27, metric 65635, tag 0
                      to 5.5.5.1 via xe-1/0/4.1
                      to 5.5.5.5 via xe-1/0/4.2
                    > to 5.5.5.9 via xe-1/0/4.3
                      to 5.5.5.13 via xe-1/0/4.4
 
inet.3: 18 destinations, 39 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
192.168.0.1/32     *[LDP/9] 00:00:58, metric 65635 ------------>>> Metric is consistent now.
                      to 5.5.5.1 via xe-1/0/4.1, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.5 via xe-1/0/4.2, label-switched-path R5_TO_R4_COR1
                    > to 5.5.5.9 via xe-1/0/4.3, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.13 via xe-1/0/4.4, label-switched-path R5_TO_R4_COR1
                    [OSPF/150] 00:38:27, metric 65635, tag 0
                      to 5.5.5.1 via xe-1/0/4.1, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.5 via xe-1/0/4.2, label-switched-path R5_TO_R4_COR1
                    > to 5.5.5.9 via xe-1/0/4.3, label-switched-path R5_TO_R4_COR1
                      to 5.5.5.13 via xe-1/0/4.4, label-switched-path R5_TO_R4_COR1

 

Cause:

One of the many criteria to update an LDP ingress route is to change the metric. However, LDP determines whether there is a change in metric only for the inet.0 route by design.

Therefore, when route deletion for the inet.3 route happens before the inet.0 route, LDP updates the route metric from the inet.3 route but does not consider the change in metric. When route deletion for the inet.0 route happens later, the LDP route metric has already been updated to the new metric. A subsequent comparison of the LDP route metric and the metric from the inet.0 route deletion results in no metric change. Hence, LDP does not update the LDP ingress route with the new metric.

This is a timing related issue and is seen only if the inet.3 route deletion happens before the inet.0 route.

 

Solution:

As documented in PR​1422645, this issue has been fixed in Junos OS releases 18.2R3, 18.3R3, 18.4R2, 16.2R3, 18.1R3-S5, 17.4R3, 19.1R2, and 19.2R1.

Meanwhile, a workaround is to clear the LDP session as shown above, by using R5> clear ldp session all.

 

Related Links: