Open Stack

Hi Michael,

Thanks for your reply.  You are right.

I found that from the OpenStack documentation as well:

"Ideally, the TAP device vnet0 would be connected directly to the
integration bridge, br-int. Unfortunately, this isn't possible because of
how OpenStack security groups are currently implemented. OpenStack uses
iptables rules on the TAP devices such as vnet0 to implement security
groups, and Open vSwitch is not compatible with iptables rules that are
applied directly on TAP devices that are connected to an Open vSwitch port."

http://docs.openstack.org/grizzly/openstack-network/admin/content/under_the_hood_openvswitch.html

Thanks again for your clarification.

-Dan




On Tue, Mar 11, 2014 at 10:22 AM, Michael Dorman <mdorman at godaddy.com>wrote:

>  I believe this is so that security groups can be applied using iptables
> on those qbrXXX interfaces.  At least that's how it works in our
> implementation under Havana.
>
>
>   From: Dan Nanni <xmodulo at gmail.com>
> Date: Tuesday, March 11, 2014 8:06 AM
> To: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: [Openstack] Why is Neutron OVS topology the way it is?
>
>    Hi,
>
> I was playing with OpenStack Neutron with OVS plugin. When I launch VMs, I
> noticed that there is a Linux bridge (qbrxxx) created for each VM, which is
> then connected to the OVS bridge (ovs-int). See the following.
>
>         VM0           VM2
>            |                 |
>       qbrXXX        qbrYYY  (per-VM linux bridges)
>            |                 |
>            |                 |
>         br-int (OVS bridge)
>                     |
>                  br-eth
>
> My question is, why couldn't VMs be directly connected to br-int (without
> qbr Linux bridges)? Why do we create additional Linux bridges between OVS
> bridge and VMs? What is the role of Linux bridges here?
>
> Thanks!
> -Dan
>
>


-- 
-Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/1630255a/attachment.html>