Bug 1202584

Description of problem:
Using OpenStack Neutron with highly available routers, configure three L3 agents and create an HA router. Go into the router namespace of the master and set the HA device to down. Observe syslog of the other two nodes, on one you will see (Over and over again):

Transition to MASTER STATE
Entering MASTER STATE
Received lower prio advert in nopreempt mode
Entering BACKUP STATE

In the other node:
Transition to MASTER STATE
Entering MASTER STATE
Received higher prio advert
Entering BACKUP STATE

Version-Release number of selected component (if applicable):
Does not reproduce on 1.2.9-1.fc20, does reproduce on 1.2.15-2.fc20.

How reproducible:
100%

Steps to Reproduce:
Detailed in problem description.

Actual results:
Nodes flapping from standby to master and back.

Expected results:
One should go to master, the other should remain in standby.

Additional information:
On each node: keepalived.conf:
Node 1 - http://www.fpaste.org/198754/
Node 2 - http://www.fpaste.org/198756/
Node 3 - http://www.fpaste.org/198757/

'ip a' output in namespace of the router:
Node 1 - http://www.fpaste.org/198758/
Node 2 - http://www.fpaste.org/198759/
Node 3 - http://www.fpaste.org/198761/

syslog summary is directly in the bug report above.

To work around the issue I tried specifying unique priorities, specifying the source advertisement address (A unique address per router instance, the one you can see in the 'ip a' output above), setting the initial state to EQUAL. I tried these in pretty much all permutations, nothing seems to make an effect. Working with pre-emption turned on eliminated the issue entirely, but no-preemption should work, and is preferred for the Neutron use case (We don't want elections when the faulty node comes back on for thousands of routers, there's just no need for another disruption in the data plane).