一、概述
想必接触过Open stack的人都知道，Opens stack中最复杂的是网络部份，在实际的生产环境中更是如此，实际场景下往往不仅有Open stack网络，还有外部网络（Open stack将其无法管理的网络统称为外部网络），即便在Open stack内部，客户也有不同的网络诉求，本文选取2个案例对常见的网络模型进行说明。
二、案例说明
1.运营商网络和租户网络
Open stack是面向众多租户提供服务的云操作系统，由租户自行创建的网络称为租户网络，但有时候会出现以下这种情况： 
上图是一个租户的VLAN网络，其VID为100，这个网络的计算机并不是虚拟机，即不受Open stack管理，此时该租户需要增加一批虚拟机，而虚拟机VID也必须是100（br-XX转换后的VID），这时Open stack就需要创建一个网络来映射外部网络，创建的这个网络就称为运营商网络。运营商网络可以看成是Open stack网络的外部延展，但其生命周期并不受Neutron组件管理，需要注意的是，创建的网络类型和VID号要和待映射的网络完全一致。运营上网络和租户网络的区别主要表现在以下2点：
（1）管理的权限与角色不同。租户网络由租户自行创建，而运营商网络是由管理员通过administrator账户创建。
（2）创建网络时，传递的参数不同。创建运营商网络时需要传递provider:network_type、provider:physical_network、provider:network_id这3个参数，Open stack认为用户只需要关心服务，所以租户创建网络时不需要传递这3个参数，这3个参数实际上是通过配置文件间接获取。
上文中提到的provider:network_type、provider:network_id好理解，就是对应的网络类型（VLAN或VXLAN）和VID值，但provider:physical_network又起到什么作用？通过上图可以知道，对于非隧道型网络（VLAN）VM在经过br-XX2之后需要转换成待映射网络的VID后就可与外部网络中的物理节点进行通信，但问题是Neutron怎么知br-int必须要将报文发送给br-XX2，此时就需要用到provider:physical_network参数了，因为在配置文件中定义了每个physical_network所对应的物理网卡。对于隧道型网络（VXLAN）这个参数没有什么意义，因为有了目的IP，主机的IP协议栈自己会找到合适的网卡发送出去。
2.VLAN aware VM
在之前的介绍中，VM接受和发送的都是Untag报文，如果这个VM（实际上是VM的vNIC）需要接入多个Vlan中，由于Neutron的资源模型是1个Port只能隶属于1个Network，所以让这1个Port属于多个Network的方法就行不通，而给1个VM配置多个vNIC的方法在VM要接入多个Network的时候（比如1000个Network）就显得不可取，此时就需要VM可以接受和发送带有tag的报文。而根据先前的模型，br-int上的VID是由Open stack自行维护，所有报文必须经过br-int，且VM与br-int之间都是Access接口，一旦将VM与br-int之间的接口改为Trunk，当VM发出带有tag的报文和br-int中的一致时就会造成撞车 
为了解决上述问题，Open stack在N版本之后，就引入了VLAN aware VM模型，它采用1个父端口+多个子端口的方式，将原有的模型改为以下所示： 
图中VM1-1是普通的虚拟机，VM2-1是VLAN aware VM的虚拟机，它是通过在VM和br-int之间加入了1个br-trunk来解决了VID在br-int上撞车的问题，同时Untag的报文走父端口，Tag报文走子接口，有多少个VLAN就有多少个子接口，这样也没有改变Neutron中1个Port属于1个Network的模型，需要注意的是：有多少个VLAN aware VM的虚拟机就有多少个br-trunk虚拟交换机。
原文地址：http://blog.51cto.com/arkling/2296072