盗梦空间之VLAN in VLAN

前言

只要做过软件开发，想必一定听说过“吃狗食”这样的说法，说的就是软件开发者应该使用自己开发的软件，这样便于理解你的系统，从而发现问题并解决问题。

从第一次做SaaS开始，当时还是订阅式经济(Subscription-Economy)方兴未艾的年代，我就被自己写的计费平台每月自动扣费（作为正直的攻城狮，没有给自己留下任何后门），到后来在IBM做OpenStack，可以在自己的OpenStack平台上通过创建All-In-One的虚拟机来获得历史版本产品，均是如此。

在OpenStack的实际应用中，对于非超大规模的环境，VLAN的网络模式是价格便宜量又足，大家都喜欢用。如何利用既有的基于VLAN的OpenStack环境进行OpenStack的深度开发（典型盗梦空间的感觉），核心就是如何才能做到VLAN in VLAN。然而大部分混迹于OpenStack多年的攻城狮们，对于OpenStack VLAN in VLAN（非All-in-one) ，却好像挂在头前的骨头一样，很少有人真正品尝过它的滋味。

来，让我们先展望一下美好的愿景。我们的目标就是在基于VLAN的OpenStack环境中，通过虚拟机，再搭建一个基于VLAN的OpenStack环境。

OpenStack的VLAN网络

首先我们来复习一下OpenStack下的VLAN网络，看看VLAN数据包是如何传递的。这里直接借用OpenStack官方著名的一个图片（原地址已经不可考了）。

在这个场景下，虚拟机的eth1发出的原始数据包在经过br-int，br-eth1后，会被附加上物理环境下的VLAN tag，例如VLAN101，然后交由物理机交换机进行转发。我们可以理解上图为一个OpenStack计算节点物理机的场景。那么我们需要解决的问题就是把其上的虚拟机作为新的OpenStack环境的控制节点，计算节点来部署基于VLAN网络的OpenStack环境。

设想一下把这个结构图缩小，压缩到vm01内，再去想从内到外的网络链路，有没有一种递归堆栈满stack overflow的感觉，瞬间头晕了。结合我们美好的愿景，Inner-VM 的VLAN数据包 在到达 Outer-VM的网卡后，由于是VLAN封包，直接就被抛弃掉了。怎么办？好在天无绝人之路。

相关的解决方案

[VLAN-trunking] (https://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html "VLAN-trunking"), 这个方案不支持VLAN 以及 OVS

[VLAN-aware-VMs] (https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html "VLAN-aware-VMs"), 这个方案的看着不错，但至少我用的版本里面没有，如果要全部merge回来，工作量还好大。

有没有简单粗暴的方案呢，我要的只是能跑起来我自己的环境就好了啊。

曲线救国

自古以来，问题的解决从来都不是只有技术一条路，当技术走不通的时候，我们一样可以从工程学的角度去考虑，甚至可以有更适合当下的方案。不禁想起了用电风扇吹空皂盒（不知道这个梗的同学，自行搜索吧）的故事了。

让我们看看，问题的根源就是tag包不能从虚拟机的网卡发出来，那么虚拟机内的数据网不用OpenStack的网络，直接捅到物理网络上的Trunk网络，来个大大的飞线，不就可以了吗？

在上面的VLAN结构图中，我们知道物理机的eth1是trunk网络，被接到OVS网桥br-eth1上，那么我们让inner-compute1的数据网的数据发送到这里然后通过物理环境的交换机通信，只要两层虚拟化环境的Neutron VLAN range不冲突即可。直接上命令行搞定：

#ip link add name qvb-data type veth peer name qvo-data

#brctl addif br-data qvb-data

#ovs-vsctl add-port br0eth1 qvo-data

#ip link set qvb-data up && ip link set qvo-data up

假设inner-compute1的domain id为10, 直接用virsh命令从物理网桥给它增加一个网卡作为eth1

#virsh attach-interface 10 --type bridge --source br-data --model virtio --current

后续需要解决的问题

这种解决方案是糙快猛的，不需要对原有的代码，结构做改造，只需要从运维的角度做适当的维护。当然糙快猛就意味着存在很多不足的地方，例如：

1. 办公网环境如何访问最内层虚拟机，以及最内层虚拟机如何访问外网，这个可以考虑在inner-controller的本地iptables，route上做手脚，做适当的端口转发。
2. 配置的持久化。可以从功能角度直接支持给虚拟机透传物理网卡，例如Intel 82599支持的SRIOV等。

总结

本文给出了一个实现VLAN in VLAN的短平快的方案，仅从实际的角度出发，利用现有的技术解决实际中的客观的某一个需求，做了一个新的尝试，行文以及技术方面难免有遗漏，欢迎指正。