Welcome! Log In Create A New Profile

Advanced

trying to understand sticky counters

Posted by Adam Spiers 
Adam Spiers
trying to understand sticky counters
April 11, 2017 07:10PM
Hi all,

I've pored over the Configuration Manual again and again, and I'm
still struggling to fully understand sticky counters. This paragraph
seems to hold some important information:

Once a "track-sc*" rule is executed, the key is looked up in the table
and if it is not found, an entry is allocated for it. Then a pointer to
that entry is kept during all the session's life, and this entry's
counters are updated as often as possible, every time the session's
counters are updated, and also systematically when the session ends.
Counters are only updated for events that happen after the tracking has
been started. As an exception, connection counters and request counters
are systematically updated so that they reflect useful
information.

It seems that one of the key concepts here is "session". I'm assuming
that this actually means "TCP session", as in layer 5 of the OSI
model; is that correct? Unfortunately there is nowhere in the manual
which explicitly states this definition, despite countless uses of the
term, but there are some hints scattered around, e.g. in the
"tcp-request session" section:

Once a session is validated, (ie. after all handshakes have been completed),

and in the "reject" part of the "tcp-request connection" section.

It seems that each session can have a maximum of three entries
associated with it in stick-tables, because there is a maximum of 3
sets of sticky counters per connection. And these entries could
potentially be in 1, 2, or 3 different stick-tables, depending on
where and how the track-scX directive is written, right?

Thirdly, I'm struggling to understand these examples:

Example: accept all connections from white-listed hosts, reject too fast
connection without counting them, and track accepted connections.
This results in connection rate being capped from abusive sources.

tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
tcp-request connection reject if { src_conn_rate gt 10 }
tcp-request connection track-sc0 src

Example: accept all connections from white-listed hosts, count all other
connections and reject too fast ones. This results in abusive ones
being blocked as long as they don't slow down.

tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
tcp-request connection track-sc0 src
tcp-request connection reject if { sc0_conn_rate gt 10 }

The stick-table directives are missing, but my experiments suggest
that not only they are mandatory, but also they must track conn_rate
samples, otherwise HAProxy has no way to know the duration of the
sliding time window which the connection rate relates to, and nothing
will get rejected. So I think the examples should include those
directives for clarity. When I added this, it worked for me:

stick-table type ip size 100k store conn_rate(30s)

Furthermore, I don't understand the explanation text which says
"without counting them". If they're not counted, how can the
connection rate be measured? So what is the real difference between
these two examples?

I'd be really grateful for any light which can be shed here. I'm
normally pretty good at inhaling large, complex technical manuals, but
I've really been struggling with HAProxy's for some reason :-/

Thanks!
Adam
Igor Cicimov
Re: trying to understand sticky counters
April 21, 2017 03:30AM
Hi Adam,

On Wed, Apr 12, 2017 at 3:00 AM, Adam Spiers <[email protected]> wrote:

> Hi all,
>
> I've pored over the Configuration Manual again and again, and I'm
> still struggling to fully understand sticky counters. This paragraph
> seems to hold some important information:
>
> Once a "track-sc*" rule is executed, the key is looked up in the table
> and if it is not found, an entry is allocated for it. Then a pointer to
> that entry is kept during all the session's life, and this entry's
> counters are updated as often as possible, every time the session's
> counters are updated, and also systematically when the session ends.
> Counters are only updated for events that happen after the tracking has
> been started. As an exception, connection counters and request counters
> are systematically updated so that they reflect useful
> information.
>
> It seems that one of the key concepts here is "session". I'm assuming
> that this actually means "TCP session", as in layer 5 of the OSI
> model; is that correct?


Just a correction here, see
https://en.wikipedia.org/wiki/Session_layer#Comparison_with_TCP.2FIP_model


> Unfortunately there is nowhere in the manual
> which explicitly states this definition, despite countless uses of the
> term, but there are some hints scattered around, e.g. in the
> "tcp-request session" section:
>
> Once a session is validated, (ie. after all handshakes have been
> completed),
>
> and in the "reject" part of the "tcp-request connection" section.
>
> It seems that each session can have a maximum of three entries
> associated with it in stick-tables, because there is a maximum of 3
> sets of sticky counters per connection. And these entries could
> potentially be in 1, 2, or 3 different stick-tables, depending on
> where and how the track-scX directive is written, right?
>
> Thirdly, I'm struggling to understand these examples:
>
> Example: accept all connections from white-listed hosts, reject too fast
> connection without counting them, and track accepted connections.
> This results in connection rate being capped from abusive
> sources.
>
> tcp-request connection accept if { src -f
> /etc/haproxy/whitelist.lst }
> tcp-request connection reject if { src_conn_rate gt 10 }
> tcp-request connection track-sc0 src
>
> Example: accept all connections from white-listed hosts, count all other
> connections and reject too fast ones. This results in abusive
> ones
> being blocked as long as they don't slow down.
>
> tcp-request connection accept if { src -f
> /etc/haproxy/whitelist.lst }
> tcp-request connection track-sc0 src
> tcp-request connection reject if { sc0_conn_rate gt 10 }
>
> The stick-table directives are missing, but my experiments suggest
> that not only they are mandatory, but also they must track conn_rate
> samples, otherwise HAProxy has no way to know the duration of the
> sliding time window which the connection rate relates to, and nothing
> will get rejected. So I think the examples should include those
> directives for clarity. When I added this, it worked for me:
>
> stick-table type ip size 100k store conn_rate(30s)
>
> Furthermore, I don't understand the explanation text which says
> "without counting them". If they're not counted, how can the
> connection rate be measured? So what is the real difference between
> these two examples?
>
> I'd be really grateful for any light which can be shed here. I'm
> normally pretty good at inhaling large, complex technical manuals, but
> I've really been struggling with HAProxy's for some reason :-/
>
> Thanks!
> Adam
>
>


--
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. igorc@encompasscorporation.com http://encompasscorporation.com/
w*.* www.encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000
Sorry, only registered users may post in this forum.

Click here to login