LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Ultramonkey/LVS-TUN connection stalls on client

To: Nigel Hamilton <nigel@xxxxxxxxxxx>
Subject: Re: Ultramonkey/LVS-TUN connection stalls on client
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 25 Feb 2004 14:21:41 +0200 (EET)
        Hello,

On Wed, 25 Feb 2004, Nigel Hamilton wrote:

>       This looks fine. Step 2 in the HOWTO suggests to check if the Real
> Server is dropping the decapsulated packets, using this command:  "ip
> route get from CIP to VIP iif tunl0".
>
>       My client IP (CIP) is 81.152.187.242, and virtual IP (VIP) is
> 66.98.227.143. So I do:
>
> [root@realserver]# /sbin/ip route get from 81.152.187.242 to 66.98.227.143 
> iif tunl0
> Cannot find device "tunl0"

        If you do not have tunneling device who decapsulates the
IPIP traffic coming from director?

>       Hmmm ... no 'tunl0'? I assume this refers to one of the interfaces
> on the RealServer? eth0?

        Yes, on the RS but not eth*

>       So assuming the above test has passed, step 3 in the HOWTO is
> to see if the RealServer's gateway passes the packet to the client using
> the command, "arp -d GW; traceroute -n -s VIP CIP" on the Real Server. The
> Gateway of my Real Server is 66.98.186.1. So I do:
>
> [root@realserver]# /sbin/arp -d 66.98.186.1; traceroute -n -s 66.98.227.143 
> 81.152.187.242
>
>       On the Director I do a /usr/bin/tcpdump | tee to truy

        Please, use the mentioned tcpdump commands, I do not know the
IPs behind ivhou-207-218-245-3.ev1.net.

> [root@director] /usr/sbin/tcpdump | tee look
> [root@director] cat look
>
>       Below is an excerpt of the tcpdump output:
>
> 3712 <nop,nop,timestamp 2036664512 23858358> (DF) [tos 0x10]
> 18:50:58.928811 ivhou-207-218-245-3.ev1.net > 66.98.227.143: icmp: time
> exceeded
>  in-transit

        What is this (ivhou-207-218-245-3.ev1.net), external IP
for the RS's gateway?

>       Step 3 of the HOWTO says "after some time we should see
> unreachable replies sent from the client". I can't see the client's IP
> address in here at all. I don't know how to spot "unreachable replies from
> the client".

        Yes, after some time because traceroute increases the TTL
for each probe hop by hop, some of the next UDP packets will reach
the client if it is not dropped from some router. If the client does
not receive such UDP packets then your ISP has filters.

>       However, I can see something from my ISP's switch/router/thingy:
>
> 18:50:58.928811 ivhou-207-218-245-3.ev1.net > 66.98.227.143: icmp: time
> exceeded in-transit

        This is good but we need ICMP answer from CIP

>       I have no idea if this is good or bad? But the HOWTO goes on to
> say "at least we should see on the client the UDP packets generated from
> the Real Server."
>
>       So I start Ethereal on Windows XP to see if I can see these UDP
> packets and re-run the test on the Real Server.

        You should wait in client for UDP packets with saddr=VIP, daddr=CIP

>       The first time I started Ethereal I thought I saw 4 UDP packets
> but then they stopped. The second time I ran the test Ethereal reports no
> UDP packets received by the client at all.

        This is bad

>       So, Doctor what nasty disease have I got here? Is my ISP blocking
> the packets somehow? It seems there is no consistent UDP response from the
> client, why is that?

        The client should receive UDP packet and to respond with ICMP
packet that will be logged in the director.

Regards

--
Julian Anastasov <ja@xxxxxx>

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