Trunk Networking

为了解决VLAN awre VM的问题，Openstack引入了Trunk Networking方案。

Trunk Networking方案需解决的问题有：

1 VM aware的VLAN ID，在Host内部不能冲突。

2 VM aware的VLAN ID，不需要在Host之间的物理网络透传。

3 不要打破原来的Network、Port的模型，否则会引发Neutron代码大修改。

下面开始介绍Trunk Networking

一 Trunk Networking的实现模型

Neutron引入了一个Trunk Bridge。Trunk Bridge仍然是一个普通的Bridge，只不过是接口模式有所不同。如下图所示：

图中VM1和VM2是普通的VM，它们不需要VLAN aware，所以它们的组网模式没有改变，直接挂接到br-int上，VM3具备VLAN aware特性，Neutron在VM3与br-int之间增加了一层Bridge：br-trunk。br-trunk的特殊之处在于，它的接口都是Trunk/Hybrid模式。这里我们暂且这样理解，实际是Access，后面再修正这个模型。

Neutron利用br-trunk做VLAN ID的转换，就可以解决上述的VLAN ID冲突问题。

如下表所示：

表中，5个内外VLAN ID的转换都在Neutron的掌控内，所以它们的算法可以保证内部VLAN ID不冲突。比如表中第4行，VM3的ware VLAN ID=10被br-trunk转换为内部VLAN ID 1010，这样就避免了内部VLAN ID的冲突。

二 Trunk Networking的资源模型

Neutron新增了一个模型，叫trunk，这个模型里面最核心的就是两个字段：Parent Port和Sub Port List，如下表所示。

这个模型的美妙之处在于不同的视角有不同的解读，而且还解决了各自的问题。

从VM的视角，它仍然相当于一个端口对接多个网络，因为它的端口可以放带VLAN ID的报文，每个VLAN ID对应一个网络。这解决了VM端口不能太多的问题。如下图所示。

注意，一个端口对接多个网络，这仅仅是VM的视角，并不是Neutron模型的视角。从Neutron模型的角度，Trunk模型利用一个Parent Port（对应字段是port_id）和多个Sub Port（对应字段是sub_ports）与不同的Network相对应。Parent Port和Sub Port对应的都是Port模型，它们与Network的关系仍然是一个Port对应一个Network,这一点并没有改变。如下图所示。

图中，P表示Parent Port，S1和S2表示Sub Port。Trunk Networking方案中，通过新增Trunk模型，保证了Network模型与Port模型都没有改变，它们之间的关系也没有改变：1个Port必须属于一个Network，而且只能属于一个Network。