|
Julian,
I'm attempting to use TUN for extensibility reasons. Eventually, we
might
want to setup a secondary off-site location for load-balancing, fail-over,
and backup purposes. (I'm using the 90.0.0.0 network as my "internet" for
testing purposes.)
Can you provide some more detail concerning the Bridging? Since my real
servers (network 192.168.32.0) are on a different network than my "test
internet" (network 90.0.0.0), how is it possible for them to use 90.0.0.3 as
a default gateway?
Thanks,
Jeff
-----Original Message-----
From: lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Julian
Anastasov
Sent: Saturday, July 06, 2002 6:18 PM
To: Jeff
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: FW: LVS-Tun and Fwmarks
Hello,
On Sat, 6 Jul 2002, Jeff wrote:
> Unfortunately, I'm missing something. I believe it may have to do with
the
> lack of a VIP on the Director because when I try and access 90.0.0.35 from
> the client, using tcpdump on eth0 of the Director, I can see the arp
request
> for 90.0.0.35, but the Director doesn't answer. Somehow I must need to
Yes, you have to deliver somehow the traffic for VIP locally.
The simplest way is to configure VIP as normal IP on the director.
> locally route all traffic destined for the VIP to 90.0.0.30 and then
> iptables (Fwmarks) should do its stuff, right? Well, I've been pounding
my
Yes, fwmark is used to distinguish the packets for the
virtual service from all locally delivered packets. If the
packets are not locally delivered at layer 3 (layer 2 is not
enough) they do not reach the LVS code.
If the RSs use the director as defgw then you need to
solve the problem of dropping the traffic in director when
src=VIP (DR and TUN). There are many solutions:
1. apply patch for the forward_shared device flag and set it
for the internal interface(s)
2. use Bridging and set 90.0.0.3 as defgw in the real servers.
By this way the director's routing will not drop the traffic
becuase it is forwarded only at layer 2.
> Jeff
P.S. I'm wondering why the people use LVS-TUN on LAN at all.
The real setup for TUN method is so different from the setup
on LAN so that any results on LAN does not mean that the
real setup should really work. TUN should be tested with the
ISPs, the tests should guarantee that the ISP allows src
address spoofing. Then the next step can be testing the IPIP
traffic.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
