openstack team mailing list archive

[Lorin Hochstein <lorin@xxxxxxxxxxxxxxxxxx>]

Édouard:

I didn't realize that there's a Linux software bridge inolved when security
groups are enabled.

However, this doesn't really answer my original question. I asked about the
fact that there seemed to be two openvswitch bridges that packets have to
cross to get from the virtual interface (say, vnet0) to the physical
interface (say, eth2) on the host, assuming the openvswitch plugin and
using vlan for transport.

vnet0 <--> br-int <--> br-eth2 <--> eth2.


Based on your answer,  I see that there are actually three bridges that
packets have to traverse when using security groups:

vnet0 <--> qbr???? <--> br-int <--> br-eth2 <--> eth2

Is this view correct? If so, is there a performance penalty (e.g.,
increased latency, reduced bandwidth) for having to cross two Open vSwitch
bridges: br-int and br-eth2?

If there is a penalty, I was curious as to whether this splitting into two
bridges was done because it isn't possible to implement the desired
functionality using a single openvswitch bridge, or if there was some other
reason why it was split out into two (e.g., to simplify the implementation).

Lorin





On Tue, May 7, 2013 at 2:38 AM, Édouard Thuleau <thuleau@xxxxxxxxx> wrote:

> 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
>>
>>
>


-- 
Lorin Hochstein
Lead Architect - Cloud Services
Nimbis Services, Inc.
www.nimbisservices.com