|
Kip Iles wrote:
>
> > Kip Iles wrote:
> > >
> > > I use the term redirect loosely.
> >
> > I have no idea what the problem is then.
> > Can you explain it in non-loose terms?
>
> ip_vs redirects IP packets using NAT, TUN, or DR. Regardless of how it is
> done, I still think of the packets as being "redirected" since they were
> sent somewhere other than the original DIP. I will not use his term in the
> future. Maybe forwarding would be a better term.
it's the one we use. redirecting is for other functions of the LVS.
>
> Anyway, In as non-loose terms as I can muster ....
>
> For simplicity, I used to have a director (dir_A) and two realservers behind
> it. Dir_A used VS-TUN to balance between both real servers. All client
> requests for the VIP resolved to an IP address on dir_A's outside interface
> eth0 (eth0:1 to be precise). Those requests were encapsulated and sent to
> one of the realservers. The realservers decapsulated the packet and returned
> responses directly to the client via the border router. This worked fine.
>
> Now I have moved one of the realservers to a remote site and put it behind a
> new director (dir_B).
OK, dir_B is now a realserver in dir_A's LVS.
Dir_B uses VS-NAT to forward requests to it's
> realserver. The realserver gets the request and responds to the client via
> NAT through dir_b. This worked fine.
>
> The problem is getting request received by dir_A to balance between it's
> local realserver and the remote realserver behind dir_B.
I would expect it is already happening. What do you see that shows you that it's
not happening?
Why do I even have
> a director at the remote site, you might ask? Why not just go directly to
> the realserver since no load balancing is required. Because in reality there
> are multiple realservers behind each director but we only talk about one for
> illustration purposes. Also, dir_B is intended to be used as a
> firewall/router/VPN at the remote site.
>
> This is how I expect the packets to flow ...
>
> Client->DIRA-tun->DIRB-nat->Real-nat->Client
client->dir_A->tun->dir_B-nat->RS->dir_B->client
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
