I was trying to follow Aaron's guide here: http://blog.aaronorosen.com/implementing-high-availability-instances-with-neutron-using-vrrp/
VRRP is working fine, but with DVR enabled there is no way to get a floatingIP address working with a vIP.
There has been a discussion about this on #openstack-neutron on the 16th of April 2015:
[23:49:26] <kevinbenton> dguerri was trying to follow Aaron's guide here: http://blog.aaronorosen.com/implementing-high-availability-instances-with-neutron-using-vrrp/
[23:49:35] <kevinbenton> and it doesn't work with DVR
[23:50:49] <armax> kevinbenton: ok, but are we sure that’s because of an unbound port?
[23:51:37] <kevinbenton> armax: seems to be
[23:51:56] <kevinbenton> armax: no l3 agent will respond to an ARP request for the floating IP when i try it
[23:52:57] <armax> kevinbenton: ok, now I am with you
[23:53:53] <armax> kevinbenton: in aaron’s case the fip is associated to an unbound port
[23:54:05] <armax> kevinbenton: and yet routing works fine
[23:55:18] <armax> kevinbenton: I don’t think taht for such scenario DVR makes much sense
[23:55:48] <armax> kevinbenton: because if we allowed to have teh FIP namespace to land on the dvr_snat agent
[23:56:02] <armax> kevinbenton: you’re basically back to central routing
[23:56:07] <kevinbenton> armax: right
[23:56:11] <armax> kevinbenton: am I making any sense?
[23:56:29] <armax> kevinbenton: I am not saying that lack of VRRP support is nice
[23:56:37] <armax> kevinbenton: I am tryign to wrap my head around this
[23:56:49] <kevinbenton> armax: i was thinking maybe there was some fallback logic where the SNAT one would host a floating IP if there wasn't another l3 agent that could handle it
[23:57:16] <kevinbenton> armax: for example if one of the compute nodes wasn't running the l3 agent
[23:57:35] <kevinbenton> armax: it would be the same scenario
[23:57:37] <kevinbenton> armax: right?
I think this is borderline between low and wishlist, but I can see why we'd want to keep the feature parity with centralized routing.