[lvs-users] Port mapping with LVS-DR using fwmark
hickersonjl at gmail.com
Thu Jan 30 19:43:25 GMT 2014
Ah I see. The ideal solution would be to have a similar setup on both
servers because any of these servers could fail-over, so the dynamic
setup/modifications would be more complex in a fail-over condition. It
would be interesting if the director maintained the original VIP port
assignment or there were a configuration item/utility setup to indicate.
But perhaps that would be inefficient.
Thanks again for your help!
On Tue, Jan 28, 2014 at 11:59 PM, Julian Anastasov <ja at ssi.bg> wrote:
> On Tue, 28 Jan 2014, Jacoby Hickerson wrote:
> > Thanks Julian this helps me understand it a lot better. Are you
> > using masquerading method? That isn't an ideal option for me unless of
> > course it is the only option.
> > To see how much further I could get using DR, I removed the redirect and
> > added the following to both real servers:
> > iptables -t nat -A PREROUTING -p tcp -m tcp --destination 172.17.0.24
> > --dport 80 -j DNAT --to-destination 172.17.0.24:50000
> You do not need REDIRECT rule on the director, use
> masquerading method for the local RIP1 and DR method for
> RIP2. Use REDIRECT on real server 2. For example:
> # DNAT by IPVS: VIP:80 -> RIP1:50000
> ipvsadm -a -f 100 -r 172.17.0.16:50000 -w 100 -m
> # DR as before: VIP:80 sent as VIP:80 to nexthop 172.17.0.17
> ipvsadm -a -f 100 -r 172.17.0.17 -w 100
> Then add REDIRECT or the above DNAT only on
> real server 2 (172.17.0.17). By this way traffic from
> real server 2 will not go to client via director.
> As you notice, the problem you are now facing
> is that from client point of view, the remote port is 80
> and real server 2 does not alter it in replies.
> Real server 2 can return only with the port it
> received. That is why the DNAT/REDIRECT for port
> should happen on the real server and not on director.
> Otherwise, we have to send replies via director for
> proper assignment of port but it is something we
> try to avoid.
> > After the DNAT update it now sends packets to the real server 2, however
> > port is not what the client expects.
> > The problem is that the real server 2 receives packets on the port mapped
> > port 50000 instead of port 80.
> Julian Anastasov <ja at ssi.bg>
More information about the lvs-users