yahoo-eng-team team mailing list archive

[Davide Guerri <davide.guerri@xxxxxxxxx>]

Public bug reported:

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?

** Affects: neutron
     Importance: Low
         Status: Confirmed


** Tags: l3-dvr-backlog

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1445255

Title:
  FloatingIP and allowed_address_pairs won't work with DVR

Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1445255/+subscriptions