Mailing List Archive

[lvs-users] local forwarding issues (keepalived and real server on same host)
Hi,

I've been setting up load balancing using keepalived, and running 2 real
server instances on the same hosts as keepalived.

I'm using a iptables REDIRECT rule in PREROUTING to prevent 'loops'.

It all works fine for all traffic to this cluster from outside, or from
the current MASTER, with traffic being balanced across both servers, and
failover happening as expected.

However, connections from the BACKUP to the VIP seem to timeout 50% of
the time (i.e when the backup tries to route the connections to itself,
rather than passing them to the master). A tcpdump on both servers shows
that the packets are never leaving the backup, and are obviously just
stuck somewhere internal to the backup.

My keepalived config is as follows:

vrrp_instance virtual_ip {
interface eth0
state EQUAL
virtual_router_id 10
priority 100
virtual_ipaddress {
192.168.1.1
}
notify /etc/keepalived/prerouting.sh
}

virtual_server 192.168.1.1 25 {
delay_loop 10
lvs_sched wlc
lvs_method DR
protocol TCP
real_server 192.168.1.10 25 {
weight 100
TCP_CHECK {
connect_timeout 10
}
}
real_server 192.168.1.20 25 {
weight 100
TCP_CHECK {
connect_timeout 10
}
}
}

iptables rule (added to/removed from the backup/master by notify script):

iptables -t nat -A PREROUTING -d 192.168.1.1 -j REDIRECT


Everything looks ok with ipvsadm -l (same on both master and backup):

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.1:25 wlc
-> 192.168.1.10:25 Route 100 0 0
-> 192.168.1.20:25 Route 100 0 0


However, I noticed that the Forward type in both cases is 'Route' while
in older docs I expected to see 'Local' - and after searching found this
thread:

http://www.gossamer-threads.com/lists/lvs/users/25080

However that doesn't really explain what I should be doing with my
keepalived/iptables config to handle this.

I could modify my notify script to 'turn off/on' the ipvs config on
state change (ie ipvsadm save/clear/restore), but this feels a little
bit hacky.

Can anyone please either point out the error in the above config, or
explain the 'new way' of handling local forwarding?

Thanks,

Matthew


--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.