Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

Optimizing Signaled LSPs

Once an LSP has been established, topology or resources changes might, over time, make the path suboptimal. A new path might have become available that is less congested, has a lower metric, and traverses fewer hops. You can configure the router to recompute paths periodically to determine whether a more optimal path has become available.

If reoptimization is enabled, an LSP can be rerouted through different paths by constrained-path recomputations. However, if reoptimization is disabled, the LSP has a fixed path and cannot take advantage of newly available network resources. The LSP is fixed until the next topology change breaks the LSP and forces a recomputation.

Reoptimization is not related to failover. A new path is always computed when topology failures occur that disrupt an established path.

Because of the potential system overhead involved, you need to carefully control the frequency of reoptimization. Network stability might suffer when reoptimization is enabled. By default, the optimize-timer statement is set to 0 (that is, it is disabled).

LSP optimization is meaningful only when constrained-path LSP computation is enabled, which is the default behavior. For more information about constrained-path LSP computation, see Disabling Constrained-Path LSP Computation. Also, LSP optimization is only applicable to ingress LSPs, so it is only necessary to configure the optimize-timer statement on the ingress router. The transit and egress routers require no specific configuration to support LSP optimization (other than to have MPLS enabled).

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Once you have configured the optimize-timer statement, the reoptimization timer continues its countdown to the configured value even if you delete the optimize-timer statement from the configuration. The next optimization uses the new value. You can force the Junos OS to use a new value immediately by deleting the old value, committing the configuration, configuring the new value for the optimize-timer statement, and then committing the configuration again.

1. The new path is not higher in IGP metric. (The metric for the old path is updated during computation, so if a recent link metric changed somewhere along the old path, it is accounted for.)
2. If the new path has the same IGP metric, it is not more hops away.
3. The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
4. The new path does not worsen congestion overall.

   The relative congestion of the new path is determined as follows:

   1. The percentage of available bandwidth on each link traversed by the new path is compared to that for the old path, starting from the most congested links.
   2. For each current (old) path, the software stores the four smallest values for bandwidth availability for the links traversed in ascending order.
   3. The software also stores the four smallest bandwidth availability values for the new path, corresponding to the links traversed in ascending order.
   4. If any of the four new available bandwidth values are smaller than any of the corresponding old bandwidth availability values, the new path has at least one link that is more congested than the link used by the old path. Because using the link would cause more congestion, traffic is not switched to this new path.
   5. If none of the four new available bandwidth values is smaller than the corresponding old bandwidth availability values, the new path is less congested than the old path.

5. If the new path has a lower IGP metric, it is accepted.
6. If the new path has an equal IGP metric and lower hop count, it is accepted.

7. If you choose least-fill as a load balancing algorithm, LSPs are load balanced as follows:

   1. The LSP is moved to a new path that is utilized at least 10% less than the current path. This might reduce congestion on the current path by only a small amount. For example, if an LSP with 1 MB of bandwidth is moved off a path carrying a minimum of 200 MB, congestion on the original path is reduced by less than 1%.
   2. For random or most-fill algorithms, this rule does not apply.
   The following example illustrates how the least-fill load balancing algorithm works.

   Figure 1: least-fill Load Balancing Algorithm Example

   

   As shown in Figure 1, there are two potential paths for an LSP to traverse from router A to router H, the odd links from L1 through L13 and the even links from L2 through L14. Currently, the router is using the even links as the active path for the LSP. Each link between the same two routers (for example, router A and router B) has the same bandwidth:

   • L1, L2 = 10GE
   • L3, L4 = 1GE
   • L5, L6 = 1GE
   • L7, L8 = 1GE
   • L9, L10 = 1GE
   • L11, L12 = 10GE
   • L13, L14 = 10GE

   The 1GE links are more likely to be congested. In this example, the odd 1GE links have the following available bandwidth:

   • L3 = 41%
   • L5 = 56%
   • L7 = 66%
   • L9 = 71%

   The even 1GE links have the following available bandwidth:

   • L4 = 37%
   • L6 = 52%
   • L8 = 61%
   • L10 = 70%

   Based on this information, the router would calculate the difference in available bandwidth between the odd links and the even links as follows:

   • L4 - L3 = 41% - 37% = 4%
   • L6 - L5 = 56% - 52% = 4%
   • L8 - L7 = 66% - 61% = 5%
   • L10 - L9 = 71% - 70% = 1%

   The total additional bandwidth available over the odd links is 14% (4% + 4% + 5% + 1%). Since 14% is greater than 10% (the least-fill algorithm minimum threshold), the LSP is moved to the new path over the odd links from the original path using the even links.

8. Otherwise, the new path is rejected.

• If the new path has the same IGP metric, it is not more hops away.
• The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
• The new path does not worsen congestion overall.
• If the new path has an equal IGP metric and lower hop count, it is accepted.

To disable them, either issue the clear mpls lsp optimize-aggressive command or include the optimize-aggressive statement:

• [edit protocols mpls]
• [edit logical-systems logical-system-name protocols mpls]

Including the optimize-aggressive statement in the configuration causes the reoptimization procedure to be triggered more often. Paths are rerouted more frequently. It also limits the reoptimization algorithm to the IGP metric only.

• [edit protocols mpls]
• [edit logical-systems logical-system-name protocols mpls]

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

• Adaptive LSPs
• Automatic bandwidth allocation
• BFD for LSPs
• Graceful Routing Engine switchover
• Link and node protection
• Nonstop routing
• Optimized LSPs
• Point-to-Multipoint (P2MP) LSPs
• Soft preemption
• Standby secondary paths