|
In article <011901c5ebbb$c2e7a5a0$150ba8c0@xxxxxxxxxxxxxxxx> you wrote:
> 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?
There are probably a few problems here. But first up, is
there any reason you are using conntrack with LVS. Its probably
not needed for LVS to function and might be causing problems.
Secondly, you can see LVS's connections and their timeouts
using ipvsadm -Lcn.
--
Horms
|
