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

[ScreenOS] CPU goes high when address groups are modified

0

0

Article ID: KB26229 KB Last Updated: 07 Dec 2012Version: 1.0
Summary:
This article describes the issue of CPU usage being high, when existing address groups, which are used in a policy, are appended.
Symptoms:
A test-group is created and three addresses are added to it:
set group address "Trust" "test-group"
set group address "Trust" "test-group" add "172.18.72.72/32"
set group address "Trust" "test-group" add "172.18.66.141/32"
set group address "Trust" "test-group" add "172.18.175.10/32"
A policy that uses the above address group is created:
set policy id 1576 from "Trust" to "Untrust" "test-group" "Any" "ANY" permit log
set policy id 1576
exit
A new address book entry is created:
firewall-> set address trust "172.19.71.17/32" 172.19.71.17/32
This is now added to the existing test-group:
firewall-> set policy id 1576
firewall(policy:1576)-> set src-address "172.19.71.17/32"
firewall(policy:1576)-> exit
firewall->
firewall-> get perf cpu all detail
59: 2( 1 1) 58: 2( 1 1) 57: 2( 1 1) 56: 71( 0 81)**
55: 2( 1 1) 54: 2( 1 1) 53: 2( 1 1) 52: 2( 1 1)
The CPU does not spike when:

  • The address book is directly added to the policy.

  • The address book is added to a address group that is not used in any policy.

How can this behavior be explained?
Cause:
When snapshots are captured for task CPU (for more information, refer to KB12143 - How to trigger the CPU snapshot tool when a high CPU spike occurs by using the alarm threshold), it is observed that rs_install spikes:

Snapshot of task run time:
time slot
Task Name       -2  -1     0  1    2
-------------------------------------
( 57)rs_install 0   0   891   448  0
( 4)1s stimer   4   5     4   4    5
( 62)hdio       1   2     4   2    1
( 58)acl_ager   3   2     3   3    2
get os task, the output of which was captured before and after the activity, also shows an increase in Scheduled, Run Time, and Lock Latency.
Solution:
This is expected behavior. From 6.2 onwards, Software rule search (SWRS) is the default rule search method being performed on the CPU. The compilation of the rule list is performed by the rs_install task, which consumes high CPU. For more information on SWRS and HWRS on high-end platforms, refer to KB12695 - Hardware Rule Search (RMS) and Software Rule Search (SWRS) on High-end Firewall Platforms.

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