Re: Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

Hi Baptiste,

Thank you for the help. What is the proper syntax for referencing the table
in the if clause? I've tried these variations but HAProxy doesn't like any
of them:

tcp-request connection reject if { src_conn_cur ge 100 } table ip_map_table
tcp-request connection reject if { table ip_map_table src_conn_cur ge 100 }
tcp-request connection reject if { src_conn_cur table ip_map_table ge 100 }

Thank you!

On Fri, Oct 2, 2015 at 5:23 AM, Baptiste  wrote:

> You can create "dummy" backends, whose main purpose will to host a table
> only.
> IE:
> backend tbl_ip
>  stick-table type ip size 10k
> backend tbl_hdr
>  stick-table type string len 12 size 10k
>
> and refer them in your rules:
> stick on src table tbl_ip
> tcp-request content track-sc1 hdr(x-app-authorization) table tbl_hdr
>
> Baptiste
>
>
>
> On Thu, Oct 1, 2015 at 10:24 AM, Igor Cicimov <
> ig...@encompasscorporation.com> wrote:
>
>> What version are you running? From memory up to 1.5.x you can have only
>> one table per fe/be, not sure about 1.6 I haven't tried it yet. I've seen
>> people using second table via dummy backend though. I don't have access to
>> my notes atm so maybe someone else can jump in and help with this.
>> On 01/10/2015 2:22 PM, "Jason J. W. Williams" 
>> wrote:
>>
>>> I still would like to keep the rate limiting based on source ip but the
>>> persistence based on header.
>>>
>>> My thought was to create a second named stick table but I didn't see a
>>> name parameter to the stick-table declaration.
>>>
>>> Sent via iPhone
>>>
>>> On Sep 30, 2015, at 18:23, Igor Cicimov 
>>> wrote:
>>>
>>> Well in case of header you would have something like this I guess:
>>>
>>> tcp-request content track-sc1 hdr(x-app-authorization)
>>>
>>>
>>>
>>> On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams <
>>> jasonjwwilli...@gmail.com> wrote:
>>>
 Wondered about that... Do the "tcp-request" rate limiters use the stick
 table (I assume they need type ip) or another implied table?

 -J

 On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
 ig...@encompasscorporation.com> wrote:

> The stick-table type would be string and not ip in that case though
>
> On 01/10/2015 5:07 AM, "Jason J. W. Williams" <
> jasonjwwilli...@gmail.com> wrote:
> >
> > We've been seeing CenturyLink and a few other residential providers
> NATing their IPv4 traffic, making client persistency on source IP result 
> in
> really lopsided load balancing lately.
> >
> > We'd like to convert to sticking on a custom header we're already
> using that IDs the user. There isn't a lot of examples of this, so I was
> curious if this is the right approach:
> >
> > Previous "stick on src" config:
> https://gist.github.com/williamsjj/7c3876d32cab627ffe70
> >
> > New "stick on header" config:
> https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
> >
> > Thank you in advance for any advice.
> >
> > -J
>
> The stick-table type would be string and not ip in that case though
>


>>>
>>>
>>> --
>>> Igor Cicimov | DevOps
>>>
>>>
>>> p. +61 (0) 433 078 728
>>> e. ig...@encompasscorporation.com 
>>> w*.* encompasscorporation.com
>>> a. Level 4, 65 York Street, Sydney 2000
>>>
>>>
>

Re: Converting from sticking on src-ip to custom auth header

[Baptiste]

You can create "dummy" backends, whose main purpose will to host a table
only.
IE:
backend tbl_ip
 stick-table type ip size 10k
backend tbl_hdr
 stick-table type string len 12 size 10k

and refer them in your rules:
stick on src table tbl_ip
tcp-request content track-sc1 hdr(x-app-authorization) table tbl_hdr

Baptiste



On Thu, Oct 1, 2015 at 10:24 AM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

> What version are you running? From memory up to 1.5.x you can have only
> one table per fe/be, not sure about 1.6 I haven't tried it yet. I've seen
> people using second table via dummy backend though. I don't have access to
> my notes atm so maybe someone else can jump in and help with this.
> On 01/10/2015 2:22 PM, "Jason J. W. Williams" 
> wrote:
>
>> I still would like to keep the rate limiting based on source ip but the
>> persistence based on header.
>>
>> My thought was to create a second named stick table but I didn't see a
>> name parameter to the stick-table declaration.
>>
>> Sent via iPhone
>>
>> On Sep 30, 2015, at 18:23, Igor Cicimov 
>> wrote:
>>
>> Well in case of header you would have something like this I guess:
>>
>> tcp-request content track-sc1 hdr(x-app-authorization)
>>
>>
>>
>> On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams <
>> jasonjwwilli...@gmail.com> wrote:
>>
>>> Wondered about that... Do the "tcp-request" rate limiters use the stick
>>> table (I assume they need type ip) or another implied table?
>>>
>>> -J
>>>
>>> On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
>>> ig...@encompasscorporation.com> wrote:
>>>
 The stick-table type would be string and not ip in that case though

 On 01/10/2015 5:07 AM, "Jason J. W. Williams" <
 jasonjwwilli...@gmail.com> wrote:
 >
 > We've been seeing CenturyLink and a few other residential providers
 NATing their IPv4 traffic, making client persistency on source IP result in
 really lopsided load balancing lately.
 >
 > We'd like to convert to sticking on a custom header we're already
 using that IDs the user. There isn't a lot of examples of this, so I was
 curious if this is the right approach:
 >
 > Previous "stick on src" config:
 https://gist.github.com/williamsjj/7c3876d32cab627ffe70
 >
 > New "stick on header" config:
 https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
 >
 > Thank you in advance for any advice.
 >
 > -J

 The stick-table type would be string and not ip in that case though

>>>
>>>
>>
>>
>> --
>> Igor Cicimov | DevOps
>>
>>
>> p. +61 (0) 433 078 728
>> e. ig...@encompasscorporation.com 
>> w*.* encompasscorporation.com
>> a. Level 4, 65 York Street, Sydney 2000
>>
>>

Re: Converting from sticking on src-ip to custom auth header

[Igor Cicimov]

What version are you running? From memory up to 1.5.x you can have only one
table per fe/be, not sure about 1.6 I haven't tried it yet. I've seen
people using second table via dummy backend though. I don't have access to
my notes atm so maybe someone else can jump in and help with this.
On 01/10/2015 2:22 PM, "Jason J. W. Williams" 
wrote:

> I still would like to keep the rate limiting based on source ip but the
> persistence based on header.
>
> My thought was to create a second named stick table but I didn't see a
> name parameter to the stick-table declaration.
>
> Sent via iPhone
>
> On Sep 30, 2015, at 18:23, Igor Cicimov 
> wrote:
>
> Well in case of header you would have something like this I guess:
>
> tcp-request content track-sc1 hdr(x-app-authorization)
>
>
>
> On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams <
> jasonjwwilli...@gmail.com> wrote:
>
>> Wondered about that... Do the "tcp-request" rate limiters use the stick
>> table (I assume they need type ip) or another implied table?
>>
>> -J
>>
>> On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
>> ig...@encompasscorporation.com> wrote:
>>
>>> The stick-table type would be string and not ip in that case though
>>>
>>> On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
>>> wrote:
>>> >
>>> > We've been seeing CenturyLink and a few other residential providers
>>> NATing their IPv4 traffic, making client persistency on source IP result in
>>> really lopsided load balancing lately.
>>> >
>>> > We'd like to convert to sticking on a custom header we're already
>>> using that IDs the user. There isn't a lot of examples of this, so I was
>>> curious if this is the right approach:
>>> >
>>> > Previous "stick on src" config:
>>> https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>>> >
>>> > New "stick on header" config:
>>> https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>>> >
>>> > Thank you in advance for any advice.
>>> >
>>> > -J
>>>
>>> The stick-table type would be string and not ip in that case though
>>>
>>
>>
>
>
> --
> Igor Cicimov | DevOps
>
>
> p. +61 (0) 433 078 728
> e. ig...@encompasscorporation.com 
> w*.* encompasscorporation.com
> a. Level 4, 65 York Street, Sydney 2000
>
>

Re: Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

I still would like to keep the rate limiting based on source ip but the 
persistence based on header. 

My thought was to create a second named stick table but I didn't see a name 
parameter to the stick-table declaration. 

Sent via iPhone

> On Sep 30, 2015, at 18:23, Igor Cicimov  
> wrote:
> 
> Well in case of header you would have something like this I guess:
> 
> tcp-request content track-sc1 hdr(x-app-authorization)
> 
> 
> 
>> On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams 
>>  wrote:
>> Wondered about that... Do the "tcp-request" rate limiters use the stick 
>> table (I assume they need type ip) or another implied table?
>> 
>> -J
>> 
>>> On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov 
>>>  wrote:
>>> The stick-table type would be string and not ip in that case though
>>> 
>>> 
>>> On 01/10/2015 5:07 AM, "Jason J. W. Williams"  
>>> wrote:
>>> >
>>> > We've been seeing CenturyLink and a few other residential providers 
>>> > NATing their IPv4 traffic, making client persistency on source IP result 
>>> > in really lopsided load balancing lately.
>>> >
>>> > We'd like to convert to sticking on a custom header we're already using 
>>> > that IDs the user. There isn't a lot of examples of this, so I was 
>>> > curious if this is the right approach:
>>> >
>>> > Previous "stick on src" config: 
>>> > https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>>> >
>>> > New "stick on header" config: 
>>> > https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>>> >
>>> > Thank you in advance for any advice.
>>> >
>>> > -J
>>> The stick-table type would be string and not ip in that case though
>>> 
> 
> 
> 
> -- 
> Igor Cicimov | DevOps
> 
> 
> 
> p. +61 (0) 433 078 728
> e. ig...@encompasscorporation.com
> w. encompasscorporation.com
> a. Level 4, 65 York Street, Sydney 2000

Re: Converting from sticking on src-ip to custom auth header

[Igor Cicimov]

Well in case of header you would have something like this I guess:

tcp-request content track-sc1 hdr(x-app-authorization)



On Thu, Oct 1, 2015 at 9:47 AM, Jason J. W. Williams <
jasonjwwilli...@gmail.com> wrote:

> Wondered about that... Do the "tcp-request" rate limiters use the stick
> table (I assume they need type ip) or another implied table?
>
> -J
>
> On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
> ig...@encompasscorporation.com> wrote:
>
>> The stick-table type would be string and not ip in that case though
>>
>> On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
>> wrote:
>> >
>> > We've been seeing CenturyLink and a few other residential providers
>> NATing their IPv4 traffic, making client persistency on source IP result in
>> really lopsided load balancing lately.
>> >
>> > We'd like to convert to sticking on a custom header we're already using
>> that IDs the user. There isn't a lot of examples of this, so I was curious
>> if this is the right approach:
>> >
>> > Previous "stick on src" config:
>> https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>> >
>> > New "stick on header" config:
>> https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>> >
>> > Thank you in advance for any advice.
>> >
>> > -J
>>
>> The stick-table type would be string and not ip in that case though
>>
>
>


-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000

Re: Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

Wondered about that... Do the "tcp-request" rate limiters use the stick
table (I assume they need type ip) or another implied table?

-J

On Wed, Sep 30, 2015 at 3:41 PM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

> The stick-table type would be string and not ip in that case though
>
> On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
> wrote:
> >
> > We've been seeing CenturyLink and a few other residential providers
> NATing their IPv4 traffic, making client persistency on source IP result in
> really lopsided load balancing lately.
> >
> > We'd like to convert to sticking on a custom header we're already using
> that IDs the user. There isn't a lot of examples of this, so I was curious
> if this is the right approach:
> >
> > Previous "stick on src" config:
> https://gist.github.com/williamsjj/7c3876d32cab627ffe70
> >
> > New "stick on header" config:
> https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
> >
> > Thank you in advance for any advice.
> >
> > -J
>
> The stick-table type would be string and not ip in that case though
>

Re: Converting from sticking on src-ip to custom auth header

[Igor Cicimov]

The stick-table type would be string and not ip in that case though
On 01/10/2015 5:07 AM, "Jason J. W. Williams" 
wrote:
>
> We've been seeing CenturyLink and a few other residential providers
NATing their IPv4 traffic, making client persistency on source IP result in
really lopsided load balancing lately.
>
> We'd like to convert to sticking on a custom header we're already using
that IDs the user. There isn't a lot of examples of this, so I was curious
if this is the right approach:
>
> Previous "stick on src" config:
https://gist.github.com/williamsjj/7c3876d32cab627ffe70
>
> New "stick on header" config:
https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906
>
> Thank you in advance for any advice.
>
> -J

The stick-table type would be string and not ip in that case though

Converting from sticking on src-ip to custom auth header

[Jason J. W. Williams]

We've been seeing CenturyLink and a few other residential providers NATing
their IPv4 traffic, making client persistency on source IP result in really
lopsided load balancing lately.

We'd like to convert to sticking on a custom header we're already using
that IDs the user. There isn't a lot of examples of this, so I was curious
if this is the right approach:

Previous "stick on src" config:
https://gist.github.com/williamsjj/7c3876d32cab627ffe70

New "stick on header" config:
https://gist.github.com/williamsjj/f0ddc58b9d028b3fb906

Thank you in advance for any advice.

-J