LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Ldirectord - ipvs - ip conntrack

To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Ldirectord - ipvs - ip conntrack
From: "Alexander Stolle" <alexlists@xxxxxx>
Date: Thu, 17 Nov 2005 22:13:30 +0100
Hi,

I have a strange behaviour with my lvs loadbalancer and sip connections.
Actually, everything works fine, as long as I don't unplug one of my 2 sip
proxies. 
Ldirectord determines correctly, that RIP1 does not respond and removes the
entry from the lvs table. From now on, every request to VIP should be
internally routed to RIP2. But this is not the case for all Clients. Some
Clients, which had a connection with RIP1 before, still get directed to
RIP1. 

The ipvs table and the connection table look fine for me:

lvs:~# ipvsadm -l -n
TCP  VIP:5060 wlc persistent 120 mask 255.255.255.0
  -> RIP2:5060           Masq    1      0          0

lvs:~# ipvsadm -l -n -c
IPVS connection entries
pro expire state       source             virtual            destination
UDP 04:22  UDP         Client1:5060             VIP:5060
RIP2:5060
UDP 00:47  UDP         Client2:5060             VIP:5060
RIP2:5060
UDP 00:36  NONE        Client3:0                VIP:5060
RIP2:5060

Anything should go to RIP2 only. But a tcpdump shows that it does not :(
So I searched a long time for a reason. 

I already set the following flags:
net.ipv4.vs.expire_nodest_conn = 1
net.ipv4.vs.secure_tcp = 3
net.ipv4.vs.timeout_finwait = 2
net.ipv4.vs.expire_quiescent_template = 1 

But I still have the same problem. I looked into ip_conntrack and found
entries with the IP of RIP1:

"udp      17 28 src=DIP_Internal_IP dst=RIP1 sport=35356 dport=5060
[UNREPLIED] src=RIP1 dst=DIP_Internal_IP sport=5060 dport=35356 use=1"

"udp      17 164 src=RIP1 dst=Client sport=5060 dport=12500 src=Client
dst=VIP sport=12500 dport=5060 [ASSURED] use=1"

^^ If one of the above entries exists, then the traffic for this client
still gets routed to RIP1. The entries get removed by some timeout after a
while. From this time on the packets are routed correctly to RIP2. 

Well, I don't really have a clue right now. I patched my kernel with the
ipvs_nfct patch a while ago. It does not work for me and I also do not
really need it. Could it be, that this patch is somehow responable for the
entries in the ip_conntrack table? Does ipvs normally use the ip_conntrack
table?
Has someone had a similar behaviour and possibly knows a solution?

Thanks for your time,

Alex


My Setup:
---------

Ldirectord.cf

# Global Directives
checktimeout=5
checkinterval=2
autoreload=no
logfile="local0"
quiescent=no

# Virtual Service for SIP TCP
virtual=VIP:5060
       real=RIP1:5060 masq
       real=RIP2:5060 masq
       scheduler=wlc
       service=sip
       protocol=tcp
       checktype=negotiate
       checktimeout=1
       netmask=255.255.255.0
       persistent=120
       quiescent=no

# Virtual Service for SIP UDP
virtual=VIP:5060
       real=RIP1:5060 masq
       real=RIP2:5060 masq
       scheduler=wlc
       service=sip
       protocol=udp
       checktype=negotiate
       checktimeout=1
       persistent=120
       netmask=255.255.255.0
       quiescent=no
------------------------------

Used Versions:

ipvsadm v1.21
IPVS v1.0.12
Vanilla Kernel 2.4.31 with ipvs_nfct Patch
ldirectord 1.77.2.36


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