|
Hello,
On Fri, 8 Nov 2002, Joseph Mack wrote:
> Was thinking about LVS-DR with active ftp and persistence on the director
> and I realised I didn't know really how it worked.
>
> After connection from the client on port=N to VIP:21 we have
>
> realserver client
> VIP:20 SYN -> client:N+1
RS port can be != 20, there is no rule that client port should
be N+1, it can be any value.
> client director
> client:N+1 ACK -> VIP:20
>
> I would have expected that the packet from client:N+1
> would not be accepted by the director as it does not follow
> a SYN packet from client:N+1->VIP:20, which would set up an
> entry for a new connection in the hash tables.
It is true, the handling is different: we accept
new connection for SYN+ACK packet (it is not only ACK):
SYN RS->CLIENT: VIP:20 -> CIP:CPORT not detected
SYN+ACK CLIENT->LVS: CIP:CPORT -> VIP:20
This happens because we check for SYN first then
for ACK in the state handling code, the ACK is ignored.
ip_vs_in() still does not check for h.th->ack==0 when creating
connection, it seems it is for good.
So, for FTP to work, we create special persistence template
for these FTP data connections:
TCP, CIPNET:*, VIP:*, RIP:*
In this case CPORT and RPORT (equal to VPORT) are unknown,
we don't know what ports the RS and client negotiated.
> Is this packet accepted because with persistence, once the initial
> connection is made, that any packets from any port on the client
> to any port on the VIP are accepted as part of the same connection
> and no new entry is made in the hash table for the packets to VIP:20?
Yes, only ip_vs_ftp can create new entries for the data
connections. Without ip_vs_ftp only the persistence guarantees
that we will not drop the SYN+ACK packet from client.
> Joe
Regards
--
Julian Anastasov <ja@xxxxxx>
|
