Thank you very much for such a valuable answer.
I'd like to add some more information about my use case. In our system client
and load-balancer work on the same server, and remote servers could bind on
different TCP ports; so VS/NAT is a requirement for us.
Do I understand correctly that I can’t use the first two options from your
previous message (conntrack=0 and --notrack) in my use case?
Why do we have to drop the first SYN packet if, in 1 second, the next SYN packet
uses the same source and destination TCP ports and it works fine?
On Jan 27, 2018, at 7:16 AM, Julian Anastasov <ja@xxxxxx> wrote:
It should be this code that leads to delay:
What happens is that we drop SYN packet that hits IPVS
connection in TIME_WAIT state if such connection uses
Netfilter connection tracking (conntrack=1).
The conn_reuse_mode=1 relies on selecting different
real server but as we can not alter the Netfilter conntrack
tuple after it is confirmed, we drop the conntrack, the IPVS
connection and current packet and expect next SYN (retransmitted
after 1 second, as you observe) to create new IPVS connection
and corresponding conntrack to some available real server.
And that is what happens after 1 second.
To get rid of this delay you have the following options:
1. do not enable IPVS conntrack mode (can be slower to create
and drop conntrack on every packet), use conntrack=0 for this.
This allows IPVS to ignore the TIME_WAIT connection and to
create a new one.
2. Use NOTRACK for IPVS connections, it should be faster
because conntracks are not created/removed
iptables -t raw -A PREROUTING -p tcp -d VIP --dport VPORT -j CT --notrack
For local clients use -A OUTPUT -o lo
If needed, such traffic can be matched with -m state --state UNTRACKED
3. Reduce the TIME_WAIT timeout in IPVS source, table
tcp_timeouts. It does not solve the problem but reduces
Julian Anastasov <ja@xxxxxx>
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users