LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

RE: SYN_RECV LVS_NAT on 2.4.7 kernel

To: Jeremy Kusnetz <JKusnetz@xxxxxxxx>
Subject: RE: SYN_RECV LVS_NAT on 2.4.7 kernel
Cc: "'lvs-users@xxxxxxxxxxxxxxxxxxxxxx'" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 7 Sep 2001 00:51:16 +0000 (GMT)
        Hello,

On Thu, 6 Sep 2001, Jeremy Kusnetz wrote:

> I'm using ipvs-0.8.1
> -----------------------------
>
> On the realserver I've tried both:
> tcpdump -ln host dip
>  and
> tcpdump -ln host vip
>  and just a plain tcpdump

        The both commands are wrong. On the real server you have only
two options:

tcpdump -ln host RIP
or
tcpdump -ln host CIP

        the second works for all forwarding methods but your commands
don't work for NAT.

> All show no packets hitting the realserver.

        This is correct considering the commands you are using. I
assume you are seeing the traffic to the real servers through eth1?

> Q.3 Is the traffic forwarded from the LVS box, in both directions?
>
> I think I fall under:
>
> A.4 All packets from the client are dropped (since it never seems to go to
> the realserver)
>
>       - the requests are received on wrong interface with rp_filter
>       protection

/proc/sys/net/ipv4/conf/*/rp_filter

        I can't believe that you can hit this problem, it is very
difficult. I don't know how many eth devices you have on the real
server(s). I see that you are using an old tcpdump version and
you have to start tcpdump with specific -i ifname option for all
devices. Then check again this A.4 point.

>       - firewall rules drop the requests
>
> I don't have any other firewall rules setup other then the masquerading.
>
> I don't know what rp_filter protection is, can you explain the first reason
> for failure there?

        The rp_filter protection can drop packets if you are trying
to deliver traffic through one device but the reverse path points to
another device.

        For example, may be you have {all,eth0}/rp_filter=1 in the
real server but your default route is on eth1. So, eth0/rp_filter can
drop your packets. In such case ping and traceroute can work if they
successfully select the right path. But they can fail even for right
routing setup. If traceroute does not work then someone have to fix
it to call bind() before sendto() through the raw socket.


Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>