How are "Limit" objects enforced on gateway?

[rogerp]

Hi!
We're testing out Limit objects to set a maximum bandwidth for traffic that hits a certain rule. Seems to be working.
We do NOT have the QoS blade enabled.
How is the traffic shaped on the security gateway? Is QoS used although the blade is disabled?
If we hit the maximum bandwidth - what can we expect? Packets discarded (leading to TCP retransmissions)? Increased latency due to queuing?

Perhaps someone can share some knowledge on this topic.

[PhoneBoy · Accepted solution]

Limit Objects are done as part of App Control and don't rely on the QoS blade at all.
It appears from this thread we drop packets that exceed the threshold:
https://community.checkpoint.com/t5/Management/How-to-monitor-bandwidth-limit-for-application-contro... 

[rogerp]

Thanks!

[the_rock · Accepted solution]

Phoneboy is 100% right. By the way, for what is worth, here is solid AI answer as well you can refer to.

*********************

✅ How Limit Objects Are Enforced on a Gateway (No QoS Blade Enabled)

Limit objects do not use the QoS blade, even though they look like bandwidth-control features.

Instead, they are enforced by the SecureXL/f2f path using kernel rate-limiting mechanisms in the Access Control rulebase. When a connection is matched to a Limit object, the gateway applies token-bucket style policing to that connection or rule flow.

This is similar to Linux tc policing, not shaping.

---

🚦 Important Distinction: Policing vs Shaping

Limit objects perform rate policing, not shaping.

✔ Policing

• Discards packets when the rate exceeds the limit

• Does not create queues

• Does not smooth traffic

• Causes TCP retransmissions or slower throughput

✘ Shaping (which QoS would do)

• Uses queues

• Adds latency to smooth traffic to a configured rate

• No packet loss unless queue overflows

Because QoS is not enabled, you get policing only, not shaping.

---

📌 What Happens When You Hit the Limit?

🔹 1. Packets are dropped

This is the primary behaviour.

For TCP:

• You will see retransmissions

• Throughput will oscillate around the configured limit

For UDP:

• Excess packets simply disappear

• No retransmission, so you may see visible degradation

🔹 2. "Shaping" does not occur

No queues are created specifically for the Limit object.
You may see small internal buffers, but the intent is not to delay.

🔹 3. Latency generally does not increase

Except:

• When TCP backs off (which looks like latency)

• When buffers momentarily fill before dropping

The gateway itself is not delaying packets on purpose.

---

✔ Summary Table

Feature	Limit Object	QoS Blade
Requires QoS blade	❌ No	✔ Yes
Enforcement method	Kernel policing	Queuing and shaping
Excess traffic	Dropped	Buffered/Queued
Causes TCP retransmissions	✔ Yes	Maybe, if queues overflow
Increases latency	❌ No intentional latency	✔ Yes (shaping adds delay)
Smooth bandwidth	❌ No	✔ Yes

---

🧪 What You Can Expect in Real Testing

If you test with iperf3 at a rate above your configured limit:

• TCP throughput = will plateau at the limit

• Retransmissions will appear in iperf3 output

• No noticeable latency increase on ping unless the CPU becomes busy

• SecureXL stats will show your rule hitting the limit

You will not see QoS tables or shaping queues because the QoS blade is not involved.

---

If you want actual shaping instead of policing

You must enable the QoS Blade and define shaping rules.
This is the only way to get:

• prioritization

• traffic smoothing

• real guaranteed bandwidth

• no packet drops during normal operation

[rogerp]

Thanks! Great clarification!