|
--On Monday, January 29, 2001 11:06:19 AM -0500 Joseph Mack
<mack.joseph@xxxxxxx> wrote:
(This isn't neccessarily a good solution, but it's a first step).
Howabout: each fw box also does NAT. Packets coming out of each fw box
have the IP on the inside of the fw box as the source addr.
(These fw boxes are going to be fairly busy CPU wise).
You could then use a regular (non martian) VS-DR director for DR-2 and the
real-servers
for LVS-2 (eg host B) would only have 3 host routes (to the 3 fws, which
are the only machines they know about, since they are only getting
packets with src_addr of the fw machines).
I assume changing the IP's on the packets is going to mess up the key
exchange a bit. ;-\
yes, absolutely. doing NAT is no option at all since it would break the VPN
stuff.
if the src MAC address of the incoming packet is not any of the
configured fw boxes, then the packet came from the attached internal LAN
and a load balancing decision has to be made if there is NOT yet an
entry in the connection tracking table. if we already got a matching
entry (same src and dst ips) we have to use the already associated fw
box for this connection (means forwarding the packet for further
processing to the MAC of the fw box).
are you saying -
packets from the local LAN are processed by the LVS in the normal way
(ie without consideration of fw boxes etc)
no, i think you got me wrong on that.
1. for the communicating hosts A and B the number of involved fw boxes is
completely transparent. they don't know that there is a load balancing
mechanism between them. host B on the local LAN only knows its default GW
for sending packets to the outside: this is the VIP of the fw cluster (i.e.
the VIP on DR2 = VIP2). host A on the other hand knows that there is
something between A and B whis has to be used to establish the secure
tunnel: this is VIP1 (the VIP of the fw cluster on DR1).
2. since the fw boxes don't share any key information we have to go sure
that all packets for a particular connection between A and B only travel
over exactly _one_ fw box (this includes of course both directions A->B and
B->A).
3. the only instances which know about the involved fw box for the
communication between A and B are the two LVS directors DR1 and DR2. for
both DR's i would chose the persistant mode, so that a load balancing
decision (i.e. which fw box to use) has to be made only for the very first
packet from A to B (this happens on DR1). all the following packets will be
just forwarded to the choosen fw box. DR2 doesn't do any load balancing for
incoming traffic from A to B - it only has to remember which fw box the
packet came from (i.e. which SRC MAC the packet had), so that the response
traffic from B to A can flow over the same fw box.
for connections initiated on host B the mechanism works the other way
round. that means DR2 makes a load balancing decision and DR1 has to
remember the fw box the packet arrived from.
as i understand the LVS for now there is not any mechanism already included
which can handle the response traffic the way i do need it in my specific
application.
so what i do need to know is whether there are already similar mechanisms
(maybe for LVS-NAT) which do inspect those return packets and how much
effort you guys think it would take to include such behaviour for that
special case of LVS-DR (if at all possible).
best regards,
-- matt.
|
