LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

DNS UDP connection never expires

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: DNS UDP connection never expires
From: "Andy Nguyen" <andy@xxxxxxxxxxxx>
Date: Fri, 10 Jun 2005 14:20:39 +1100
Hi all,

I am having a HA setup with two load balancers running ldirectord talking to 
two dns servers using direct routing:

10.0.1/24     192.168.1/24
     |-[DNS1]-|
->---|-[LB1 ]-|
->---|-[LB2 ]-|
     |-[DNS2]-|

I am testing by sending DNS queries using queryperf to the VIP from outside 
the subnet.

By quickly failing a DNS server (stopping bind9) while it was the active 
server, I was able to have a UDP connection in the connection table that 
never expires.
The timer keeps counting down to 0, then starts again from 60.

lb2:/etc/ha.d# ipvsadm -Lnc
IPVS connection entries
pro expire state       source             virtual            destination
UDP 00:46  UDP         10.1.0.2:32799     10.10.10.1:53      192.168.1.22:53
lb2:/etc/ha.d# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
UDP  10.10.10.1:53 wrr
  -> 192.168.1.21:53              Route   5      0          0         
  -> 10.0.1.22:53                 Route   0      0          0         
  -> 10.0.1.21:53                 Route   1      0          0         
  -> 192.168.1.22:53              Route   0      0          1         

lb2:/etc/ha.d# sysctl -A|grep vs
net/ipv4/vs/nat_icmp_send = 0
net/ipv4/vs/sync_threshold = 3  50
net/ipv4/vs/expire_quiescent_template = 1
net/ipv4/vs/expire_nodest_conn = 1
net/ipv4/vs/cache_bypass = 0
net/ipv4/vs/secure_tcp = 0
net/ipv4/vs/drop_packet = 0
net/ipv4/vs/drop_entry = 0
net/ipv4/vs/am_droprate = 10
net/ipv4/vs/amemthresh = 1024

lb2:/etc/ha.d# ipvsadm -v
ipvsadm v1.24 2003/06/07 (compiled with getopt_long and IPVS v1.2.1)

lb2:/etc/ha.d# uname -a
Linux lb2 2.6.11.10.05052702 #1 SMP Fri May 27 18:17:56 EST 2005 i686 
GNU/Linux


Queryperf uses the same source port for the queries, so when this happens 
the queries are still sent to 192.168.1.22 even with the realserver marked 
as not available. 

Has anyone seen anything like this?

Regards
Andy






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