VLAN aware VM引发的问题
VM能够发送和接收带有VLAN Tag的报文，这种情况叫VLAN aware VM。
一个可以VLAN aware 的VM，意味着它可以接入多个Network(VLAN),如下图所示。
在Neutron模型中并没有VM的概念，而是以Port指代。我们先这样简单的理解port，Port是VM的虚拟网口。在没有引入Trunk Networking特性之前，Neutron的模型设计中有这样的约束：一个Port只能属于一个Network。假设一个VM只有一个Port，如果想让VM具备VLAN aware特性，这就意味着这个Port必须要属于多个network,这与Neutron的约束是矛盾的，如下图：
那么这个问题怎样解决呢？
这里先引入几种不太合适的方案，以此引出TrunkNetworking的设计。
一 一个VM多个Port
一个VM具有多个Port，这个很正常，而且这个方案还不打破Neutron原来的模型和实现方案。如下图：
这个方案几乎完美，但是如果考虑到这样的需求：一个VM需要对接到几百个Network，那么一个VM就需要几百个Port,也就是说需要几百个虚拟网卡，这是不现实的。
二 一个Port对应多个Network
既然需要那么多network,那么我们可以修改一下模型，就让一个Port对应多个Network，而且将VM的虚拟网口（port）设置为“Trunk”模式。如下图所示：
这个方案表面上看没问题，但是还是要考虑具体的实现模型。如果实现模型不改变，还是有一点问题，如下图所示。
计算节点的实现模型中涉及内外VLAN的转换。我们假设这个计算节点中，一开始只有VM1、VM2两个虚拟机。这两个虚拟机的内外VLAN ID如下表：
如果我们不考虑VLAN aware VM特性，这一切都是正常的。内部VLAN只会在Host内局部有效，br-int会保证这些内部VLAN ID不冲突。
此时，如果一个租户创建一个虚拟机VM3，他要求这个VM是VLAN aware的，并且要求这个aware的VLAN ID是：10、11。这样VLAN ID=10就与VM1的内部VLAN ID冲突了，而且这个冲突还非常严重。
1 冲突无法避免：租户并不知道计算节点的内部实现，并不知道他选择的VLAN ID冲突了。而且就算知道了，也可能没办法，他就是需要这个VLAN ID，你说怎么办。
2 冲突难以解决：租户VLAN ID不能更改，只能修改VM1的内部VLAN了，这个修改好像不太可取。
三 VLAN透传
出于各种各样的原因，OVS(Open vSwitch)就不支持VLAN透传特性。Openstack对OVS有很强的依赖性，OVS如果不支持VLAN透传特性，那意味着Neutron试图通过VLAN透传方案解决VLAN aware VM的问题基本宣告失败。