On Wed, Mar 15, 2017 at 05:06:58PM -0700, Eric Dumazet wrote:
>
> Nat are good, Nat are good.
>
> I can't find this hilarious video we watched in Copenhagen ;)
>
Maybe 'Oops, I did it: IPv6 NAT by Patrick McHardy'[0]. Starts around
19:10.
[0]: http://video.dkuug.dk/media/oops-i-did-it-ipv6-nat-
On 03/16/2017 04:40 PM, Neal Cardwell wrote:
I currently wonder: What it the correct advise to an operator who needs
to run one server instance that is meant to accept thousands of new,
short-lived TCP connections per minute?
Note that for this to be a problem there would have to be thousands o
Hi Neal,
On Thu, Mar 16, 2017 at 11:40:52AM -0400, Neal Cardwell wrote:
> On Thu, Mar 16, 2017 at 7:31 AM, Lutz Vieweg wrote:
> >
> > On 03/15/2017 11:55 PM, Willy Tarreau wrote:
> >>
> >> At least I can say I've seen many people enable it without understanding
> >> its impact, confusing it
> >>
On Thu, Mar 16, 2017 at 7:31 AM, Lutz Vieweg wrote:
>
> On 03/15/2017 11:55 PM, Willy Tarreau wrote:
>>
>> At least I can say I've seen many people enable it without understanding its
>> impact, confusing it
>> with tcp_tw_reuse, and copy-pasting it from random blogs and complaining
>> about iss
On 03/15/2017 11:55 PM, Willy Tarreau wrote:
At least I can say I've seen many people enable it without understanding its
impact, confusing it
with tcp_tw_reuse, and copy-pasting it from random blogs and complaining about
issues in
production.
I currently wonder: What it the correct advise to
On Wed, 2017-03-15 at 16:45 -0700, David Miller wrote:
> Ok, I guess we can remove it in that case. I'm still a bit disappointed
> as I was always hoping someone would find a way to make this work even
> in the presence of NAT.
Nat are good, Nat are good.
I can't find this hilarious video we wa
From: Florian Westphal
Date: Wed, 15 Mar 2017 23:57:26 +0100
> AFAIU we only have two alternatives, removal of the randomization feature
> or switch to a offset computed via hash(saddr, daddr, secret).
>
> Unless there are more comments I'll look into doing the latter tomorrow.
No, I'll apply t
From: Eric Dumazet
Date: Wed, 15 Mar 2017 15:59:01 -0700
> On Wed, 2017-03-15 at 15:40 -0700, David Miller wrote:
>> From: Soheil Hassas Yeganeh
>> Date: Wed, 15 Mar 2017 16:30:45 -0400
>>
>> > Note that this cache was already broken for caching timestamps of
>> > multiple machines behind a NAT
On Wed, 2017-03-15 at 15:40 -0700, David Miller wrote:
> From: Soheil Hassas Yeganeh
> Date: Wed, 15 Mar 2017 16:30:45 -0400
>
> > Note that this cache was already broken for caching timestamps of
> > multiple machines behind a NAT sharing the same address.
>
> That's the documented, well establ
David Miller wrote:
> From: Soheil Hassas Yeganeh
> Date: Wed, 15 Mar 2017 16:30:45 -0400
>
> > Note that this cache was already broken for caching timestamps of
> > multiple machines behind a NAT sharing the same address.
>
> That's the documented, well established, limitation of time-wait
> r
Hi David,
On Wed, Mar 15, 2017 at 03:40:44PM -0700, David Miller wrote:
> From: Soheil Hassas Yeganeh
> Date: Wed, 15 Mar 2017 16:30:45 -0400
>
> > Note that this cache was already broken for caching timestamps of
> > multiple machines behind a NAT sharing the same address.
>
> That's the docum
From: Soheil Hassas Yeganeh
Date: Wed, 15 Mar 2017 16:30:45 -0400
> Note that this cache was already broken for caching timestamps of
> multiple machines behind a NAT sharing the same address.
That's the documented, well established, limitation of time-wait
recycling.
People who enable it, need
From: Soheil Hassas Yeganeh
Commit 8a5bd45f6616 (tcp: randomize tcp timestamp offsets for each connection)
randomizes TCP timestamps per connection. After this commit,
there is no guarantee that the timestamps received from the
same destination are monotonically increasing. As a result,
the per-d
13 matches
Mail list logo
