Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a keepalived + LVS set up I'm trying to get to work

Clients, LB and real servers are all on the same subnet.

Keepalived config:

global_defs {
    notification_email {
    smtp_connect_timeout 30
    router_id ukld5p500x

vrrp_instance some_service {
    state             MASTER
    interface         em1
    virtual_router_id 100
    priority          100
    virtual_ipaddress {

    track_script {

virtual_server 58563 {
    delay_loop      10
    lb_algo     rr
    lb_kind     DR

    protocol        TCP

    real_server 58563 {
        weight          1
        TCP_CHECK {
            connect_timeout 3   
            connect_port    58563

    ... more real_servers ...


So if I set lb_type to nat then I can connect from the LB itself to the VIP/port and stuff goes through, but not from an external host (client). If I set lb_type to DR then neither the LB connecting to itself nor an external client can connect. is set to 1 and there is only one LB configured atm.

share|improve this question

Don't know if you've gotten this answered since its so old, but DR (Direct Routing) is much different than NAT. NAT makes the load balancer (LB) act like a router by passing the packet to the real server, and the real server passes it back to the LB to deliver back to the client.

With DR, the LB is only a pseudo-middleman. When a packet comes in on the VIP the LB has, it decides which RS (real server) to send it to, and rewrites the packet header by changing the MAC address. It then passes the packet back to the switch, and the switch delivers it to the RS with the matching MAC address.

You then have to trick your RS into accepting a packet destined for its interface. You typically do this by adding the VIP to a loopback adapter and giving it a netmask of Your service daemon will also need to be configured to listen on this VIP as well (in apache you just add an additional Listen x.x.x.x:80 line).

To top it off, you have to deal with the ARP problem. Typically, adding

net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth0.arp_ignore = 1

to your sysctl.conf will take care of it

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.