Support Support Downloads Knowledge Base Juniper Support Portal 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

[MX] How to decrease service impact time for VPN services while the LDP/IGP network converges

0

0

Article ID: KB37495 KB Last Updated: 30 Sep 2021Version: 1.0
Summary:

In a plain Label Distribution Protocol (LDP)/interior gateway protocol (IGP) network that does not have any advanced protection mechanisms, convergence time and extent of service impact would depend on the "muscle" power of the hardware and network scale.

In this article, you will see some ways of improving convergence time without utilizing additional protection mechanisms.

Symptoms:

Events that cause an LDP/IGP network to converge:

  • Link goes down (the path is no longer usable).

  • Link comes up (a new better path is available).

  • A metric has changed, which causes another best path to be selected.

In other words, any event that causes a given router to change its active next-hop will result in the LDP/IGP network to converge. In the case of VPN services, our interest would be in next-hops to other Provider Edge (PE) devices.

Example 1

PE1 uses interface A to reach PE2. Then a link inside the core goes down. Consequently, the network converges and PE1 starts using the path through interface B because it has a better metric now.

                             xxxxxx
┌─────┐interface A    xxxxxxx      xxxxxxx              ┌─────┐
│     ├──────────────xx                  xx             │     │
│ PE1 │              x        CORE        x─────────────┤ PE2 │
│     ├──────────────xxx                xxx             │     │
└─────┘interface B     xxxxxxxxxxxxxxxxxx               └─────┘

Example 2

The core (P) routers also go through similar events. Here, router P starts using interface Z to reach PE_X after a metric change on one of the links in the core.

      xxxxx                                  xxxxx      
 xxxxx     xxxxx ┌─────┐interface Y     xxxxx     xxxxx ┌─────┐
xx             xx│     ├───────────────xx             xx│     │
x      CORE     x│  P  │               x      CORE     x│PE_X │
xxx           xxx│     ├───────────────xxx           xxx│     │
  xxxxxxxxxxxxx  └─────┘interface Z      xxxxxxxxxxxxx  └─────┘

In both examples, transit traffic may be dropped during convergence—that is, from the time an event occurred up to the moment the last router in the path finished converging.

Solution:

There are two ways possible to improve convergence and decrease service impact time without design change in such a scenario:

  1. Keep the number of LDP routes at a minimum.

  2. Implement prefix prioritization for loopback addresses of important PEs.

 

Keep the number of LDP routes at a minimum

For VPN services, you only need to have the loopback addresses (/32) of PE routers. In most cases, non /32 prefixes do not need to be advertised into LDP. By default, Juniper routers advertise only loopback addresses, and no policies are required for that.

If such prefixes do exist, they can be filtered either on the advertising router (preferred) or on LDP import on other routers. Similarly, non /32 prefixes can be filtered by using an import policy. Refer to Filtering Inbound LDP Label Bindings for more information.

 

Implement prefix prioritization for loopback addresses of important PEs

It can be beneficial if a part of the addresses present in LDP is used for VPN services or if there is a subset of PEs, which can handle the most critical of services and requires minimal disruption.

In both cases, you can mark specific prefixes to be updated in the hardware with a priority that is higher than other less important prefixes.

Example with ISIS as IGP

Suppose that you have 1000 important loopbacks (in the 10.66.0.0/16 subnet) and 3000 not so important prefixes (in the 10.55.0.0/16 subnet).

You can check the order of processing for the prefixes in ISIS (default order, no prioritization) as follows:

user@Router1> show isis route download-priority
IS-IS routing table             Current version: L1: 9 L2: 1516
IPv4/IPv6 Routes
----------------
Prefix             L Version   Metric Type Interface       NH   Via                 Backup Score
10.11.21.0/30      2    1516      200 int  ge-0/0/0.0      IPV4 Router2
10.12.21.0/30      2    1516      300 int  ge-0/0/0.0      IPV4 Router2
10.13.21.0/30      2    1516      300 int  ge-0/0/0.0      IPV4 Router2
10.21.55.0/30      2    1516      210 int  ge-0/0/0.0      IPV4 Router2
10.55.0.0/32       2    1516      260 int  ge-0/0/0.0      IPV4 Router2
10.55.0.1/32       2    1516      260 int  ge-0/0/0.0      IPV4 Router2
10.55.0.2/32       2    1516      260 int  ge-0/0/0.0      IPV4 Router2
.....

Now in order to prioritize the important loopbacks, you can use the following configuration:

set protocols isis import PRIORITIZE
set policy-options policy-statement PRIORITIZE term IMP_LO from route-filter 10.66.0.0/16 prefix-length-range /32-/32
set policy-options policy-statement PRIORITIZE term IMP_LO then priority high
set policy-options policy-statement PRIORITIZE term IMP_LO then accept

This will put the important prefixes at the top of the list:

user@Router1> show isis route download-priority
IS-IS routing table             Current version: L1: 9 L2: 1515
IPv4/IPv6 Routes
----------------
Prefix             L Version   Metric Type Interface       NH   Via                 Backup Score
10.66.0.0/32       2    1515      260 int  ge-0/0/0.0      IPV4 Router2
10.66.0.1/32       2    1515      260 int  ge-0/0/0.0      IPV4 Router2
10.66.0.2/32       2    1515      260 int  ge-0/0/0.0      IPV4 Router2
10.66.0.3/32       2    1515      260 int  ge-0/0/0.0      IPV4 Router2
.....

To know more about prefix prioritization in RPD with OSPF as IGP, see Example: Configuring the Priority for Route Prefixes in the RPD Infrastructure.

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