openstack team mailing list archive

[Édouard Thuleau <thuleau@xxxxxxxxx>]

OVS is not compatible with iptables + ebtables rules that are applied
directly on VIF ports.
So the libvirt_vif_driver 'nova.virt.libvirt.vif.LibvirtHybirdOVSBridgeDriver'
create a Linux software bridge to be able to apply security group rules
with iptables.

If you don't need the security group functionalities, you can
use libvirt_vif_driver
'nova.virt.libvirt.vif.LibvirtOpenVswitchVirtualPortDriver'
or 'nova.virt.libvirt.vif.LibvirtOpenVswitchDriver' (depends on your
libvirt version).
http://docs.openstack.org/trunk/openstack-network/admin/content/nova_with_quantum_vifplugging_ovs.html

I think this point must be listed in the limitations page of the OpenStack
Networking Admin guide
http://docs.openstack.org/grizzly/openstack-network/admin/content/ch_limitations.html

Édouard.

On Tue, May 7, 2013 at 2:46 AM, Lorin Hochstein <lorin@xxxxxxxxxxxxxxxxxx>wrote:

> I'm trying to wrap my head around how Quantum works. If understanding
> things correctly, when using the openvswitch plugin, a packet traveling
> from a guest out to the physical switch has to cross two software bridges:
>
> 1. br-int
> 2. br-ethN or br-tun (depending on whether using VLANs or GRE tunnels)
>
> So, I think I understand the motivation behind this: the integration
> bridge handles the rules associated with the virtual networks defined by
> OpenStack users, and the (br-ethN | br-tun) bridge handles the rules
> associated with moving the packets across the physical network.
>
> My question is:  Does having two software bridges in the path incur a
> larger network performance penalty than if there was only a single software
> bridge between the VIF and the physical network interface?
>
> If so, was Quantum implemented this way because it's simply not possible
> to achieve the desired functionality using a single openvswitch bridge, or
> was it because using the dual-bridge approach simplified the
> implementation, or was there some other reason?
>
> Lorin
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>