Open Stack

Seems like a tweak would be to identify virtual IPs as separate to the
primary IP on a port:
 you don't need to permit spoofing of the actual host IP for each host in
the HA cluster; you just need to permit spoofing of the virtual IP. This
would be safer than disabling the spoofing rules, and avoid configuration
errors such as setting the primary IP of one node in the cluster to be a
virtual IP on another node - neutron would reject that as the primary IP
would be known as that.

-Rob

On 5 July 2013 09:33, Aaron Rosen <arosen at nicira.com> wrote:

> [Moving to list]
>
> Hi Sam,
>
> responses inline
>
> ---------- Forwarded message ----------
> From: Samuel Bercovici <SamuelB at radware.com>
> Date: Thu, Jun 27, 2013 at 1:43 PM
> Subject: Chalenges with highly available service VMs
> To: "Mark McClain (mark.mcclain at dreamhost.com)" <
> mark.mcclain at dreamhost.com>, "arosen at nicira.com" <arosen at nicira.com>
> Cc: Samuel Bercovici <SamuelB at radware.com>, Avishay Balderman <
> AvishayB at radware.com>, "gary.kotton at gmail.com" <gary.kotton at gmail.com>, "
> gkotton at redhat.com" <gkotton at redhat.com>
>
>
>  Hi,****
>
> ** **
>
> As part of provisioning load balancer service VMs we have encountered the
> following changes.****
>
> Our planned HA model for this release is going to use a strategy in which
> IP addresses are configured on the HA VM pair in the same way but only the
> active box is “connected” to the network and answers ARP request.****
>
> When the 1st VM fails and after the 2nd VM detects this, it will do a
> GARP and will take ownership on the IP addresses.****
>
> The assumption is the underlying L2 network can support IP to MAC
> discovery.****
>
> **
>
> *[arosen] - yup makes sense. *
>
>
> The challenge that we are facing is that currently each Neutron port,
> automatically gets “security” protection via IP tables which is intended to
> prevent IP spoofing. ****
>
> If the load balancer service VM gets configured with an IP (ex: VIP) this
> security blocks traffic to the IP until the Neutron port gets updated with
> this addition IP.****
>
> In addition the IP should be allocated/marked as used in a Neutron subnet
> and currency AFAIK there is no means to allocate an IP address without
> attaching it to a Neutron port.****
>
> I do not know how a network based on Nicira behaves as AFAIK it does not
> use IP tables.****
>
> ** **
>
> In the case of 2 machines acting as an HA pair the same IP address needs
> to be assigned to two Neutron ports so that the IP tables rules will be
> update correctly for bot. AFAIK this (IP attached to two Neutron Pots) is
> currently not supported.****
>
> As I expect that get 10s-100s VIPs mapped to the same Neutron port, I am
> worried that having many rules in a chain will have an impact.****
>
> ** **
>
> Follows a few options to solve this:****
>
> **1.     **Define a Neutron port as a Neutron service port. In this case
> the assumption is that the VM/Port belongs to the cloud infrastructure and
> hence no need to specify the IP tables rules that prevents “MAC” spoofing
> or “IP” spoofing (which are some of the different strategies to achieve
> HA). Potentially add support in Nova so that when a VM marked as service VM
> in nova is provisioned, than the Neutron ports of this VM will be defines
> as Neutron service ports.****
>
>
> *[arosen] - there is already an extension that does this though only the
> nvp plugin implements it at the time though it shouldn't be very hard to
> add support for it in other plugins. *
> https://github.com/openstack/quantum/blob/master/quantum/extensions/portsecurity.py
>
>
> **2.     **Add support for assigning the same IP address to two Neutron
> ports****
>
> [arosen] - there is a blueprint for pluggable ipam which might work for
> this.  That said. it seems like it might also be worth while to add an
> extension that allows you to add/remove ip/mac address pairs to a port.
>
>
>  **
>
> What do you think?****
>
> ** **
>
> Regards,****
>
>             -Sam.****
>
> ** **
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130705/b0c7fcbd/attachment.html>