Open Stack

This makes sense.  Thanks for the clarification.

@jay,  As I understand, OVS incompatibility with iptables is not related to
br-tun.   It has more to do with the security groups associated with VM
ports.

-hs




On Thu, Apr 24, 2014 at 1:21 PM, Narasimhan, Vivekanandan <
vivekanandan.narasimhan at hp.com> wrote:

>
>
> I believe the major reason for doing so could be to decouple underlay L2
> technology from
>
> the overlay VM ports themselves.
>
>
>
> The overlay VM ports can continue to plugged with classic VLAN , while the
> underlay L2 technology on how these VMs talk to the
>
> cloud could be dynamically changed.
>
> If the underlay is going to be VLAN, then physical bridges will do traffic
> management.
>
> If the underlay is going to be VXLAN, the tunnel bridge will do traffic
> management.
>
>
>
> Also on a single Compute Node you can have both the underlay technologies
> running, with some tenant VMs running with
>
> VLAN Network Type underlay and some other tenant VMs on the same compute
> node running with VXLAN(or GRE)
>
> Network Type underlay.
>
>
>
> --
>
> Thanks,
>
>
>
> Vivek
>
>
>
> *From:* HS [mailto:hyunseok at ieee.org]
> *Sent:* Thursday, April 24, 2014 8:20 AM
> *To:* openstack at lists.openstack.org
> *Subject:* [Openstack] br-tun and br-int bridges in Neutron OVS
>
>
>
> Hi,
>
> When OVS plugin is used with GRE option in Neutron, I see that each
> compute node has br-tun and br-int bridges created.
>
> I'm trying to understand why we need the additional br-tun bridge here.
> Can't we create tunneling ports in br-int bridge, and have br-int relay
> traffic between VM ports and tunneling ports directly?  Why do we have to
> introduce another br-tun bridge in between?
>
>
>
> Thanks,
>
> -hs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140425/b049c57f/attachment.html>