nova team mailing list archive

[Soren Hansen <soren@xxxxxxxxxx>]

On 20-09-2010 20:15, Dan Wendlandt wrote:
> Thanks for sending this out.  My vote would be to expose this as
> optional, at least with respect to ARP and IP packets.  Such filters
> definitely make sense in a "flat" network model like Amazon, but
> there are interesting use cases (in addition to what Josh mentioned)
> for clouds that choose to expose a private network (e.g., VLAN)
> model:

Thanks for this feedback.

> 1) Using a VM as an L3 Firewall/NAT.  In this scenario, a firewall VM
> might have VIFs on both a "public" and "private" network, with VM
> hosts only on the "private" network.  The firewall VM must be able to
> transmit packets packets with many different source IP addresses
> (enforcing a particular MAC and ARP limits, however, would still be
> fine).
> 
> 2) A common mechanism for primary-secondary failover in some clouds
> is to run two VMs that both provide a particular service and have a
> "fail-over" IP that can float between the two.
> If the secondary fails to get heartbeat responses from the primary,
> it will "steal" the fail-over IP address, for example, using a
> gratuitous ARP with its MAC address for the fail-over IP. This
> technique is definitely common in clouds with per-tenant private 
> network, but I believe it is also supported in some clouds with a
> flatter networking model (in fact, I believe that Rackspace provides
> such a capability: 
> http://cloudservers.rackspacecloud.com/index.php/IP_Failover_-_High_Availability_Explained).

As far as I understand these use cases, Rackspace's IP group
functionality should acommodate both.  Both are essentially about
allowing more than one VM to transmit packets with a given IP, right?

I think what I'm getting at is that I'd much rather have the API exposed
by Nova be rich and flexible enough that theses sort of things can be
exposed there rather than require per-vm tweaking or, even worse,
changing global configuration.

> In this case, limiting a VM to using a single IP for ARP and IP would
> be prohibitive, though MAC filters would be fine.

Certainly. Implementing Rackspace's IP groups would certainly require
changes to the model introduced here.

> 3) The final scenario is a case where customers may want to control
> their own IP addressing, and thus the cloud provider and hypervisor
> layer does not know what IP addresses to enforce for IP / ARP
> traffic.   This applies only in the context of private per-tenant
> network, for example, if a customer wishes to connect a network in
> the cloud to a network on their on premises, or simply wants to use
> the same RFC 1918 space they used in the data center before
> transitioning an app to the cloud.

I'm kind of on the fence on this one. For instance, on the Rackspace
cloud, you get two interfaces: One with a public IP, one with a private
(in the RFC 1918 sense) one. The private interface is not separated from
other users[1], it's simply an extra interface through which you can
reach (I suppose) some internal Rackspace services.

I think it could make good sense to have an API call to create an extra
network with a self-chosen IP-range and have another API call to add an
interface connected to said network to VM's. This part of the API would
only be exposed if the network model had a way to keep users' networks
segregated.

[1]:
http://www.rackspacecloud.com/blog/2010/08/31/private-network-interfaces-the-forgotten-security-hole/

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/