On Fri, 5 Aug 2011, Caleb Anthony wrote:
> At my organization, we are doing something very similar to
> this, but we are going from LVS-TUN to LVS-DR to Real
> Server using firewall marks:
> Client --> LVS-TUN --> LVS-DR --> Real Server --> Back to the Client.
> This configuration forced us to configure LVS in a strange
> way. We basically needed a dedicated "remote delivery
> address" as we called it.
> Incoming traffic that is destined for the Real Server is
> firewall marked. The LVS-TUN server then forwards the
> traffic to the LVS-DR server using a dedicated address
> just for this communication.
I don't understand this. Can you give IPs (and/or fwmark)?
> That server, de-capsualtes it, and then forwards it to the
> Real Server, which then replies to the Client.
> What we're really accomplishing here is if a request comes
> into a data center, but another one of our data centers is
> closer to the client who made the request, we redirect
> that traffic to the other data center.
you have a director with a geographic scheduler?
> Requests are small, but replies are large,
the packet size doesn't make any difference. A packet of 1
byte or the whole MTU takes just as long to assemble and
transmit. We didn't understand this in the early days of LVS
and the misconception might still be in the HOWTO. I
thought I'd fixed this up. Anyhow the work that shows that
packet size is irrelevant is here
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users