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 have two machines (A and B, A is Master) running VRPP (from keepalived) for a Virtual IP.

How can I prevent A from becoming Master again if it has failed and come back up (for whatever reason)?

I'm doing this so that we have a single fail-over to the second box, and going back to normal would require manual intervention.

share|improve this question
I'm too new to create tag "VRRP" – MrMagu Jul 22 '09 at 16:32
up vote 10 down vote accepted

According to this relatively old post on the keepalived developer list, it can be done. You set both servers to be equal priority (or none at all), and do not declare the state for either as MASTER or BACKUP, and instead set the state to EQUAL for both.

share|improve this answer
Thank you -- Also worth a note, using above configuration (of equal priority and using "EQUAL") if no master has taken over, the VRRP instance with lowest IP will become MASTER. – MrMagu Jul 22 '09 at 17:37

The way we solved this is by adding the nopreempt flag to our keepalived config file. Didn't have to change anything else (still left one as MASTER and one as BACKUP and so on). Basically this tells it to not switch masters just because a new server came online, only switch when the current master fails.

share|improve this answer
from ""; If "state" is set to MASTER, "nopreempt" is basically ignored since when the machine with "state MASTER" returns it will just grab the IP from the machine with "state BACKUP" without even holding an election. I had to set both my machines to state BACKUP with one having higher priority in order for "nopreempt" to function as intended. – MrMagu Jul 22 '09 at 19:07

As I understand it, when a new VRRP server comes up, it forces an election, and the current server doesn't get any benefit, so the old master will come up and win the election. I doubt there is much you could do to stop this, beyond the rather brutal Shoot The Other Node In The Head. Keepalive may have some configuration to control the election process. Sadly I don't have time to check now, but I'll try to look later.

share|improve this answer
There is a config flag of doing this, so this answer is wrong. – davr Jul 22 '09 at 17:54
The voted answer is correct for a general deployment of vrrp where you don't want a master to take over when it returns to service. As you say, there is also a keepalived way of doing this which is probably more correct for when doing linux HA stuff instead of just using vrrp to provide L3 redundancy for a default route (the more traditional reason for using vrrp). – chris Jul 22 '09 at 18:59

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.