|
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>
|
