wrong real server ip in connection

"Vlad" <[email protected]>
Newsgroups gmane.linux.keepalived.devel
Organization ponch.ru
Message-ID <[email protected]>
Hello!

First of all - Sorry, if wrong maillist.
I come up with strange situation and i dont really know, if its by
design or something is wrong in my configuration. so pls help)

i have three node self-balancing keepalived cluster for smtp.

server1 195.111.111.164 195.111.111.168
server2 195.111.111.165 195.111.111.169
server3 195.111.111.166 195.111.111.170

two vip address 195.111.111.177 and 195.111.111.176

problem:

when i do "telnet 195.111.111.176 25" i got balanced to address
from "virtual_server 195.111.111.176" group .164 .165 .166(i can see in
mail server log, which ip i am connected to). It ok, correct.

but with "telnet 195.111.111.177 25", i am expecting to see in
mail log, that connection goes to ip .168 or .169. or 170. But they,
somehow, again goes to .164 .165 .166. Is it correct behavior? I wish
it is not. Any ideas how to fix?

======
two vrrp instaces:

vrrp_instance VI_domain1 {
    state MASTER
    interface eth3
    lvs_sync_daemon_inteface eth3
    virtual_router_id 101
    priority 200
    advert_int 2
    virtual_ipaddress {
        195.111.111.176/27 dev bond0
    }
}

vrrp_instance VI_domain2 {
    state MASTER
    interface eth3
    lvs_sync_daemon_inteface eth3
    virtual_router_id 102
    priority 200
    advert_int 2
    virtual_ipaddress {
        195.111.1111.177/27 dev bond0
    }
}

=====
virtual_server 195.111.111.176 25 {
    delay_loop 30
    lb_algo wrr
    lb_kind DR
    protocol TCP
    persistence_timeout 50

    real_server 195.111.111.164 25 {
        weight 100
        SMTP_CHECK {
                connect_timeout 3
                retry 1
                delay_before_retry 2
                helo_name keepalived
        }
    }

    real_server 195.111.111.165 25 {
        weight 100
        SMTP_CHECK {
                connect_timeout 3
                retry 1
                delay_before_retry 2
                helo_name keepalived
        }
    }

    real_server 195.111.111.166 25 {
        weight 100
        SMTP_CHECK {
                connect_timeout 3
                retry 1
                delay_before_retry 2
                helo_name keepalived
        }
    }
}

virtual_server 195.111.111.177 25 {
    delay_loop 30
    lb_algo wrr
    lb_kind DR
    protocol TCP
    persistence_timeout 50

    real_server 195.111.111.168 25 {
        weight 100
        SMTP_CHECK {
                connect_timeout 3
                retry 1
                delay_before_retry 2
                helo_name keepalived
        }
    }

    real_server 195.111.111.169 25 {
        weight 100
        SMTP_CHECK {
                connect_timeout 3
                retry 1
                delay_before_retry 2
                helo_name keepalived
        }
    }

    real_server 195.111.111.170 25 {
        weight 100
        SMTP_CHECK {
                connect_timeout 3
                retry 1
                delay_before_retry 2
                helo_name keepalived
        }
    }
}

------------------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.