LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Keepalived + ipvsadm showing connections for both master and backup VRRP (https://www.linuxquestions.org/questions/linux-networking-3/keepalived-ipvsadm-showing-connections-for-both-master-and-backup-vrrp-4175483435/)

campi01 11-05-2013 04:59 AM
Keepalived + ipvsadm showing connections for both master and backup VRRP
 
Hi,

as the title says I have set up 2 load balancers with 2 VRRP instances, lets say VR1 and VR2.

System is Debian Squeeze with Kernel 3.4.54 64bit.

LB1 is master for VR1 and backup for VR2, and LB2 is master for VR2 and backup for VR1. Everything works fine, failover also works fine in case one of the LB's is down, the other takes over and etc.

My question is this: is "ipvsadm -Ln" supposed to show active connections of BOTH his MASTER and BACKUP VRRP instances? Currently each LB shows connections of both VRRP instances, MASTER and BACKUP, even though he is not handling/receiving the connections of the BACKUP VRRP instance.

Now, I have also this same setup on 2 other LB's which have been set up since years ago, and when I do "ipvsadm -Ln" each LB will only show connections of his "MASTER" state VRRP instance, and will only show the connections of the other VRRP instance when he transitions to MASTER state (ie. when he actually starts serving connection for the VIP's in the BACKUP VRRP instance). While the connection count for the BACKUP VRRP instance VIP's while it's in "BACKUP state" is 0.


So which of the 2 is the normal behaviour? And if possible, can I make it so that "ipvsadm -Ln" only shows active connections of the MASTER VRRP instance(s) and show 0 for BACKUP VRRP instance while it's in "BACKUP state" ?


Here is the version of Keepalived and ipvsadm on the new LB's:

ipvsadm v1.26 2008/5/15 (compiled with popt and IPVS v1.2.1)
Keepalived v1.1.20 (03/24,2012)


Here is the version of Keepalived and ipvsadm on old LB's (which have the desired behaviour):

ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)
Keepalived v1.1.20 (08/18,2010)


Here is example output of "ipvsadm -Ln":

Code:
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port          Forward Weight ActiveConn InActConn
FWM  1000 wlc
  -> 10.11.90.123:0              Route  100    433        47
  -> 10.11.90.148:0              Route  100    433        36
FWM  1010 wlc
  -> 10.11.90.57:0                Route  100    79        16
  -> 10.11.90.58:0                Route  100    58        11
  -> 10.11.90.147:0              Route  100    72        16
  -> 10.11.90.184:0              Route  100    70        16
FWM 1000 is VIP assigned to MASTER state VRRP instance for this LB, while FWM 1010 is VIP assigned to BACKUP state VRRP instance on this LB, so it is actually not serving any connections, but is instead (I assume) getting data from the other LB (I assume via the lvs_sync_daemon) which is MASTER state for this VIP for FWM 1010.


Any ideas?

kbp 11-10-2013 04:56 PM
You could specify the service address of the master instance when running the command, maybe just create an alias on each one like:

Code:
alias <any_name_you_like>='ipvsadm -Ln <service_address>'

campi01 11-11-2013 03:52 AM
Quote:
Originally Posted by kbp (Post 5062127)
You could specify the service address of the master instance when running the command, maybe just create an alias on each one like:

Code:
alias <any_name_you_like>='ipvsadm -Ln <service_address>'

I can already do that with "ipvsadm -Ln -f 1000" and "ipvsadm -Ln -f 1010", to only see connection for the service I want. But that still doesn't change the fact that I can see connections which are not handled by that particular LB :/.

Do you know if this is normal behaviour or?

Since I'm kinda used to seeing connections only on the LB which is actually handling the connections.

kbp 11-11-2013 05:16 AM
Sorry, I don't know - I haven't set one up for a few years.


All times are GMT -5. The time now is 01:04 PM.