You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe I'm missing something, but out-of-the-box seesaw doesn't seem to support having the backend servers initiate TCP connections to outside servers (say, Gmail mail servers) for LVS-DR.
Here is a longer form explanation of an example setup with one outside client, one outside server, seesaw load balancer with a VIPand three backend real servers:
CIP = Client IP address (outside) SIP = Server IP address (outside) VIP = Virtual IP address of the seesaw service / vserver RIP1 = Real (backend) server IP address number 1 RIP2 = Real (backend) server IP address number 2 RIP3 = Real (backend) server IP address number 3
Typically for LVS-DR, a client from outside will initiate TCP (say, port 25) connection with [source IP=CIP, source port=34567, destination IP=VIP, destination port=25] to the load balancer. Load balancer (if it has a matching vserver configured for port 25) then forwards via MAC address re-write to one of the backend servers, say server with RIP3. TCP Server living on that server sees a TCP SYN packet with [source IP=CIP, source port=34567, destination IP=VIP, destination port=25], the VIP being configured on one of its dummy interfaces. The TCP server on port 25 on the backend server with RIP3 will then respond with a SYN,ACK TCP packet with [source IP=VIP, source port=25, destination IP=CIP, destination port=34567] directly to the router and the packets end up on the client with IP address=CIP that originally initiated the TCP connection.
I am just describing this for clarity. This is what normal LVS-DR looks like and what seesaw typically does. This is when TCP connections are initiated from an outside client towards seesaw/VIP.
What about the reverse? Say I have a TCP client on one of the real (backend) servers. I want this client to initiate TCP connection with [source IP=VIP, source port=34568, destination IP=SIP, destination IP=25]. For the initial SYN package, this works fine, as it is send directly via the router, not through the seesaw director node. The outside server listening on SIP then responds with SYN,ACK packet with [source IP=SIP, source port=25, destination IP=VIP, destination port=34568]. Then the problem occurs: The seesaw node sees the packet coming in and, since its sent towards a port that isn't configured as a vserver (ephemeral port 34568), drops the packet and the connection isn't established.
Now, if I add the following configuration to the seesaw node by hand, it does work:
# iptables -I INPUT -p tcp -m tcp -d $VIP --sport 25 -j MARK --set-mark 0x1
# ipvsadm -A -f 1 -s rr
# ipvsadm -a -f 1 -r $RIP3 -g # Just using RIP3 as an example here
Is there any other way to do this? As it looks now, I would have to fork seesaw to add this functionality into the code so it works with seesaw node switchover etc.
The text was updated successfully, but these errors were encountered:
Maybe I'm missing something, but out-of-the-box
seesaw
doesn't seem to support having the backend servers initiate TCP connections to outside servers (say, Gmail mail servers) for LVS-DR.Here is a longer form explanation of an example setup with one outside client, one outside server, seesaw load balancer with a
VIP
and three backend real servers:CIP
= Client IP address (outside)SIP
= Server IP address (outside)VIP
= Virtual IP address of the seesaw service /vserver
RIP1
= Real (backend) server IP address number 1RIP2
= Real (backend) server IP address number 2RIP3
= Real (backend) server IP address number 3Typically for LVS-DR, a client from outside will initiate TCP (say, port 25) connection with [source IP=
CIP
, source port=34567, destination IP=VIP
, destination port=25] to the load balancer. Load balancer (if it has a matchingvserver
configured for port 25) then forwards via MAC address re-write to one of the backend servers, say server withRIP3
. TCP Server living on that server sees a TCPSYN
packet with [source IP=CIP
, source port=34567, destination IP=VIP
, destination port=25], theVIP
being configured on one of its dummy interfaces. The TCP server on port 25 on the backend server withRIP3
will then respond with aSYN,ACK
TCP packet with [source IP=VIP
, source port=25, destination IP=CIP
, destination port=34567] directly to the router and the packets end up on the client with IP address=CIP
that originally initiated the TCP connection.I am just describing this for clarity. This is what normal LVS-DR looks like and what
seesaw
typically does. This is when TCP connections are initiated from an outside client towardsseesaw
/VIP
.What about the reverse? Say I have a TCP client on one of the real (
backend
) servers. I want this client to initiate TCP connection with [source IP=VIP
, source port=34568, destination IP=SIP
, destination IP=25]. For the initialSYN
package, this works fine, as it is send directly via the router, not through theseesaw
director node. The outside server listening onSIP
then responds withSYN,ACK
packet with [source IP=SIP
, source port=25, destination IP=VIP
, destination port=34568]. Then the problem occurs: Theseesaw
node sees the packet coming in and, since its sent towards a port that isn't configured as avserver
(ephemeral port 34568), drops the packet and the connection isn't established.Now, if I add the following configuration to the seesaw node by hand, it does work:
Is there any other way to do this? As it looks now, I would have to fork seesaw to add this functionality into the code so it works with
seesaw
node switchover etc.The text was updated successfully, but these errors were encountered: