Sven,
tcp_tw_recycle is incompatible with NAT on the server side
... because it will enforce the verification of TCP time stamps.
Unless all clients behind a NAT (actually PAD/masquerading) device
use identical timestamps (within a certain range), most of them will
send invalid TCP
Nils Goroll wrote:
The outer conditional verifies that the incoming SYN has
a timestamp, that tcp_tw_recycle is enabled, and that the origin
exists in our peer cache. Note that it only checks the IP of the
origin. Doesn't it make sense to also match on port?
My understanding is that the
Sven,
Right, you're saying that the srcaddr+srcport pair of a connection in
TIME_WAIT should not be reused under this scheme (i.e. the SYN can be
dropped), and I agree. Then I don't understand why a new connection
originating from a *different* source port (although from the same
source IP)
Hi Michael and all,
tcp_tw_recycle is incompatible with NAT on the server side
... because it will enforce the verification of TCP time stamps.
Unless all
clients behind a NAT (actually PAD/masquerading) device use identical
timestamps
(within a certain range), most of them will send
Nils Goroll wrote:
tcp_tw_recycle is incompatible with NAT on the server side
... because it will enforce the verification of TCP time stamps.
Unless all clients behind a NAT (actually PAD/masquerading) device
use identical timestamps (within a certain range), most of them will
send invalid
Hi Sven,
I don't know the basis precise for it, but I can vouch for the fact that
tcp_tw_recycle is incompatible with NAT on the server side. I would
guess it is because the NAT gateway keeps a connection tracking list and
is unhappy that the webserver is trying to reuse the same ip:port hash
On Sep 20, 2009, at 6:20 AM, Nils Goroll wrote:
tcp_tw_recycle is incompatible with NAT on the server side
... because it will enforce the verification of TCP time stamps.
Unless all
clients behind a NAT (actually PAD/masquerading) device use
identical timestamps
(within a certain
I was recently debugging an issue where several clients experienced
sporadic problems connecting to a website cached by varnish. Every now
and then (say, something like every 20-50th TCP connection) would time
out, or sometimes take a few SYNs before being accepted.
Here's a typical example. It's
