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/ _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
