Introduce exclude cidrs list from rate-limiting feature#948
Introduce exclude cidrs list from rate-limiting feature#948Mrizwanshaik wants to merge 2 commits into
Conversation
cf-foundation-community-automation
Bot
moved this to Inbox
in Application Runtime Platform Working Group
Mrizwanshaik
force-pushed
the
add-nat-exclusion-list
branch
from
53c4f07 to
cd81126
Compare
| expect(frontend_https).to include('acl rate_limit_exclude src -f /var/vcap/jobs/haproxy/config/rate_limit_exclusion_cidrs.txt') | ||
| end | ||
|
|
||
| it 'still tracks excluded sources in the stick-table' do |
There was a problem hiding this comment.
This test does not check whether the excluded sources are in the stick-table, but only whether the line is included in the config.
|
|
||
| # Connections rate-limit exclusion: sources matching exclude_cidrs are tracked but never rejected | ||
| conn_rate_limit_exclude = "" | ||
| if_p("ha_proxy.connections_rate_limit.exclude_cidrs") do |
There was a problem hiding this comment.
I am thinking whether it is simpler to always have a default empty array and get rid of if exclude_cidrs are set.
If the array remains empty, there are no CIDRS to exclude from rejection.
github-project-automation
Bot
moved this from Inbox
to Pending Merge | Prioritized
in Application Runtime Platform Working Group
| tcp-request <%= tcp_request_phase %> track-sc0 src table st_tcp_conn_rate | ||
| # use sub() converter as variable references are only accepted as arguments to converters | ||
| tcp-request <%= tcp_request_phase %> reject if { var(proc.connections_rate_limit_block) -m bool } { var(proc.connections_rate_limit_connections) -m int gt 0 } { sc_conn_rate(0),sub(proc.connections_rate_limit_connections) gt 0 } | ||
| tcp-request <%= tcp_request_phase %> reject if { var(proc.connections_rate_limit_block) -m bool } { var(proc.connections_rate_limit_connections) -m int gt 0 } { sc_conn_rate(0),sub(proc.connections_rate_limit_connections) gt 0 }<%= conn_rate_limit_exclude %> |
There was a problem hiding this comment.
We should find out if the order of the conditions here makes a difference.
We know that >50% of the ingress traffic is landscape-internal and therefore would be matched by the exclusion list.
If we move the exclusion list to the front to be the first checked condition, will it skip the stick table fetches (which could be more expensive? If not, we need to keep this order)
3 participants
Adds an optional
ha_proxy.connections_rate_limit.exclude_cidrsproperty that exempts specific source ranges (e.g. internal/NAT ranges, health checkers,trusted peers) from connection-based rate limiting.Excluded sources are still tracked in the
st_tcp_conn_ratestick-table (so they remain visible viashow table st_tcp_conn_rate), but are never rejected, regardless of the configured threshold or the runtimeblocksetting.