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! Jacoby On Tue, Jan 28, 2014 at 11:59 PM, Julian Anastasov <j...@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 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 > 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 <j...@ssi.bg> > _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org Send requests to lvs-users-requ...@linuxvirtualserver.org or go to http://lists.graemef.net/mailman/listinfo/lvs-users
