|
On Thu, Sep 15, 2005 at 11:39:43AM +0200, mquich wrote:
> On 14/09/05, Ranga Nathan <kairanga@xxxxxxx> wrote:
> > One of the things I missed out, that was not obvious in the documentation.
> >
> > Did you bind the virtual IP to the loop back adaptors of the real
> > servers and the load balancers? Also, make sure that the loop back
> > virtual IP is hidden. The commands to hide are different for 2.2x, 2.4x
> > and 2.6x kernel.
> >
> > On my SuSE 9.2 (2.6x kernel) I do this on the real servers:
> > echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
> > echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
> > echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
> > echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
> >
> > Mind you, I am doing LVS/DR not the LVS/NAT. But I think it applies
> > there too.
> >
>
> Thanks for the response but my problem goes on. I've made several
> tests and changed configurations and my situation is this:
>
> 1. LVS1 acts as a director and LVS2 acts as a real-server.
> 2. LVS1 iptables marks packets.
> 3. I've changed that LVS1 don't capture those packets.
> 4. LVS2 captures packets with that dst_port.
> 5. LVS2 doesn't have any ipvs rule
> 6. No packets at all arrive to LVS.
> 7. LVS1 doesn't forward packets to LVS2.
> 8. As LVS1 is a bridge (br0), it forwards the packets through the DSL
> router and everything works fine (but it doesn't capture the packets).
> 9. If I make LVS capture the packets (iptables ...-j REDIRECT
> --to-ports...), then "ipvsadm -l" shows an innactive connection
> towards LVS.
> 10. LVS2 sees packets with src_ip=CIP and dst_ip=LVS1.
> 11. LVS1 sees packets like these:
> 11:35:52.689019 IP 192.168.5.221 > 192.168.5.247: icmp 68: time
> exceeded in-transit
> 11:35:57.680777 arp who-has 192.168.5.221 tell 192.168.5.111
> 11:35:57.680863 arp reply 192.168.5.221 is-at 00:0c:76:f4:d6:af
>
> I still don't understand what's happenning, but I think it may be
> something related to bridge.
It might be to do with bridging, it might not, I am not sure.
Simplifying the configuration as you have, is a good idea.
I would debug the problem from here by opening up connections,
and tracking the packets across the network, and withing the kernel.
The former can be done using tcpdump, I recommend using the -e option
to show you the mac address, which is very handy when playing with
LVS-DR.
The later can be done by placing iptables rules in the various chains.
They can just be -j ACEPT rules that you monotior
using watch -n 1 iptables -L -v -n
Or you can use LOG to get more information about the packets
>
> Any hint?
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
--
Horms
|
