← Back to team overview

nova team mailing list archive

Re: Network filtering for libvirt and for non-libvirt hypervisors


On Wed, Sep 15, 2010 at 4:33 AM, Soren Hansen <soren@xxxxxxxxxx> wrote:

> I have a spec[1] and a corresponding branch[2] about making basic use of
> libvirt's nwfilter support. It basically just adds a snippet to the
> libvirt templates that enables a number of network filtering techniques.
> Specifically, it prevents MAC spoofing, ARP spoofing, and IP spoofing. I
> didn't bother making this configurable, since it seems like the sort of
> thing everyone will always want. As such, there's no API call to enable
> it, nor is there a setting in the datamodel that enables/disables it.
Hi Soren,

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:

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
 In this case, limiting a VM to using a single IP for ARP and IP would
prohibitive, though MAC filters would be fine.

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.

In sum, I think there are some compelling reasons to provide the option of
not enforcing a particular IP address in ARP / IP packets sent by a VM.  Off
the top of my head I can't think of such well-known use cases for needing to
disable MAC address spoofing protections (anyone using a VM as an L2 bridge
for transparent IDS?) but I wouldn't be surprised if someone else did.



Dan Wendlandt
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
cell: 650-906-2650

Follow ups