Perhaps it has something to do with Citrix being a dinosaur.
God forbid the powers that be choose on premise unix.
Regards
Patrick
> On Jun 4, 2021, at 6:43 AM, Stuart Henderson <stu@spacehopper.org> wrote:
>
> On 2021/06/03 15:04, Chris Cappuccio wrote:
>> Stuart Henderson [stu@spacehopper.org] wrote:
>>>
>>> Oh watch out with sloppy. Keep an eye on your state table size.
>>
>> Really? Wouldn't sloppy keep the state table smaller if anything since it's tracking less specifically?
>>
>> Anyways I use sloppy across four boxes that run in parallel with pfsync. There could easily be 10,000 devices behind it at any given time. I keep my state table limit at 1,000,000. It's around 300,000 during this lighter traffic period today. I had to do sloppy after moving to several boxes in parallel, I didn't notice sloppy making any significant difference?
>>
>> Chris
>
> The problem I had was in conjunction with synfloods. I didn't get
> captures for everything to figure it out (it was in 2018 and my
> network was in flames, with the full state table bgp sessions were
> getting dropped / not reestablishing) but I think what happened was
> this,
>
> spoofed SYN to real server behind PF
> SYN+ACK from server
>
> and the state entry ended up as ESTABLISHED:ESTABLISHED where it
> remained until the tcp.established timer expired (24h default
> or 5h with "set optimization aggressive").
>
> My "fix" was to move as much as possible to "pass XX flags any no state"
> but that's clearly not going to help with what Denis would like to do.
> (fwiw - I'm not doing flow monitoring regularly, but when I do it's
> usually via sflow on switches instead, which solves some problems,
> though it's only possible in some situations).
>
No comments:
Post a Comment