156-581 · Question #58
The customer is using Check Point appliances that were configured long ago by third-party administrators. Current policy includes different enabled IPS protections and Bypass Under Load function…
The correct answer is A. The kernel parameter ids_assume_stress is set to 1. ids_assume_stress, 1 = IDS mechanism assumes that the Security Gateway is under stress, regardless of the actual utilization of CPU and memory. https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails =&solutionid=sk62848
Question
The customer is using Check Point appliances that were configured long ago by third-party administrators. Current policy includes different enabled IPS protections and Bypass Under Load function. Bypass Under Load is configured to disable IPS inspections if CPU and Memory usage is higher than 80%. The Customer reports that IPS protections are not working at all regardless of CPU and Memory usage. What is a possible reason of such behavior?
Options
- AThe kernel parameter ids_assume_stress is set to 1
- BThe kernel parameter ids_tolerance_stress is set to 10
- CThe kernel parameter ids_tolerance_no_stress is set to 10
- DThe kernel parameter ids_assume_stress is set to 0
How the community answered
(66 responses)- A71% (47)
- B18% (12)
- C8% (5)
- D3% (2)
Explanation
ids_assume_stress, 1 = IDS mechanism assumes that the Security Gateway is under stress, regardless of the actual utilization of CPU and memory. https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails =&solutionid=sk62848
Topics
Community Discussion
5
Lena V.Feb 15, 2026The correct answer is A. The kernel parameter ids_assume_stress, when set to 1, forces the gateway to permanently behave as if it is under stress, meaning IPS inspection is bypassed continuously regardless of actual CPU and memory utilization. This is exactly the kind of hidden legacy configuration a third-party admin might have set and never documented, and it would explain why Bypass Under Load appears to be "always on" even when resources are well within the 80% threshold. Options B and C involve tolerance parameters that tune sensitivity thresholds but do not force a constant stress state, and D (ids_assume_stress set to 0) is the normal default that tells the gateway to rely on actual load metrics, so that would not cause the behavior described.
Amara A.Feb 16, 2026Solid catch on ids_assume_stress, though worth flagging that before chasing kernel parameters you should verify the IPS bypass setting in the Threat Prevention profile itself, since a profile-level "Bypass under load" checkbox left enabled by whoever built the policy will produce the exact same symptom and is far easier to overlook in SmartConsole than a sysctl value buried in the OS.
Wesley A.Feb 3, 2026I went with C on this one and I feel solid about it. The ids_tolerance_no_stress parameter controls how many packets are sampled for inspection when the system is NOT under stress, so if some third-party admin cranked that down to 10, the gateway is basically skipping inspection on almost everything even when CPU and memory are perfectly fine. That directly explains why IPS protections appear dead regardless of load conditions, because the tolerance threshold is so low the engine is treating normal traffic as if it barely needs to look at it. The Bypass Under Load setting at 80% becomes irrelevant when this parameter is already starving the inspection engine of packets to process before any stress condition even kicks in.
Amara A.Feb 4, 2026Took 156-581 back when I was still managing a mixed R81 and R80.40 estate, and I hit this exact gotcha on the real exam, almost bubbled C because the "no stress" wording threw me off. The trick is that ids_assume_stress set to 1 tells the kernel to permanently pretend the gateway is under load, so IPS drops into bypass mode constantly, no CPU or memory threshold required, making Bypass Under Load appear broken when it is actually working exactly as instructed.
Anastasia B.Feb 11, 2026Going with D on this one because ids_assume_stress set to 0 tells the gateway to never assume stress, which on certain code versions actually causes the IPS engine to skip inspections entirely rather than following the Bypass Under Load threshold, and that would explain why protections are dead regardless of CPU and memory readings. The third-party admins probably touched that parameter without documenting it, and since it sits outside the SmartConsole policy it would survive every policy install the current team has done since taking over.