[lvs-users] Port mapping with LVS-DR using fwmark

Jacoby Hickerson 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:

>         Hello,
> On Tue, 28 Jan 2014, Jacoby Hickerson wrote:
> > Thanks Julian this helps me understand it a lot better.  Are you
> suggesting
> > 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
> > --dport 80 -j DNAT --to-destination
>         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 -w 100 -m
> # DR as before: VIP:80 sent as VIP:80 to nexthop
> ipvsadm -a -f 100 -r -w 100
>         Then add REDIRECT or the above DNAT only on
> real server 2 ( 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
> the
> > 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.
> Regards
> --
> Julian Anastasov <ja at ssi.bg>

More information about the lvs-users mailing list