Traffic Shaping issue

Help!
1

Hello

I try to setup shared bandwidth limitation. My objective is to setup a limit per IP. I started with this blog post as example and here is my configuration:

frontend <> 
[...]
	filter bwlim-out limit_by_src limit 50M key src table st_src_bw  # 50MB/s per IP
	# Disable per IP bw limitation because of monitoring issues
	http-response set-bandwidth-limit limit_by_src

backend st_src_bw
	stick-table type ipv6 size 1m expire 3600s store bytes_out_rate(1s)

But as side effect I’ve got issues with monitoring, the check got timeouts:

image
image739×209 21.6 KB

Try to guess when I disabled this filter :wink:

I also setup a stream limit at 10MB/s, which it still enabled, whithout effect on monitoring.

The monitoring check is juste a single page HTTP GET, so no reason that it could reach 50MB/s.

Is there a way to log when BW limitation is applied?
Is there other way to setup this shared limit?

Thanks

2

Any ideas?

Did someone already set up this kind of feature?

3

That should work and not block your monitoring unless you mean that it’s disrupting monitor traffic from another system? I have this configuration

frontend fe_port_81
  mode http
  bind *:81
  log global
  option httplog
  filter bwlim-out limit_by_src limit 10K key src table be_app
  default_backend be_app
  http-response set-bandwidth-limit limit_by_src

backend be_app
  mode http
  option httpchk GET /
  log global
  timeout server 25s
  default-server inter 3s rise 2 fall 3
  stick-table type ip size 1m expire 3600s store bytes_out_rate(1s)
  server app2 12.1.1.3:80 maxconn 1000 weight 10 check

I didn’t see any timeouts or issues with monitoring during that at all. Can you show me the full front end and back end configuration when you get the issues?

You can view the table like this:

echo "show table be_app" | socat stdio /var/run/hapee-2.8/hapee-lb.sock
# table: be_app, type: ip, size:1048576, used:1
0x55a3dbbc53b0: key=172.19.121.235 use=0 exp=3400858 shard=0 bytes_out_rate(1000)=0
4

He is more detailled configuration:

frontend front_all_https
	bind :443 tfo ssl crt /etc/ssl/private/haproxy/<certname1> crt /etc/ssl/private/haproxy/<certname2> alpn h2,http/1.1
	mode http
	option http-keep-alive
	option forwardfor

	# --------------------------------------------
	# Path ACLs
	# --------------------------------------------
	acl path_admin path_beg /<path_admin1>
	acl path_admin path_beg /<path_admin2>

	acl path_public path_beg /<publicpath1>

	acl path_downloads path_beg /<downloadpath1>
	acl path_downloads path_beg /<downloadpath2>
	acl path_downloads path_beg /<downloadpath3>

	acl path_status path /status.php



	# Note: disabled for now, as it can break the streaming of videos in mobile apps
	#http-request tarpit deny_status 403 if path_direct_link

	# --------------------------------------------
	# Rate limiting (max 1000 req per 10s per IP)
	# --------------------------------------------
	http-request track-sc0 src table st_src_http_rate
	http-request deny deny_status 429 if { src,table_http_req_rate(st_src_http_rate) gt 1000 } !is_src_whitelist

	# --------------------------------------------
	# Traffic Shaping per stream
	# --------------------------------------------
	filter bwlim-out global_download default-limit 10m default-period 1s # 10MB/s per stream
	http-request set-bandwidth-limit global_download limit 10M period 1s if path_downloads   # 10MB/s per stream
	http-request set-bandwidth-limit global_download limit 5M period 1s if path_public # 5MB/s  per stream

	# --------------------------------------------
	# Traffic Shaping per source IP
	# --------------------------------------------
	filter bwlim-out limit_by_src limit 50M key src table st_src_bw # 50MB/s per IP
	http-response set-bandwidth-limit limit_by_src
[...]

backend st_src_bw
	stick-table type ipv6 size 1m expire 3600s store bytes_out_rate(1s)

backend st_src_http_rate
	stick-table type ipv6 size 100k expire 30s store http_req_rate(10s)

 echo "show table st_src_bw" | sudo -u haproxy socat stdio unix-connect:/var/run/haproxy/admin.sock 
# table: st_src_bw, type: ipv6, size:1048576, used:1
0x7fe2f00877d0: key=::ffff:<redactedIP1> use=0 exp=3587424 shard=0 bytes_out_rate(1000)=0

The difference is that the table is defined in another backend, don’t know if it can change anything

5

I’ve tested using two different backends and it’s not impacting monitors regardless of how much I throw at it. However, are you talking about using monitors directly to the servers using the configuration on the backend? Or are you sending monitor traffic from another service and having it traverse the load balancer?

As you can see in the table output your monitor IP shouldn’t even be listed or tracked so no shaping would apply.

If you want to re-enable the configuration that was causing issues and then run a tcpdump and check the logs it might give you more clues.