|
Hello,
On Wed, 31 Jan 2018, Sergey Urbanovich wrote:
> Hi Julian,
>
> 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?
conntrack=1 allows the IPVS traffic to be under
netfilter control, such as, matching by conntrack state (NEW,
ESTABLISHED, RELATED), additional NAT, etc. You do not need
netfilter conntracks to NAT the packets, IPVS can do its
function without using conntracks.
> 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?
The original direction (CIP:CPORT->VIP:VPORT) is
same because the client sockets retransmits its SYN packet.
But IPVS can select different real server. So, the reply
direction can be from different RIP:RPORT to CIP:CPORT.
Both IPVS conns and the Netfilter conntrack require unique
tuple in both directions, so we can not keep the old
connections. As conntracks are created only when packet
enters the stack, our solution is to drop the old
conntrack, so that the new one is created with unique
tuples to the newly selected real server.
Regards
--
Julian Anastasov <ja@xxxxxx>_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
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
|
