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

[Junos] Using the match-all wildcard in Junos groups and applying it in a policy causes high CPU

0

0

Article ID: KB35745 KB Last Updated: 30 Apr 2020Version: 1.0
Summary:

Using the match-all wildcard <*> in Junos OS groups and applying them in the policy may lead to high RPD CPU.

This article recommends that users should plan more specific matching strings such as <foo-*> for the name elements along the configuration path under Junos OS groups than just a single match-all wildcard <*>.

 

Symptoms:

A customer has a configuration as follows:

  1. Step 1. The content of a defined group is applied at a very specific level under policy-options:

set policy-options policy-statement export-AS1234 term no-private apply-groups rfc1918
set policy-options policy-statement export-AS1234 term no-private then reject
set policy-options policy-statement export-AS5678 term specific-reject from route-filter 172.16.0.0/12 orlonger
set policy-options policy-statement export-AS5678 term specific-reject then reject
set policy-options policy-statement import-AS1234 term no-private from route-filter 172.16.0.0/12 orlonger
set policy-options policy-statement import-AS1234 term no-private then reject
  1. Step 2. The groups defined use the match-all wildcard <*> as a quick way, not considering a specific match, and just rely on the apply-group setting:

set groups rfc1918 policy-options policy-statement <*> term <*> from route-filter 10.0.0.0/8 orlonger
set groups rfc1918 policy-options policy-statement <*> term <*> from route-filter 192.168.0.0/16 orlonger

When this configuration change is committed, RPD CPU utilization is high and it takes several minutes or longer to finish the commit procedure.

 

Cause:

Use # show policy-options | display xml | display changed | display mark-changed to check the differences in the flag junos:changed after you change the contents of a group but before you commit.

In the following example, even though the other two policies do not have the apply-group configuration, the flag is marked as changed. In some rare situations, if the import policy is flagged as changed, it may trigger the RPD to re-calculate a few million BGP routes that are inbound.

[edit]
user@MX80-1# show groups rfc1918
policy-options {
    policy-statement <*> {
        term <*> {
            from {
                route-filter 10.0.0.0/8 orlonger;
            }
        }
    }
}

[edit]
user@MX80-1# show policy-options
policy-statement export-AS1234 {
    term no-private {
        apply-groups rfc1918;
        then reject;
    }
}
policy-statement export-AS5678 {
    term specific-reject {
        from {
            route-filter 172.16.0.0/12 orlonger;
        }
        then reject;
    }
}
policy-statement import-AS1234 {
    term no-private {
        from {
            route-filter 172.16.0.0/12 orlonger;
        }
        then reject;
    }
}

[edit]
user@MX80-1# top show | compare
[edit groups rfc1918 policy-options policy-statement <*> term <*> from]
        route-filter 10.0.0.0/8 orlonger { ... }
+       route-filter 192.168.0.0/16 orlonger;

[edit]
user@MX80-1# top show policy-options | display xml | display changed | display mark-changed   
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.3R1/junos">
    <configuration junos:changed-seconds="1587111772" junos:changed-localtime="2020-04-17 01:22:52 PDT" junos:changed="changed">
            <policy-options junos:changed="changed">
                <snip>
                <policy-statement junos:changed="changed">
                    <name>export-AS5678</name>
                    <term junos:changed="changed">    <<<<<no 'apply-group' policy also has flag 'changed.'
                <snip>
                    </term>
                </policy-statement>
                <policy-statement junos:changed="changed">   <<<<no 'apply-group' policy also has flag 'changed.'
                    <name>import-AS1234</name>
                <snip>

The match-all wildcard in the group makes the device traverse through all the configuration paths at the root level (meaning not sit inside the groups) and mark the flag as changed on each element along the path it traverses, and then works on the content inheritance linkage where the corresponding apply-group is used.

The action of marking flags is not dependent on the level at which the apply-group is set. As a consequence, all the elements along the path will be flagged as changed as long as it breaks down in the same manner as described in the groups. This might have unnecessary influence on other Junos OS processes that interlock with the changed flags regardless of whether the actual inherited contents changed or not.

The way Junos OS parses configuration from the root level when the match-all wildcard is used is intentionally designed to tackle various configuration scaling considerations.

 

Solution:

It is seen that if wildcard groups are applied at the root level, then there are no problems. Non wild-card groups applied at any level were also seen to be working fine.

Therefore, the recommendation is to plan your configuration with a proper prefix or suffix when using the match-all wildcard <*> with Junos OS groups.

In the above example, adding meaningful and specific prefix strings to the match-all <*> wildcard in the group can greatly narrow the scope of "changed" in configuration hierarchies.

set groups rfc1918 policy-options policy-statement <export*> term <no-*> from route-filter 10.0.0.0/8 orlonger
set groups rfc1918 policy-options policy-statement <export*> term <no-*> from route-filter 192.168.0.0/16 orlonger

 

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